From nobody Thu May 1 01:44: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 2401F1A0773 for ; Thu, 1 May 2014 01:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNGWaZXiu2yI for ; Thu, 1 May 2014 01:43:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C05E1A6EFF for ; Thu, 1 May 2014 01:43:56 -0700 (PDT) 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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140501084356.11041.32880.idtracker@ietfa.amsl.com> Date: Thu, 01 May 2014 01:43:56 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LYOd9KKXJp0Ij1DnAjEOppM1pu0 Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 08:44:01 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-multi-topology for publication", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu May 1 01:58: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 C79241A6F12 for ; Thu, 1 May 2014 01:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5_NVM53acYi for ; Thu, 1 May 2014 01:57:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D261A6F20 for ; Thu, 1 May 2014 01:57:56 -0700 (PDT) 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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140501085756.9464.55996.idtracker@ietfa.amsl.com> Date: Thu, 01 May 2014 01:57:56 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ydORxh9T0u9LCPaqt_XEdZhkJ2Y Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 08:58:02 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-multi-topology for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Thu May 1 04:23: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 BDD8A1A0A17; Wed, 30 Apr 2014 23:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTFzjQ12N6O9; Wed, 30 Apr 2014 23:44:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32F1A0A15; Wed, 30 Apr 2014 23:44:37 -0700 (PDT) Received: from BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) by BLUPR03MB423.namprd03.prod.outlook.com (10.141.78.150) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 06:44:29 +0000 Received: from BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) by BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) with mapi id 15.00.0929.001; Thu, 1 May 2014 06:44:29 +0000 From: Christian Huitema To: "Rajiv Asati (rajiva)" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpH5srRWcQ Date: Thu, 1 May 2014 06:44:29 +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: [24.16.156.113] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(77096999)(87936001)(33646001)(2201001)(19580395003)(85852003)(20776003)(76576001)(15202345003)(46102001)(79102001)(83072002)(101416001)(81342001)(77982001)(92566001)(54356999)(86362001)(50986999)(99396002)(83322001)(80022001)(99286001)(81542001)(74502001)(86612001)(4396001)(80976001)(2656002)(66066001)(31966008)(15975445006)(76176999)(76482001)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB423; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:BCA2C0F5.3EFE1DC9.9D11349.C68AE311.201EE; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-k0AemchxWkUlyKGN_AJmO9SC1A X-Mailman-Approved-At: Thu, 01 May 2014 04:23:33 -0700 Cc: "mpls@ietf.org" Subject: Re: [mpls] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 06:44:42 -0000 > We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 > of [RFC4291]).=20 > > 1. Should/Would they appear in IPv6 routing table? > 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped o= r > treated as a loopback packet, if ever received? > > The answer to Q#1 will help MPLS WG to decide the proper handling of > v4-mapped v6 addresses in LDPv6 draft section 7 1st para. > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * You may want to check RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators. R= FC 6052 updates RFC4291, and lets translators construct domain specific add= resses that can actually be used in the routing tables. It also includes an= answer to your loopback packet question: The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non- global IPv4 address; they MUST drop these packets. -- Christian Huitema From nobody Thu May 1 04:23: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 90B651A0A3C for ; Wed, 30 Apr 2014 23:46:49 -0700 (PDT) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gJxJAygIw-S for ; Wed, 30 Apr 2014 23:46:47 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3E1A0A15 for ; Wed, 30 Apr 2014 23:46:46 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.8]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1WfklV-0006Ph-Va; Thu, 01 May 2014 16:46:42 +1000 User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 01 May 2014 16:46:33 +1000 From: Hesham Soliman To: Mikael Abrahamsson , "Rajiv Asati (rajiva)" Message-ID: Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HB4A2cOqejcT-29QnF0-J6w0Pvg X-Mailman-Approved-At: Thu, 01 May 2014 04:23:33 -0700 Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 06:46:49 -0000 >> >>We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 >> of [RFC4291]). >> >> 1. Should/Would they appear in IPv6 routing table? >> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped >>or >> treated as a loopback packet, if ever received? >> >> The answer to Q#1 will help MPLS WG to decide the proper handling of >> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * >> >> The answer to Q2 will help us assess the efficacy of RFC4379. > >http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 > >I realise this draft seems to have died, but I would never expect to see >packets with these addresses on the wire =3D> I recall an information RFC but don=B9t remember the number. I agree they will most likely not appear on the wire. > or in the routing table =3D> That=B9s a different story. I don=B9t think there is anything banning this, not least due to the fact that it is an implementation issue. If that entry points to an IPv4 tunnel it should be fine. So it is possible to implement a tunnel that way inside the host/router and nothing to stop someone from doing unless I missed an RFC. > and if=20 >they're there, I would want hosts/routers to drop them. =3D> Is that behaviour documented somewhere? Also, you=B9re mixing them appearing on the wire with an internal implementation issue. Hesham >Not doing this=20 >seems to me it would open to all kinds of unwanted consequences when it >comes to filtering etc. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 1 04:23:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F7B1A0A6E for ; Thu, 1 May 2014 00:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 JNx5BK0INfVQ for ; Thu, 1 May 2014 00:12:46 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 005AA1A0A25 for ; Thu, 1 May 2014 00:12:45 -0700 (PDT) Received: (qmail 66636 invoked from network); 1 May 2014 07:12:42 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 1 May 2014 07:12:42 -0000 Date: Thu, 01 May 2014 09:12:42 +0200 (CEST) Message-Id: <20140501.091242.74687867.sthaug@nethelp.no> To: swmike@swm.pp.se From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/tA9dImhU-ljpcdk9AWtdeFvFLlM X-Mailman-Approved-At: Thu, 01 May 2014 04:23:33 -0700 Cc: mpls@ietf.org, v6ops@ietf.org, 6man@ietf.org Subject: Re: [mpls] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 07:12:51 -0000 > http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 > > I realise this draft seems to have died, but I would never expect to see > packets with these addresses on the wire or in the routing table and if > they're there, I would want hosts/routers to drop them. Not doing this > seems to me it would open to all kinds of unwanted consequences when it > comes to filtering etc. On the wire, definitely no. In the routing tables - ::ffff:127.0.0.0 is not expected, but other IPv4-mapped IPv6 address are possible, for instance if you use 6VPE. Steinar Haug, AS 2116 From nobody Thu May 1 04:23: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 DCF971A6F2A for ; Thu, 1 May 2014 01:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtqIyQyanMAL for ; Thu, 1 May 2014 01:59:45 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBD31A6F1B for ; Thu, 1 May 2014 01:59:42 -0700 (PDT) X-Original-To: mpls@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 97B4E62A41 for ; Thu, 1 May 2014 10:59:39 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 61A0962A3E for ; Thu, 1 May 2014 10:59:39 +0200 (CEST) Received: (qmail 66840 invoked by uid 1007); 1 May 2014 10:59:39 +0200 Date: Thu, 1 May 2014 10:59:39 +0200 From: Gert Doering To: "Rajiv Asati \(rajiva\)" Message-ID: <20140501085939.GG43641@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ECiAUR1_WU6faOR3MnsX8OBm0gw X-Mailman-Approved-At: Thu, 01 May 2014 04:23:33 -0700 Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 08:59:46 -0000 Hi, On Thu, May 01, 2014 at 06:08:51AM +0000, Rajiv Asati (rajiva) wrote: > We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 > of [RFC4291]). > > 1. Should/Would they appear in IPv6 routing table? "Yes and no". It depends on the context - if the packet comes in and has an IPv6 header, address lookup happens via the IPv6 routing table. If a packet comes in with an IPv4 header, address lookup happens via the IPv4 routing table. So, IPv4 should never "bleed over" to the IPv6 routing table, but if you happen to receive an IPv6 packet with a destination IPv6 address in it's header of ::ffff:1.2.3.4, you'd either drop it right away, or use the IPv6 routing table to find the destination. The router itself should never ever source packets with a v4-mapped destination address in the packet (see below). > 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or > treated as a loopback packet, if ever received? Dropped. v4-mapped is an internal representation of an IPv4 address recevied on an ipv6 socket, and should never ever appear in packets on the wire. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 1 04:23: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 0BFE91A88EB for ; Thu, 1 May 2014 02:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yua-pRcBMLbF for ; Thu, 1 May 2014 02:02:22 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 942961A88E9 for ; Thu, 1 May 2014 02:02:19 -0700 (PDT) X-Original-To: mpls@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 682F162A49 for ; Thu, 1 May 2014 11:02:17 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 27BD062A3B for ; Thu, 1 May 2014 11:02:17 +0200 (CEST) Received: (qmail 67576 invoked by uid 1007); 1 May 2014 11:02:17 +0200 Date: Thu, 1 May 2014 11:02:17 +0200 From: Gert Doering To: Hesham Soliman Message-ID: <20140501090217.GH43641@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/R3_3YQ6efXFbTf9XJuxfwqDqaJo X-Mailman-Approved-At: Thu, 01 May 2014 04:23:33 -0700 Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 09:02:23 -0000 Hi, On Thu, May 01, 2014 at 04:46:33PM +1000, Hesham Soliman wrote: > >I realise this draft seems to have died, but I would never expect to see > >packets with these addresses on the wire > > => I recall an information RFC but donıt remember the number. I agree they > will most likely not appear on the wire. > > > or in the routing table > > => Thatıs a different story. I donıt think there is anything banning this, If the packets are not going to appear on the wire, argueing about the content of the routing table is a bit... theoretical. I'd argue for internal representations of stuff to not use that format either, as it will just confuse things. The dual-stack API is bad enough for operating system implementors (ran into a bunch of issues with Linux recently) to avoid further use of v4-mapped stuff, anywhere. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 1 05: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 1DF251A6F4D for ; Thu, 1 May 2014 05:37:30 -0700 (PDT) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69CuHREhSXWY for ; Thu, 1 May 2014 05:37:28 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 369521A08C2 for ; Thu, 1 May 2014 05:37:27 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.8]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1WfqEs-0000hA-7Z; Thu, 01 May 2014 22:37:22 +1000 User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 01 May 2014 22:37:12 +1000 From: Hesham Soliman To: Gert Doering Message-ID: Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS References: <20140501090217.GH43641@Space.Net> In-Reply-To: <20140501090217.GH43641@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mqkdb-Gmssp-7nUEDq6p-H4JV98 Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 12:37:30 -0000 >Hi, > >On Thu, May 01, 2014 at 04:46:33PM +1000, Hesham Soliman wrote: >> >I realise this draft seems to have died, but I would never expect to >>see >> >packets with these addresses on the wire >>=20 >> =3D> I recall an information RFC but don=A9=F6t remember the number. I agree >>they >> will most likely not appear on the wire. >>=20 >> > or in the routing table >>=20 >> =3D> That=A9=F6s a different story. I don=A9=F6t think there is anything banning >>this, > >If the packets are not going to appear on the wire, argueing about the >content of the routing table is a bit... theoretical. =3D> Of course it is. In theory we have no business mandating what hosts should do internally, we can discuss best practices ..etc. The question was whether it can happen and it can. Hesham > >I'd argue for internal representations of stuff to not use that format >either, as it will just confuse things. The dual-stack API is bad enough >for operating system implementors (ran into a bunch of issues with Linux >recently) to avoid further use of v4-mapped stuff, anywhere. > >Gert Doering > -- NetMaster >--=20 >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 1 13:46: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 9A5621A0990; Thu, 1 May 2014 13:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx7D12ddkuHm; Thu, 1 May 2014 13:46:49 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C7FAE1A093E; Thu, 1 May 2014 13:46:49 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id fp1so3644114pdb.9 for ; Thu, 01 May 2014 13:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q4FEWSZC9vwYJLDdeQ1/jPvgcYHqofYoJYJ6ed0Jz/w=; b=AsCKhMR9N/AcugBVP+j2w8Ib0E+yd2WpE906gcYhS+WsA6mBsV+WoeU/WW10OTEpbY LJmX0Y+69eWseQrgcEil4wdHzS6gqdgN4ZEDJwsj5u8TGwVgaeTQVVpGBXOsNtLl9nSR 7SGTKWPUG9AT8R3bWsUsw5XpBMIIicOhe1b9O8tWUeyJasKUsZrp02hAeJHkufMdpKxp ZRIMTXutmMLn5V/Q4tnMlELQfUCK3gh9mPgPCVG45KnvNamA+FiwIxD3PmA5R5xrWcOy GQcMf9fBbxaa6/7BeBOFhIKOTaZqupFC86r7WFeOsdzgF4OzsLyXrH+RzPFrMXGeoiLH RGlw== X-Received: by 10.66.146.170 with SMTP id td10mr25414186pab.105.1398977207665; Thu, 01 May 2014 13:46:47 -0700 (PDT) Received: from [192.168.178.20] (234.193.69.111.dynamic.snap.net.nz. [111.69.193.234]) by mx.google.com with ESMTPSA id ss2sm164748278pab.8.2014.05.01.13.46.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 13:46:46 -0700 (PDT) Message-ID: <5362B2BD.7060602@gmail.com> Date: Fri, 02 May 2014 08:46:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <20140501085939.GG43641@Space.Net> In-Reply-To: <20140501085939.GG43641@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mjjqA0vY4D5LNAqdxatfvhvL58M Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:46:51 -0000 On 01/05/2014 20:59, Gert Doering wrote: > Hi, > > On Thu, May 01, 2014 at 06:08:51AM +0000, Rajiv Asati (rajiva) wrote: >> We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 >> of [RFC4291]). >> >> 1. Should/Would they appear in IPv6 routing table? > > "Yes and no". It depends on the context - if the packet comes in and has > an IPv6 header, address lookup happens via the IPv6 routing table. If > a packet comes in with an IPv4 header, address lookup happens via the > IPv4 routing table. > > So, IPv4 should never "bleed over" to the IPv6 routing table, but if > you happen to receive an IPv6 packet with a destination IPv6 address > in it's header of ::ffff:1.2.3.4, you'd either drop it right away, > or use the IPv6 routing table to find the destination. > > The router itself should never ever source packets with a v4-mapped > destination address in the packet (see below). > >> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or >> treated as a loopback packet, if ever received? > > Dropped. v4-mapped is an internal representation of an IPv4 address > recevied on an ipv6 socket, and should never ever appear in packets on > the wire. Nobody seems to have mentioned RFC 4038, which makes this very clear. These addresses are an artefact and have no place in the routing system as such, and still less on the wire. Brian From nobody Thu May 1 13:54: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 8AD651A6FA7; Thu, 1 May 2014 13:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TvX5G1glsY5; Thu, 1 May 2014 13:53:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 269AB1A093E; Thu, 1 May 2014 13:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1739; q=dns/txt; s=iport; t=1398977633; x=1400187233; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=alqSDzlX9MhUwXav2nw6kw4kGN8px33LmluVDrbdgdw=; b=S0BdYAEpDuMZV455Q3iMnhPJK5vNljlgKXuhRFrxIKFJOIIRvulNpJow 3gQ0M/1Edaq1e2E4syXgE22vL4OTuLBa8mfU9ocUgD4qpmpuB7i+bYyjl DVwEAwsNlB6QoFbLl4Pbru8mczVGLXITeBBIy4K5JXelRVVnecp33H9Va o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEizYlOrRDoG/2dsb2JhbABagwZPV8RagRQWdIIlAQEBAwE6PwwEAgEIEQMBAh8QMh0IAgQBDQWIOQcBDcluF45SBwaEMwEDhFmUVoE8kTKDM4Ir X-IronPort-AV: E=Sophos;i="4.97,966,1389744000"; d="scan'208";a="109108251" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 01 May 2014 20:53:52 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s41Krptj019847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 20:53:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 1 May 2014 15:53:50 -0500 From: "Rajiv Asati (rajiva)" To: Christian Huitema , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpH5srRWcQgAEANQA= Date: Thu, 1 May 2014 20:53:49 +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.3.9.131030 x-originating-ip: [10.82.218.19] 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/O-SFpU26yqnE9SEmeb20TnqNMBo Cc: "mpls@ietf.org" Subject: Re: [mpls] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:53:56 -0000 Hi Christian, Thanks for the pointer. WKPs surely qualify to be in in the RIB/FIB and label allocations.=20 However, v4-mapped v6 addresses are not used by RFC 6052. :o =20 --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: Christian Huitema Date: Thursday, May 1, 2014 at 2:44 AM To: Rajiv Asati , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Cc: "mpls@ietf.org" Subject: RE: Q about IPv4-mapped IPv6 address & MPLS >> We need your guidance on handling v4-mapped v6 addresses (section >>2.5.5.2 >> of [RFC4291]).=20 >> >> 1. Should/Would they appear in IPv6 routing table? >> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped >>or >> treated as a loopback packet, if ever received? >> >> The answer to Q#1 will help MPLS WG to decide the proper handling of >> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * > >You may want to check RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators. >RFC 6052 updates RFC4291, and lets translators construct domain specific >addresses that can actually be used in the routing tables. It also >includes an answer to your loopback packet question: > > The Well-Known Prefix MUST NOT be used to represent non-global IPv4 > addresses, such as those defined in [RFC1918] or listed in Section 3 > of [RFC5735]. Address translators MUST NOT translate packets in > which an address is composed of the Well-Known Prefix and a non- > global IPv4 address; they MUST drop these packets. > >-- Christian Huitema > > > From nobody Thu May 1 15:20: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 CA6301A0948; Thu, 1 May 2014 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6a3X7n5ZGhr; Thu, 1 May 2014 15:20:22 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5837D1A06DB; Thu, 1 May 2014 15:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1520; q=dns/txt; s=iport; t=1398982820; x=1400192420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=k4S/nS0HaDlaEU0x2uJcZ98uVGbisT63Zg6f8W/d8qc=; b=LUJJBZHVxCSUVfdN0YGrobWgpYPJzdaPKsFuSCFYWOZSvOzAJbI8mO/+ FsGk4OfA7KwRtL1vwzBIZ4PMTQ6+4yQIIyFp/4UNuTZrdxbSBGSCs6o25 Sexfi0uYS1jihnH8nGaRfQ9Hrtw2qFLPp9OmJjvNKMYmxzWVcRbFkECmR I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACTIYlOtJA2D/2dsb2JhbABagwZPvXOHPoEUFnSCJQEBAQMBAQEBawsFCwIBCBguJwslAgQOBYg5CA3JaBeOUgeDJIEVBIlMj2OBPJEygzM X-IronPort-AV: E=Sophos;i="4.97,967,1389744000"; d="scan'208";a="321837749" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 01 May 2014 22:20:20 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s41MKJO7032112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 22:20:19 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 1 May 2014 17:20:19 -0500 From: "Rajiv Asati (rajiva)" To: Simon Perreault Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZYHVKyuQb1xSnUicpDemuoOtD5ssTA69 Date: Thu, 1 May 2014 22:20:19 +0000 Message-ID: References: ,<5362B83F.4020808@per.reau.lt> In-Reply-To: <5362B83F.4020808@per.reau.lt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/eFv_NKeCgskzHmJLzZo91lJ193o Cc: "mpls@ietf.org" , "v6ops@ietf.org" , 6man WG Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:20:23 -0000 Hi Simon, Ditto. This is what I was about to suggest for Q#1. Thanks.=20 I wish there was something like that for ospfv3, isis, rip, BGP etc. too.=20 Cheers, Rajiv > On May 1, 2014, at 5:10 PM, "Simon Perreault" wrote: >=20 > Le 2014-05-01 02:08, Rajiv Asati (rajiva) a =E9crit : >> The answer to Q#1 will help MPLS WG to decide the proper handling of >> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * >=20 > Rajiv, >=20 > In addition to what the others have said, to provide very precise > guidance, I think this text in your draft... >=20 > An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings > for link-local IPv6 address, and ignore such bindings, if ever > received. An LSR MUST treat the IPv4-mapped IPv6 address, defined in > section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 > address and not mix it with the 'corresponding' IPv4 address. >=20 > ...should be changed to: >=20 > An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings > for link-local or IPv4-mapped IPv6 address, and ignore such > bindings, if ever received. >=20 > Simon >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu May 1 15:21: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 BD3911A0948; Thu, 1 May 2014 15:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGou2mUIlS-b; Thu, 1 May 2014 15:21:29 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id EE7331A09C3; Thu, 1 May 2014 15:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1716; q=dns/txt; s=iport; t=1398982884; x=1400192484; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=myYq2XzCSmfR0qTQjRtA3D652avJA/7IdtRy07C9q9c=; b=NxfuQKN55d1iNsknSrfUoa05TsgBXINv8Di+Ia0grH1+4KKCBcMJ0UjR z5l7UGgQARY7QZNO0v6juLiA3Rz3VEtLAj8iaCYuYfXJvYHvTSJs+J/FR 7VGD/A/LMmEWh3J4YCdAAZJx72n7rl1+dVt9FAm5GysHxYp0Ym/dAzmt7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK/HYlOtJA2N/2dsb2JhbABagwbGAIEUFnSCJQEBAQMBOj8FCwIBCBgeECERJQIEDgWILQMJCMMiDYZFF4w7gWQzB4MkgRUBA5c9gXKNE4VbgzM X-IronPort-AV: E=Sophos;i="4.97,967,1389744000"; d="scan'208";a="40393657" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 01 May 2014 22:21:23 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s41MLNSx024751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 22:21:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 1 May 2014 17:21:23 -0500 From: "Rajiv Asati (rajiva)" To: Brian E Carpenter Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZRuxmza+wZtqAkG9xRAfqumSLZsshpGA///GlVc= Date: Thu, 1 May 2014 22:21:22 +0000 Message-ID: References: <20140501085939.GG43641@Space.Net>,<5362B2BD.7060602@gmail.com> In-Reply-To: <5362B2BD.7060602@gmail.com> 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/BgkWGLVloe-LkPyxUAP7EY9-5ZU Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Gert Doering Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:21:30 -0000 Thanks, Brian. Which RFC 4038 section in particular should be referenced to= ? Cheers, Rajiv > On May 1, 2014, at 4:47 PM, "Brian E Carpenter" wrote: >=20 >> On 01/05/2014 20:59, Gert Doering wrote: >> Hi, >>=20 >>> On Thu, May 01, 2014 at 06:08:51AM +0000, Rajiv Asati (rajiva) wrote: >>> We need your guidance on handling v4-mapped v6 addresses (section 2.5.5= .2 >>> of [RFC4291]).=20 >>>=20 >>> 1. Should/Would they appear in IPv6 routing table? >>=20 >> "Yes and no". It depends on the context - if the packet comes in and ha= s >> an IPv6 header, address lookup happens via the IPv6 routing table. If=20 >> a packet comes in with an IPv4 header, address lookup happens via the >> IPv4 routing table. =20 >>=20 >> So, IPv4 should never "bleed over" to the IPv6 routing table, but if=20 >> you happen to receive an IPv6 packet with a destination IPv6 address >> in it's header of ::ffff:1.2.3.4, you'd either drop it right away, >> or use the IPv6 routing table to find the destination. >>=20 >> The router itself should never ever source packets with a v4-mapped >> destination address in the packet (see below). >>=20 >>> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped= or >>> treated as a loopback packet, if ever received? >>=20 >> Dropped. v4-mapped is an internal representation of an IPv4 address >> recevied on an ipv6 socket, and should never ever appear in packets on >> the wire. >=20 > Nobody seems to have mentioned RFC 4038, which makes this very clear. > These addresses are an artefact and have no place in the routing > system as such, and still less on the wire. >=20 > Brian >=20 From nobody Thu May 1 15:23: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 721041A6FD1; Thu, 1 May 2014 15:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqWOY5IsAyC6; Thu, 1 May 2014 15:23:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AEDAC1A09FD; Thu, 1 May 2014 15:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1486; q=dns/txt; s=iport; t=1398983002; x=1400192602; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=96vsd51YQJo+TPtRwY3YG0Z6Lb+rTV+ilM9D0NirNpM=; b=Ee4z89Vx/aT0/I3insgTNdEk+3UyKPW2S70UfYAij50jTQl5s0K9egCm I7sFlzuWRpMqP6EH8xzV83nJDASwtHJgcvpRjzo/UZLhrOhafSWOwlAhx DY9LGjBihDHS4UbYGgUoGHBW2f75Gm/LBBbel8NQ8ZQ+K+LRu7l8yvnah Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAjJYlOtJA2G/2dsb2JhbABagwbGAIEUFnSCJQEBAQMBeQULAgEIGC4yJQIEDgWIOQjJdReOHzMHgySBFQSJTI9jkm6DMw X-IronPort-AV: E=Sophos;i="4.97,967,1389744000"; d="scan'208";a="318773423" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 01 May 2014 22:23:21 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s41MNLZ2028760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 22:23:21 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 1 May 2014 17:23:20 -0500 From: "Rajiv Asati (rajiva)" To: Gert Doering Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQkfIYq9UHb5jEKNapytnrV9qJsrwdmAgACL/+k= Date: Thu, 1 May 2014 22:23:21 +0000 Message-ID: References: ,<20140501090217.GH43641@Space.Net> In-Reply-To: <20140501090217.GH43641@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/z1I-qw4dSZog-OZ9dCqlA3Ywmuo Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Hesham Soliman Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:23:25 -0000 I wish there was a document stating this. It would help to refine the proto= col behavior.=20 Cheers, Rajiv > On May 1, 2014, at 5:02 AM, "Gert Doering" wrote: >=20 > Hi, >=20 > On Thu, May 01, 2014 at 04:46:33PM +1000, Hesham Soliman wrote: >>> I realise this draft seems to have died, but I would never expect to se= e >>> packets with these addresses on the wire >>=20 >> =3D> I recall an information RFC but don=B9t remember the number. I agre= e they >> will most likely not appear on the wire. >>=20 >>> or in the routing table >>=20 >> =3D> That=B9s a different story. I don=B9t think there is anything banni= ng this, >=20 > If the packets are not going to appear on the wire, argueing about the > content of the routing table is a bit... theoretical. >=20 > I'd argue for internal representations of stuff to not use that format > either, as it will just confuse things. The dual-stack API is bad enough > for operating system implementors (ran into a bunch of issues with Linux > recently) to avoid further use of v4-mapped stuff, anywhere. >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 1 16:00: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 3458C1A09FA; Thu, 1 May 2014 16:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0crbun9m1HHn; Thu, 1 May 2014 16:00:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id 851A81A0986; Thu, 1 May 2014 16:00:18 -0700 (PDT) Received: from BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) by BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 23:00:15 +0000 Received: from BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) by BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) with mapi id 15.00.0929.001; Thu, 1 May 2014 23:00:15 +0000 From: Christian Huitema To: "Rajiv Asati (rajiva)" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpH5srRWcQgAEANQCAABITAA== Date: Thu, 1 May 2014 23:00:15 +0000 Message-ID: <85910072e0794eae8149ba10ff933c58@BLUPR03MB424.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(86362001)(81542001)(76482001)(4396001)(86612001)(77982001)(81342001)(87936001)(101416001)(33646001)(92566001)(2656002)(558084003)(46102001)(83072002)(83322001)(31966008)(80022001)(20776003)(85852003)(80976001)(2201001)(74502001)(99396002)(79102001)(50986999)(76576001)(77096999)(76176999)(74316001)(99286001)(54356999)(74662001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB424; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:BF12F1BD.36B147A3.39E38DCF.C4CE9E18.20082; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RmRJh_04HiDiRhbl5-HG-YaIXZA Cc: "mpls@ietf.org" Subject: Re: [mpls] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:00:21 -0000 > However, v4-mapped v6 addresses are not used by RFC 6052. :o =20 That's intentional. The short answer is that you should not use them, and y= ou should not place them in the routing tables. -- Christian Huitema From nobody Thu May 1 16:19: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 C5E021A882B; Thu, 1 May 2014 16:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI4kly5hdEFs; Thu, 1 May 2014 16:18:56 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id DE5411A8829; Thu, 1 May 2014 16:18:55 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id ld10so4384151pab.40 for ; Thu, 01 May 2014 16:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E8J5t2zwBb7fIQheP/TNx4iWEF6ghG08CIDi8SUWrRA=; b=Kql3njOjXa1/zkBTtQIWvyEDFtUK+kOnzAFYRc5I1NgQeWmTEow3IvwP3r0oYT5KX5 bsGHIlAfW11yAhqY7VOy939+24A5l3wFWyazNPtzfrYhsehivNvw4S50tiaKBhFCbzkV dE7sP95EKquEU/cnpM4flvmwKZY+LOHO9QOSZS1lTIg5x1y1D1VEvyrYmYsTEZuMmMQK gGC8b+Ju0d87WpMGgs5Uu/t4vzpI2qGMfGBbwP7xPg1EO2K1uEF6xtGVyTKLQd8+ZJji GQLnhcvOQHTftmXvyoOZSoB+5Fh0h7SFUg0xuKnSk9f7NfxUavLYIgNsnkMJlqUpG88z no9Q== X-Received: by 10.66.153.80 with SMTP id ve16mr26839745pab.143.1398986333809; Thu, 01 May 2014 16:18:53 -0700 (PDT) Received: from [192.168.178.20] (234.193.69.111.dynamic.snap.net.nz. [111.69.193.234]) by mx.google.com with ESMTPSA id vx10sm167396420pac.17.2014.05.01.16.18.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 16:18:53 -0700 (PDT) Message-ID: <5362D663.7090501@gmail.com> Date: Fri, 02 May 2014 11:18:59 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <20140501085939.GG43641@Space.Net>, <5362B2BD.7060602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vYjJVUy5VYfFDO_jI1Bkx7tjexc Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Gert Doering Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:18:59 -0000 On 02/05/2014 10:21, Rajiv Asati (rajiva) wrote: > Thanks, Brian. Which RFC 4038 section in particular should be referenced to? I think section 4.2. "IPv6 Applications in a Dual-Stack Node". It has a diagram that very clearly shows that packets that are "decorated" inside the host with an IPv4-mapped address are sent or received as native IPv4 packets. It's an Informational RFC but even so it seem to be the authoritative text in this case. Brian > Cheers, > Rajiv > >> On May 1, 2014, at 4:47 PM, "Brian E Carpenter" wrote: >> >>> On 01/05/2014 20:59, Gert Doering wrote: >>> Hi, >>> >>>> On Thu, May 01, 2014 at 06:08:51AM +0000, Rajiv Asati (rajiva) wrote: >>>> We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 >>>> of [RFC4291]). >>>> >>>> 1. Should/Would they appear in IPv6 routing table? >>> "Yes and no". It depends on the context - if the packet comes in and has >>> an IPv6 header, address lookup happens via the IPv6 routing table. If >>> a packet comes in with an IPv4 header, address lookup happens via the >>> IPv4 routing table. >>> >>> So, IPv4 should never "bleed over" to the IPv6 routing table, but if >>> you happen to receive an IPv6 packet with a destination IPv6 address >>> in it's header of ::ffff:1.2.3.4, you'd either drop it right away, >>> or use the IPv6 routing table to find the destination. >>> >>> The router itself should never ever source packets with a v4-mapped >>> destination address in the packet (see below). >>> >>>> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or >>>> treated as a loopback packet, if ever received? >>> Dropped. v4-mapped is an internal representation of an IPv4 address >>> recevied on an ipv6 socket, and should never ever appear in packets on >>> the wire. >> Nobody seems to have mentioned RFC 4038, which makes this very clear. >> These addresses are an artefact and have no place in the routing >> system as such, and still less on the wire. >> >> Brian >> > . > From nobody Fri May 2 05:19: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 BC2DA1A06DB; Thu, 1 May 2014 15:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXM7UiMTaTHl; Thu, 1 May 2014 15:53:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 739241A09B8; Thu, 1 May 2014 15:53:29 -0700 (PDT) Received: from [10.5.16.141] (adsl-69-228-81-237.dsl.pltn13.pacbell.net [69.228.81.237]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s41MoxI2027613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 15:51:00 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s41MoxI2027613 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1398984668; bh=s/p5JdKTZkmXXHVyAP7o24EKXZg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=1HIL8aJbARsPdUde/tN3ZJQ+NYbjdZc+4C4Rrz3yiP2WP7QuhO8tq9eCiyLKwQOR/ jaBlI2ECfYVrLpIcbY2l1PRFolk2xgH9oGdCu9ZmbfMKCsIsTFsvS7kR8og9ipqTXz 48WTF+Dn7gmRl3dbI7tzGrl14oqlvbniUB89t+HA= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Thu, 1 May 2014 15:50:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52768D51-C3DB-4EE8-BBDA-C54CF5027F27@delong.com> References: , <5362B83F.4020808@per.reau.lt> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 01 May 2014 15:51:08 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OfBmnJBbzLd_LBpO03i9-TUVkvE X-Mailman-Approved-At: Fri, 02 May 2014 05:19:45 -0700 Cc: Simon Perreault , "v6ops@ietf.org" , 6man WG , "mpls@ietf.org" Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:53:30 -0000 I like this proposed change as well. Owne On May 1, 2014, at 3:20 PM, Rajiv Asati (rajiva) = wrote: > Hi Simon, >=20 > Ditto. This is what I was about to suggest for Q#1. Thanks.=20 >=20 > I wish there was something like that for ospfv3, isis, rip, BGP etc. = too.=20 >=20 > Cheers, > Rajiv >=20 >> On May 1, 2014, at 5:10 PM, "Simon Perreault" = wrote: >>=20 >> Le 2014-05-01 02:08, Rajiv Asati (rajiva) a =E9crit : >>> The answer to Q#1 will help MPLS WG to decide the proper handling of >>> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >>> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * >>=20 >> Rajiv, >>=20 >> In addition to what the others have said, to provide very precise >> guidance, I think this text in your draft... >>=20 >> An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings >> for link-local IPv6 address, and ignore such bindings, if ever >> received. An LSR MUST treat the IPv4-mapped IPv6 address, defined in >> section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 >> address and not mix it with the 'corresponding' IPv4 address. >>=20 >> ...should be changed to: >>=20 >> An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings >> for link-local or IPv4-mapped IPv6 address, and ignore such >> bindings, if ever received. >>=20 >> Simon >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri May 2 05:19: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 422861A7D81; Thu, 1 May 2014 14:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tSDUeGsRvbXR; Thu, 1 May 2014 14:10:27 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 444661A0971; Thu, 1 May 2014 14:10:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:ada6:3fa9:d0fd:fbe0]) by nomis80.org (Postfix) with ESMTPSA id 97BCC10EAB; Thu, 1 May 2014 21:10:45 +0000 (UTC) Message-ID: <5362B83F.4020808@per.reau.lt> Date: Thu, 01 May 2014 17:10:23 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PkSNZVY1oB2uZ-vtXiUKwQZsrTc X-Mailman-Approved-At: Fri, 02 May 2014 05:19:54 -0700 Cc: mpls@ietf.org, 6man WG Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 21:10:36 -0000 Le 2014-05-01 02:08, Rajiv Asati (rajiva) a écrit : > The answer to Q#1 will help MPLS WG to decide the proper handling of > v4-mapped v6 addresses in LDPv6 draft section 7 1st para. > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * Rajiv, In addition to what the others have said, to provide very precise guidance, I think this text in your draft... An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings for link-local IPv6 address, and ignore such bindings, if ever received. An LSR MUST treat the IPv4-mapped IPv6 address, defined in section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 address and not mix it with the 'corresponding' IPv4 address. ...should be changed to: An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings for link-local or IPv4-mapped IPv6 address, and ignore such bindings, if ever received. Simon From nobody Fri May 2 06:52: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 5B3A41A6F71; Fri, 2 May 2014 06:52:43 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: \342rtg-ads@tools.i[...] X-Spam-Flag: NO X-Spam-Score: 0.256 X-Spam-Level: X-Spam-Status: No, score=0.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 cL17ZLTosZAR; Fri, 2 May 2014 06:52:41 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5974E1A0816; Fri, 2 May 2014 06:52:41 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s42DqQOD016237; Fri, 2 May 2014 22:52:26 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B8341E0176; Fri, 2 May 2014 22:52:26 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id AC237E016C; Fri, 2 May 2014 22:52:26 +0900 (JST) Received: from [IPv6:::1] (panasonic.nslab.ecl.ntt.co.jp [129.60.85.25]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s42DqJqR009999; Fri, 2 May 2014 22:52:26 +0900 Message-ID: <5363A354.8090007@lab.ntt.co.jp> Date: Fri, 02 May 2014 22:53:24 +0900 From: Tomonori Takeda User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja-JP; rv:1.9.2.15) Gecko/20110323 Lanikai/3.1.9 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit To: ârtg-ads@tools.ietf.org X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vgLFdxpAYugVl7rAxQ8EYOov93U Cc: mpls@ietf.org, ârtg-dir@ietf.org, draft-ietf-mpls-extended-admin-group.all@tools.ietf.org Subject: [mpls] RtgDir review: draft-ietf-mpls-extended-admin-group-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, 02 May 2014 13:52:43 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-extended-admin-group-06.txt Reviewer: Tomonori Takeda Review Date: 2 May 2014 IETF LC End Date: 6 May 2014 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document is short, clearly written and easy to understand. This document writes protocol extensions for OSPF-TE and ISIS-TE, which is straight-forward. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: o Abstract It says: "the Administrative Group sub-TLV of the Link TLV" Precisely speaking, I think this should be: "the Administrative Group sub-TLV of the Link TLV for OSPFv2/OSPFv3 and of the Extended IS Reachability TLV for ISIS" Or this could simply be: "the Administrative Group sub-TLV" o Section 1, 3rd paragraph s/vaues/values o Section 2 "This document defines a sub-TLV of the Link TLV for both OSPF [RFC3630] and ISIS [RFC5305] ... " Same as above (comment for Abstract). o Section 2.2 "the existing Administrative Group TLVs" should be: "the existing Administrative Group sub-TLVs". o Section 2.3.2, 3rd paragraph "as the assumption is than an unadvertised bit is set to 0" I guess "than" should be "that". Thanks, Tomonori Takeda From nobody Fri May 2 08:32: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 D8E1F1A0A0D for ; Fri, 2 May 2014 08:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-DxsYib829u for ; Fri, 2 May 2014 08:32:50 -0700 (PDT) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by ietfa.amsl.com (Postfix) with ESMTP id 313871A08F4 for ; Fri, 2 May 2014 08:32:50 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so3949170ykp.18 for ; Fri, 02 May 2014 08:32:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tjEtEW5c6m69TZNpPeo+UA4onBgqpgO6vwwsVgTGAL0=; b=f4iDUY2WSJgaicAQ4N8KZoxC4NozVMNenPkfwmZU3d7Vd+DpiKn8ihoxv852yQLDQI IXduZZRChTdiMJwQUWspCAz6GE+/yXlyljWGSXU4KtzTtt95f7nh/1nwpnU6equQNLzv cyCNMlyY08zv+1p3nZgw8CW8+05O3SMcOUn8Km30EdxCKSa2Q+BObEolB0T2m2opLH3c L5FDsZJlWuEPetRvGWN63j5Es16Cn9i0aPL7ds+io16bCGw1hbvOsId84hJ7a7RWzNRu jOKM0ZJgTDziOng/nmk4+9x4Vocz14hl4oQYzlom6T8NqgkPeQ+HmPMjuKRZBV7C5e/V 1mYA== X-Gm-Message-State: ALoCoQmF6DyU7EbKli6GfJg7WIJiQp/KHLDWIa6y0EvFfhBXPJy9S2KXlDUGYPcqL5E2cgv9dI/D MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr23978829yhj.63.1399044767792; Fri, 02 May 2014 08:32:47 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Fri, 2 May 2014 08:32:47 -0700 (PDT) In-Reply-To: <5363A354.8090007@lab.ntt.co.jp> References: <5363A354.8090007@lab.ntt.co.jp> Date: Fri, 2 May 2014 11:32:47 -0400 Message-ID: From: Eric Osborne To: Tomonori Takeda Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9cHEXSGUQIEH7OvwYMGcsS0rDh8 Cc: "mpls@ietf.org" , "draft-ietf-mpls-extended-admin-group.all@tools.ietf.org" , b4a99d417be785e4.invalid@internationalized.invalid, d586783d77c2558c.invalid@internationalized.invalid Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-extended-admin-group-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, 02 May 2014 15:32:52 -0000 Thanks! Do I need to fix these and post a new version, or will the RFC Editor take care of them? eric On Fri, May 2, 2014 at 9:53 AM, Tomonori Takeda wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-mpls-extended-admin-group-06.txt > Reviewer: Tomonori Takeda > Review Date: 2 May 2014 > IETF LC End Date: 6 May 2014 > Intended Status: Standards Track > > > Summary: > This document is basically ready for publication, but has nits that should > be considered prior to publication. > > Comments: > This document is short, clearly written and easy to understand. > This document writes protocol extensions for OSPF-TE and ISIS-TE, which is > straight-forward. > > Major Issues: > No major issues found. > > Minor Issues: > No minor issues found. > > Nits: > > o Abstract > It says: > "the Administrative Group sub-TLV of the Link TLV" > Precisely speaking, I think this should be: > "the Administrative Group sub-TLV of the Link TLV for OSPFv2/OSPFv3 > and of the Extended IS Reachability TLV for ISIS" > Or this could simply be: > "the Administrative Group sub-TLV" > > o Section 1, 3rd paragraph > s/vaues/values > > o Section 2 > "This document defines a sub-TLV of the Link TLV for both OSPF > [RFC3630] and ISIS [RFC5305] ... " > Same as above (comment for Abstract). > > o Section 2.2 > "the existing Administrative Group TLVs" should be: > "the existing Administrative Group sub-TLVs". > > o Section 2.3.2, 3rd paragraph > "as the assumption is than an unadvertised bit is set to 0" > I guess "than" should be "that". > > Thanks, > Tomonori Takeda > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri May 2 09:27: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 DB8B61A6F7D for ; Fri, 2 May 2014 09:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hSWF_63CjDJ for ; Fri, 2 May 2014 09:27:26 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id F13E71A09E8 for ; Fri, 2 May 2014 09:27:25 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s42GRMj3030018; Fri, 2 May 2014 17:27:22 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s42GRJG3029952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 May 2014 17:27:19 +0100 From: "Adrian Farrel" To: "'Eric Osborne'" References: <5363A354.8090007@lab.ntt.co.jp> In-Reply-To: Date: Fri, 2 May 2014 17:27:13 +0100 Message-ID: <00e701cf6623$61a58640$24f092c0$@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: AQJye/S6xJdUmuMKtd5az86pvO02TgDN4p+6meDedfA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20670.000 X-TM-AS-Result: No--5.301-10.0-31-10 X-imss-scan-details: No--5.301-10.0-31-10 X-TMASE-MatchedRID: pBwXUM+nCws4HKI/yaqRm5dc7I2df+mswx0jRRxcQfO4Kkg59mswF9Iv 7YBYphkjAvs4cyNxHzZZ94mCPwoGbkoW1fqT8MhScFEiuPxHjsUhmbYg1ZcOnjASEdbkpUDP876 azl5+m3vi8zVgXoAltlwtzewu2M63tuZmiwj/lnLdB/CxWTRRu4as+d5/8j56VP+JldPPA5cq/r 267zFzW6C1OcAxeD0ytO+ARCAIcCDh5kunxtNT9A== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2ppXOfIV3uQQPqxW1mvXO4GupqY Cc: mpls@ietf.org, draft-ietf-mpls-extended-admin-group.all@tools.ietf.org Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-extended-admin-group-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:27:28 -0000 Hi Eric, > Do I need to fix these and post a new version, or will the RFC Editor > take care of them? I think there are sufficient in the list that it is worth tidying up. Like Loa said wrt the GenArt review, last call ends on the 6th and other reviews might arrive before then. But the document looks pretty stable. You choice to post a new I-D now or wait until the end of last call. I've put the document on the next IESG telechat (15th May) anyway. Cheers, Adrian From nobody Mon May 5 14:06: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 559471A041B for ; Mon, 5 May 2014 14:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 bQ7EHQqGwnOD for ; Mon, 5 May 2014 14:06:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 784EA1A01C1 for ; Mon, 5 May 2014 14:06:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDV77552; Mon, 05 May 2014 21:06:11 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 22:04:36 +0100 Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 22:06:08 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML701-CHM.china.huawei.com ([169.254.3.206]) with mapi id 14.03.0158.001; Mon, 5 May 2014 14:06:02 -0700 From: Huaimo Chen To: Autumn Liu , Yimin Shen , "Ross Callon" , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaKXRNui9++LYwkadb4wi40bsvQ== Date: Mon, 5 May 2014 21:06:01 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C66B35@SJCEML703-CHM.china.huawei.com> References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.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.212.244.239] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C66B35SJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PanN9yjbdYikRlbAcck3fzXIQ5k Subject: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 21:06:20 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C66B35SJCEML703CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-chen-mpls-p2mp-egress-protection@tool= s.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_5316A0AB3C851246A7CA5758973207D445C66B35SJCEML703CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Autumn,

 <= /p>

Can you elaborate a little bit on “the egress protection of p2p LSP needs to be addressed specifically with the draft.&#= 8221;?

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; draft-chen-mpls-p2mp-egress-protecti= on@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

 <= /p>

I am ok with the name cha= nge, and agree with Yimin that the egress protection of p2p LSP needs to be= addressed specifically with the draft.

-Autumn=

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

Hi chairs, authors,<= /o:p>

 <= /p>

To help make this draft m= ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe= rentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed= by inner labels (i.e. service labels).

 <= /p>

Of course, a complete sol= ution for P2P LSP egress protection will require extensions to Layer-2/3 VP= N service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have = already been addressed by some existing IETF work and drafts, this draft co= uld refer to them in the text.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 

--_000_5316A0AB3C851246A7CA5758973207D445C66B35SJCEML703CHMchi_-- From nobody Tue May 6 02:22: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 AAA241A0786; Tue, 6 May 2014 02:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EijyzygjyX8B; Tue, 6 May 2014 02:22:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5691A0157; Tue, 6 May 2014 02:22:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140506092220.4437.52081.idtracker@ietfa.amsl.com> Date: Tue, 06 May 2014 02:22:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IpPVX24M2NmBsrz4g8A6GxjTVoo Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-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: Tue, 06 May 2014 09:22:21 -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 Hello Cryptographic Authentication Authors : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-05.txt Pages : 14 Date : 2014-05-06 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-hello-crypto-auth-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 Tue May 6 02:56:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03FF1A0659 for ; Tue, 6 May 2014 02:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 81OEwmIBmw6m for ; Tue, 6 May 2014 02:56:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC2AC1A029B for ; Tue, 6 May 2014 02:56:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGL36330; Tue, 06 May 2014 09:56:39 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 May 2014 10:55:21 +0100 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 May 2014 10:56:35 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.15]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Tue, 6 May 2014 17:56:33 +0800 From: Vero Zheng To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: New Version Notification - draft-ietf-mpls-ldp-hello-crypto-auth-05.txt Thread-Index: AQHPaQy4Ph0YQrhbOkujU3NXAT3IDJszSH5Q Date: Tue, 6 May 2014 09:56:33 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8108B5@SZXEMA504-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] 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/uzTy0tbHLlZvjNdsIEtWoEJu_2U Subject: [mpls] FW: New Version Notification - draft-ietf-mpls-ldp-hello-crypto-auth-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: Tue, 06 May 2014 09:56:46 -0000 SGVsbG8gQWRyaWFuLA0KDQpUaGFua3MgYWdhaW4gZm9yIHlvdXIgQUQgcmV2aWV3IG9uIGRyYWZ0 LWlldGYtbXBscy1sZHAtaGVsbG8tY3J5cHRvLWF1dGguDQpBIG5ldyB2ZXJzaW9uIGhhcyBiZWVu IHN1Ym1pdHRlZC4gSSBiZWxpZXZlIGl0IGFkZHJlc3NlZCBtb3N0IG9mIHlvdXIgcmV2aWV3IGNv bW1lbnRzLg0KDQpDaGVlcnMsIFZlcm8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBUdWVzZGF5LCBNYXkgMDYsIDIwMTQgNToyMiBQTQ0KVG86IG1wbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRo QHRvb2xzLmlldGYub3JnOyBhZHJpYW5Ab2xkZG9nLmNvLnVrDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoLTA1 LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gKC0wNSkgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBkcmFm dC1pZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC0wNS50 eHQNCg0KU3ViIHN0YXRlIGhhcyBiZWVuIGNoYW5nZWQgdG8gQUQgRm9sbG93dXAgZnJvbSBSZXZp c2VkIElEIE5lZWRlZA0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHBhZ2UgZm9yIHRoaXMgSW50 ZXJuZXQtRHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoLw0KDQpEaWZmIGZyb20gcHJldmlvdXMgdmVy c2lvbjoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1s ZHAtaGVsbG8tY3J5cHRvLWF1dGgtMDUNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KDQpJRVRGIFNlY3JldGFyaWF0Lg0KDQo= From nobody Tue May 6 05:20: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 262E71A020A for ; Tue, 6 May 2014 05:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 p7U9b4tT95iV for ; Tue, 6 May 2014 05:20:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADBE1A02A1 for ; Tue, 6 May 2014 05:20:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDW40736; Tue, 06 May 2014 12:20:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 May 2014 13:18:44 +0100 Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 May 2014 13:19:59 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML701-CHM.china.huawei.com ([169.254.3.206]) with mapi id 14.03.0158.001; Tue, 6 May 2014 05:19:56 -0700 From: Huaimo Chen To: Autumn Liu , Yimin Shen , "Ross Callon" , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaSV8o/K71U51ukWB9kHnTmwa6w== Date: Tue, 6 May 2014 12:19:55 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C66C94@SJCEML703-CHM.china.huawei.com> References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.167] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C66C94SJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wkk9rQAl0IqD6SP9kE7nrD1y42A Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:20:09 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C66C94SJCEML703CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Autumn, It is not clear for me what you mean with "the egress protection of p2p= LSP needs to be addressed specifically with the draft." Can you please supply some text that addresses the issue(s) you mention= ed. Best Regards, Huaimo From: Huaimo Chen Sent: Monday, May 05, 2014 5:05 PM To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org Subject: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_5316A0AB3C851246A7CA5758973207D445C66C94SJCEML703CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Autumn,

 

    It is not clear for me what yo= u mean with “the egress protection of p2p LSP needs to be addressed s= pecifically with the draft.”

    Can you please supply some tex= t that addresses the issue(s) you mentioned.

 

Best Regards,

Huaimo

From: Huaimo C= hen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: draft-ietf-mpls-rsvp-egress-protection-00=

 

Hi Autumn,

 <= /p>

Can you elaborate a little bit on “the egress protection of p2p LS= P needs to be addressed specifically with the draft.”?

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

 <= /p>

I am ok with the name cha= nge, and agree with Yimin that the egress protection of p2p LSP needs to be= addressed specifically with the draft.

-Autumn=

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

Hi chairs, authors,<= /o:p>

 <= /p>

To help make this draft m= ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe= rentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed= by inner labels (i.e. service labels).

 <= /p>

Of course, a complete sol= ution for P2P LSP egress protection will require extensions to Layer-2/3 VP= N service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have = already been addressed by some existing IETF work and drafts, this draft co= uld refer to them in the text.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 

--_000_5316A0AB3C851246A7CA5758973207D445C66C94SJCEML703CHMchi_-- From nobody Tue May 6 21:09:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4409E1A04AE; Tue, 6 May 2014 21:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw_mix03774I; Tue, 6 May 2014 21:09:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 730261A0217; Tue, 6 May 2014 21:09:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507040944.2950.12882.idtracker@ietfa.amsl.com> Date: Tue, 06 May 2014 21:09:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/E0iz1ztBmAGjy9QtyalpnksEHDQ Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-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: Wed, 07 May 2014 04:09:47 -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-08.txt Pages : 57 Date : 2014-05-06 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 of Tunnels, Identifiers, Label Switching Router and Textual conventions 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-te-mib-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 May 7 10:37: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 4BBE41A07D0; Wed, 7 May 2014 10:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15C_ioH9L0K5; Wed, 7 May 2014 10:37:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 521351A0386; Wed, 7 May 2014 10:37:29 -0700 (PDT) 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.4.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140507173729.23800.33055.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 10:37:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/It1RSzi8N8ciJABT1Bbu4F0_qfQ Cc: mpls@ietf.org Subject: [mpls] Last Call: (LDP Hello Cryptographic Authentication) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 17:37:31 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP Hello Cryptographic Authentication' 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-05-21. 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 introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed May 7 23:49:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A31A03F2 for ; Wed, 7 May 2014 23:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVIaQr39t42C for ; Wed, 7 May 2014 23:49:12 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0EF1A023E for ; Wed, 7 May 2014 23:49:12 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.95.153.210]) (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 000E71802AD1; Thu, 8 May 2014 08:49:05 +0200 (CEST) Message-ID: <536B28DE.7090504@pi.nu> Date: Thu, 08 May 2014 08:49:02 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.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/d-w0Oy-4wvVQSyDEPAQtSsoXRdI Subject: [mpls] hiccup in my mail service X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 06:49:14 -0000 Folks, I've had a temporary (36 hours) hiccup in the service of pi.nu, I've not been able to send or receive mails on that address. The mails sent to that address during that time will be permanently lost. On the other hand Martin have told that there have not been much traffic to the mailing list over that period. However if you start wondering why I'm not responding to something you have sent to me, it is probably because I never received it. If so please re-send. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu May 8 17:44:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130AC1A01C2 for ; Thu, 8 May 2014 17:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 frGjk6_M16vI for ; Thu, 8 May 2014 17:44:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA01A01B5 for ; Thu, 8 May 2014 17:44:32 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-cb-536bd5cf1a2a Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CC.F4.07420.FC5DB635; Thu, 8 May 2014 21:06:55 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Thu, 8 May 2014 20:44:19 -0400 From: Autumn Liu To: Huaimo Chen , Yimin Shen , "Ross Callon" , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaSWCEEuEYsttJkWkfWQejQJT9Zs3aVgQ Date: Fri, 9 May 2014 00:44:19 +0000 Message-ID: References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C66C94@SJCEML703-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C66C94@SJCEML703-CHM.china.huawei.com> Accept-Language: zh-CN, 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_E4F89EAEF1386F42AA8E6FB5C35399A61C10E7E3eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPrO75q9nBBrv+ylhsfXqF0eLW0pWs Fn9XXGGx2L78G4sDi0fLkbesHkuW/GTyuN50lT2AOYrLJiU1J7MstUjfLoErY/W0OcwFP+Yy VjycuZu5gXFiL2MXIyeHhICJxNLuB8wQtpjEhXvr2boYuTiEBI4ySvSsOMAC4SxjlFh2/iEb SBWbgJbEvv3v2EESIgITGCVe/rkK5HBwCAuYSWx+bwVSIyJgLnHtwgE2CNtIYt3PJnYQm0VA RWLNz9lg23gFfCVO/dkCtW0ai0Rj5xxWkASnQJjE+2fXmUBsRgFZiWmP7oPZzALiEreezGeC OFVAYsme81Bni0q8fPyPFcJWkpi09BwrRH2+xMLO2WwQywQlTs58wjKBUWQWklGzkJTNQlIG EdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFylBanluWmGxlsYgTG2DEJNt0djHteWh5i FOBgVOLhXRCaHSzEmlhWXJl7iFGag0VJnLfgS2ywkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p BsbWpGnPsk6FrtCoWZ869cgrzkz1SU2qBZYTZuv03ZIp8Gti5FTeGvDh5hrHrr6QM2tPLD5f Wh6l8iFg+1LHmT5Oah9com8/Vbs6ofQR46GNnLMP2je+ffomUZAj82Pn2shj4TE5tjd4tkRZ vPKXnl2iVi/yZ86SI9vNXuwLDs6rt+uw/1Q297sSS3FGoqEWc1FxIgDMz7GEkgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ql0HukN9ewlmoTEKZZSewvHwyJA Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 00:44:35 -0000 --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C10E7E3eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, I have some questions. 1) How Inner label (vpn label) acquired on primary egress node is sent= to backup egress node? Via PATH message for backup LSP? which object is us= ed? How this label is processed? How this label is maintained? 2) How PLR can acquire a path to backup egress node, its address is th= e same as primary egress node? 3) Does PLR sends the PATH message for primary LSP to backup egress no= de? Thanks, Autumn From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, May 06, 2014 5:20 AM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, It is not clear for me what you mean with "the egress protection of p2p= LSP needs to be addressed specifically with the draft." Can you please supply some text that addresses the issue(s) you mention= ed. Best Regards, Huaimo From: Huaimo Chen Sent: Monday, May 05, 2014 5:05 PM To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org Subject: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C10E7E3eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

 <= /p>

I have some questions.

1) = ;     How Inner label (= vpn label) acquired on primary egress node is sent to backup egress node? V= ia PATH message for backup LSP? which object is used? How this label is processed? How this label is maintained?

2) = ;     How PLR can acqui= re a path to backup egress node, its address is the same as primary egress = node?

3) = ;     Does PLR sends th= e PATH message for primary LSP to backup egress node?

Thanks,=

Autumn<= /p>

 <= /span>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Tuesday, May 06, 2014 5:20 AM
To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Autumn,

 

    It is not clear for me what yo= u mean with “the egress protection of p2p LSP needs to be addressed s= pecifically with the draft.”

    Can you please supply some tex= t that addresses the issue(s) you mentioned.

 

Best Regards,

Huaimo

From: Huaimo C= hen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: draft-ietf-mpls-rsvp-egress-protection-00=

 

Hi Autumn,

 <= /p>

Can you elaborate a little bit on “the egress protection of p2p LS= P needs to be addressed specifically with the draft.”?

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

 <= /p>

I am ok with the name cha= nge, and agree with Yimin that the egress protection of p2p LSP needs to be= addressed specifically with the draft.

-Autumn=

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

Hi chairs, authors,<= /o:p>

 <= /p>

To help make this draft m= ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe= rentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed= by inner labels (i.e. service labels).

 <= /p>

Of course, a complete sol= ution for P2P LSP egress protection will require extensions to Layer-2/3 VP= N service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have = already been addressed by some existing IETF work and drafts, this draft co= uld refer to them in the text.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 

--_000_E4F89EAEF1386F42AA8E6FB5C35399A61C10E7E3eusaamb103erics_-- From nobody Fri May 9 05:38: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 23FF81A029E for ; Fri, 9 May 2014 05:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 IEdd-IKnlzyG for ; Fri, 9 May 2014 05:38:27 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) by ietfa.amsl.com (Postfix) with ESMTP id C06361A0296 for ; Fri, 9 May 2014 05:38:26 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: Huaimo Chen , Autumn Liu , Yimin Shen , Ross Callon , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaKXRNui9++LYwkadb4wi40bsvZs4Na6w Date: Fri, 9 May 2014 12:38:17 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EA9F4@EX01.swan.local> References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C66B35@SJCEML703-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C66B35@SJCEML703-CHM.china.huawei.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: multipart/alternative; boundary="_000_61DC6BC4ABA10E4489D4A73EBABAC18B011EA9F4EX01swanlocal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gEGYce4o5cJxklnxWN-ooiGI5Jc Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 12:38:32 -0000 --_000_61DC6BC4ABA10E4489D4A73EBABAC18B011EA9F4EX01swanlocal_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello Huaimo, I'd like to discuss some thoughts regarding the very much appreciated rsvp = egress protection idea. 5.2. Intermediate Node and PLR Behavior The PLR (upstream node of the primary egress) tries to get the backup egress from EGRESS_BACKUP in the egress backup descriptor list if the Path message contains the list. If the PLR can not get it, the PLR tries to find the backup egress, which is not the primary egress but has the same IP address as the destination IP address of the LSP. -maybe the procedures proposed in: Segment Routing Use Cases draft-filsfils-rtgwg-segment-routing-use-cases-02 3.2. Protecting a node segment upon the failure of its -can be leveraged to determine all the backup egress candidates for the par= ticular LSP primary egress node. Or the VPN backup label can be used to signal backup egress candidate capab= ility to the LSP head-end LSP head-end can than include this list of candidates in the EGRESS_BACKUP = object of the PATH msg. So this list can be then used by the PLR to select one or multiple best bac= kup egress nodes. The constrained SPF could be run to determine one or multiple backup egress= nodes among all the backup egress node candidates. The particular PLR can tan build backup LSPs to one or multiple backup egre= ss nodes 5.2.2. Signaling for Facility Protection For a number of primary P2P LSPs going through the same PLR to the same primary egress, the primary egress of these LSPs may be protected by one backup LSP from the PLR to the backup egress designated for protecting the primary egress With multiple backup egress candidates: For the P2P LSPs going through the same PLR to the same primary egress node -the PLR could distribute these onto several backup egress nodes based on t= he LSP constrains satisfied by the path to each of the backup egress nodes. 5.2.4. PLR Procedures during Local Repair Moreover, the PLR lets the upstream part of the primary LSP stay after the primary egress fails. The downstream part of the primary LSP from the PLR to the primary egress SHOULD be removed. Please consider topology: [CE]$$$$[PE1]*****[P1]****[PLR]****[PE2]$$$$[CE] |-------| $ | $ [P2]------[PE3]$$$$$$$$ In the above topology for the primary path from PE1 to PE2 via P1 and PLR A backup path is built from PLR to PE3 via P1 and P2 In case the PE2 fails the traffic destined for PE2 has to go via P1 to PLR = and then back to P1 and then to P2 and PE3 In this case it is desirable for the LSP head-end PE1 to signal a new path = from PE1 to PE4 via P and PE3 Adam Vitkovsky CCIP(r) CCNP(r) Certified Network Architecture Department SWAN a.s. Borsk=E1 6, 841 04 Bratislava 4 adam.vitkovsky@swan.sk GSM: + 421 903 423 800 www.swan.sk From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Huaimo Chen Sent: Monday, May 05, 2014 11:06 PM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_61DC6BC4ABA10E4489D4A73EBABAC18B011EA9F4EX01swanlocal_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello Huaimo,

 

I’d like to discuss some thoughts re= garding the very much appreciated rsvp egress protection idea.

 

5.2. Intermediate Node and PLR Behavior

   The PLR (upstream node of the primary egress)= tries to get the backup

   egress from EGRESS_BACKUP in the egress backu= p descriptor list if the

   Path message contains the list.  If the = PLR can not get it, the PLR

   tries to find the backup egress, which is not= the primary egress but

   has the same IP address as the destination IP= address of the LSP.

 

-maybe the procedures  proposed in:

Segment Routing Use Cases
           draft-fil=
sfils-rtgwg-segment-routing-use-cases-02
           &nbs=
p;   3.2.  Protecting a node segment upon the failure of its=

 

-can be leveraged to determine all the bac= kup egress candidates for the particular LSP primary egress node.

Or the VPN backup label can be used to sig= nal backup egress candidate capability to the LSP head-end

LSP head-end can than include this list of= candidates in the EGRESS_BACKUP object of the PATH msg.<= /p>

So this list can be then used by the PLR t= o select one or multiple best backup egress nodes.  =

The constrained SPF could be run to determ= ine one or multiple backup egress nodes among all the backup egress node ca= ndidates.

The particular PLR can tan build backup LS= Ps to one or multiple backup egress nodes

 

5.2.2. Signaling for Facility Protection

   For a number of primary P2P LSPs going through the same P=
LR to the
   same primary egress, the primary egress of these LSPs may=
 be
   protected by one backup LSP from the PLR to the backup eg=
ress
   designated for protecting the primary egress

 


With multiple backup egress candidates:


For the P2P LSPs going through the same PL=
R to the same primary egress node


-the PLR could distribute these onto sever=
al backup egress nodes based on the LSP constrains satisfied by the path to=
 each of the backup egress nodes.



 


 


 


5.2.4. PLR Procedures during Local Repair<=
o:p>


   Moreover, the PLR lets the upstream part of the primary L=
SP stay


   after the primary egress fails.  The downstream part=
 of the primary


   LSP from the PLR to the primary egress SHOULD be removed.=



 


Please consider topology:


[CE]$$$$[PE1]*****[P1]****[PLR]****[PE2]$$$$[CE]


           =
        |-------|    =
;          $


           =
        |    &n=
bsp;            =
;    $


           =
       [P2]------[PE3]$$$$$$$$ &nbs=
p;    



 


In the above topology for the primary path=
 from PE1 to PE2 via P1 and PLR


A backup path is built from PLR to PE3 via=
 P1 and P2


In case the PE2 fails the traffic destined=
 for PE2 has to go via P1 to PLR and then back to P1 and then to P2 and PE3=



In this case it is desirable for the LSP h=
ead-end PE1 to signal a new path from PE1 to PE4 via P and PE3




 <=
/p>

 


 


Adam Vitkovsky
CCIP®<=
span style=3D"font-size:9.0pt;color:#002060">
CCNP®
Cert=
ified<=
o:p>


Network Architecture Department




SWAN a.s.


Borsk=E1 6, 841 04 Bratislava 4


adam.vitkovsky@swan.sk


GSM: + 421 903 423 800


www.swa=
n.sk


 


 


 


 


 <=
/p>

 <=
/p>







From: mpls [ma=
ilto:mpls-bounces@ietf.org]
On Behalf Of Huaimo Chen

Sent: Monday, May 05, 2014 11:06 PM

To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org

Subject: [mpls] draft-ietf-mpls-rsvp-egress-protection-00=







 


Hi Autumn,


 <=
/p>

Can you elaborate a little bit on “the egress protection of p2p LS=
P needs to be addressed specifically with the draft.”?


 


Best Regards,<=
/span>


Huaimo<=
/p>





From: mpls [mailto:mpls-bounces@ietf.org]
On Behalf Of Autumn Liu

Sent: Friday, March 14, 2014 9:03 PM

To: Yimin Shen; Ross Callon; mpls@i=
etf.org

Cc: mpls-chairs@tools.=
ietf.org;
dr=
aft-chen-mpls-p2mp-egress-protection@tools.ietf.org

Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad=
option draft-chen-mpls-p2mp-egress-protection-11






 


 <=
/p>

I am ok with the name cha=
nge, and agree with Yimin that the egress protection of p2p LSP needs to be=
 addressed specifically with the draft.


-Autumn=



 <=
/p>





From: mpls [mailto:mpls-bounces@ietf.org]
On Behalf Of Yimin Shen

Sent: Friday, March 14, 2014 4:14 PM

To: Yimin Shen; Ross Callon; mpls@i=
etf.org

Cc: mpls-chairs@tools.=
ietf.org;
dr=
aft-chen-mpls-p2mp-egress-protection@tools.ietf.org

Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad=
option draft-chen-mpls-p2mp-egress-protection-11






 


Hi chairs, authors,<=
/o:p>


 <=
/p>

To help make this draft m=
ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe=
rentiate the problems faced by P2MP LSPs and P2P LSPs, and also
 to discuss specifically the set of problems of P2P LSPs, which are imposed=
 by inner labels (i.e. service labels).



 <=
/p>

Of course, a complete sol=
ution for P2P LSP egress protection will require extensions to Layer-2/3 VP=
N service label distribution protocols, which may be out
 of the scope of RSVP and this draft. However, since these extensions have =
already been addressed by some existing IETF work and drafts, this draft co=
uld refer to them in the text.




 <=
/p>

Thanks,=



 <=
/p>

/Yimin<=
/p>

 <=
/p>





 
--_000_61DC6BC4ABA10E4489D4A73EBABAC18B011EA9F4EX01swanlocal_-- From nobody Mon May 12 06:52: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 D45541A06FA for ; Mon, 12 May 2014 06:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKyaUIVPtwGe for ; Mon, 12 May 2014 06:52:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAB11A070E for ; Mon, 12 May 2014 06:52:47 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) with Microsoft SMTP Server (TLS) id 15.0.918.8; Mon, 12 May 2014 13:52:32 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0918.000; Mon, 12 May 2014 13:52:32 +0000 From: Yimin Shen To: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: MPLS-RT review of draft-chen-mpls-source-label Thread-Index: Ac9mHhPQL+zgqxffQMyvtWl3yVZPQgHyI0kQ Date: Mon, 12 May 2014 13:52:32 +0000 Message-ID: <69ebedd287424fc19de474a2673004de@BY2PR05MB728.namprd05.prod.outlook.com> 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] x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(86362001)(575784001)(15202345003)(74316001)(77982001)(50986999)(80022001)(81542001)(31966008)(99286001)(46102001)(81342001)(79102001)(20776003)(76482001)(83322001)(85852003)(33646001)(92566001)(87936001)(54356999)(74662001)(15975445006)(99396002)(76576001)(83072002)(101416001)(74502001)(4396001)(2656002)(66066001)(561944003)(77096999)(19580395003)(76176999)(24736002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB728; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:E618D90A.8AF6D988.B8FD6197.11C46D41.20B4B; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_69ebedd287424fc19de474a2673004deBY2PR05MB728namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CGn-viLYNPZlp1yL5QYKWZT3J60 Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 13:52:50 -0000 --_000_69ebedd287424fc19de474a2673004deBY2PR05MB728namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG chairs, authors, I have finished my review for this draft. Overall, I think the document is = easy to understand, and useful from the perspective that the mechanism may = support egress routers to identify source of traffic for measurement purpos= es. >From technical perspetive, I do have the following comments, and hope the a= uthors can address them before WG adoption. 1. Granularity of SL The document currently views "sources" as ingress nodes, hence assumes t= he granularity of SL as per-node. From a generic point of view, I'd like to= see some discussion on per-flow SL (multiple flows ingress on a given node= ), or why this mode may not be useful. 2. SL allocation and disbritubtion. I think this is a big missing piece. The draft currently pushes this out= of scope. However, the procedures of how a router may allocate an SL for i= tself without colliding with other routers, and how a source-to-SL mapping = may be disctributed to egress routers are both relavant and important to th= e proposal. Therefore, they should be specified in this draft for completen= ess. 3. Transit router use cases. The draft has improved its clarity from previous rev by removing transit= router use cases. However, transit router is still mentioned in a few plac= es. So a cleanup may still be need to achieve consistency. Regards, /Yimin Shen --_000_69ebedd287424fc19de474a2673004deBY2PR05MB728namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
WG chairs, authors,
 
I have finished my review for this draft. Over= all, I think the document is easy to understand, and useful from the perspe= ctive that the mechanism may support egress routers to identify source of t= raffic for measurement purposes.
 
From technical perspetive, I do have the follo= wing comments, and hope the authors can address them before WG adoption.
 
  1. Granularity of SL
    2.
 
The document curr= ently views “sources” as ingress nodes, hence assumes the granu= larity of SL as per-node. From a generic point of view, I’d like to s= ee some discussion on per-flow SL (multiple flows ingress on a given node), or why this mode may not be useful.
 
  1. SL  allocation and disbritubtion.
 
I think this is a= big missing piece. The draft currently pushes this out of scope. However, = the procedures of how a router may allocate an SL for itself without collid= ing with other routers, and how a source-to-SL mapping may be disctributed to egress routers are both relavant and importa= nt to the proposal. Therefore, they should be specified in this draft for c= ompleteness.
 
  1. Transit router use cases.
 
The draft has imp= roved its clarity from previous rev by removing transit router use cases. H= owever, transit router is still mentioned in a few places. So a cleanup may= still be need to achieve consistency.
 
 
Regards,
 
/Yimin Shen
 
 
 --_000_69ebedd287424fc19de474a2673004deBY2PR05MB728namprd05pro_-- From nobody Tue May 13 03:40: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 AF8301A004D for ; Tue, 13 May 2014 03:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 QTpGg7fOOYVt for ; Tue, 13 May 2014 03:40:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C8CA61A0009 for ; Tue, 13 May 2014 03:40:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEC27882; Tue, 13 May 2014 10:40:00 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 13 May 2014 11:38:53 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 13 May 2014 11:39:46 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 13 May 2014 18:39:40 +0800 From: Mach Chen To: Yimin Shen , "draft-chen-mpls-source-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: MPLS-RT review of draft-chen-mpls-source-label Thread-Index: Ac9mHhPQL+zgqxffQMyvtWl3yVZPQgHyI0kQACt/N1AAAANKsA== Date: Tue, 13 May 2014 10:39:40 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wi3KrRuvkEziVbvwJAgM9yRWkYI Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 10:40:08 -0000 Hi Yimin, Thanks for your detail review and valuable comments on the draft! Please see my reply inline... > -----Original Message----- > From: Mach Chen > Sent: Tuesday, May 13, 2014 6:18 PM > To: Mach Chen > Subject: FW: MPLS-RT review of draft-chen-mpls-source-label >=20 >=20 >=20 > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen > Sent: Monday, May 12, 2014 9:53 PM > To: draft-chen-mpls-source-label@tools.ietf.org; mpls-chairs@tools.ietf.o= rg; > Martin Vigoureux > Cc: mpls@ietf.org > Subject: [mpls] MPLS-RT review of draft-chen-mpls-source-label >=20 > WG chairs, authors, >=20 > I have finished my review for this draft. Overall, I think the document i= s easy to > understand, and useful from the perspective that the mechanism may suppor= t > egress routers to identify source of traffic for measurement purposes. Thanks. >=20 > From technical perspetive, I do have the following comments, and hope the > authors can address them before WG adoption. >=20 > 1. Granularity of SL >=20 > The document currently views "sources" as ingress nodes, hence assumes th= e > granularity of SL as per-node. From a generic point of view, I'd like to = see some > discussion on per-flow SL (multiple flows ingress on a given node), or wh= y this > mode may not be useful. I personally open to this point and had thought about this. There are scena= rios that may need multiple SLs. I'd like to hear more opinions from the WG= .=20 >=20 > 2. SL=A0 allocation and disbritubtion. >=20 > I think this is a big missing piece. The draft currently pushes this out = of scope. > However, the procedures of how a router may allocate an SL for itself wit= hout > colliding with other routers, and how a source-to-SL mapping may be disct= ributed > to egress routers are both relavant and important to the proposal. Theref= ore, > they should be specified in this draft for completeness. Regarding to the allocation, this is same as the IP address allocation, "se= gment index" allocation. In practice, this is the task of the operators to = guarantee the uniqueness. It's more about a deployment issue. The operator = could use either static or dynamic mechanisms to achieve this. As for the distribution, seems that IGP extension is a reasonable choice, n= ormally, the IGP extensions will be defined in draft-xxx-ospf or draft-xxx-= isis, means it's better to define the distribution mechanisms in separate d= ocument. And actually, there are two initial drafts submitted (draft-chen-o= spf-source-label-distribution-00 and draft-chen-isis-source-label-distribut= ion-00). =20 >=20 > 3. Transit router use cases. >=20 > The draft has improved its clarity from previous rev by removing transit = router > use cases. However, transit router is still mentioned in a few places. So= a cleanup > may still be need to achieve consistency. OK. Thanks, Mach >=20 >=20 > Regards, >=20 > /Yimin Shen >=20 >=20 From nobody Wed May 14 06:45: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 3E01D1A00A7 for ; Wed, 14 May 2014 06:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suDtxtN5xSJ0 for ; Wed, 14 May 2014 06:45:09 -0700 (PDT) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by ietfa.amsl.com (Postfix) with ESMTP id 59D0D1A009A for ; Wed, 14 May 2014 06:45:09 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id q9so1551831ykb.39 for ; Wed, 14 May 2014 06:45:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jHynCqrPwJDVWz3rg3m4Iz7UM4olvoWx6hXtJLFqIbc=; b=RJ/xr2tV4gne9ZSq7URTX1T6JTAC17bgQyJWkgLvsQ++uVmD4E4c8wNxXSC/48SrT1 XZA0/msLR8ZjG1tnU44AoipyCvgkIy+hTlGsNxhlLsHgL28fqq37a8EscerNJXMytMQf HAWARbWsja/MXS5eJ8B87GSvaoOnf4HMpL8yB1RF3sxy9Bjc8JlifuPTssqF9h/x5r65 8Zy9BAJ0EPj9lG9PmThhLxLQlKhnlcV+6gjRCFiba+l1I3RRu5ZvVxgcDgm7kelnveoQ 693PAE6ozNv28kCrDoR+N5n54+X2l827UtjrXix4ynUmrvjDH+hUsGz47VhoStHmUsv9 2fsg== X-Gm-Message-State: ALoCoQn2CHuOIrcHNOoJEyJ+tfuGUc4lvVFw4iBqsGXOiqJq5WnRWmO5oeQgrNGjBP/ocP+ii/hh MIME-Version: 1.0 X-Received: by 10.236.126.43 with SMTP id a31mr3446989yhi.154.1400075102543; Wed, 14 May 2014 06:45:02 -0700 (PDT) Received: by 10.170.60.20 with HTTP; Wed, 14 May 2014 06:45:02 -0700 (PDT) In-Reply-To: <5363A354.8090007@lab.ntt.co.jp> References: <5363A354.8090007@lab.ntt.co.jp> Date: Wed, 14 May 2014 09:45:02 -0400 Message-ID: From: Eric Osborne To: Tomonori Takeda Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OK3J0NL1a9eXXG9z3a-CUyH3zQA Cc: "mpls@ietf.org" , "draft-ietf-mpls-extended-admin-group.all@tools.ietf.org" , b4a99d417be785e4.invalid@internationalized.invalid, d586783d77c2558c.invalid@internationalized.invalid Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-extended-admin-group-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, 14 May 2014 13:45:11 -0000 ... All nits have been addressed. I went with 'the Administrative Group sub-TLV' in the abstract. For section 2, I reworded the first paragraph as: This document defines the Extended Administrative Group (EAG) sub-TLV for both OSPF [RFC3630] and ISIS [RFC5305]. eric > > Nits: > > o Abstract > It says: > "the Administrative Group sub-TLV of the Link TLV" > Precisely speaking, I think this should be: > "the Administrative Group sub-TLV of the Link TLV for OSPFv2/OSPFv3 > and of the Extended IS Reachability TLV for ISIS" > Or this could simply be: > "the Administrative Group sub-TLV" > > o Section 1, 3rd paragraph > s/vaues/values > > o Section 2 > "This document defines a sub-TLV of the Link TLV for both OSPF > [RFC3630] and ISIS [RFC5305] ... " > Same as above (comment for Abstract). > > o Section 2.2 > "the existing Administrative Group TLVs" should be: > "the existing Administrative Group sub-TLVs". > > o Section 2.3.2, 3rd paragraph > "as the assumption is than an unadvertised bit is set to 0" > I guess "than" should be "that". > > Thanks, > Tomonori Takeda > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed May 14 08:22: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 5E4481A00C2 for ; Wed, 14 May 2014 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqz1Xs7omERw for ; Wed, 14 May 2014 08:22:19 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 694C21A008F for ; Wed, 14 May 2014 08:22:19 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id as1so2028551iec.3 for ; Wed, 14 May 2014 08:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5vb+ZWXkUQt4g28i74DqhXN+ZICCQR1F9+cBg/qjIOM=; b=OfmEH4mYvjMmAYw6A9w8JZeXyfcSd8zf2uA5+nUkuolFlV+yqhg7qzfVDb2Ub7IF4x cAHQMgDTDJx6AyeS5t/UJX/wPgZbvL13qAhsUSU4khn0LwXW199KXuiRGGDYxjd7TAsz 95eUF82uambV8kBibM70CVVszjbs4gA+VO07xXwTCsdyPXnVV0BzhCO5khOFRpQ87GWa 3X5U40/LpUM1Q6YmG+r1F4BNvRb/Xb9X3uex9Gp2eft+YAEHflMFb9IHmRNkfMoh96uE WvFkJnGSF3j1EUX/m7ENo6PyM4dbCtK0rJkml3741S7FFrFUYZTUVzeJNKYn5OJc+cQw 25yA== MIME-Version: 1.0 X-Received: by 10.42.148.67 with SMTP id q3mr3943485icv.5.1400080932676; Wed, 14 May 2014 08:22:12 -0700 (PDT) Received: by 10.42.95.208 with HTTP; Wed, 14 May 2014 08:22:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 May 2014 23:22:12 +0800 Message-ID: From: Lizhong Jin To: draft-chen-mpls-source-label@tools.ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8a14a62fb204f95dbe0e Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YUK8QvlZOGN8G_liN2LvrjNyz_Y Cc: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" , Ross Callon Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:22:26 -0000 --90e6ba6e8a14a62fb204f95dbe0e Content-Type: text/plain; charset=UTF-8 Hi authors, I finished the review, and the text is easy to understandable. I have some technical comments and concerns before adoption. Hope the authors could help to clarify. Section 1, line 159 Suggest to remove the Segment Routing case, otherwise, we have to co-work with SPRING WG for this draft. Section 3, line 188 MPLS label is originally designed to be a locally unique label. But this draft propose the label to be globally unique. That will bring many new things, e.g., label management complexity, label space limitation, etc. Could we achieve the purpose of Performance Measurement by other way, e.g., by using psuedowire between two endpoints. Section 4.1, line 236 My concern here is, is it valuable to get the measurement of a P2P path within a MP2P path (in section 1, you said, MP2P is a problem). The performance you get at one time for this P2P path is surely influenced by other P2P path of the same MP2P path. Keep in mind that the LSP label tested is also shared by other P2P LSP within same MP2P LSP. If you really want the MPLS path performance between two endpoints in LDP environment, suggest to use PW instead. Section 6.1.1, line 361 I have concern with the signaling mechanism. In a large network, if only one LSR does not support SLC, then the whole network could not support SLC. If one LSR changes its SLC status, it will flood to every node. That may bring some instability to the network, and make the signaling unscalable. And it maybe possible to optimize the signaling. The SLC status from the next hop could be used to send upstream, right? Section 6.1.2, 6.1.2.3 Since RSVP-TE LSP does not have the measurement problem listed in this draft, why we need to do RSVP-TE extension? MP-BGP is not used to setup MP2P / MP2MP LSP, then why we need the extension? Did I miss something? Regards Lizhong On Friday, May 2, 2014, Ross Callon wrote: > Eric, Yimin, Lizhong; > > You have been selected as MPLS Review team reviewers for > draft-chen-mpls-source-label-03. > > 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? Also, is the text and grammar > understandable (it doesn't need to be perfect at this point, but should be > reasonably clear). 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. > > Are you able to review this draft by May 16, 2014? > > Thanks, Ross > (as MPLS WG chair) > > --90e6ba6e8a14a62fb204f95dbe0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi authors,
I finished the review, and the text is easy to understandab= le. I have some technical comments and concerns before adoption. Hope the a= uthors could help to clarify.

Section 1, line 159<= /div>
Suggest to remove the=C2=A0Segment Routing case, otherwise, we have to= co-work with SPRING WG for this draft.

Section 3,= line 188
MPLS label is originally designed to be a locally uniqu= e label. But this draft propose the label to be globally unique. That will = bring many new things, e.g., label management complexity, label space limit= ation, etc. Could we achieve the purpose of=C2=A0Performance Measurement by= other way, e.g., by using psuedowire between two endpoints.

Section 4.1, line 236
My concern here is, is = it valuable to get the measurement of a P2P path within a MP2P path (in sec= tion 1, you said, MP2P is a problem). The performance you get at one time f= or this P2P path is surely influenced by other P2P path of the same MP2P pa= th. Keep in mind that the LSP label tested is also shared by other P2P LSP = within same MP2P LSP.
If you really want the MPLS path performance between two endpoints in LDP e= nvironment, suggest to use PW instead.

Section 6.1= .1, line 361
I have concern with the signaling mechanism. In= a large network, if only one LSR does not support SLC, then the whole netw= ork could not support SLC. If one LSR changes its SLC status, it will flood= to every node. That may bring some instability to the network, and make th= e signaling unscalable. And it maybe possible to optimize the signaling. Th= e SLC status from the next hop could be used to send upstream, right?

Section 6.1.2, 6.1.2.3
Since RSVP-TE LS= P does not have the measurement problem listed in this draft, why we need t= o do RSVP-TE extension? MP-BGP is not used to setup MP2P / MP2MP LSP, then = why we need the extension? Did I miss something?

Regards
Lizhong


= On Friday, May 2, 2014, Ross Callon <rcallon@juniper.net> wrote:
Eric, Yimin, Lizhong;
=C2=A0
You have been selected as MPLS Review team reviewers for draft-chen-mp= ls-source-label-03.
=C2=A0
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 d= ocument.
=C2=A0
Reviews should comment on whether the document is coherent, is it usef= ul (ie, is it likely to be actually useful in operational networks), and is= the document technically sound?=C2=A0 Also, is the text and grammar unders= tandable (it doesn't need to be perfect at this point, but should be reasonably clear). We are interested in knowin= g whether the document is ready to be considered for WG adoption (ie, it do= esn't have to be perfect at this point, but should be a good start).
=C2=A0
Reviews should be sent to the document authors, WG co-chairs and WG se= cretary, and CC'd to the MPLS WG email list. If necessary, Comments may= be sent privately to only the WG chairs.
=C2=A0
Are you able to review this draft by May 16, 2014?
=C2=A0
Thanks, Ross
(as MPLS WG chair)
=C2=A0
--90e6ba6e8a14a62fb204f95dbe0e-- From nobody Wed May 14 09:47: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 514501A02C3 for ; Wed, 14 May 2014 09:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVgGv7cCCvs5 for ; Wed, 14 May 2014 09:47:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8682F1A00D5 for ; Wed, 14 May 2014 09:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1806; q=dns/txt; s=iport; t=1400086038; x=1401295638; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RUXUzaaZwlvTyE1PhGlBChQbf9mbtpURCvPeqST5IWI=; b=fq7yFRaMC41KjBOwaoLnC3pllvz2wAZE9QyqBGrZlWts/+J6/BHhYtOG W4KG7YMXn15cJleXJ+dCF4WfJStBdJGtGvKEQoy/pZSorzm3DGWPxflgk v/+FMCgV75jd/GQy78mItth6SMN/Yun1qto9Lfc5Nc7g0BN4l/VYEQvAi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAO2cc1OtJV2P/2dsb2JhbABZgwZPWL40hzsBgSMWdIImAQEEAQEBNzEDBgUOAgIBCDYQGwwLJQIEAQ0FiEEN0RwTBASNaBACAU8HhEAEmVGTFIM2gjA X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="324892382" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 14 May 2014 16:47:17 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4EGlHSE005847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 16:47:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 14 May 2014 11:47:17 -0500 From: "George Swallow (swallow)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-lsp-ping-relay-reply Thread-Index: AQHPWhPCunuDn1ut+0S5aJVdxuT4b5tAhOwA Date: Wed, 14 May 2014 16:47:17 +0000 Message-ID: References: <534F8B25.80802@pi.nu> In-Reply-To: <534F8B25.80802@pi.nu> 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.165] 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/l4uq44-Sg_T_iwUHTJL6CMmiQWU Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: Re: [mpls] IPR poll 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: Wed, 14 May 2014 16:47:26 -0000 I am not aware of any IPR other than that previously disclosed. 2012-12-15 ID # 1945 "Cisco's Statement of IPR Related to draft-zjns-mpls-lsp-ping-relay-reply-00" George On 4/17/14 4:04 AM, "Loa Andersson" wrote: >Working Group, > >The authors of draft-ietf-mpls-lsp-ping-relay-reply has informed us >that the draft is ready for working groups last call. > >Before starting the working group last call we want to run an IPR poll. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to >draft-ietf-mpls-lsp-ping-relay-reply? > >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 two 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 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Wed May 14 10:04: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 879BC1A0109 for ; Wed, 14 May 2014 10:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP5pzaSiyoKh for ; Wed, 14 May 2014 10:04:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::622]) by ietfa.amsl.com (Postfix) with ESMTP id D5CED1A02BF for ; Wed, 14 May 2014 10:04:18 -0700 (PDT) Received: from DM2PR05CA003.namprd05.prod.outlook.com (10.141.96.23) by BL2PR05MB098.namprd05.prod.outlook.com (10.255.232.15) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 17:03:49 +0000 Received: from BN1BFFO11FD057.protection.gbl (2a01:111:f400:7c10::1:149) by DM2PR05CA003.outlook.office365.com (2a01:111:e400:2428::23) with Microsoft SMTP Server (TLS) id 15.0.944.11 via Frontend Transport; Wed, 14 May 2014 17:03:49 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1BFFO11FD057.mail.protection.outlook.com (10.58.145.12) with Microsoft SMTP Server (TLS) id 15.0.939.9 via Frontend Transport; Wed, 14 May 2014 17:03:49 +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, 14 May 2014 10:03:43 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s4EH3eL92691; Wed, 14 May 2014 10:03:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201405141703.s4EH3eL92691@magenta.juniper.net> To: Mach Chen In-Reply-To: References: X-MH-In-Reply-To: Mach Chen message dated "Tue, 13 May 2014 10:39:40 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12632.1400087019.1@juniper.net> Date: Wed, 14 May 2014 10:03:39 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(13464003)(51704005)(377454003)(19580405001)(74502001)(31966008)(6806004)(85852003)(4396001)(68736004)(97756001)(69596002)(19580395003)(46102001)(16796002)(83072002)(561944003)(92566001)(84676001)(86362001)(74662001)(83322001)(102836001)(99396002)(21056001)(97736001)(44976005)(46406003)(50466002)(77982001)(92726001)(2009001)(76176999)(50986999)(20776003)(80022001)(81156002)(64706001)(23726002)(76482001)(81342001)(47776003)(77096999)(79102001)(87936001)(81542001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB098; H:P-EMF03-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Forefront-PRVS: 0211965D06 Received-SPF: SoftFail (: 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-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/S6hSBabekTSdzyzO50dTDjsYIMI Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:04:22 -0000 Mach, > Hi Yimin, > > Thanks for your detail review and valuable comments on the draft! > > Please see my reply inline... few comments in-line below... > > -----Original Message----- > > From: Mach Chen > > Sent: Tuesday, May 13, 2014 6:18 PM > > To: Mach Chen > > Subject: FW: MPLS-RT review of draft-chen-mpls-source-label > > > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen > > Sent: Monday, May 12, 2014 9:53 PM > > To: draft-chen-mpls-source-label@tools.ietf.org; mpls-chairs@tools.ietf.org ; > > Martin Vigoureux > > Cc: mpls@ietf.org > > Subject: [mpls] MPLS-RT review of draft-chen-mpls-source-label > > > > WG chairs, authors, > > > > I have finished my review for this draft. Overall, I think the document is easy to > > understand, and useful from the perspective that the mechanism may support > > egress routers to identify source of traffic for measurement purposes. > > Thanks. > > > > > From technical perspetive, I do have the following comments, and hope the > > authors can address them before WG adoption. > > > > 1. Granularity of SL > > > > The document currently views "sources" as ingress nodes, hence assumes the > > granularity of SL as per-node. From a generic point of view, I'd like to se e some > > discussion on per-flow SL (multiple flows ingress on a given node), or why this > > mode may not be useful. > > I personally open to this point and had thought about this. There are scenari os that may need multiple SLs. I'd like to hear more opinions from the WG. > > > > > 2. SL's allocation and disbritubtion. > > > > I think this is a big missing piece. The draft currently pushes this > > out of scope. > > However, the procedures of how a router may allocate an SL for itself > > without > > colliding with other routers, and how a source-to-SL mapping may be > > disctributed > > to egress routers are both relavant and important to the proposal. > > Therefore, > > they should be specified in this draft for completeness. > > Regarding to the allocation, this is same as the IP address allocation, > "segment index" allocation. Saying that it is the same as "IP address allocation" is a bit misleading, as for IP allocation we have a hierarchy of allocation authorities that intended to provide *globally* unique allocation of IP addresses. > In practice, this is the task of the operators to guarantee the uniqueness. Saying that "this is the task of the operators to guarantee the uniqueness", assumes that providing such guarantee is fully within the control of the operator, which may not be the case when not all the equipment is under control of a single operator. > It's more about a deployment issue. The operator could use > either static or dynamic mechanisms to achieve this. > > As for the distribution, seems that IGP extension is a reasonable > choice, normally, the IGP extensions will be defined in draft-xxx-ospf > or draft-xxx-isis, means it's better to define the distribution > mechanisms in separate document. And actually, there are two initial > drafts submitted (draft-chen-ospf-source-lab el-distribution-00 and > draft-chen-isis-source-label-distribution-00). Given all this and my comments above, I wonder whether the document should explicitly spell out that the scope of source-label is a single IGP domain, and also spell out what should be done to prevent source labels to leak across IGP domain boundaries. Yakov. From nobody Wed May 14 10:56: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 169341A013C for ; Wed, 14 May 2014 10:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zO9Ak_yPKcf for ; Wed, 14 May 2014 10:56:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 732CE1A00B2 for ; Wed, 14 May 2014 10:56:28 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-8a-53735ee3cfb5 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A6.94.07420.3EE53735; Wed, 14 May 2014 14:17:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Wed, 14 May 2014 13:56:19 -0400 From: Gregory Mirsky To: Lizhong Jin , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: Ac9mHhPQL+zgqxffQMyvtWl3yVZPQgJi7qUAAAPBHoA= Date: Wed, 14 May 2014 17:56:19 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7B12A5@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7B12A5eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPlO6TuOJgg7nXWCzmbJ3IYrHi9DNm i++XlrBY3Fq6ktXi74orLA6sHjtn3WX3WLLkJ5PH9aar7B5fLn9mC2CJ4rJJSc3JLEst0rdL 4Mq483M7c8GrLYwVB3frNDC2bGDsYuTkkBAwkeic0c4EYYtJXLi3nq2LkYtDSOAoo8Sb9/8Z IZzljBJ3+j+yglSxCRhJvNjYww5iiwi0MUoc7bMGsZkFmhklJp7kA7GFBZwkjl5/yQpR4yxx +tF0JgjbSuLrnH9gvSwCqhI7P0LM4RXwlWhZ28YCsWwOo8Sf9UuZQRKcAoESr99PAmtmBDrv +6k1TBDLxCVuPZkPdbaAxJI955khbFGJl4//sULYShKTlp5jhajPl+h6uwhqmaDEyZlPWCYw is5CMmoWkrJZSMpmMXIAxTUl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypGjtLi1LLcdCOD TYzAWDwmwaa7g3HPS8tDjAIcjEo8vAmqRcFCrIllxZW5hxilOViUxHkLvsQGCwmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamDU1Jf+FbfTa3avVJ1Y7s+bV5hvtJeHax29wXps24X4r41PD6zP M57y+Bbn3cifDS41zI7PPM6pbJ7y7P8rgbVfa2cYf6lgOqWeK9YTvC03q+ygrv9Xn7/3ZB7u qS09x7o0yOr1xUWn1cS2qVXf+Sb8VHm9cMXm7krGg2szZOUdDM13ui7LKeJWYinOSDTUYi4q TgQAXbuSAqYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rwtOGqXRrweoGpnWXUN6rspS23Q Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:56:32 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7B12A5eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGl6aG9uZywNCm1hbnkgdGhhbmtzIGZvciB5b3Uga2luZCBjb25zaWRlcmF0aW9uIG9mIG91 ciB3b3JrIGFuZCB0aG91Z2h0ZnVsIGNvbW1lbnRzLiBQbGVhc2UgZmluZCBteSBub3RlcyBpbi1s aW5lIGFuZCB0YWdnZWQgR0lNPj4uDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IG1wbHMgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXpob25nIEppbg0KU2VudDogV2VkbmVz ZGF5LCBNYXkgMTQsIDIwMTQgODoyMiBBTQ0KVG86IGRyYWZ0LWNoZW4tbXBscy1zb3VyY2UtbGFi ZWxAdG9vbHMuaWV0Zi5vcmcNCkNjOiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgbXBsc0Bp ZXRmLm9yZzsgUm9zcyBDYWxsb24NClN1YmplY3Q6IFJlOiBbbXBsc10gTVBMUy1SVCByZXZpZXcg b2YgZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1sYWJlbA0KDQpIaSBhdXRob3JzLA0KSSBmaW5pc2hl ZCB0aGUgcmV2aWV3LCBhbmQgdGhlIHRleHQgaXMgZWFzeSB0byB1bmRlcnN0YW5kYWJsZS4gSSBo YXZlIHNvbWUgdGVjaG5pY2FsIGNvbW1lbnRzIGFuZCBjb25jZXJucyBiZWZvcmUgYWRvcHRpb24u IEhvcGUgdGhlIGF1dGhvcnMgY291bGQgaGVscCB0byBjbGFyaWZ5Lg0KDQpTZWN0aW9uIDEsIGxp bmUgMTU5DQpTdWdnZXN0IHRvIHJlbW92ZSB0aGUgU2VnbWVudCBSb3V0aW5nIGNhc2UsIG90aGVy d2lzZSwgd2UgaGF2ZSB0byBjby13b3JrIHdpdGggU1BSSU5HIFdHIGZvciB0aGlzIGRyYWZ0Lg0K R0lNPj4gQXMgTVBMUyBkYXRhIHBsYW5lIGlzIGluIHNjb3BlIG9mIFNQUklORyBXRyB3ZSBjZXJ0 YWlubHkgd2lsbCBhc2sgaXQgdG8gcmV2aWV3IHRoaXMgZG9jdW1lbnQgYW5kIHdlbGNvbWUgdGhl aXIgY29tbWVudHMuDQoNClNlY3Rpb24gMywgbGluZSAxODgNCk1QTFMgbGFiZWwgaXMgb3JpZ2lu YWxseSBkZXNpZ25lZCB0byBiZSBhIGxvY2FsbHkgdW5pcXVlIGxhYmVsLiBCdXQgdGhpcyBkcmFm dCBwcm9wb3NlIHRoZSBsYWJlbCB0byBiZSBnbG9iYWxseSB1bmlxdWUuIFRoYXQgd2lsbCBicmlu ZyBtYW55IG5ldyB0aGluZ3MsIGUuZy4sIGxhYmVsIG1hbmFnZW1lbnQgY29tcGxleGl0eSwgbGFi ZWwgc3BhY2UgbGltaXRhdGlvbiwgZXRjLiBDb3VsZCB3ZSBhY2hpZXZlIHRoZSBwdXJwb3NlIG9m IFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IGJ5IG90aGVyIHdheSwgZS5nLiwgYnkgdXNpbmcgcHN1 ZWRvd2lyZSBiZXR3ZWVuIHR3byBlbmRwb2ludHMuDQpHSU0+PiBZZXMsIFNvdXJjZSBMYWJlbCBj aGFuZ2VzIHVuaXF1ZW5lc3Mgc2NvcGUgZnJvbSBsb2NhbCB0byBzb21ldGhpbmcgZWxzZS4gQXMg WWFrb3Ygc3VnZ2VzdHMgdG8gbWFrZSBleHBsaWNpdCBzdGF0ZW1lbnQgdGhhdCBTb3VyY2UgTGFi ZWwgbXVzdCBiZSB1bmlxdWUgb25seSB3aXRoaW4gZ2l2ZW4gSUdQIGRvbWFpbiBhbmQgbm90IGds b2JhbGx5LiBJIHNlZSB0aGUgcG9pbnQgaW4gc3VjaCBkZWZpbml0aW9uIGJ1dCB3b3VsZCBsaWtl IHRvIGRpc2N1c3MgaXQgbW9yZSwgZ2V0IG1vcmUgb3BpbmlvbnMgZnJvbSB0aGUgZ3JvdXAuDQoN ClNlY3Rpb24gNC4xLCBsaW5lIDIzNg0KTXkgY29uY2VybiBoZXJlIGlzLCBpcyBpdCB2YWx1YWJs ZSB0byBnZXQgdGhlIG1lYXN1cmVtZW50IG9mIGEgUDJQIHBhdGggd2l0aGluIGEgTVAyUCBwYXRo IChpbiBzZWN0aW9uIDEsIHlvdSBzYWlkLCBNUDJQIGlzIGEgcHJvYmxlbSkuIFRoZSBwZXJmb3Jt YW5jZSB5b3UgZ2V0IGF0IG9uZSB0aW1lIGZvciB0aGlzIFAyUCBwYXRoIGlzIHN1cmVseSBpbmZs dWVuY2VkIGJ5IG90aGVyIFAyUCBwYXRoIG9mIHRoZSBzYW1lIE1QMlAgcGF0aC4gS2VlcCBpbiBt aW5kIHRoYXQgdGhlIExTUCBsYWJlbCB0ZXN0ZWQgaXMgYWxzbyBzaGFyZWQgYnkgb3RoZXIgUDJQ IExTUCB3aXRoaW4gc2FtZSBNUDJQIExTUC4NCklmIHlvdSByZWFsbHkgd2FudCB0aGUgTVBMUyBw YXRoIHBlcmZvcm1hbmNlIGJldHdlZW4gdHdvIGVuZHBvaW50cyBpbiBMRFAgZW52aXJvbm1lbnQs IHN1Z2dlc3QgdG8gdXNlIFBXIGluc3RlYWQuDQpHSU0+PiBBbGwgcGVyZm9ybWFuY2UgbWV0cmlj cyBhbmQgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgbWV0aG9kcyBJIGtub3cgYmVlbiBkZWZpbmVk IGZvciBwMnAuIElmIHdlIGxvb2sgYXQgTUVG4oCZcyBtb2RlbCBmb3IgRXRoZXJuZXQgUy1PQU0g UE0sIHRoZW4gZm9yIEUtTEFOIGl0IGlzIHN0aWxsIHAycCBtZWFzdXJlbWVudC4NCg0KU2VjdGlv biA2LjEuMSwgbGluZSAzNjENCkkgaGF2ZSBjb25jZXJuIHdpdGggdGhlIHNpZ25hbGluZyBtZWNo YW5pc20uIEluIGEgbGFyZ2UgbmV0d29yaywgaWYgb25seSBvbmUgTFNSIGRvZXMgbm90IHN1cHBv cnQgU0xDLCB0aGVuIHRoZSB3aG9sZSBuZXR3b3JrIGNvdWxkIG5vdCBzdXBwb3J0IFNMQy4gSWYg b25lIExTUiBjaGFuZ2VzIGl0cyBTTEMgc3RhdHVzLCBpdCB3aWxsIGZsb29kIHRvIGV2ZXJ5IG5v ZGUuIFRoYXQgbWF5IGJyaW5nIHNvbWUgaW5zdGFiaWxpdHkgdG8gdGhlIG5ldHdvcmssIGFuZCBt YWtlIHRoZSBzaWduYWxpbmcgdW5zY2FsYWJsZS4gQW5kIGl0IG1heWJlIHBvc3NpYmxlIHRvIG9w dGltaXplIHRoZSBzaWduYWxpbmcuIFRoZSBTTEMgc3RhdHVzIGZyb20gdGhlIG5leHQgaG9wIGNv dWxkIGJlIHVzZWQgdG8gc2VuZCB1cHN0cmVhbSwgcmlnaHQ/DQpHSU0+PiBJIHRoaW5rIHRoYXQg bm90IGFsbCBMU1JzIGluIGFuIElHUCBkb21haW4gYXJlIHJlcXVpcmVkIHRvIGJlIFNMQyBidXQg b25seSBlbmQtcG9pbnRzIG9mIGFuIExTUC4gVGh1cywgaWYgYW4gTFNSIGlzIG5vdCBTTEMsIHRo ZW4gU0wgY2Fubm90IGJlIHVzZWQgb24gTFNQcyBpdCBvcmlnaW5hdGVzL3Rlcm1pbmF0ZXMuIENo YW5nZSBpbiBTTEMsIEkgaW1hZ2luZSwgbWF5IGNvbWUgYXMgcmVzdWx0IG9mIFNXIHVwZ3JhZGUu IFRob3VnaCBpdCB3b3VsZCB0cmlnZ2VkIGZsb29kIG9mIHVwZGF0ZXMgdGhhdCwgSU1PLCB3b3Vs ZCBiZSBvbmUtdGltZSBldmVudC4NCg0KU2VjdGlvbiA2LjEuMiwgNi4xLjIuMw0KU2luY2UgUlNW UC1URSBMU1AgZG9lcyBub3QgaGF2ZSB0aGUgbWVhc3VyZW1lbnQgcHJvYmxlbSBsaXN0ZWQgaW4g dGhpcyBkcmFmdCwgd2h5IHdlIG5lZWQgdG8gZG8gUlNWUC1URSBleHRlbnNpb24/IE1QLUJHUCBp cyBub3QgdXNlZCB0byBzZXR1cCBNUDJQIC8gTVAyTVAgTFNQLCB0aGVuIHdoeSB3ZSBuZWVkIHRo ZSBleHRlbnNpb24/IERpZCBJIG1pc3Mgc29tZXRoaW5nPw0KR0lNPj4gSSB0aGluayB0aGF0IFJT VlAtVEUgTFNQIHdpdGggbGFiZWwgbWVyZ2UgYW5kIFBIUCBzdGlsbCBoYXZlIGlzc3VlcyBkZXNj cmliZWQgaW4gdGhlIGRvY3VtZW50LiBQZXJoYXBzIG9ubHkgTVBMUy1UUCBjb25zdHJ1Y3RzIGhh dmUgZGV0ZXJtaW5pc20gb2YgdHJhbnNwb3J0IG5ldHdvcmsgYW5kIG1heSBub3QgaGF2ZSB0aGlz IHByb2JsZW0uDQoNClJlZ2FyZHMNCkxpemhvbmcNCg0KDQpPbiBGcmlkYXksIE1heSAyLCAyMDE0 LCBSb3NzIENhbGxvbiA8cmNhbGxvbkBqdW5pcGVyLm5ldDxtYWlsdG86cmNhbGxvbkBqdW5pcGVy Lm5ldD4+IHdyb3RlOg0KRXJpYywgWWltaW4sIExpemhvbmc7DQoNCllvdSBoYXZlIGJlZW4gc2Vs ZWN0ZWQgYXMgTVBMUyBSZXZpZXcgdGVhbSByZXZpZXdlcnMgZm9yIGRyYWZ0LWNoZW4tbXBscy1z b3VyY2UtbGFiZWwtMDMuDQoNCk5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBDQydkIG9u IHRoaXMgZW1haWwgc28gdGhhdCB5b3UgY2FuIGtub3cgdGhhdCB0aGlzIHJldmlldyBpcyBnb2lu ZyBvbi4gSG93ZXZlciwgcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91ciBvd24gZG9jdW1lbnQuDQoN ClJldmlld3Mgc2hvdWxkIGNvbW1lbnQgb24gd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJl bnQsIGlzIGl0IHVzZWZ1bCAoaWUsIGlzIGl0IGxpa2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwg aW4gb3BlcmF0aW9uYWwgbmV0d29ya3MpLCBhbmQgaXMgdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5 IHNvdW5kPyAgQWxzbywgaXMgdGhlIHRleHQgYW5kIGdyYW1tYXIgdW5kZXJzdGFuZGFibGUgKGl0 IGRvZXNuJ3QgbmVlZCB0byBiZSBwZXJmZWN0IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUg cmVhc29uYWJseSBjbGVhcikuIFdlIGFyZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgd2hldGhlciB0 aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lkZXJlZCBmb3IgV0cgYWRvcHRpb24gKGll LCBpdCBkb2Vzbid0IGhhdmUgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxk IGJlIGEgZ29vZCBzdGFydCkuDQoNClJldmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3Vt ZW50IGF1dGhvcnMsIFdHIGNvLWNoYWlycyBhbmQgV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0 aGUgTVBMUyBXRyBlbWFpbCBsaXN0LiBJZiBuZWNlc3NhcnksIENvbW1lbnRzIG1heSBiZSBzZW50 IHByaXZhdGVseSB0byBvbmx5IHRoZSBXRyBjaGFpcnMuDQoNCkFyZSB5b3UgYWJsZSB0byByZXZp ZXcgdGhpcyBkcmFmdCBieSBNYXkgMTYsIDIwMTQ/DQoNClRoYW5rcywgUm9zcw0KKGFzIE1QTFMg V0cgY2hhaXIpDQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B7B12A5eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTGl6aG9uZyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+bWFueSB0aGFua3MgZm9yIHlvdSBraW5kIGNvbnNp ZGVyYXRpb24gb2Ygb3VyIHdvcmsgYW5kIHRob3VnaHRmdWwgY29tbWVudHMuIFBsZWFzZSBmaW5k IG15IG5vdGVzIGluLWxpbmUgYW5kIHRhZ2dlZCBHSU0mZ3Q7Jmd0Oy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+TGl6aG9uZyBKaW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBNYXkgMTQsIDIwMTQgODoyMiBBTTxicj4NCjxiPlRvOjwvYj4gZHJhZnQtY2hlbi1tcGxzLXNv dXJjZS1sYWJlbEB0b29scy5pZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gbXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IFJvc3MgQ2FsbG9uPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbbXBsc10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1s YWJlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYXV0aG9ycyw8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZpbmlzaGVkIHRoZSByZXZpZXcs IGFuZCB0aGUgdGV4dCBpcyBlYXN5IHRvIHVuZGVyc3RhbmRhYmxlLiBJIGhhdmUgc29tZSB0ZWNo bmljYWwgY29tbWVudHMgYW5kIGNvbmNlcm5zIGJlZm9yZSBhZG9wdGlvbi4gSG9wZSB0aGUgYXV0 aG9ycyBjb3VsZCBoZWxwIHRvIGNsYXJpZnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMSwgbGluZSAxNTk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1Z2dlc3QgdG8gcmVtb3Zl IHRoZSZuYnNwO1NlZ21lbnQgUm91dGluZyBjYXNlLCBvdGhlcndpc2UsIHdlIGhhdmUgdG8gY28t d29yayB3aXRoIFNQUklORyBXRyBmb3IgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5HSU0mZ3Q7Jmd0OyBBcyBNUExTIGRhdGEgcGxhbmUgaXMgaW4gc2NvcGUgb2YgU1BSSU5HIFdH IHdlIGNlcnRhaW5seSB3aWxsIGFzayBpdCB0byByZXZpZXcgdGhpcyBkb2N1bWVudCBhbmQgd2Vs Y29tZSB0aGVpciBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2VjdGlvbiAzLCBsaW5lIDE4ODxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TVBMUyBsYWJlbCBpcyBvcmlnaW5hbGx5IGRlc2lnbmVkIHRvIGJl IGEgbG9jYWxseSB1bmlxdWUgbGFiZWwuIEJ1dCB0aGlzIGRyYWZ0IHByb3Bvc2UgdGhlIGxhYmVs IHRvIGJlIGdsb2JhbGx5IHVuaXF1ZS4gVGhhdCB3aWxsIGJyaW5nIG1hbnkgbmV3IHRoaW5ncywg ZS5nLiwgbGFiZWwgbWFuYWdlbWVudCBjb21wbGV4aXR5LCBsYWJlbCBzcGFjZSBsaW1pdGF0aW9u LCBldGMuIENvdWxkIHdlIGFjaGlldmUgdGhlDQogcHVycG9zZSBvZiZuYnNwO1BlcmZvcm1hbmNl IE1lYXN1cmVtZW50IGJ5IG90aGVyIHdheSwgZS5nLiwgYnkgdXNpbmcgcHN1ZWRvd2lyZSBiZXR3 ZWVuIHR3byBlbmRwb2ludHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R0lNJmd0OyZndDsgWWVz LCBTb3VyY2UgTGFiZWwgY2hhbmdlcyB1bmlxdWVuZXNzIHNjb3BlIGZyb20gbG9jYWwgdG8gc29t ZXRoaW5nIGVsc2UuIEFzIFlha292IHN1Z2dlc3RzIHRvIG1ha2UgZXhwbGljaXQgc3RhdGVtZW50 IHRoYXQgU291cmNlIExhYmVsIG11c3QgYmUgdW5pcXVlIG9ubHkgd2l0aGluIGdpdmVuIElHUCBk b21haW4gYW5kIG5vdCBnbG9iYWxseS4gSSBzZWUNCiB0aGUgcG9pbnQgaW4gc3VjaCBkZWZpbml0 aW9uIGJ1dCB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgaXQgbW9yZSwgZ2V0IG1vcmUgb3BpbmlvbnMg ZnJvbSB0aGUgZ3JvdXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNl Y3Rpb24gNC4xLCBsaW5lIDIzNjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TXkgY29uY2VybiBoZXJlIGlzLCBpcyBpdCB2YWx1YWJsZSB0byBnZXQg dGhlIG1lYXN1cmVtZW50IG9mIGEgUDJQIHBhdGggd2l0aGluIGEgTVAyUCBwYXRoIChpbiBzZWN0 aW9uIDEsIHlvdSBzYWlkLCBNUDJQIGlzIGEgcHJvYmxlbSkuIFRoZSBwZXJmb3JtYW5jZSB5b3Ug Z2V0IGF0IG9uZSB0aW1lIGZvciB0aGlzIFAyUCBwYXRoIGlzIHN1cmVseSBpbmZsdWVuY2VkIGJ5 IG90aGVyIFAyUCBwYXRoIG9mIHRoZQ0KIHNhbWUgTVAyUCBwYXRoLiBLZWVwIGluIG1pbmQgdGhh dCB0aGUgTFNQIGxhYmVsIHRlc3RlZCBpcyBhbHNvIHNoYXJlZCBieSBvdGhlciBQMlAgTFNQIHdp dGhpbiBzYW1lIE1QMlAgTFNQLjxicj4NCklmIHlvdSByZWFsbHkgd2FudCB0aGUgTVBMUyBwYXRo IHBlcmZvcm1hbmNlIGJldHdlZW4gdHdvIGVuZHBvaW50cyBpbiBMRFAgZW52aXJvbm1lbnQsIHN1 Z2dlc3QgdG8gdXNlIFBXIGluc3RlYWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R0lNJmd0OyZn dDsgQWxsIHBlcmZvcm1hbmNlIG1ldHJpY3MgYW5kIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG1l dGhvZHMgSSBrbm93IGJlZW4gZGVmaW5lZCBmb3IgcDJwLiBJZiB3ZSBsb29rIGF0IE1FRuKAmXMg bW9kZWwgZm9yIEV0aGVybmV0IFMtT0FNIFBNLCB0aGVuIGZvciBFLUxBTiBpdCBpcyBzdGlsbCBw MnAgbWVhc3VyZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNl Y3Rpb24gNi4xLjEsIGxpbmUgMzYxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGNvbmNlcm4gd2l0aCB0aGUgc2lnbmFsaW5n IG1lY2hhbmlzbS4gSW4gYSBsYXJnZSBuZXR3b3JrLCBpZiBvbmx5IG9uZSBMU1IgZG9lcyBub3Qg c3VwcG9ydCBTTEMsIHRoZW4gdGhlIHdob2xlIG5ldHdvcmsgY291bGQgbm90IHN1cHBvcnQgU0xD LiBJZiBvbmUgTFNSIGNoYW5nZXMgaXRzIFNMQyBzdGF0dXMsIGl0IHdpbGwgZmxvb2QgdG8gZXZl cnkgbm9kZS4gVGhhdCBtYXkgYnJpbmcgc29tZSBpbnN0YWJpbGl0eQ0KIHRvIHRoZSBuZXR3b3Jr LCBhbmQgbWFrZSB0aGUgc2lnbmFsaW5nIHVuc2NhbGFibGUuIEFuZCBpdCBtYXliZSBwb3NzaWJs ZSB0byBvcHRpbWl6ZSB0aGUgc2lnbmFsaW5nLiBUaGUgU0xDIHN0YXR1cyBmcm9tIHRoZSBuZXh0 IGhvcCBjb3VsZCBiZSB1c2VkIHRvIHNlbmQgdXBzdHJlYW0sIHJpZ2h0PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+R0lNJmd0OyZndDsgSSB0aGluayB0aGF0IG5vdCBhbGwgTFNScyBp biBhbiBJR1AgZG9tYWluIGFyZSByZXF1aXJlZCB0byBiZSBTTEMgYnV0IG9ubHkgZW5kLXBvaW50 cyBvZiBhbiBMU1AuIFRodXMsIGlmIGFuIExTUiBpcyBub3QgU0xDLCB0aGVuIFNMIGNhbm5vdCBi ZSB1c2VkIG9uIExTUHMgaXQgb3JpZ2luYXRlcy90ZXJtaW5hdGVzLiBDaGFuZ2UgaW4gU0xDLCBJ IGltYWdpbmUsDQogbWF5IGNvbWUgYXMgcmVzdWx0IG9mIFNXIHVwZ3JhZGUuIFRob3VnaCBpdCB3 b3VsZCB0cmlnZ2VkIGZsb29kIG9mIHVwZGF0ZXMgdGhhdCwgSU1PLCB3b3VsZCBiZSBvbmUtdGlt ZSBldmVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiA2 LjEuMiwgNi4xLjIuMzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2luY2UgUlNWUC1URSBMU1AgZG9lcyBub3QgaGF2ZSB0aGUgbWVhc3VyZW1lbnQg cHJvYmxlbSBsaXN0ZWQgaW4gdGhpcyBkcmFmdCwgd2h5IHdlIG5lZWQgdG8gZG8gUlNWUC1URSBl eHRlbnNpb24/IE1QLUJHUCBpcyBub3QgdXNlZCB0byBzZXR1cCBNUDJQIC8gTVAyTVAgTFNQLCB0 aGVuIHdoeSB3ZSBuZWVkIHRoZSBleHRlbnNpb24/IERpZCBJIG1pc3Mgc29tZXRoaW5nPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkdJTSZndDsmZ3Q7IEkgdGhpbmsgdGhhdCBSU1ZQLVRFIExTUCB3 aXRoIGxhYmVsIG1lcmdlIGFuZCBQSFAgc3RpbGwgaGF2ZSBpc3N1ZXMgZGVzY3JpYmVkIGluIHRo ZSBkb2N1bWVudC4gUGVyaGFwcyBvbmx5IE1QTFMtVFAgY29uc3RydWN0cyBoYXZlIGRldGVybWlu aXNtIG9mIHRyYW5zcG9ydCBuZXR3b3JrIGFuZCBtYXkgbm90IGhhdmUgdGhpcyBwcm9ibGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaXpob25nPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIEZy aWRheSwgTWF5IDIsIDIwMTQsIFJvc3MgQ2FsbG9uICZsdDs8YSBocmVmPSJtYWlsdG86cmNhbGxv bkBqdW5pcGVyLm5ldCI+cmNhbGxvbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkVyaWMsIFlpbWluLCBMaXpob25nOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Zb3UgaGF2 ZSBiZWVuIHNlbGVjdGVkIGFzIE1QTFMgUmV2aWV3IHRlYW0gcmV2aWV3ZXJzIGZvciBkcmFmdC1j aGVuLW1wbHMtc291cmNlLWxhYmVsLTAzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ob3RlIHRvIGF1dGhvcnM6IFlv dSBoYXZlIGJlZW4gQ0MnZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93IHRoYXQg dGhpcyByZXZpZXcgaXMgZ29pbmcgb24uIEhvd2V2ZXIsIHBsZWFzZSBkbyBub3QgcmV2aWV3IHlv dXIgb3duIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZXZpZXdzIHNob3VsZCBjb21tZW50IG9uIHdo ZXRoZXIgdGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LCBpcyBpdCB1c2VmdWwgKGllLCBpcyBpdCBs aWtlbHkgdG8gYmUgYWN0dWFsbHkgdXNlZnVsIGluIG9wZXJhdGlvbmFsIG5ldHdvcmtzKSwgYW5k IGlzIHRoZSBkb2N1bWVudCB0ZWNobmljYWxseQ0KIHNvdW5kPyZuYnNwOyBBbHNvLCBpcyB0aGUg dGV4dCBhbmQgZ3JhbW1hciB1bmRlcnN0YW5kYWJsZSAoaXQgZG9lc24ndCBuZWVkIHRvIGJlIHBl cmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZSByZWFzb25hYmx5IGNsZWFyKS4gV2Ug YXJlIGludGVyZXN0ZWQgaW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0 byBiZSBjb25zaWRlcmVkIGZvciBXRyBhZG9wdGlvbiAoaWUsIGl0IGRvZXNuJ3QgaGF2ZSB0byBi ZSBwZXJmZWN0DQogYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZSBhIGdvb2Qgc3RhcnQpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5SZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBhdXRob3Jz LCBXRyBjby1jaGFpcnMgYW5kIFdHIHNlY3JldGFyeSwgYW5kIENDJ2QgdG8gdGhlIE1QTFMgV0cg ZW1haWwgbGlzdC4gSWYgbmVjZXNzYXJ5LCBDb21tZW50cyBtYXkgYmUgc2VudCBwcml2YXRlbHkg dG8gb25seSB0aGUNCiBXRyBjaGFpcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFyZSB5b3UgYWJsZSB0byByZXZp ZXcgdGhpcyBkcmFmdCBieSBNYXkgMTYsIDIwMTQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcywgUm9zczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KGFzIE1QTFMgV0cgY2hhaXIpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B7B12A5eusaamb103erics_-- From nobody Wed May 14 11:01: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 46D2E1A015B for ; Wed, 14 May 2014 11:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEq_Q6AS_lVQ for ; Wed, 14 May 2014 11:01:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id 290751A0147 for ; Wed, 14 May 2014 11:01:27 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB213.namprd05.prod.outlook.com (10.255.191.17) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 18:01:20 +0000 Received: from BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) by BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) with mapi id 15.00.0929.001; Wed, 14 May 2014 18:01:20 +0000 From: Yimin Shen To: Yakov Rekhter , Mach Chen Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPb5aWYo8VFBvL90KqjdHzhd5S05tAXR0w Date: Wed, 14 May 2014 18:01:19 +0000 Message-ID: <9ea5176fb86d4f719498d88cff17b2b2@BLUPR05MB722.namprd05.prod.outlook.com> References: <201405141703.s4EH3eL92691@magenta.juniper.net> In-Reply-To: <201405141703.s4EH3eL92691@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(52604005)(377454003)(199002)(13464003)(164054003)(189002)(92566001)(66066001)(80022001)(81542001)(46102001)(74662001)(81342001)(1941001)(85852003)(74316001)(77982001)(76576001)(79102001)(99286001)(83072002)(99396002)(74502001)(54356999)(86362001)(77096999)(76176999)(2656002)(31966008)(50986999)(87936001)(4396001)(20776003)(19580405001)(101416001)(561944003)(64706001)(76482001)(33646001)(21056001)(83322001)(19580395003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB213; H:BLUPR05MB722.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=yshen@juniper.net; 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/EikZkXjFvNrO06TVcwBZWfJe5uU Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 18:01:30 -0000 Hi Mach, Taking Yakov's point as well, I think granularity and scope are two things = that draft would need to make additional consideration when defining the se= mantics of SL.=20 Once that is decided, it will in turn shape the requirements for SL allocat= ion and distribution. Allocation and distribution would need to be done in = a scalable and manageable fashion. Configuration and static provisioning ca= nnot scale well. Therefore some protocols or protocol extensions are needed= here. This is where inter-operability would demand standardization. Withou= t a detailed specification for allocation and distribution, it is difficult= to evaluate the feasibility and usability of the proposal. So I think this= should be in-scope for this draft. Thanks for pointing out draft-chen-ospf-source-label-distribution-00 and dr= aft-chen-isis-source-label-distribution-00. I'd like to suggest to incorpor= ate them into the current draft. OTOH, both drafts currently assume per-nod= e SL and intra-area scope, which remains to be seen as sufficient or not, p= er the granularity and scope above. Thanks, /Yimin -----Original Message----- From: Yakov Rekhter=20 Sent: Wednesday, May 14, 2014 1:04 PM To: Mach Chen Cc: Yimin Shen; draft-chen-mpls-source-label@tools.ietf.org; mpls-chairs@to= ols.ietf.org; Martin Vigoureux; mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label=20 Mach, > Hi Yimin, >=20 > Thanks for your detail review and valuable comments on the draft! >=20 > Please see my reply inline... few comments in-line below... > > -----Original Message----- > > From: Mach Chen > > Sent: Tuesday, May 13, 2014 6:18 PM > > To: Mach Chen > > Subject: FW: MPLS-RT review of draft-chen-mpls-source-label > >=20 > >=20 > >=20 > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen > > Sent: Monday, May 12, 2014 9:53 PM > > To: draft-chen-mpls-source-label@tools.ietf.org;=20 > > mpls-chairs@tools.ietf.org ; > > Martin Vigoureux > > Cc: mpls@ietf.org > > Subject: [mpls] MPLS-RT review of draft-chen-mpls-source-label > >=20 > > WG chairs, authors, > >=20 > > I have finished my review for this draft. Overall, I think the=20 > > document is easy to > > understand, and useful from the perspective that the mechanism may=20 > > support egress routers to identify source of traffic for measurement pu= rposes. >=20 > Thanks. >=20 > >=20 > > From technical perspetive, I do have the following comments, and=20 > > hope the authors can address them before WG adoption. > >=20 > > 1. Granularity of SL > >=20 > > The document currently views "sources" as ingress nodes, hence=20 > > assumes the granularity of SL as per-node. From a generic point of=20 > > view, I'd like to se e some > > discussion on per-flow SL (multiple flows ingress on a given node),=20 > > or why this > > mode may not be useful. >=20 > I personally open to this point and had thought about this. There are=20 > scenari os that may need multiple SLs. I'd like to hear more opinions from the WG.= =20 >=20 > >=20 > > 2. SL's allocation and disbritubtion. > >=20 > > I think this is a big missing piece. The draft currently pushes this=20 > > out of scope. > > However, the procedures of how a router may allocate an SL for=20 > > itself without colliding with other routers, and how a source-to-SL=20 > > mapping may be disctributed to egress routers are both relavant and=20 > > important to the proposal. > > Therefore, > > they should be specified in this draft for completeness. >=20 > Regarding to the allocation, this is same as the IP address=20 > allocation, "segment index" allocation. Saying that it is the same as "IP address allocation" is a bit misleading, = as for IP allocation we have a hierarchy of allocation authorities that int= ended to provide *globally* unique allocation of IP addresses. > In practice, this is the task of the operators to guarantee the uniquenes= s.=20 Saying that "this is the task of the operators to guarantee the uniqueness"= , assumes that providing such guarantee=20 is fully within the control of the operator, which may = =20 not be the case when not all the equipment is under control =20 of a single operator. > It's more about a deployment issue. The operator could use either=20 > static or dynamic mechanisms to achieve this. >=20 > As for the distribution, seems that IGP extension is a reasonable=20 > choice, normally, the IGP extensions will be defined in draft-xxx-ospf=20 > or draft-xxx-isis, means it's better to define the distribution=20 > mechanisms in separate document. And actually, there are two initial=20 > drafts submitted (draft-chen-ospf-source-lab el-distribution-00 and=20 > draft-chen-isis-source-label-distribution-00). Given all this and my comments above, I wonder whether the document should = explicitly spell out that the scope of source-label is a single IGP domain,= and also spell out what should be done to prevent source labels to leak ac= ross IGP domain boundaries. Yakov. From nobody Wed May 14 20:17: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 0E9C51A03A9 for ; Wed, 14 May 2014 20:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 zbEQpT0_4qsx for ; Wed, 14 May 2014 20:17:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0561A0380 for ; Wed, 14 May 2014 20:17:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU08277; Thu, 15 May 2014 03:16:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 04:15:50 +0100 Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 04:16:49 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.79]) by SJCEML701-CHM.china.huawei.com ([169.254.3.206]) with mapi id 14.03.0158.001; Wed, 14 May 2014 20:16:44 -0700 From: Huaimo Chen To: Autumn Liu , Yimin Shen , "Ross Callon" , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaSV8o/K71U51ukWB9kHnTmwa65s34q2AgAkYsaA= Date: Thu, 15 May 2014 03:16:43 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C68100@SJCEML703-CHM.china.huawei.com> References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C66C94@SJCEML703-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.77] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C68100SJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/g46tqoBl8cZUTL4_uZ0mcbg_uJg Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 03:17:06 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C68100SJCEML703CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Autumn, Thanks for your questions! My answers are inline below. Best Regards, Huaimo From: Autumn Liu [mailto:autumn.liu@ericsson.com] Sent: Thursday, May 08, 2014 8:44 PM To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Huaimo, I have some questions. 1) How Inner label (vpn label) acquired on primary egress node is sent= to backup egress node? Via PATH message for backup LSP? which object is us= ed? How this label is processed? How this label is maintained? [Huaimo] An inner label (such as VPN label) allocated on the primary egress= node may be sent to the backup egress node in one of a few ways. One way i= s to use BGP to send the inner label to the backup egress node from the pri= mary egress node. Alternatively, the inner label may be sent from the prima= ry egress node to the upstream node of the primary egress node through an E= GRESS-BACKUP object in RESV message and then the upstream node sends the in= ner label to the backup egress node via an EGRESS-BACKUP object in the PAT= H message for the backup LSP. When the backup egress node receives the inne= r label as a UA label originally from the primary egress, it adds a forward= ing entry with the label into the LFIB for the primary egress node. When th= e backup egress node receives a packet from the backup LSP, it uses the top= label as a context label to find the LFIB for the primary egress node and = the inner label to deliver the packet to the same destination as the primar= y egress node according to the LFIB. Note that exactly how the inner label is sent from the primary egress node = to the backup egress node is out of scope for this document. 2) How PLR can acquire a path to backup egress node, its address is th= e same as primary egress node? [Huaimo] PLR gets the backup egress node first and then computes a path fro= m the PLR to the backup egress node. The backup egress node may be configur= ed by an operator on the ingress of the primary LSP. If it is configured, t= he ingress will include the backup egress node in the PATH message through = using EGRESS_BACKUP object. If the backup egress node is not given by the o= perator, the PLR tries to find the backup egress node, which is not the pri= mary egress node but has the same IP address as the destination IP address = of the LSP. Note that the primary egress node and the backup egress node S= HOULD have a same local address configured, and the cost to the local addre= ss on the backup egress node SHOULD be much bigger than the cost to the loc= al address on the primary egress node. 3) Does PLR sends the PATH message for primary LSP to backup egress no= de? [Huaimo] No. Thanks, Autumn From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, May 06, 2014 5:20 AM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, It is not clear for me what you mean with "the egress protection of p2p= LSP needs to be addressed specifically with the draft." Can you please supply some text that addresses the issue(s) you mention= ed. Best Regards, Huaimo From: Huaimo Chen Sent: Monday, May 05, 2014 5:05 PM To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org Subject: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_5316A0AB3C851246A7CA5758973207D445C68100SJCEML703CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Autumn,

 <= /p>

Thanks for your questions!

My answers are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Autumn L= iu [mailto:autumn.liu@ericsson.com]
Sent: Thursday, May 08, 2014 8:44 PM
To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Huaimo,

 <= /p>

I have some questions.

1) = ;     How Inner label (= vpn label) acquired on primary egress node is sent to backup egress node? V= ia PATH message for backup LSP? which object is used? How this label is processed? How this label is maintained?

[Huaimo] An inner label (= such as VPN label) allocated on the primary egress node may be sent to the = backup egress node in one of a few ways. One way is to use BGP to send the inner label to the backup egress node from the primary egr= ess node. Alternatively, the inner label may be sent from the primary egres= s node to the upstream node of the primary egress node through an EGRESS-BA= CKUP object in RESV message and then the upstream node sends the inner label to the backup egress node via=  an EGRESS-BACKUP object in the PATH message for the backup LSP. When= the backup egress node receives the inner label as a UA label originally f= rom the primary egress, it adds a forwarding entry with the label into the LFIB for the primary egress node. When the b= ackup egress node receives a packet from the backup LSP, it uses the top la= bel as a context label to find the LFIB for the primary egress node and the= inner label to deliver the packet to the same destination as the primary egress node according to the LFIB. =  

Note that exactly how the= inner label is sent from the primary egress node to the backup egress node= is out of scope for this document.

2) = ;     How PLR can acqui= re a path to backup egress node, its address is the same as primary egress = node?

[Huaimo] PLR gets the bac= kup egress node first and then computes a path from the PLR to the backup e= gress node. The backup egress node may be configured by an operator on the ingress of the primary LSP. If it is configured, the in= gress will include the backup egress node in the PATH message through using= EGRESS_BACKUP object. If the backup egress node is not given by the operat= or, the PLR tries to find the backup egress node, which is not the primary egress node but has the same IP addr= ess as the destination IP address of the LSP.  Note that the primary e= gress node and the backup egress node SHOULD have a same local address conf= igured, and the cost to the local address on the backup egress node SHOULD be much bigger than the cost to the local= address on the primary egress node.

3) = ;     Does PLR sends th= e PATH message for primary LSP to backup egress node?

[Huaimo] No.

Thanks,=

Autumn<= /p>

 <= /span>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Tuesday, May 06, 2014 5:20 AM
To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Autumn,

 

    It is not clear for me what yo= u mean with “the egress protection of p2p LSP needs to be addressed s= pecifically with the draft.”

    Can you please supply some tex= t that addresses the issue(s) you mentioned.

 

Best Regards,

Huaimo

From: Huaimo C= hen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: draft-ietf-mpls-rsvp-egress-protection-00=

 

Hi Autumn,

 <= /p>

Can you elaborate a little bit on “the egress protection of p2p LS= P needs to be addressed specifically with the draft.”?

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

 <= /p>

I am ok with the name cha= nge, and agree with Yimin that the egress protection of p2p LSP needs to be= addressed specifically with the draft.

-Autumn=

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

Hi chairs, authors,<= /o:p>

 <= /p>

To help make this draft m= ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe= rentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed= by inner labels (i.e. service labels).

 <= /p>

Of course, a complete sol= ution for P2P LSP egress protection will require extensions to Layer-2/3 VP= N service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have = already been addressed by some existing IETF work and drafts, this draft co= uld refer to them in the text.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 

--_000_5316A0AB3C851246A7CA5758973207D445C68100SJCEML703CHMchi_-- From nobody Thu May 15 01:06:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFEF1A041A for ; Thu, 15 May 2014 01:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 OnSrz11GttHl for ; Thu, 15 May 2014 01:06:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97CC1A0412 for ; Thu, 15 May 2014 01:06:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU29237; Thu, 15 May 2014 08:06:27 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 09:05:46 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 09:06:23 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Thu, 15 May 2014 16:06:21 +0800 From: Mach Chen To: Yakov Rekhter Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPb5aCW69ugCsIcUW1W6srQwTcrZtA2AVQ Date: Thu, 15 May 2014 08:06:19 +0000 Message-ID: References: <201405141703.s4EH3eL92691@magenta.juniper.net> In-Reply-To: <201405141703.s4EH3eL92691@magenta.juniper.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/FBGslznj2pXBE4ltcy4cUdHJSXA Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:06:41 -0000 Hi Yakov, Thanks for your comments! See my reply inline... > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Thursday, May 15, 2014 1:04 AM > To: Mach Chen > Cc: Yimin Shen; draft-chen-mpls-source-label@tools.ietf.org; > mpls-chairs@tools.ietf.org; Martin Vigoureux; mpls@ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label Sniped. > > > > > > 2. SL's allocation and disbritubtion. > > > > > > I think this is a big missing piece. The draft currently pushes this > > > out of scope. > > > However, the procedures of how a router may allocate an SL for > > > itself without colliding with other routers, and how a source-to-SL > > > mapping may be disctributed to egress routers are both relavant and > > > important to the proposal. > > > Therefore, > > > they should be specified in this draft for completeness. > > > > Regarding to the allocation, this is same as the IP address > > allocation, "segment index" allocation. >=20 > Saying that it is the same as "IP address allocation" is a bit misleading= , as for IP > allocation we have a hierarchy of allocation authorities that intended to= provide > *globally* unique allocation of IP addresses. Here the "Same as IP address allocation" is just an analog, there are simil= ar cases that require to guarantee the uniqueness of IDs, for example, Rout= er ID.=20 IMHO, the allocation is more like a management policy issue other than a te= chnical issue, it may not be suitable to discuss it in this document.=20 =20 In addition, the Source Label is not intended to be *globally* unique. The = draft says: "In its function as a Source Label, it MUST be unique within a domain. In cases where a Source Label is used across domains it MUST be unique within the scope it is used." >=20 > > In practice, this is the task of the operators to guarantee the uniquen= ess. >=20 > Saying that "this is the task of the operators to guarantee the uniquenes= s", > assumes that providing such guarantee > is fully within the control of the operator, which may > not be the case when not all the equipment is under control > of a single operator. Yes, for a single operator, to guarantee the uniqueness is relevant easy. F= or multiple operators case, if they want to use the source label across dom= ains, they have to make an agreement how to allocate the source label and m= ake sure the uniqueness. =20 >=20 > > It's more about a deployment issue. The operator could use either > > static or dynamic mechanisms to achieve this. > > > > As for the distribution, seems that IGP extension is a reasonable > > choice, normally, the IGP extensions will be defined in draft-xxx-ospf > > or draft-xxx-isis, means it's better to define the distribution > > mechanisms in separate document. And actually, there are two initial > > drafts submitted (draft-chen-ospf-source-lab el-distribution-00 and > > draft-chen-isis-source-label-distribution-00). >=20 > Given all this and my comments above, I wonder whether the document shoul= d > explicitly spell out that the scope of source-label is a single IGP domai= n, and also > spell out what should be done to prevent source labels to leak across IGP= domain > boundaries. Presumably, most of the cases, SL is used within a single administrative do= main, but there may be requirement to use SL across domains. I'd like to he= ar more opinions from WG about the scope of the SL.=20 Thanks, Mach >=20 > Yakov. From nobody Thu May 15 01:38: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 835381A0417 for ; Thu, 15 May 2014 01:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 MwkLRcOAU2L2 for ; Thu, 15 May 2014 01:38:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE3C1A0413 for ; Thu, 15 May 2014 01:38:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU32840; Thu, 15 May 2014 08:38:20 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 09:37:38 +0100 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 09:38:15 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Thu, 15 May 2014 16:38:09 +0800 From: Mach Chen To: Yimin Shen , Yakov Rekhter Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPb56JQ8bpSPI8AEC4VFj6anLGgJtBSgaQ Date: Thu, 15 May 2014 08:38:07 +0000 Message-ID: References: <201405141703.s4EH3eL92691@magenta.juniper.net> <9ea5176fb86d4f719498d88cff17b2b2@BLUPR05MB722.namprd05.prod.outlook.com> In-Reply-To: <9ea5176fb86d4f719498d88cff17b2b2@BLUPR05MB722.namprd05.prod.outlook.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/s52DCSu3tnnRgt01imTs5uKtSv4 Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:38:39 -0000 Hi Yimin, I'd like to encourage more people to express their opinions about the granu= larity and scope of the SL. Regarding allocation and distribution, IMHO, they may not belong to this ba= se document. There are separate drafts for defining distribution of SL, and= for the allocation, as replied to Yakov, it's a management policy issue ot= her than a technical issue.=20 Thanks, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen > Sent: Thursday, May 15, 2014 2:01 AM > To: Yakov Rekhter; Mach Chen > Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label >=20 > Hi Mach, >=20 > Taking Yakov's point as well, I think granularity and scope are two thing= s that draft > would need to make additional consideration when defining the semantics o= f SL. >=20 > Once that is decided, it will in turn shape the requirements for SL alloc= ation and > distribution. Allocation and distribution would need to be done in a scal= able and > manageable fashion. Configuration and static provisioning cannot scale we= ll. > Therefore some protocols or protocol extensions are needed here. This is = where > inter-operability would demand standardization. Without a detailed specif= ication > for allocation and distribution, it is difficult to evaluate the feasibil= ity and usability > of the proposal. So I think this should be in-scope for this draft. >=20 > Thanks for pointing out draft-chen-ospf-source-label-distribution-00 and > draft-chen-isis-source-label-distribution-00. I'd like to suggest to inco= rporate > them into the current draft. OTOH, both drafts currently assume per-node = SL and > intra-area scope, which remains to be seen as sufficient or not, per the > granularity and scope above. >=20 > Thanks, >=20 > /Yimin >=20 >=20 > -----Original Message----- > From: Yakov Rekhter > Sent: Wednesday, May 14, 2014 1:04 PM > To: Mach Chen > Cc: Yimin Shen; draft-chen-mpls-source-label@tools.ietf.org; > mpls-chairs@tools.ietf.org; Martin Vigoureux; mpls@ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label >=20 > Mach, >=20 > > Hi Yimin, > > > > Thanks for your detail review and valuable comments on the draft! > > > > Please see my reply inline... >=20 > few comments in-line below... >=20 > > > -----Original Message----- > > > From: Mach Chen > > > Sent: Tuesday, May 13, 2014 6:18 PM > > > To: Mach Chen > > > Subject: FW: MPLS-RT review of draft-chen-mpls-source-label > > > > > > > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen > > > Sent: Monday, May 12, 2014 9:53 PM > > > To: draft-chen-mpls-source-label@tools.ietf.org; > > > mpls-chairs@tools.ietf.org > ; > > > Martin Vigoureux > > > Cc: mpls@ietf.org > > > Subject: [mpls] MPLS-RT review of draft-chen-mpls-source-label > > > > > > WG chairs, authors, > > > > > > I have finished my review for this draft. Overall, I think the > > > document is > easy to > > > understand, and useful from the perspective that the mechanism may > > > support egress routers to identify source of traffic for measurement > purposes. > > > > Thanks. > > > > > > > > From technical perspetive, I do have the following comments, and > > > hope the authors can address them before WG adoption. > > > > > > 1. Granularity of SL > > > > > > The document currently views "sources" as ingress nodes, hence > > > assumes the granularity of SL as per-node. From a generic point of > > > view, I'd like to se > e some > > > discussion on per-flow SL (multiple flows ingress on a given node), > > > or why > this > > > mode may not be useful. > > > > I personally open to this point and had thought about this. There are > > scenari > os that may need multiple SLs. I'd like to hear more opinions from the WG= . > > > > > > > > 2. SL's allocation and disbritubtion. > > > > > > I think this is a big missing piece. The draft currently pushes this > > > out of scope. > > > However, the procedures of how a router may allocate an SL for > > > itself without colliding with other routers, and how a source-to-SL > > > mapping may be disctributed to egress routers are both relavant and > > > important to the proposal. > > > Therefore, > > > they should be specified in this draft for completeness. > > > > Regarding to the allocation, this is same as the IP address > > allocation, "segment index" allocation. >=20 > Saying that it is the same as "IP address allocation" is a bit misleading= , as for IP > allocation we have a hierarchy of allocation authorities that intended to= provide > *globally* unique allocation of IP addresses. >=20 > > In practice, this is the task of the operators to guarantee the uniquen= ess. >=20 > Saying that "this is the task of the operators to guarantee the uniquenes= s", > assumes that providing such guarantee > is fully within the control of the operator, which may > not be the case when not all the equipment is under control > of a single operator. >=20 > > It's more about a deployment issue. The operator could use either > > static or dynamic mechanisms to achieve this. > > > > As for the distribution, seems that IGP extension is a reasonable > > choice, normally, the IGP extensions will be defined in draft-xxx-ospf > > or draft-xxx-isis, means it's better to define the distribution > > mechanisms in separate document. And actually, there are two initial > > drafts submitted (draft-chen-ospf-source-lab el-distribution-00 and > > draft-chen-isis-source-label-distribution-00). >=20 > Given all this and my comments above, I wonder whether the document shoul= d > explicitly spell out that the scope of source-label is a single IGP domai= n, and also > spell out what should be done to prevent source labels to leak across IGP= domain > boundaries. >=20 > Yakov. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu May 15 07:58: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 F26FF1A02A0 for ; Thu, 15 May 2014 07:57:57 -0700 (PDT) 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_OFF=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 PVutDD6AT4bb for ; Thu, 15 May 2014 07:57:55 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2591A00BE for ; Thu, 15 May 2014 07:57:55 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so1078669igd.14 for ; Thu, 15 May 2014 07:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IFKQH7vDuJmjtSjbDVrdvyNEntz/V4jsK+mentZx9C8=; b=tcrHPIH2hgiNCICiCz2pAXjU5U0GqkV/1B3ZIVXCzmaTtZgJv7GN6md4dhX7xCvFdi MaCqVp6JJSRlgoBkeJmuurUotIcYTpHxqDtvAFwg4KpTjjWcIJRc5TWhcrFHxo1xn3lI DjyBVm2z72s1tOkFJC7KkFq7MnIMW+R4h5TMn55Ehmx4Kf75jWIzIDoA48o5gT6FBj0n Fq9lokyzazZIDIjwXStcw9GrxWgkO1GKJ+/DjBDb48aZeki7EwPqsLa6N5WCPgy4BVL5 Bhdzfklu9oMUIe0GpHh+TvDU75G+L8LFds+34Rxk1ge+wYkAG+PBeU3MS/k7PFybL1jy n2HQ== MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr73056189igl.29.1400165868108; Thu, 15 May 2014 07:57:48 -0700 (PDT) Received: by 10.42.95.208 with HTTP; Thu, 15 May 2014 07:57:47 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7B12A5@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B7B12A5@eusaamb103.ericsson.se> Date: Thu, 15 May 2014 22:57:47 +0800 Message-ID: From: Lizhong Jin To: Gregory Mirsky Content-Type: multipart/alternative; boundary=089e010d8dd63201c704f97185d8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1Adn_sihILNJBtdMEUTG2Co6TmA Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Ross Callon Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 14:57:58 -0000 --089e010d8dd63201c704f97185d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for the reply. See more inline below. Regards Lizhong On Thursday, May 15, 2014, Gregory Mirsky wrote: > Hi Lizhong, > > many thanks for you kind consideration of our work and thoughtful > comments. Please find my notes in-line and tagged GIM>>. > > > > Regards, > > Greg > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] > *On Behalf Of *Lizhong Jin > *Sent:* Wednesday, May 14, 2014 8:22 AM > *To:* draft-chen-mpls-source-label@tools.ietf.org > *Cc:* mpls-chairs@tools.ietf.org; > mpls@ietf.org ; Ross Callo= n > *Subject:* Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label > > > > Hi authors, > > I finished the review, and the text is easy to understandable. I have som= e > technical comments and concerns before adoption. Hope the authors could > help to clarify. > > > > Section 1, line 159 > > Suggest to remove the Segment Routing case, otherwise, we have to co-work > with SPRING WG for this draft. > > GIM>> As MPLS data plane is in scope of SPRING WG we certainly will ask i= t > to review this document and welcome their comments. > > > > Section 3, line 188 > > MPLS label is originally designed to be a locally unique label. But this > draft propose the label to be globally unique. That will bring many new > things, e.g., label management complexity, label space limitation, etc. > Could we achieve the purpose of Performance Measurement by other way, e.g= ., > by using psuedowire between two endpoints. > > GIM>> Yes, Source Label changes uniqueness scope from local to something > else. As Yakov suggests to make explicit statement that Source Label must > be unique only within given IGP domain and not globally. I see the point = in > such definition but would like to discuss it more, get more opinions from > the group. > > > > Section 4.1, line 236 > > My concern here is, is it valuable to get the measurement of a P2P path > within a MP2P path (in section 1, you said, MP2P is a problem). The > performance you get at one time for this P2P path is surely influenced by > other P2P path of the same MP2P path. Keep in mind that the LSP label > tested is also shared by other P2P LSP within same MP2P LSP. > If you really want the MPLS path performance between two endpoints in LDP > environment, suggest to use PW instead. > > GIM>> All performance metrics and performance measurement methods I know > been defined for p2p. If we look at MEF=E2=80=99s model for Ethernet S-OA= M PM, then > for E-LAN it is still p2p measurement. > > > > Section 6.1.1, line 361 > > I have concern with the signaling mechanism. In a large network, if only > one LSR does not support SLC, then the whole network could not support SL= C. > If one LSR changes its SLC status, it will flood to every node. That may > bring some instability to the network, and make the signaling unscalable. > And it maybe possible to optimize the signaling. The SLC status from the > next hop could be used to send upstream, right? > > GIM>> I think that not all LSRs in an IGP domain are required to be SLC > but only end-points of an LSP. Thus, if an LSR is not SLC, then SL cannot > be used on LSPs it originates/terminates. Change in SLC, I imagine, may > come as result of SW upgrade. Though it would trigged flood of updates > that, IMO, would be one-time event. > [Lizhong] in an LDP network, every node would be possibly to be egress of an FEC. In the draft, it says: An LSR X may receive multiple Label Mappings for a given FEC F from its neighbors. In its turn, X may advertise a Label Mapping for F to its neighbors. If X understands the SLC TLV, and if any of the advertisements it received for FEC F does not include the SLC TLV, X MUST NOT include the SLC TLV in its own advertisements of F. In DU mode, the mapping advertisement will be influenced by other received advertisement, which will bring more signaling. This is not one-time event, any LDP session UP/DOWN will influence the whole signaling. But why don't you limit the received advertisement only from the downstream node, not all nodes? Only the received advertisement from downstream node does not SLC TLV, X must not include SLC TLV. Section 6.1.2, 6.1.2.3 > > Since RSVP-TE LSP does not have the measurement problem listed in this > draft, why we need to do RSVP-TE extension? MP-BGP is not used to setup > MP2P / MP2MP LSP, then why we need the extension? Did I miss something? > > GIM>> I think that RSVP-TE LSP with label merge and PHP still have issues > described in the document. Perhaps only MPLS-TP constructs have determini= sm > of transport network and may not have this problem. > [Lizhong] PHP could be disabled for RSVP-TE LSP. Which case has label merge for RSVP-TE LSP? Anyway, if you think RSVP-TE also has issue, you should say that in section 1. However, using source label to do LM for RSVP-TE LSP may not be helpful, since the RSVP-TE label is more accurate to identify an LSP, including source + destination + tunnel ID + LSP ID + PHB, etc. > > > Regards > > Lizhong > > > > > On Friday, May 2, 2014, Ross Callon > > wrote: > > Eric, Yimin, Lizhong; > > > > You have been selected as MPLS Review team reviewers for > draft-chen-mpls-source-label-03. > > > > 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? Also, is the text and grammar > understandable (it doesn't need to be perfect at this point, but should b= e > reasonably clear). 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. > > > > Are you able to review this draft by May 16, 2014? > > > > Thanks, Ross > > (as MPLS WG chair) > > > --089e010d8dd63201c704f97185d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

Thanks for the reply. See more inlin= e below.

Regards

Lizhong<= /div>
On Thursday, May 15, 2014, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Lizhong,=

many thanks for you kind = consideration of our work and thoughtful comments. Please find my notes in-= line and tagged GIM>>.

=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 Regards,=

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Wednesday, May 14, 2014 8:22 AM
To: draft-chen-mpls-s= ource-label@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org; mpls@ietf.org; Ross Callon
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label

=C2=A0

Hi authors,

I finished the review, and the text is easy to under= standable. I have some technical comments and concerns before adoption. Hop= e the authors could help to clarify.

=C2=A0

Section 1, line 159

Suggest to remove the=C2=A0Segment Routing case, oth= erwise, we have to co-work with SPRING WG for this draft.

GIM>> As MPLS da= ta plane is in scope of SPRING WG we certainly will ask it to review this d= ocument and welcome their comments.

=C2=A0

Section 3, line 188

MPLS label is originally designed to be a locally un= ique label. But this draft propose the label to be globally unique. That wi= ll bring many new things, e.g., label management complexity, label space li= mitation, etc. Could we achieve the purpose of=C2=A0Performance Measurement by other way, e.g., by using psued= owire between two endpoints.

GIM>> Yes, Sourc= e Label changes uniqueness scope from local to something else. As Yakov sug= gests to make explicit statement that Source Label must be unique only with= in given IGP domain and not globally. I see the point in such definition but would like to discuss it more, get more o= pinions from the group.

=C2=A0

Section 4.1, line 236

My concern here is, is it valuable to get the measur= ement of a P2P path within a MP2P path (in section 1, you said, MP2P is a p= roblem). The performance you get at one time for this P2P path is surely in= fluenced by other P2P path of the same MP2P path. Keep in mind that the LSP label tested is also shared by o= ther P2P LSP within same MP2P LSP.
If you really want the MPLS path performance between two endpoints in LDP e= nvironment, suggest to use PW instead.

GIM>> All perfor= mance metrics and performance measurement methods I know been defined for p= 2p. If we look at MEF=E2=80=99s model for Ethernet S-OAM PM, then for E-LAN= it is still p2p measurement.

=C2=A0

Section 6.1.1, line 361

I have concern with the signaling mechanism. In a la= rge network, if only one LSR does not support SLC, then the whole network c= ould not support SLC. If one LSR changes its SLC status, it will flood to e= very node. That may bring some instability to the network, and make the signaling unscalable. And it maybe possible t= o optimize the signaling. The SLC status from the next hop could be used to= send upstream, right?

GIM>> I think th= at not all LSRs in an IGP domain are required to be SLC but only end-points= of an LSP. Thus, if an LSR is not SLC, then SL cannot be used on LSPs it o= riginates/terminates. Change in SLC, I imagine, may come as result of SW upgrade. Though it would trigged flood of updates= that, IMO, would be one-time event.

[Lizhong] in an LDP network, every node would be possibly to be egress of = an FEC. In the draft, it says:
An LSR X may= receive multiple Label Mappings for a given

=C2=A0 =C2=A0FEC F from its neigh= bors. =C2=A0In its turn, X may advertise a Label
=C2=A0 =C2=A0Mapp= ing for F to its neighbors. =C2=A0If X understands the SLC TLV, and if
=C2=A0 = =C2=A0any of the advertisements it received for FEC F does not include the<= /font>
=C2=A0 =C2=A0SLC = TLV, X MUST NOT include the SLC TLV in its own advertisements of
=C2=A0 =C2=A0F.=

In D= U mode, the mapping advertisement will be influenced by other received adve= rtisement, which will bring more signaling. This is not one-time event, any= LDP session UP/DOWN will influence the whole signaling. But why don't = you limit the received advertisement only from the downstream node, not all= nodes? Only the received advertisement from downstream node does not SLC T= LV, X must not include SLC TLV.

Section 6.1.2, 6.1.2.3

Since RSVP-TE LSP does not have the measurement prob= lem listed in this draft, why we need to do RSVP-TE extension? MP-BGP is no= t used to setup MP2P / MP2MP LSP, then why we need the extension? Did I mis= s something?

GIM>> I think th= at RSVP-TE LSP with label merge and PHP still have issues described in the = document. Perhaps only MPLS-TP constructs have determinism of transport net= work and may not have this problem.

[Lizhong] PHP could be disabled for RSV= P-TE LSP. Which case has label merge for RSVP-TE LSP? Anyway, if you think = RSVP-TE also has issue, you should say that in section 1. However, using so= urce label to do LM for RSVP-TE LSP may not be helpful, since the RSVP-TE l= abel is more accurate to identify an LSP, including source + destination + = tunnel ID + LSP ID + PHB, etc.=C2=A0

=C2=A0

Regards

Lizhong

=C2=A0


On Friday, May 2, 2014, Ross Callon <rcallon@juni= per.net> wrote:

Eric, Yimin, Lizhong;

=C2=A0

You have been selected as MPLS Review t= eam reviewers for draft-chen-mpls-source-label-03.

=C2=A0

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.

=C2=A0

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?=C2=A0 Also, is the text and grammar understandable (it doesn't = need to be perfect at this point, but should be reasonably clear). We are i= nterested 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).

=C2=A0

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

=C2=A0

Are you able to review this draft by Ma= y 16, 2014?

=C2=A0

Thanks, Ross

(as MPLS WG chair)=

=C2=A0

--089e010d8dd63201c704f97185d8-- From nobody Thu May 15 08:50:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7C91A0642 for ; Thu, 15 May 2014 08:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKqEs5KpuuEl for ; Thu, 15 May 2014 08:50:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C690F1A05E5 for ; Thu, 15 May 2014 08:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3101; q=dns/txt; s=iport; t=1400169004; x=1401378604; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=B+/pdLmlQvjuygPcjQtwW7jWp55MzsVdowdUAhfPz/8=; b=XxIFyJof5+W4l8Dub09iFzI5jVJuIxe0+AoPYO9pxr6NBZCeLwfKtCit SIX4/MSGwpHr+ETqk+dWyHpK6jOy+MQvn9sTwh/rxHEU51bXlHrsfh1y+ oM5GBlu1Gquqp594JaqrUPwKkDM+VrKGPyBWq4z4VHfG4Jb6XCtu8/AUp 0=; X-IronPort-AV: E=Sophos;i="4.97,1060,1389744000"; d="scan'208";a="325190903" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 15 May 2014 15:50:03 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4FFo3sF014675; Thu, 15 May 2014 15:50:03 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id 00D87789; Thu, 15 May 2014 11:50:02 -0400 (EDT) From: Eric Rosen To: Mach Chen In-reply-to: Your message of Tue, 13 May 2014 10:39:40 -0000. Date: Thu, 15 May 2014 11:50:02 -0400 Message-ID: <3798.1400169002@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Auyfy6Z_XDEsCS47YPeL7-gEPDo Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:50:34 -0000 Mach> As for the distribution, seems that IGP extension is a reasonable Mach> choice, The distribution mechanism needs to ensure that each egress LSR will learn the source label of each ingress LSR. There are MPLS deployments in which an ingress LSR may be separated from an egress LSR by multiple Autonomous Systems, each of which consists of at least one IGP domain. (Of course, an AS is not limited to consisting of only one IGP domain.) In a deployment like this, how will the egress LSRs learn the source labels of all the ingress LSRs? Something more than an IGP extension seems to be required. Or is the intention that source labels be unique only within an IGP domain? In that case, I agree with Yakov that the draft should state that clearly. But that would mean that the source label can only be used when the ingress and egress LSRs are in the same IGP domain. But that would raise a number of other issues: - With a restriction to one IGP domain, can the intended use case be supported? - The ingress would have know, not only that the egress is capable of processing the source label, but that the egress will interpret the source label in the proper scope. The draft doesn't address the issue of how to ensure that ingress and egress agree on the intended scope of the label. - Since a packet does not carry an identifier of its ingress IGP domain, the egress wouldn't be able to interpret the label without first determining the ingress IGP domain. The draft says nothing about how this is done. At the very least, this draft needs to specify the characteristics a distribution mechanism must have in order to ensure that a source label never gets distributed outside the "domain" in which it is unique. There also need to be assurance that a data packet carrying a source label will never carry the source label outside the proper domain. Mach> Regarding to the allocation, this is same as the IP address allocation If an allocation scheme is to have more than local scope, it usually has some sort of hierarchy that can be used to prevent collisions. IP addresses, Route Distinguishers, Route Targets, all have some kind of structure. > for a single operator, to guarantee the uniqueness is relevant easy. With no structure and no "domain identifier" in the source label, it is very easy end up with non-unique labels within a domain. One might also ask why there is a need to use a 20-bit label to identify a node, instead of using some other format. The draft doesn't actually seem to address this issue, it just says "right now you can't identify the ingress, we need to identify the ingress, therefore we need to have a 20-bit label that identifies it". It would be good if the draft said more about why a single 20-bit value is needed to identify the ingress router. By the way, "source label" is an unfortunate choice of terminology for a field that identifies an ingress LSR, as folks outside the Routing Area will have trouble thinking of a router as the "source" of a packet. From nobody Thu May 15 08:50:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387611A064B for ; Thu, 15 May 2014 08:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOOBNV8VjVyX for ; Thu, 15 May 2014 08:50:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807D21A064A for ; Thu, 15 May 2014 08:50:49 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 15 May 2014 15:50:40 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0944.000; Thu, 15 May 2014 15:50:40 +0000 From: Ross Callon To: Lizhong Jin , Gregory Mirsky Thread-Topic: MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPcE4lUwvbDEOh60WIHpXE2sYv7ZtBwsJg Date: Thu, 15 May 2014 15:50:39 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7B12A5@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: [66.129.241.11] x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(24454002)(51444003)(52314003)(164054003)(377454003)(51914003)(37854004)(51704005)(66654002)(199002)(189002)(76576001)(15975445006)(79102001)(19609705001)(74502001)(31966008)(74662001)(80022001)(81342001)(85852003)(83072002)(81542001)(74316001)(77982001)(76482001)(16236675002)(46102001)(19300405004)(4396001)(15202345003)(87936001)(2656002)(83322001)(19580405001)(21056001)(19580395003)(18717965001)(33646001)(20776003)(64706001)(99286001)(99396002)(92566001)(101416001)(76176999)(50986999)(77096999)(86362001)(54356999)(19625215002)(55754002)(24736002)(9078065003); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: multipart/alternative; boundary="_000_aa36851d2e9649f2977429cac6c08f7cCO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IlILHHUnLKf-bZqSv2Cm4pHl8eE Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:50:54 -0000 --_000_aa36851d2e9649f2977429cac6c08f7cCO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gU3VnZ2VzdCB0byByZW1vdmUgdGhlIFNlZ21lbnQgUm91dGluZyBjYXNlLCBvdGhlcndpc2Us IHdlIGhhdmUgdG8gY28td29yayB3aXRoIFNQUklORyBXRyBmb3IgdGhpcyBkcmFmdC4NCj4+DQo+ PiBHSU0+PiBBcyBNUExTIGRhdGEgcGxhbmUgaXMgaW4gc2NvcGUgb2YgU1BSSU5HIFdHIHdlIGNl cnRhaW5seSB3aWxsIGFzayBpdCB0byByZXZpZXcgdGhpcyBkb2N1bWVudCBhbmQgd2VsY29tZSB0 aGVpciBjb21tZW50cy4NCg0KVGhlIFNQUklORyBXRyBjaGFpcnMgYXJlIGFscmVhZHkgYXdhcmUg b2YgdGhpcyBkb2N1bWVudC4gSSBpbnRlbmQgdG8gbm90aWZ5IHRoZW0gd2hlbiB3ZSBjYWxsIHRo aXMgZG9jdW1lbnQgZm9yIFdHIGFkb3B0aW9uLCBhbmQgYWdhaW4gYXQgV0cgbGFzdCBjYWxsLg0K DQpUaGFua3MsIFJvc3MNCg0KRnJvbTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpoby5qaW5AZ21h aWwuY29tXQ0KU2VudDogVGh1cnNkYXksIE1heSAxNSwgMjAxNCAxMDo1OCBBTQ0KVG86IEdyZWdv cnkgTWlyc2t5DQpDYzogZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1sYWJlbEB0b29scy5pZXRmLm9y ZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IFJvc3MgQ2FsbG9u DQpTdWJqZWN0OiBSZTogTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1s YWJlbA0KDQpIaSBHcmVnLA0KDQpUaGFua3MgZm9yIHRoZSByZXBseS4gU2VlIG1vcmUgaW5saW5l IGJlbG93Lg0KDQpSZWdhcmRzDQoNCkxpemhvbmcNCg0KT24gVGh1cnNkYXksIE1heSAxNSwgMjAx NCwgR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBMaXpob25nLA0KbWFueSB0aGFu a3MgZm9yIHlvdSBraW5kIGNvbnNpZGVyYXRpb24gb2Ygb3VyIHdvcmsgYW5kIHRob3VnaHRmdWwg Y29tbWVudHMuIFBsZWFzZSBmaW5kIG15IG5vdGVzIGluLWxpbmUgYW5kIHRhZ2dlZCBHSU0+Pi4N Cg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEdyZWcNCg0KRnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzxqYXZh c2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ21wbHMtYm91bmNlc0BpZXRmLm9yZycpOz5dIE9uIEJl aGFsZiBPZiBMaXpob25nIEppbg0KU2VudDogV2VkbmVzZGF5LCBNYXkgMTQsIDIwMTQgODoyMiBB TQ0KVG86IGRyYWZ0LWNoZW4tbXBscy1zb3VyY2UtbGFiZWxAdG9vbHMuaWV0Zi5vcmc8amF2YXNj cmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsQHRvb2xz LmlldGYub3JnJyk7Pg0KQ2M6IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPGphdmFzY3JpcHQ6 X2UoJTdCJTdELCdjdm1sJywnbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcnKTs+OyBtcGxzQGll dGYub3JnPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnbXBsc0BpZXRmLm9yZycpOz47IFJv c3MgQ2FsbG9uDQpTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMtUlQgcmV2aWV3IG9mIGRyYWZ0LWNo ZW4tbXBscy1zb3VyY2UtbGFiZWwNCg0KSGkgYXV0aG9ycywNCkkgZmluaXNoZWQgdGhlIHJldmll dywgYW5kIHRoZSB0ZXh0IGlzIGVhc3kgdG8gdW5kZXJzdGFuZGFibGUuIEkgaGF2ZSBzb21lIHRl Y2huaWNhbCBjb21tZW50cyBhbmQgY29uY2VybnMgYmVmb3JlIGFkb3B0aW9uLiBIb3BlIHRoZSBh dXRob3JzIGNvdWxkIGhlbHAgdG8gY2xhcmlmeS4NCg0KU2VjdGlvbiAxLCBsaW5lIDE1OQ0KU3Vn Z2VzdCB0byByZW1vdmUgdGhlIFNlZ21lbnQgUm91dGluZyBjYXNlLCBvdGhlcndpc2UsIHdlIGhh dmUgdG8gY28td29yayB3aXRoIFNQUklORyBXRyBmb3IgdGhpcyBkcmFmdC4NCkdJTT4+IEFzIE1Q TFMgZGF0YSBwbGFuZSBpcyBpbiBzY29wZSBvZiBTUFJJTkcgV0cgd2UgY2VydGFpbmx5IHdpbGwg YXNrIGl0IHRvIHJldmlldyB0aGlzIGRvY3VtZW50IGFuZCB3ZWxjb21lIHRoZWlyIGNvbW1lbnRz Lg0KDQpTZWN0aW9uIDMsIGxpbmUgMTg4DQpNUExTIGxhYmVsIGlzIG9yaWdpbmFsbHkgZGVzaWdu ZWQgdG8gYmUgYSBsb2NhbGx5IHVuaXF1ZSBsYWJlbC4gQnV0IHRoaXMgZHJhZnQgcHJvcG9zZSB0 aGUgbGFiZWwgdG8gYmUgZ2xvYmFsbHkgdW5pcXVlLiBUaGF0IHdpbGwgYnJpbmcgbWFueSBuZXcg dGhpbmdzLCBlLmcuLCBsYWJlbCBtYW5hZ2VtZW50IGNvbXBsZXhpdHksIGxhYmVsIHNwYWNlIGxp bWl0YXRpb24sIGV0Yy4gQ291bGQgd2UgYWNoaWV2ZSB0aGUgcHVycG9zZSBvZiBQZXJmb3JtYW5j ZSBNZWFzdXJlbWVudCBieSBvdGhlciB3YXksIGUuZy4sIGJ5IHVzaW5nIHBzdWVkb3dpcmUgYmV0 d2VlbiB0d28gZW5kcG9pbnRzLg0KR0lNPj4gWWVzLCBTb3VyY2UgTGFiZWwgY2hhbmdlcyB1bmlx dWVuZXNzIHNjb3BlIGZyb20gbG9jYWwgdG8gc29tZXRoaW5nIGVsc2UuIEFzIFlha292IHN1Z2dl c3RzIHRvIG1ha2UgZXhwbGljaXQgc3RhdGVtZW50IHRoYXQgU291cmNlIExhYmVsIG11c3QgYmUg dW5pcXVlIG9ubHkgd2l0aGluIGdpdmVuIElHUCBkb21haW4gYW5kIG5vdCBnbG9iYWxseS4gSSBz ZWUgdGhlIHBvaW50IGluIHN1Y2ggZGVmaW5pdGlvbiBidXQgd291bGQgbGlrZSB0byBkaXNjdXNz IGl0IG1vcmUsIGdldCBtb3JlIG9waW5pb25zIGZyb20gdGhlIGdyb3VwLg0KDQpTZWN0aW9uIDQu MSwgbGluZSAyMzYNCk15IGNvbmNlcm4gaGVyZSBpcywgaXMgaXQgdmFsdWFibGUgdG8gZ2V0IHRo ZSBtZWFzdXJlbWVudCBvZiBhIFAyUCBwYXRoIHdpdGhpbiBhIE1QMlAgcGF0aCAoaW4gc2VjdGlv biAxLCB5b3Ugc2FpZCwgTVAyUCBpcyBhIHByb2JsZW0pLiBUaGUgcGVyZm9ybWFuY2UgeW91IGdl dCBhdCBvbmUgdGltZSBmb3IgdGhpcyBQMlAgcGF0aCBpcyBzdXJlbHkgaW5mbHVlbmNlZCBieSBv dGhlciBQMlAgcGF0aCBvZiB0aGUgc2FtZSBNUDJQIHBhdGguIEtlZXAgaW4gbWluZCB0aGF0IHRo ZSBMU1AgbGFiZWwgdGVzdGVkIGlzIGFsc28gc2hhcmVkIGJ5IG90aGVyIFAyUCBMU1Agd2l0aGlu IHNhbWUgTVAyUCBMU1AuDQpJZiB5b3UgcmVhbGx5IHdhbnQgdGhlIE1QTFMgcGF0aCBwZXJmb3Jt YW5jZSBiZXR3ZWVuIHR3byBlbmRwb2ludHMgaW4gTERQIGVudmlyb25tZW50LCBzdWdnZXN0IHRv IHVzZSBQVyBpbnN0ZWFkLg0KR0lNPj4gQWxsIHBlcmZvcm1hbmNlIG1ldHJpY3MgYW5kIHBlcmZv cm1hbmNlIG1lYXN1cmVtZW50IG1ldGhvZHMgSSBrbm93IGJlZW4gZGVmaW5lZCBmb3IgcDJwLiBJ ZiB3ZSBsb29rIGF0IE1FRuKAmXMgbW9kZWwgZm9yIEV0aGVybmV0IFMtT0FNIFBNLCB0aGVuIGZv ciBFLUxBTiBpdCBpcyBzdGlsbCBwMnAgbWVhc3VyZW1lbnQuDQoNClNlY3Rpb24gNi4xLjEsIGxp bmUgMzYxDQpJIGhhdmUgY29uY2VybiB3aXRoIHRoZSBzaWduYWxpbmcgbWVjaGFuaXNtLiBJbiBh IGxhcmdlIG5ldHdvcmssIGlmIG9ubHkgb25lIExTUiBkb2VzIG5vdCBzdXBwb3J0IFNMQywgdGhl biB0aGUgd2hvbGUgbmV0d29yayBjb3VsZCBub3Qgc3VwcG9ydCBTTEMuIElmIG9uZSBMU1IgY2hh bmdlcyBpdHMgU0xDIHN0YXR1cywgaXQgd2lsbCBmbG9vZCB0byBldmVyeSBub2RlLiBUaGF0IG1h eSBicmluZyBzb21lIGluc3RhYmlsaXR5IHRvIHRoZSBuZXR3b3JrLCBhbmQgbWFrZSB0aGUgc2ln bmFsaW5nIHVuc2NhbGFibGUuIEFuZCBpdCBtYXliZSBwb3NzaWJsZSB0byBvcHRpbWl6ZSB0aGUg c2lnbmFsaW5nLiBUaGUgU0xDIHN0YXR1cyBmcm9tIHRoZSBuZXh0IGhvcCBjb3VsZCBiZSB1c2Vk IHRvIHNlbmQgdXBzdHJlYW0sIHJpZ2h0Pw0KR0lNPj4gSSB0aGluayB0aGF0IG5vdCBhbGwgTFNS cyBpbiBhbiBJR1AgZG9tYWluIGFyZSByZXF1aXJlZCB0byBiZSBTTEMgYnV0IG9ubHkgZW5kLXBv aW50cyBvZiBhbiBMU1AuIFRodXMsIGlmIGFuIExTUiBpcyBub3QgU0xDLCB0aGVuIFNMIGNhbm5v dCBiZSB1c2VkIG9uIExTUHMgaXQgb3JpZ2luYXRlcy90ZXJtaW5hdGVzLiBDaGFuZ2UgaW4gU0xD LCBJIGltYWdpbmUsIG1heSBjb21lIGFzIHJlc3VsdCBvZiBTVyB1cGdyYWRlLiBUaG91Z2ggaXQg d291bGQgdHJpZ2dlZCBmbG9vZCBvZiB1cGRhdGVzIHRoYXQsIElNTywgd291bGQgYmUgb25lLXRp bWUgZXZlbnQuDQpbTGl6aG9uZ10gaW4gYW4gTERQIG5ldHdvcmssIGV2ZXJ5IG5vZGUgd291bGQg YmUgcG9zc2libHkgdG8gYmUgZWdyZXNzIG9mIGFuIEZFQy4gSW4gdGhlIGRyYWZ0LCBpdCBzYXlz Og0KQW4gTFNSIFggbWF5IHJlY2VpdmUgbXVsdGlwbGUgTGFiZWwgTWFwcGluZ3MgZm9yIGEgZ2l2 ZW4NCg0KICAgRkVDIEYgZnJvbSBpdHMgbmVpZ2hib3JzLiAgSW4gaXRzIHR1cm4sIFggbWF5IGFk dmVydGlzZSBhIExhYmVsDQogICBNYXBwaW5nIGZvciBGIHRvIGl0cyBuZWlnaGJvcnMuICBJZiBY IHVuZGVyc3RhbmRzIHRoZSBTTEMgVExWLCBhbmQgaWYNCiAgIGFueSBvZiB0aGUgYWR2ZXJ0aXNl bWVudHMgaXQgcmVjZWl2ZWQgZm9yIEZFQyBGIGRvZXMgbm90IGluY2x1ZGUgdGhlDQogICBTTEMg VExWLCBYIE1VU1QgTk9UIGluY2x1ZGUgdGhlIFNMQyBUTFYgaW4gaXRzIG93biBhZHZlcnRpc2Vt ZW50cyBvZg0KICAgRi4NCg0KSW4gRFUgbW9kZSwgdGhlIG1hcHBpbmcgYWR2ZXJ0aXNlbWVudCB3 aWxsIGJlIGluZmx1ZW5jZWQgYnkgb3RoZXIgcmVjZWl2ZWQgYWR2ZXJ0aXNlbWVudCwgd2hpY2gg d2lsbCBicmluZyBtb3JlIHNpZ25hbGluZy4gVGhpcyBpcyBub3Qgb25lLXRpbWUgZXZlbnQsIGFu eSBMRFAgc2Vzc2lvbiBVUC9ET1dOIHdpbGwgaW5mbHVlbmNlIHRoZSB3aG9sZSBzaWduYWxpbmcu IEJ1dCB3aHkgZG9uJ3QgeW91IGxpbWl0IHRoZSByZWNlaXZlZCBhZHZlcnRpc2VtZW50IG9ubHkg ZnJvbSB0aGUgZG93bnN0cmVhbSBub2RlLCBub3QgYWxsIG5vZGVzPyBPbmx5IHRoZSByZWNlaXZl ZCBhZHZlcnRpc2VtZW50IGZyb20gZG93bnN0cmVhbSBub2RlIGRvZXMgbm90IFNMQyBUTFYsIFgg bXVzdCBub3QgaW5jbHVkZSBTTEMgVExWLg0KDQpTZWN0aW9uIDYuMS4yLCA2LjEuMi4zDQpTaW5j ZSBSU1ZQLVRFIExTUCBkb2VzIG5vdCBoYXZlIHRoZSBtZWFzdXJlbWVudCBwcm9ibGVtIGxpc3Rl ZCBpbiB0aGlzIGRyYWZ0LCB3aHkgd2UgbmVlZCB0byBkbyBSU1ZQLVRFIGV4dGVuc2lvbj8gTVAt QkdQIGlzIG5vdCB1c2VkIHRvIHNldHVwIE1QMlAgLyBNUDJNUCBMU1AsIHRoZW4gd2h5IHdlIG5l ZWQgdGhlIGV4dGVuc2lvbj8gRGlkIEkgbWlzcyBzb21ldGhpbmc/DQpHSU0+PiBJIHRoaW5rIHRo YXQgUlNWUC1URSBMU1Agd2l0aCBsYWJlbCBtZXJnZSBhbmQgUEhQIHN0aWxsIGhhdmUgaXNzdWVz IGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuIFBlcmhhcHMgb25seSBNUExTLVRQIGNvbnN0cnVj dHMgaGF2ZSBkZXRlcm1pbmlzbSBvZiB0cmFuc3BvcnQgbmV0d29yayBhbmQgbWF5IG5vdCBoYXZl IHRoaXMgcHJvYmxlbS4NCltMaXpob25nXSBQSFAgY291bGQgYmUgZGlzYWJsZWQgZm9yIFJTVlAt VEUgTFNQLiBXaGljaCBjYXNlIGhhcyBsYWJlbCBtZXJnZSBmb3IgUlNWUC1URSBMU1A/IEFueXdh eSwgaWYgeW91IHRoaW5rIFJTVlAtVEUgYWxzbyBoYXMgaXNzdWUsIHlvdSBzaG91bGQgc2F5IHRo YXQgaW4gc2VjdGlvbiAxLiBIb3dldmVyLCB1c2luZyBzb3VyY2UgbGFiZWwgdG8gZG8gTE0gZm9y IFJTVlAtVEUgTFNQIG1heSBub3QgYmUgaGVscGZ1bCwgc2luY2UgdGhlIFJTVlAtVEUgbGFiZWwg aXMgbW9yZSBhY2N1cmF0ZSB0byBpZGVudGlmeSBhbiBMU1AsIGluY2x1ZGluZyBzb3VyY2UgKyBk ZXN0aW5hdGlvbiArIHR1bm5lbCBJRCArIExTUCBJRCArIFBIQiwgZXRjLg0KDQpSZWdhcmRzDQpM aXpob25nDQoNCg0KT24gRnJpZGF5LCBNYXkgMiwgMjAxNCwgUm9zcyBDYWxsb24gPHJjYWxsb25A anVuaXBlci5uZXQ8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdyY2FsbG9uQGp1bmlwZXIu bmV0Jyk7Pj4gd3JvdGU6DQpFcmljLCBZaW1pbiwgTGl6aG9uZzsNCg0KWW91IGhhdmUgYmVlbiBz ZWxlY3RlZCBhcyBNUExTIFJldmlldyB0ZWFtIHJldmlld2VycyBmb3IgZHJhZnQtY2hlbi1tcGxz LXNvdXJjZS1sYWJlbC0wMy4NCg0KTm90ZSB0byBhdXRob3JzOiBZb3UgaGF2ZSBiZWVuIENDJ2Qg b24gdGhpcyBlbWFpbCBzbyB0aGF0IHlvdSBjYW4ga25vdyB0aGF0IHRoaXMgcmV2aWV3IGlzIGdv aW5nIG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmlldyB5b3VyIG93biBkb2N1bWVudC4N Cg0KUmV2aWV3cyBzaG91bGQgY29tbWVudCBvbiB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyBjb2hl cmVudCwgaXMgaXQgdXNlZnVsIChpZSwgaXMgaXQgbGlrZWx5IHRvIGJlIGFjdHVhbGx5IHVzZWZ1 bCBpbiBvcGVyYXRpb25hbCBuZXR3b3JrcyksIGFuZCBpcyB0aGUgZG9jdW1lbnQgdGVjaG5pY2Fs bHkgc291bmQ/ICBBbHNvLCBpcyB0aGUgdGV4dCBhbmQgZ3JhbW1hciB1bmRlcnN0YW5kYWJsZSAo aXQgZG9lc24ndCBuZWVkIHRvIGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBi ZSByZWFzb25hYmx5IGNsZWFyKS4gV2UgYXJlIGludGVyZXN0ZWQgaW4ga25vd2luZyB3aGV0aGVy IHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBjb25zaWRlcmVkIGZvciBXRyBhZG9wdGlvbiAo aWUsIGl0IGRvZXNuJ3QgaGF2ZSB0byBiZSBwZXJmZWN0IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91 bGQgYmUgYSBnb29kIHN0YXJ0KS4NCg0KUmV2aWV3cyBzaG91bGQgYmUgc2VudCB0byB0aGUgZG9j dW1lbnQgYXV0aG9ycywgV0cgY28tY2hhaXJzIGFuZCBXRyBzZWNyZXRhcnksIGFuZCBDQydkIHRv IHRoZSBNUExTIFdHIGVtYWlsIGxpc3QuIElmIG5lY2Vzc2FyeSwgQ29tbWVudHMgbWF5IGJlIHNl bnQgcHJpdmF0ZWx5IHRvIG9ubHkgdGhlIFdHIGNoYWlycy4NCg0KQXJlIHlvdSBhYmxlIHRvIHJl dmlldyB0aGlzIGRyYWZ0IGJ5IE1heSAxNiwgMjAxND8NCg0KVGhhbmtzLCBSb3NzDQooYXMgTVBM UyBXRyBjaGFpcikNCg0K --_000_aa36851d2e9649f2977429cac6c08f7cCO2PR05MB636namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7IFN1Z2dl c3QgdG8gcmVtb3ZlIHRoZSBTZWdtZW50IFJvdXRpbmcgY2FzZSwgb3RoZXJ3aXNlLCB3ZSBoYXZl IHRvIGNvLXdvcmsgd2l0aCBTUFJJTkcgV0cgZm9yIHRoaXMgZHJhZnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZndDsmZ3Q7IEdJTSZndDsmZ3Q7IEFzIE1QTFMgZGF0YSBwbGFuZSBpcyBpbiBzY29wZSBv ZiBTUFJJTkcgV0cgd2UgY2VydGFpbmx5IHdpbGwgYXNrIGl0IHRvIHJldmlldyB0aGlzIGRvY3Vt ZW50IGFuZCB3ZWxjb21lIHRoZWlyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIFNQUklORyBXRyBj aGFpcnMgYXJlIGFscmVhZHkgYXdhcmUgb2YgdGhpcyBkb2N1bWVudC4gSSBpbnRlbmQgdG8gbm90 aWZ5IHRoZW0gd2hlbiB3ZSBjYWxsIHRoaXMgZG9jdW1lbnQgZm9yIFdHIGFkb3B0aW9uLCBhbmQg YWdhaW4gYXQgV0cgbGFzdCBjYWxsLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsIFJvc3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IExpemhvbmcgSmluIFttYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgTWF5IDE1LCAyMDE0IDEwOjU4IEFNPGJyPg0KPGI+VG86PC9iPiBH cmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj4gZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1sYWJl bEB0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5v cmc7IFJvc3MgQ2FsbG9uPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBNUExTLVJUIHJldmlldyBv ZiBkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBHcmVnLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSByZXBseS4gU2VlIG1vcmUg aW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5SZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkxpemhvbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KT24gVGh1cnNkYXksIE1heSAxNSwgMjAxNCwgR3JlZ29yeSBNaXJz a3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iPmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBMaXpob25nLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPm1hbnkgdGhhbmtzIGZvciB5b3Uga2luZCBjb25zaWRlcmF0aW9uIG9mIG91ciB3b3Jr IGFuZCB0aG91Z2h0ZnVsIGNvbW1lbnRzLiBQbGVhc2UgZmluZCBteSBub3Rlcw0KIGluLWxpbmUg YW5kIHRhZ2dlZCBHSU0mZ3Q7Jmd0Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IG1wbHMgW21haWx0bzo8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3Zt bCcsJ21wbHMtYm91bmNlc0BpZXRmLm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxpemhvbmcgSmluPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDE0LCAyMDE0IDg6MjIgQU08YnI+DQo8Yj5Ubzo8L2I+ IDxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnZHJhZnQtY2hlbi1tcGxzLXNv dXJjZS1sYWJlbEB0b29scy5pZXRmLm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtY2hl bi1tcGxzLXNvdXJjZS1sYWJlbEB0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnbXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmcnKTsiIHRhcmdldD0iX2JsYW5rIj4NCm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9h PjsgPGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdtcGxzQGlldGYub3JnJyk7 IiB0YXJnZXQ9Il9ibGFuayI+DQptcGxzQGlldGYub3JnPC9hPjsgUm9zcyBDYWxsb248YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFttcGxzXSBNUExTLVJUIHJldmlldyBvZiBkcmFmdC1jaGVuLW1w bHMtc291cmNlLWxhYmVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYXV0 aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZmlu aXNoZWQgdGhlIHJldmlldywgYW5kIHRoZSB0ZXh0IGlzIGVhc3kgdG8gdW5kZXJzdGFuZGFibGUu IEkgaGF2ZSBzb21lIHRlY2huaWNhbCBjb21tZW50cyBhbmQgY29uY2VybnMgYmVmb3JlIGFkb3B0 aW9uLiBIb3BlIHRoZSBhdXRob3JzIGNvdWxkIGhlbHAgdG8gY2xhcmlmeS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlY3Rpb24gMSwg bGluZSAxNTk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+U3VnZ2VzdCB0byByZW1vdmUgdGhlJm5ic3A7U2VnbWVudCBSb3V0aW5nIGNhc2UsIG90 aGVyd2lzZSwgd2UgaGF2ZSB0byBjby13b3JrIHdpdGggU1BSSU5HIFdHIGZvciB0aGlzIGRyYWZ0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R0lNJmd0OyZndDsgQXMgTVBMUyBkYXRhIHBsYW5l IGlzIGluIHNjb3BlIG9mIFNQUklORyBXRyB3ZSBjZXJ0YWlubHkgd2lsbCBhc2sgaXQgdG8gcmV2 aWV3IHRoaXMgZG9jdW1lbnQgYW5kIHdlbGNvbWUgdGhlaXIgY29tbWVudHMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZWN0aW9uIDMsIGxpbmUgMTg4PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1QTFMgbGFi ZWwgaXMgb3JpZ2luYWxseSBkZXNpZ25lZCB0byBiZSBhIGxvY2FsbHkgdW5pcXVlIGxhYmVsLiBC dXQgdGhpcyBkcmFmdCBwcm9wb3NlIHRoZSBsYWJlbCB0byBiZSBnbG9iYWxseSB1bmlxdWUuIFRo YXQgd2lsbCBicmluZyBtYW55IG5ldyB0aGluZ3MsIGUuZy4sIGxhYmVsIG1hbmFnZW1lbnQgY29t cGxleGl0eSwNCiBsYWJlbCBzcGFjZSBsaW1pdGF0aW9uLCBldGMuIENvdWxkIHdlIGFjaGlldmUg dGhlIHB1cnBvc2Ugb2YmbmJzcDtQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBieSBvdGhlciB3YXks IGUuZy4sIGJ5IHVzaW5nIHBzdWVkb3dpcmUgYmV0d2VlbiB0d28gZW5kcG9pbnRzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+R0lNJmd0OyZndDsgWWVzLCBTb3VyY2UgTGFiZWwgY2hhbmdlcyB1 bmlxdWVuZXNzIHNjb3BlIGZyb20gbG9jYWwgdG8gc29tZXRoaW5nIGVsc2UuIEFzIFlha292IHN1 Z2dlc3RzIHRvIG1ha2UgZXhwbGljaXQgc3RhdGVtZW50IHRoYXQgU291cmNlIExhYmVsIG11c3Qg YmUNCiB1bmlxdWUgb25seSB3aXRoaW4gZ2l2ZW4gSUdQIGRvbWFpbiBhbmQgbm90IGdsb2JhbGx5 LiBJIHNlZSB0aGUgcG9pbnQgaW4gc3VjaCBkZWZpbml0aW9uIGJ1dCB3b3VsZCBsaWtlIHRvIGRp c2N1c3MgaXQgbW9yZSwgZ2V0IG1vcmUgb3BpbmlvbnMgZnJvbSB0aGUgZ3JvdXAuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZWN0aW9uIDQuMSwgbGluZSAyMzY8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkg Y29uY2VybiBoZXJlIGlzLCBpcyBpdCB2YWx1YWJsZSB0byBnZXQgdGhlIG1lYXN1cmVtZW50IG9m IGEgUDJQIHBhdGggd2l0aGluIGEgTVAyUCBwYXRoIChpbiBzZWN0aW9uIDEsIHlvdSBzYWlkLCBN UDJQIGlzIGEgcHJvYmxlbSkuIFRoZSBwZXJmb3JtYW5jZSB5b3UgZ2V0IGF0IG9uZSB0aW1lIGZv ciB0aGlzDQogUDJQIHBhdGggaXMgc3VyZWx5IGluZmx1ZW5jZWQgYnkgb3RoZXIgUDJQIHBhdGgg b2YgdGhlIHNhbWUgTVAyUCBwYXRoLiBLZWVwIGluIG1pbmQgdGhhdCB0aGUgTFNQIGxhYmVsIHRl c3RlZCBpcyBhbHNvIHNoYXJlZCBieSBvdGhlciBQMlAgTFNQIHdpdGhpbiBzYW1lIE1QMlAgTFNQ Ljxicj4NCklmIHlvdSByZWFsbHkgd2FudCB0aGUgTVBMUyBwYXRoIHBlcmZvcm1hbmNlIGJldHdl ZW4gdHdvIGVuZHBvaW50cyBpbiBMRFAgZW52aXJvbm1lbnQsIHN1Z2dlc3QgdG8gdXNlIFBXIGlu c3RlYWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5HSU0mZ3Q7Jmd0OyBBbGwgcGVyZm9ybWFu Y2UgbWV0cmljcyBhbmQgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgbWV0aG9kcyBJIGtub3cgYmVl biBkZWZpbmVkIGZvciBwMnAuIElmIHdlIGxvb2sgYXQgTUVG4oCZcyBtb2RlbCBmb3IgRXRoZXJu ZXQgUy1PQU0gUE0sIHRoZW4NCiBmb3IgRS1MQU4gaXQgaXMgc3RpbGwgcDJwIG1lYXN1cmVtZW50 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VjdGlvbiA2LjEu MSwgbGluZSAzNjE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBjb25jZXJuIHdpdGggdGhlIHNpZ25hbGluZyBtZWNoYW5p c20uIEluIGEgbGFyZ2UgbmV0d29yaywgaWYgb25seSBvbmUgTFNSIGRvZXMgbm90IHN1cHBvcnQg U0xDLCB0aGVuIHRoZSB3aG9sZSBuZXR3b3JrIGNvdWxkIG5vdCBzdXBwb3J0IFNMQy4gSWYgb25l IExTUiBjaGFuZ2VzIGl0cyBTTEMgc3RhdHVzLA0KIGl0IHdpbGwgZmxvb2QgdG8gZXZlcnkgbm9k ZS4gVGhhdCBtYXkgYnJpbmcgc29tZSBpbnN0YWJpbGl0eSB0byB0aGUgbmV0d29yaywgYW5kIG1h a2UgdGhlIHNpZ25hbGluZyB1bnNjYWxhYmxlLiBBbmQgaXQgbWF5YmUgcG9zc2libGUgdG8gb3B0 aW1pemUgdGhlIHNpZ25hbGluZy4gVGhlIFNMQyBzdGF0dXMgZnJvbSB0aGUgbmV4dCBob3AgY291 bGQgYmUgdXNlZCB0byBzZW5kIHVwc3RyZWFtLCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+R0lNJmd0OyZndDsgSSB0aGluayB0aGF0IG5vdCBhbGwgTFNScyBpbiBhbiBJ R1AgZG9tYWluIGFyZSByZXF1aXJlZCB0byBiZSBTTEMgYnV0IG9ubHkgZW5kLXBvaW50cyBvZiBh biBMU1AuIFRodXMsIGlmIGFuIExTUiBpcyBub3QgU0xDLCB0aGVuIFNMIGNhbm5vdCBiZQ0KIHVz ZWQgb24gTFNQcyBpdCBvcmlnaW5hdGVzL3Rlcm1pbmF0ZXMuIENoYW5nZSBpbiBTTEMsIEkgaW1h Z2luZSwgbWF5IGNvbWUgYXMgcmVzdWx0IG9mIFNXIHVwZ3JhZGUuIFRob3VnaCBpdCB3b3VsZCB0 cmlnZ2VkIGZsb29kIG9mIHVwZGF0ZXMgdGhhdCwgSU1PLCB3b3VsZCBiZSBvbmUtdGltZSBldmVu dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTGl6aG9uZ10g aW4gYW4gTERQIG5ldHdvcmssIGV2ZXJ5IG5vZGUgd291bGQgYmUgcG9zc2libHkgdG8gYmUgZWdy ZXNzIG9mIGFuIEZFQy4gSW4gdGhlIGRyYWZ0LCBpdCBzYXlzOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFuIExTUiBYIG1heSByZWNlaXZlIG11bHRpcGxlIExhYmVsIE1hcHBp bmdzIGZvciBhIGdpdmVuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyAmbmJz cDtGRUMgRiBmcm9tIGl0cyBuZWlnaGJvcnMuICZuYnNwO0luIGl0cyB0dXJuLCBYIG1heSBhZHZl cnRpc2UgYSBMYWJlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNwO01h cHBpbmcgZm9yIEYgdG8gaXRzIG5laWdoYm9ycy4gJm5ic3A7SWYgWCB1bmRlcnN0YW5kcyB0aGUg U0xDIFRMViwgYW5kIGlmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgJm5ic3A7 YW55IG9mIHRoZSBhZHZlcnRpc2VtZW50cyBpdCByZWNlaXZlZCBmb3IgRkVDIEYgZG9lcyBub3Qg aW5jbHVkZSB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyAmbmJzcDtTTEMg VExWLCBYIE1VU1QgTk9UIGluY2x1ZGUgdGhlIFNMQyBUTFYgaW4gaXRzIG93biBhZHZlcnRpc2Vt ZW50cyBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNwO0YuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIERVIG1vZGUsIHRoZSBtYXBwaW5nIGFkdmVydGlz ZW1lbnQgd2lsbCBiZSBpbmZsdWVuY2VkIGJ5IG90aGVyIHJlY2VpdmVkIGFkdmVydGlzZW1lbnQs IHdoaWNoIHdpbGwgYnJpbmcgbW9yZSBzaWduYWxpbmcuIFRoaXMgaXMgbm90IG9uZS10aW1lIGV2 ZW50LCBhbnkgTERQIHNlc3Npb24gVVAvRE9XTg0KIHdpbGwgaW5mbHVlbmNlIHRoZSB3aG9sZSBz aWduYWxpbmcuIEJ1dCB3aHkgZG9uJ3QgeW91IGxpbWl0IHRoZSByZWNlaXZlZCBhZHZlcnRpc2Vt ZW50IG9ubHkgZnJvbSB0aGUgZG93bnN0cmVhbSBub2RlLCBub3QgYWxsIG5vZGVzPyBPbmx5IHRo ZSByZWNlaXZlZCBhZHZlcnRpc2VtZW50IGZyb20gZG93bnN0cmVhbSBub2RlIGRvZXMgbm90IFNM QyBUTFYsIFggbXVzdCBub3QgaW5jbHVkZSBTTEMgVExWLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlNlY3Rpb24gNi4xLjIsIDYuMS4yLjM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2luY2UgUlNWUC1URSBMU1Ag ZG9lcyBub3QgaGF2ZSB0aGUgbWVhc3VyZW1lbnQgcHJvYmxlbSBsaXN0ZWQgaW4gdGhpcyBkcmFm dCwgd2h5IHdlIG5lZWQgdG8gZG8gUlNWUC1URSBleHRlbnNpb24/IE1QLUJHUCBpcyBub3QgdXNl ZCB0byBzZXR1cCBNUDJQIC8gTVAyTVAgTFNQLCB0aGVuIHdoeSB3ZSBuZWVkDQogdGhlIGV4dGVu c2lvbj8gRGlkIEkgbWlzcyBzb21ldGhpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5HSU0m Z3Q7Jmd0OyBJIHRoaW5rIHRoYXQgUlNWUC1URSBMU1Agd2l0aCBsYWJlbCBtZXJnZSBhbmQgUEhQ IHN0aWxsIGhhdmUgaXNzdWVzIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuIFBlcmhhcHMgb25s eSBNUExTLVRQIGNvbnN0cnVjdHMgaGF2ZSBkZXRlcm1pbmlzbQ0KIG9mIHRyYW5zcG9ydCBuZXR3 b3JrIGFuZCBtYXkgbm90IGhhdmUgdGhpcyBwcm9ibGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5bTGl6aG9uZ10gUEhQIGNvdWxkIGJlIGRpc2FibGVkIGZvciBSU1ZQLVRFIExT UC4gV2hpY2ggY2FzZSBoYXMgbGFiZWwgbWVyZ2UgZm9yIFJTVlAtVEUgTFNQPyBBbnl3YXksIGlm IHlvdSB0aGluayBSU1ZQLVRFIGFsc28gaGFzIGlzc3VlLCB5b3Ugc2hvdWxkIHNheSB0aGF0IGlu IHNlY3Rpb24gMS4gSG93ZXZlciwgdXNpbmcgc291cmNlIGxhYmVsIHRvIGRvIExNIGZvciBSU1ZQ LVRFIExTUCBtYXkgbm90IGJlDQogaGVscGZ1bCwgc2luY2UgdGhlIFJTVlAtVEUgbGFiZWwgaXMg bW9yZSBhY2N1cmF0ZSB0byBpZGVudGlmeSBhbiBMU1AsIGluY2x1ZGluZyBzb3VyY2UgJiM0Mzsg ZGVzdGluYXRpb24gJiM0MzsgdHVubmVsIElEICYjNDM7IExTUCBJRCAmIzQzOyBQSEIsIGV0Yy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5MaXpob25nPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpPbiBGcmlkYXks IE1heSAyLCAyMDE0LCBSb3NzIENhbGxvbiAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0Il N0QsJ2N2bWwnLCdyY2FsbG9uQGp1bmlwZXIubmV0Jyk7IiB0YXJnZXQ9Il9ibGFuayI+cmNhbGxv bkBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RXJp YywgWWltaW4sIExpemhvbmc7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Zb3UgaGF2ZSBiZWVuIHNlbGVjdGVk IGFzIE1QTFMgUmV2aWV3IHRlYW0gcmV2aWV3ZXJzIGZvciBkcmFmdC1jaGVuLW1wbHMtc291cmNl LWxhYmVsLTAzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Tm90ZSB0byBhdXRob3JzOiBZb3UgaGF2ZSBiZWVu IENDJ2Qgb24gdGhpcyBlbWFpbCBzbyB0aGF0IHlvdSBjYW4ga25vdyB0aGF0IHRoaXMgcmV2aWV3 IGlzIGdvaW5nIG9uLiBIb3dldmVyLCBwbGVhc2UNCiBkbyBub3QgcmV2aWV3IHlvdXIgb3duIGRv Y3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmV2aWV3cyBzaG91bGQgY29tbWVudCBvbiB3aGV0aGVy IHRoZSBkb2N1bWVudCBpcyBjb2hlcmVudCwgaXMgaXQgdXNlZnVsIChpZSwgaXMgaXQgbGlrZWx5 IHRvIGJlIGFjdHVhbGx5IHVzZWZ1bA0KIGluIG9wZXJhdGlvbmFsIG5ldHdvcmtzKSwgYW5kIGlz IHRoZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZD8mbmJzcDsgQWxzbywgaXMgdGhlIHRleHQg YW5kIGdyYW1tYXIgdW5kZXJzdGFuZGFibGUgKGl0IGRvZXNuJ3QgbmVlZCB0byBiZSBwZXJmZWN0 IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUgcmVhc29uYWJseSBjbGVhcikuIFdlIGFyZSBp bnRlcmVzdGVkIGluIGtub3dpbmcgd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUg Y29uc2lkZXJlZA0KIGZvciBXRyBhZG9wdGlvbiAoaWUsIGl0IGRvZXNuJ3QgaGF2ZSB0byBiZSBw ZXJmZWN0IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUgYSBnb29kIHN0YXJ0KS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlJldmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50IGF1dGhvcnMs IFdHIGNvLWNoYWlycyBhbmQgV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUgTVBMUyBXRyBl bWFpbCBsaXN0Lg0KIElmIG5lY2Vzc2FyeSwgQ29tbWVudHMgbWF5IGJlIHNlbnQgcHJpdmF0ZWx5 IHRvIG9ubHkgdGhlIFdHIGNoYWlycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFyZSB5b3UgYWJsZSB0byBy ZXZpZXcgdGhpcyBkcmFmdCBieSBNYXkgMTYsIDIwMTQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3Ms IFJvc3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KGFzIE1QTFMgV0cgY2hhaXIp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_aa36851d2e9649f2977429cac6c08f7cCO2PR05MB636namprd05pro_-- From nobody Thu May 15 21:21: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 410E61A0107; Thu, 15 May 2014 21:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA60SRKyLDJs; Thu, 15 May 2014 21:20:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F581A0104; Thu, 15 May 2014 21:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6290; q=dns/txt; s=iport; t=1400214051; x=1401423651; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ENamyT1mNAb2EJ0hu/Wp2y/rNrGaOnpttR655VKOeZk=; b=XObgx1WC/143JCT4MWWQgtC1/UkjFf5M3ED3tP2/n6jfV1D/Lp/8rZvU bb+ACrLVGhScTwVLnXO99lKCN7WQ6AFWQKu1hDGoKmwN/QQYYTBfYzre7 hpIdsDlelqsNXkMOzvhpApjU4gWAx+XQ0e6BNE0VCc7QEIvUnIWr1CtpJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAI+RdVOtJV2c/2dsb2JhbABZgwaBJ8RnAYEXFnSCJQEBAQMBOi0SBQsCAQg2EDIlAgQOiD4I0XkXiS+EbDMHgyuBFQSZUZMUgzaBbgc7 X-IronPort-AV: E=Sophos;i="4.97,1064,1389744000"; d="scan'208";a="325155913" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 16 May 2014 04:20:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4G4KoMc022038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 May 2014 04:20:50 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.59]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 15 May 2014 23:20:49 -0500 From: "Sami Boutros (sboutros)" To: Mach Chen Thread-Topic: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHPcL43MdQKFwuY10i9fAzq1cK1Rg== Date: Fri, 16 May 2014 04:20:49 +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.82.253.159] Content-Type: text/plain; charset="us-ascii" Content-ID: <1882FB137D37A04FA9019D075AC2CB16@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Vfann6V6VVzmWR6RQaO84KcxMFQ Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-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: Fri, 16 May 2014 04:21:00 -0000 >=20 > Minor Issues:=20 >=20 > 1. Since the TTL TLV is defined for both MS-PW and bidirectional co-route= d > LSP, it should be better to explicitly state this in the abstract section= . >=20 Sami: Sure will do. > 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", "ech= o > request" and "request" are interchangeably used in the draft, it's better= to > unify the usage of it to "MPLS echo request" (to align with the usage in > RFC4379). For "echo reply", "bidirectional co-routed LSP", they have the > similar issue. >=20 Sami: Ok, will fix that. > 3.Section 3.1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value | Reserved | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > For the TTL TLV, the value filed should include the "value", "Reserved" a= nd > "Flags", so it's better to change the "Value" field to "TTL" field hence = to > reduce the confusion. >=20 Sami: Sure. > 4. Section 3.2 > "This TLV shall be included in the echo request by the originator of > request. The use of this TLV is optional. If a receiver does not > understand the TTL TLV, it will simply ignore the TLV (Type value of > TLV is assumed to be in the range of optional TLV's which SHOULD be > ignored if an implementation does not support or understand them). In > the absence of TTL TLV or if TTL TLV is ignored by a receiver, the > determination of the TTL value used in the MPLS label on the echo > reply is beyond the scope of this document." >=20 > What's your mean of "beyond the scope of this document" here? Is it to > apply the procedures defined in RFC4379 or just let it to the > implementation?I guess you assume to apply the definition in RFC4379, Sami: It is out of scope of this document, but for sure procedure in 4379 a= pply. > if > so, the TTL of the MPLS label will be more probably set to 255, means the > echo reply will be sent to the ingress of the MS-PW or LSP. I am not sure > whether this is the right procedure, it seems a security issue. IMHO, it > does not make any sense to expect the receiver to send echo reply in this > situation, and even sent, the initiator will not receive the reply. The > safer way is to drop the whole echo request and record an error log. Sami:=20 We are not saying the receiver must send a reply, however if he does the re= ply may be received by the ingress node which might be the wrong node, since=20 the receiver may not set the TTL properly on the reply, keep in mind that t= his is=20 a receiver with an old implementation and the TLV is optional. Please refer to the security section for your security concern. Sami: >=20 > 5. Section 3.2 >=20 > "In other words, if the value of the TTL provided by this TLV does not > match the TTL > determined by other means, such as Switching Point TLV in MS-PW, then > TTL TLV must be used." > Here, it implies that the receiver has to perform TTL matching process, > since how to set the TTL is independent of such matching, seems this > sentence is redundant and confusion. >=20 Sami: Are you familiar with the switching point TLV? and what it includes? > 6. Section 4. >=20 > "...The value field of the TTL TLV and the TTL field of the MPLS label ar= e > set to 2," >=20 > I guess that the MPLS Label is the PW label, right? It's better to add mo= re > text to make this more explicit. In addition, how to set the TTL value of > the tunnel Label? 255 or any other value? >=20 Sami: The tunnel label TTL is irrelevant here, however we will make it expl= icit that this is a PW label. > 5. Section 4.1. Traceroute mode > "In the traceroute mode TTL value in the TLV is successively set to 1, > 2, and so on. This is similar to the TTL values used for the label > set on the packet." > IMHO, some text may be needed to clarify which "FEC" should be carried, > especially for MS-PW trace. Since in Section 4.0, the example says the FE= C > of segment C-D should be carried, does it mean the FEC of last PW Segment= of > the segment under test should be carried or the FEC will vary when TTL > changed. For example, when perform segment trace (e.g., to trace B-D > segment), when TTL is 1, which FEC should be carried? Sami:=20 We are not here redefining a trace route for a MS-PW, we are describing ho= w our extensions will apply. Sami: >=20 > 6. Section 4.2. Error scenario > For this scenario, do you need to define some error codes here? Sami:=20 The section describe how to handle the error scenario, there is no need for= an error code. Sami: >=20 > 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if so, > it should be explicitly stated. If not, you should define how the MS-PW > trace works (given that the tunnels in both directions may span different > hops).=20 Sami:=20 Not sure I get the concern? Again we are not re-defining how MS-PW trace wo= rk. Thanks, Sami >=20 > Nits:=20 >=20 > 1. Please check the text for acronyms that have not been expanded in thei= r > first use. >=20 > 2. I run the idnits tool and found the following nits, please check and > fix.=20 > (See RFCs 3967 and 4897 for information about using normative > references > to lower-maturity documents in RFCs) >=20 > -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 >=20 > -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 >=20 > =3D=3D Unused Reference: '1' is defined on line 284, but no explicit > reference > was found in the text >=20 > =3D=3D Unused Reference: '2' is defined on line 287, but no explicit > reference > was found in the text >=20 > =3D=3D Unused Reference: '3' is defined on line 291, but no explicit > reference > was found in the text >=20 > 3. Section 3.2, > 3.1 first para first sentence > s/shall/SHALL > 3.2 last para, the last second sentence > s/must/MUST >=20 > 4. The draft quotes the MS-PW and bidirectional co-routed LSP concept, it= 's > better to add related references to this document. >=20 >=20 > Best regards, > Mach >=20 >=20 From nobody Thu May 15 23:47: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 B4F6E1A014A for ; Thu, 15 May 2014 23:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 gk3LVx-DFBXy for ; Thu, 15 May 2014 23:47:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5FC21A014C for ; Thu, 15 May 2014 23:47:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGV17928; Fri, 16 May 2014 06:47:24 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 07:46:15 +0100 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 07:46:56 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Fri, 16 May 2014 14:46:53 +0800 From: Mach Chen To: "erosen@cisco.com" Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPcFVVL+zgqxffQMyvtWl3yVZPQptCZDCA Date: Fri, 16 May 2014 06:46:52 +0000 Message-ID: References: Your message of Tue, 13 May 2014 10:39:40 -0000. <3798.1400169002@erosen-lnx> In-Reply-To: <3798.1400169002@erosen-lnx> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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/5w202Z6oi_CCjLM8HOVCyz4gXQg Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 06:47:38 -0000 Hi Eric, Thanks for your comments! See my reply inline... > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, May 15, 2014 11:50 PM > To: Mach Chen > Cc: Yimin Shen; draft-chen-mpls-source-label@tools.ietf.org; > mpls-chairs@tools.ietf.org; Martin Vigoureux; mpls@ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label >=20 >=20 > Mach> As for the distribution, seems that IGP extension is a reasonable > Mach> choice, >=20 > The distribution mechanism needs to ensure that each egress LSR will lear= n the > source label of each ingress LSR. There are MPLS deployments in which an > ingress LSR may be separated from an egress LSR by multiple Autonomous > Systems, each of which consists of at least one IGP domain. (Of course, = an AS is > not limited to consisting of only one IGP domain.) In a deployment like = this, The reply to Yimin is not about whether IGP is sufficient for all cases, it= 's about whether the distribution mechanisms should be define in this docum= ent. My point is that the distribution mechanisms should be defined in sepa= rate documents. > how will the egress LSRs learn the source labels of all the ingress LSRs? > Something more than an IGP extension seems to be required. I agree that IGP may not satisfy all the scenarios, especially the inter-AS= case. There may need other solutions (e.g., BGP extensions) for the distri= bution in that case. This should be discussed when we start to define the d= istribution mechanisms. >=20 > Or is the intention that source labels be unique only within an IGP domai= n? The draft says: "In its function as a Source Label, it MUST be unique within a domain. In cases where a Source Label is used across domains it MUST be unique within the scope it is used." The intention is not just a single IGP domain, it may be used across domain= s when needed.=20 BTW, we'd like to solicit the feedbacks about the scope of SL.=20 > In that case, I agree with Yakov that the draft should state that clearly= . The draft currently explicitly says as above, if you have better text, that= will be appreciated!=20 > But that would mean that the source label can only be used when the ingre= ss and > egress LSRs are in the same IGP domain. But that would raise a number of > other issues: >=20 > - With a restriction to one IGP domain, can the intended use case be > supported? Even limited to a single administrative domain, the use case is still valid= . And IMHO, for most of the cases, one single administrative domain is the = major scenario.=20 >=20 > - The ingress would have know, not only that the egress is capable of > processing the source label, but that the egress will interpret the sou= rce > label in the proper scope. The draft doesn't address the issue of how = to > ensure that ingress and egress agree on the intended scope of the label= . For single domain case, the SLC will be only exchanged among the LSRs withi= n the domain, when the ingress knows the egress can support SLC, it implici= t indicates that the egress will interpret the SL in the same scope of itse= lf. >=20 > - Since a packet does not carry an identifier of its ingress IGP domain, = the > egress wouldn't be able to interpret the label without first determinin= g > the ingress IGP domain. The draft says nothing about how this is done. For single domain case, there is only one space, the egress could just inte= rpret the label in the space.=20 Actually, even for multiple domains, it is still the case, since SL will be= used across domains, the SL space should be shared by the domains. There i= s no different from the Segment ID, VE ID (BGP VPLS).=20 >=20 > At the very least, this draft needs to specify the characteristics a dist= ribution > mechanism must have in order to ensure that a source label never gets > distributed outside the "domain" in which it is unique. There also need = to be > assurance that a data packet carrying a source label will never carry the= source > label outside the proper domain. Good point, will add some text to say this. >=20 > Mach> Regarding to the allocation, this is same as the IP address > Mach> allocation >=20 > If an allocation scheme is to have more than local scope, it usually has = some sort > of hierarchy that can be used to prevent collisions. IP addresses, Route > Distinguishers, Route Targets, all have some kind of structure. >=20 > > for a single operator, to guarantee the uniqueness is relevant easy. >=20 > With no structure and no "domain identifier" in the source label, it is v= ery easy > end up with non-unique labels within a domain. There are also many non-structure cases, for example, Router ID, Segment ID= , VE ID of BGP VPLS (http://tools.ietf.org/html/rfc4761#section-3.4.4 ), th= ey work fine.=20 In addition, even for your RT example, for L3VPN inter-AS scenario, the RT = has to be considered as single space, the domain identifier does not help h= ere.=20 >=20 > One might also ask why there is a need to use a 20-bit label to identify = a node, > instead of using some other format. The draft doesn't actually seem to a= ddress > this issue, it just says "right now you can't identify the ingress, we ne= ed to > identify the ingress, therefore we need to have a 20-bit label that ident= ifies it". > It would be good if the draft said more about why a single 20-bit value i= s needed > to identify the ingress router. We are talking about identifying the source of an LSP, and the label stack = is the MPLS header and there are only labels, then seems that a label to id= entify the ingress LSR is a naturally choice. >=20 > By the way, "source label" is an unfortunate choice of terminology for a = field that > identifies an ingress LSR, as folks outside the Routing Area will > have trouble thinking of a router as the "source" of a packet. Any better name are welcome! Thanks, Mach >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Fri May 16 02:11: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 26A361A0194 for ; Fri, 16 May 2014 02:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 KuRdIaF5hNgS for ; Fri, 16 May 2014 02:11:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54DF1A018E for ; Fri, 16 May 2014 02:11:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGV31950; Fri, 16 May 2014 09:11:30 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 10:10:26 +0100 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 10:11:28 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Fri, 16 May 2014 17:10:05 +0800 From: Mach Chen To: Lizhong Jin , Gregory Mirsky Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: Ac9mHhPQL+zgqxffQMyvtWl3yVZPQgJJyVgAAAVh6YAALA5kgAA24REA Date: Fri, 16 May 2014 09:10:04 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7B12A5@eusaamb103.ericsson.se> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/TfLSOwGpYaOILSf0_10UQcZx9IA Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Ross Callon Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 09:11:46 -0000 SGkgTGl6aG9uZywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KDQpTZWUgbXkgcmVwbHkg aW5saW5lLi4uDQoNClNuaXBlZC4NCg0KPiBHSU0+PiBJIHRoaW5rIHRoYXQgbm90IGFsbCBMU1Jz IGluIGFuIElHUCBkb21haW4gYXJlIHJlcXVpcmVkIHRvIGJlIA0KPiBHSU0+PiBTTEMgYnV0IG9u bHkNCj4gZW5kLXBvaW50cyBvZiBhbiBMU1AuIFRodXMsIGlmIGFuIExTUiBpcyBub3QgU0xDLCB0 aGVuIFNMIGNhbm5vdCBiZSANCj4gdXNlZCBvbiBMU1BzIGl0IG9yaWdpbmF0ZXMvdGVybWluYXRl cy4gQ2hhbmdlIGluIFNMQywgSSBpbWFnaW5lLCBtYXkgDQo+IGNvbWUgYXMgcmVzdWx0IG9mIFNX IHVwZ3JhZGUuIFRob3VnaCBpdCB3b3VsZCB0cmlnZ2VkIGZsb29kIG9mIHVwZGF0ZXMgDQo+IHRo YXQsIElNTywgd291bGQgYmUgb25lLXRpbWUgZXZlbnQuDQo+IFtMaXpob25nXSBpbiBhbiBMRFAg bmV0d29yaywgZXZlcnkgbm9kZSB3b3VsZCBiZSBwb3NzaWJseSB0byBiZSBlZ3Jlc3Mgb2YgYW4g RkVDLg0KPiBJbiB0aGUgZHJhZnQsIGl0IHNheXM6DQo+IEFuIExTUiBYIG1heSByZWNlaXZlIG11 bHRpcGxlIExhYmVsIE1hcHBpbmdzIGZvciBhIGdpdmVuDQo+IA0KPiAgICBGRUMgRiBmcm9tIGl0 cyBuZWlnaGJvcnMuICBJbiBpdHMgdHVybiwgWCBtYXkgYWR2ZXJ0aXNlIGEgTGFiZWwNCj4gICAg TWFwcGluZyBmb3IgRiB0byBpdHMgbmVpZ2hib3JzLiAgSWYgWCB1bmRlcnN0YW5kcyB0aGUgU0xD IFRMViwgYW5kIA0KPiBpZg0KPiAgICBhbnkgb2YgdGhlIGFkdmVydGlzZW1lbnRzIGl0IHJlY2Vp dmVkIGZvciBGRUMgRiBkb2VzIG5vdCBpbmNsdWRlIA0KPiB0aGUNCj4gICAgU0xDIFRMViwgWCBN VVNUIE5PVCBpbmNsdWRlIHRoZSBTTEMgVExWIGluIGl0cyBvd24gYWR2ZXJ0aXNlbWVudHMgDQo+ IG9mDQo+ICAgIEYuDQo+IA0KPiBJbiBEVSBtb2RlLCB0aGUgbWFwcGluZyBhZHZlcnRpc2VtZW50 IHdpbGwgYmUgaW5mbHVlbmNlZCBieSBvdGhlciANCj4gcmVjZWl2ZWQgYWR2ZXJ0aXNlbWVudCwg d2hpY2ggd2lsbCBicmluZyBtb3JlIHNpZ25hbGluZy4gVGhpcyBpcyBub3QgDQo+IG9uZS10aW1l IGV2ZW50LCBhbnkgTERQIHNlc3Npb24gVVAvRE9XTiB3aWxsIGluZmx1ZW5jZSB0aGUgd2hvbGUg DQo+IHNpZ25hbGluZy4gQnV0IHdoeSBkb24ndCB5b3UgbGltaXQgdGhlIHJlY2VpdmVkIGFkdmVy dGlzZW1lbnQgb25seSANCj4gZnJvbSB0aGUgZG93bnN0cmVhbSBub2RlLCBub3QgYWxsIG5vZGVz PyBPbmx5IHRoZSByZWNlaXZlZCANCj4gYWR2ZXJ0aXNlbWVudCBmcm9tIGRvd25zdHJlYW0gbm9k ZSBkb2VzIG5vdCBTTEMgVExWLCBYIG11c3Qgbm90IGluY2x1ZGUgU0xDIFRMVi4NCg0KVGhlIGFi b3ZlIG1lY2hhbmlzbSBpcyBvcmlnaW5hbGx5IGRlZmluZWQgZm9yIEVMQywgYW5kIElNSE8sIGZy b20gdGhlIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gcG9pbnQgb2YgdmlldywgdGhlcmUgaXMgbm8g ZGlmZmVyZW50IGJldHdlZW4gRUxDIGFuZCBTTEMuIEFzIHN0YXRlZCBpbiB0aGUgQWNrbm93bGVk Z2VtZW50cyBzZWN0aW9uLCB0aGUgU0xDIG5lZ290aWF0aW9uIGlzIHJlZmVycmVkIHRvIEVMQyBu ZWdvdGlhdGlvbiBtZWNoYW5pc20uIA0KDQpJZiB5b3UgaGF2ZSBiZXR0ZXIgc3VnZ2VzdGlvbiwg dGhhdCB3aWxsIGJlIGFwcHJlY2lhdGVkLiANCiAgDQo+IA0KPiBTZWN0aW9uIDYuMS4yLCA2LjEu Mi4zDQo+IFNpbmNlIFJTVlAtVEUgTFNQIGRvZXMgbm90IGhhdmUgdGhlIG1lYXN1cmVtZW50IHBy b2JsZW0gbGlzdGVkIGluIHRoaXMgDQo+IGRyYWZ0LCB3aHkgd2UgbmVlZCB0byBkbyBSU1ZQLVRF IGV4dGVuc2lvbj8gTVAtQkdQIGlzIG5vdCB1c2VkIHRvIA0KPiBzZXR1cCBNUDJQIC8gTVAyTVAg TFNQLCB0aGVuIHdoeSB3ZSBuZWVkIHRoZSBleHRlbnNpb24/IERpZCBJIG1pc3Mgc29tZXRoaW5n Pw0KPiBHSU0+PiBJIHRoaW5rIHRoYXQgUlNWUC1URSBMU1Agd2l0aCBsYWJlbCBtZXJnZSBhbmQg UEhQIHN0aWxsIGhhdmUgDQo+IEdJTT4+IGlzc3Vlcw0KPiBkZXNjcmliZWQgaW4gdGhlIGRvY3Vt ZW50LiBQZXJoYXBzIG9ubHkgTVBMUy1UUCBjb25zdHJ1Y3RzIGhhdmUgDQo+IGRldGVybWluaXNt IG9mIHRyYW5zcG9ydCBuZXR3b3JrIGFuZCBtYXkgbm90IGhhdmUgdGhpcyBwcm9ibGVtLg0KPiBb TGl6aG9uZ10gUEhQIGNvdWxkIGJlIGRpc2FibGVkIGZvciBSU1ZQLVRFIExTUC4gV2hpY2ggY2Fz ZSBoYXMgbGFiZWwgDQo+IG1lcmdlIGZvciBSU1ZQLVRFIExTUD8gQW55d2F5LCBpZiB5b3UgdGhp bmsgUlNWUC1URSBhbHNvIGhhcyBpc3N1ZSwgDQo+IHlvdSBzaG91bGQgc2F5IHRoYXQgaW4gc2Vj dGlvbiAxLiBIb3dldmVyLCB1c2luZyBzb3VyY2UgbGFiZWwgdG8gZG8gTE0gDQo+IGZvciBSU1ZQ LVRFIExTUCBtYXkgbm90IGJlIGhlbHBmdWwsIHNpbmNlIHRoZSBSU1ZQLVRFIGxhYmVsIGlzIG1v cmUgDQo+IGFjY3VyYXRlIHRvIGlkZW50aWZ5IGFuIExTUCwgaW5jbHVkaW5nIHNvdXJjZSArIGRl c3RpbmF0aW9uICsgdHVubmVsIElEICsgTFNQIElEICsgUEhCLCBldGMuDQoNCklmIHRoZSBQSFAg aXMgZGlzYWJsZWQsIHRoZW4gc291cmNlIGxhYmVsIGZvciBSU1BWLVRFIG1heSBub3QgYmUgbmVl ZGVkLiBJZiBwZW9wbGUgdGhpbmsgUlNWUC1URSBjYXNlIGlzIG5vdCBhIHZhbGlkIGNhc2UsIHdl IGNvdWxkIHJlbW92ZSBpdC4NCg0KQlRXLCBwbGVhc2UgaGF2ZSBhIGxvb2sgYXQgdGhlIGxhc3Qg cGFyYWdyYXBoIG9mIHNlY3Rpb24gMyBvZiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhlbmctbDN2cG4tcG0tYW5hbHlzaXMtMDIjc2VjdGlvbi0zICkgLCBpdCB0YWxrcyBhIGNh c2UgdGhhdCBldmVuIGZvciBSU1ZQLVRFLCB0aGUgc291cmNlIGxhYmVsIG1heSBhbHNvIG5lZWRl ZC4gDQoNClRoYW5rcywNCk1hY2gNCg0KPiANCj4gUmVnYXJkcw0KPiBMaXpob25nDQoNClNuaXBl ZC4NCg== From nobody Fri May 16 02:50: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 4CFA11A01EA for ; Fri, 16 May 2014 02:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 em26xYlZCl2C for ; Fri, 16 May 2014 02:50:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDE01A01E9 for ; Fri, 16 May 2014 02:50:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGV36349; Fri, 16 May 2014 09:50:05 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 10:49:21 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 10:50:02 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 16 May 2014 17:49:53 +0800 From: Xuxiaohu To: "erosen@cisco.com" , Mach Chen Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPcFVVjHYT3+tqHUeXgDrK9iFdKptCb4Jw Date: Fri, 16 May 2014 09:49:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082726FF@NKGEML512-MBS.china.huawei.com> References: Your message of Tue, 13 May 2014 10:39:40 -0000. <3798.1400169002@erosen-lnx> In-Reply-To: <3798.1400169002@erosen-lnx> 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wZbdP5auoVOBNOc6O4rc6rOuyu4 Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 09:50:17 -0000 SGkgRXJpYywNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBFcmljIFJvc2VuIFtt YWlsdG86ZXJvc2VuQGNpc2NvLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTTE6jXUwjE1yNUgMjM6NTAN Cj4gytW8/sjLOiBNYWNoIENoZW4NCj4gs63LzTogWWltaW4gU2hlbjsgZHJhZnQtY2hlbi1tcGxz LXNvdXJjZS1sYWJlbEB0b29scy5pZXRmLm9yZzsNCj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc7IE1hcnRpbiBWaWdvdXJldXg7IG1wbHNAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFttcGxzXSBN UExTLVJUIHJldmlldyBvZiBkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsDQo+IA0KPiANCj4g TWFjaD4gQXMgZm9yIHRoZSBkaXN0cmlidXRpb24sIHNlZW1zIHRoYXQgSUdQIGV4dGVuc2lvbiBp cyBhIHJlYXNvbmFibGUNCj4gTWFjaD4gY2hvaWNlLA0KPiANCj4gVGhlIGRpc3RyaWJ1dGlvbiBt ZWNoYW5pc20gbmVlZHMgdG8gZW5zdXJlIHRoYXQgZWFjaCBlZ3Jlc3MgTFNSIHdpbGwgbGVhcm4g dGhlDQo+IHNvdXJjZSBsYWJlbCBvZiBlYWNoIGluZ3Jlc3MgTFNSLiAgVGhlcmUgYXJlIE1QTFMg ZGVwbG95bWVudHMgaW4gd2hpY2ggYW4NCj4gaW5ncmVzcyBMU1IgbWF5IGJlIHNlcGFyYXRlZCBm cm9tIGFuIGVncmVzcyBMU1IgYnkgbXVsdGlwbGUgQXV0b25vbW91cw0KPiBTeXN0ZW1zLCBlYWNo IG9mIHdoaWNoIGNvbnNpc3RzIG9mIGF0IGxlYXN0IG9uZSBJR1AgZG9tYWluLiAgKE9mIGNvdXJz ZSwgYW4gQVMNCj4gaXMgbm90IGxpbWl0ZWQgdG8gY29uc2lzdGluZyBvZiBvbmx5IG9uZSBJR1Ag ZG9tYWluLikgIEluIGEgZGVwbG95bWVudCBsaWtlIHRoaXMsDQo+IGhvdyB3aWxsIHRoZSBlZ3Jl c3MgTFNScyBsZWFybiB0aGUgc291cmNlIGxhYmVscyBvZiBhbGwgdGhlIGluZ3Jlc3MgTFNScz8N Cj4gU29tZXRoaW5nIG1vcmUgdGhhbiBhbiBJR1AgZXh0ZW5zaW9uIHNlZW1zIHRvIGJlIHJlcXVp cmVkLg0KDQpJdCBkb2Vzbid0IHJlcXVpcmUgdGhhdCB0aGUgc291cmNlIGxhYmVsIG9mIGEgZ2l2 ZW4gaW5ncmVzcyBMU1IgbXVzdCBiZSBhZHZlcnRpc2VkIGJ5IHRoYXQgaW5ncmVzcyBMU1IsIGVz cGVjaWFsbHkgaW4gdGhlIGludGVyLUFTIHNjZW5hcmlvIGFzIHlvdSBtZW50aW9uZWQuIEluIGZh Y3QsIHRoZSBTTCBhZHZlcnRpc2VtZW50IGNvdWxkIGJlIGRvbmUgYnkgYSBjZW50cmFsaXplZCBt YXBwaW5nIHNlcnZlciBpbiBlYWNoIElHUCBkb21haW4gYXMgd2VsbCAoc2VlIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWlzaXMtZ2xvYmFsLWxhYmVsLXNpZC1hZHYtMDApLiBB cyBzdWNoLCB0aGUgZWdyZXNzIExTUiBpbiBkb21haW4gWCBjb3VsZCBsZWFybiB0aGUgc291cmNl IGxhYmVsIG9mIHRoZSBpbmdyZXNzIExTUiBpbiBkb21haW4gWSB0aHJvdWdoIHRoZSBTTCBhZHZl cnRpc2VtZW50IG9yaWdpbmF0ZWQgYnkgYSBtYXBwaW5nIHNlcnZlciBpbiBkb21haW4gWCwgYXMg bG9uZyBhcyBkb21haW4gWCBhbmQgWSBzaGFyZSBhIHNpbmdsZSBzb3VyY2UgbGFiZWwgc3BhY2Ug YW5kIGFsbG9jYXRlIHRoZSBzYW1lIFNMIGZvciBhIGdpdmVuIGluZ3Jlc3MgTFNSLiBJbiBhZGRp dGlvbiwgYXMgTWFjaCBoYXMgbWVudGlvbmVkIGluIGEgcHJldmlvdXMgZW1haWwsIHdlIGNvdWxk IGZ1cnRoZXIgY29uc2lkZXIgdXNpbmcgQkdQIGV4dGVuc2lvbiB0byBleGNoYW5nZSB0aGUgU0wg bWFwcGluZyBpbmZvcm1hdGlvbiBiZXR3ZWVuIGRvbWFpbnMuIEluIHRoaXMgd2F5LCB0aGUgbWFw cGluZyBzZXJ2ZXIgd2l0aGluIGVhY2ggZG9tYWluIGNvdWxkIGRpcmVjdGx5IHJlZGlzdHJpYnV0 ZSB0aGUgU0wgbWFwcGluZ3MgbGVhcm50IGZyb20gbmVpZ2hib3JpbmcgZG9tYWlucyBpbnRvIElH UC4NCg0KQW55d2F5LCBJIGFncmVlIHdpdGggTWFjaCdzIHBvaW50IHRoYXQgdGhlIFNMIGRpc3Ry aWJ1dGlvbiBtZWNoYW5pc21zIHNob3VsZCBiZSBkZWZpbmVkIGluIHNlcGFyYXRlIGRvY3VtZW50 cy4NCg0KPiBPciBpcyB0aGUgaW50ZW50aW9uIHRoYXQgc291cmNlIGxhYmVscyBiZSB1bmlxdWUg b25seSB3aXRoaW4gYW4gSUdQIGRvbWFpbj8NCj4gSW4gdGhhdCBjYXNlLCBJIGFncmVlIHdpdGgg WWFrb3YgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIHN0YXRlIHRoYXQgY2xlYXJseS4NCj4gQnV0IHRo YXQgd291bGQgbWVhbiB0aGF0IHRoZSBzb3VyY2UgbGFiZWwgY2FuIG9ubHkgYmUgdXNlZCB3aGVu IHRoZSBpbmdyZXNzDQo+IGFuZCBlZ3Jlc3MgTFNScyBhcmUgaW4gdGhlIHNhbWUgSUdQIGRvbWFp bi4gIEJ1dCB0aGF0IHdvdWxkIHJhaXNlIGEgbnVtYmVyIG9mDQo+IG90aGVyIGlzc3VlczoNCj4g DQo+IC0gV2l0aCBhIHJlc3RyaWN0aW9uIHRvIG9uZSBJR1AgZG9tYWluLCBjYW4gdGhlIGludGVu ZGVkIHVzZSBjYXNlIGJlDQo+ICAgc3VwcG9ydGVkPw0KPiANCj4gLSBUaGUgaW5ncmVzcyB3b3Vs ZCBoYXZlIGtub3csIG5vdCBvbmx5IHRoYXQgdGhlIGVncmVzcyBpcyBjYXBhYmxlIG9mDQo+ICAg cHJvY2Vzc2luZyB0aGUgc291cmNlIGxhYmVsLCBidXQgdGhhdCB0aGUgZWdyZXNzIHdpbGwgaW50 ZXJwcmV0IHRoZSBzb3VyY2UNCj4gICBsYWJlbCBpbiB0aGUgcHJvcGVyIHNjb3BlLiAgVGhlIGRy YWZ0IGRvZXNuJ3QgYWRkcmVzcyB0aGUgaXNzdWUgb2YgaG93IHRvDQo+ICAgZW5zdXJlIHRoYXQg aW5ncmVzcyBhbmQgZWdyZXNzIGFncmVlIG9uIHRoZSBpbnRlbmRlZCBzY29wZSBvZiB0aGUgbGFi ZWwuDQoNClNpbmNlIHRoZSBzb3VyY2UgbGFiZWwgaXMgbm90IGludGVuZGVkIGZvciBwYWNrZXQg Zm9yd2FyZGluZywgdGhlIHNvdXJjZSBsYWJlbCBzcGFjZSBjYW4gYmUgZGVlbWVkIGFzIGFub3Ro ZXIgcGFydGljdWxhciBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlLiBPbmNlIGFuIGVncmVz cyBMU1IgaW5kaWNhdGVzIGl0IGhhcyB0aGUgU0xDLCBpdCBpbXBsaWNpdGx5IG1lYW5zIHRoYXQg aXQgY291bGQgY29ycmVjdGx5IGludGVycHJldCB0aGUgc291cmNlIGxhYmVsIGluIHRoYXQgcGFy dGljdWxhciBsYWJlbCBzcGFjZS4NCg0KPiAtIFNpbmNlIGEgcGFja2V0IGRvZXMgbm90IGNhcnJ5 IGFuIGlkZW50aWZpZXIgb2YgaXRzIGluZ3Jlc3MgSUdQIGRvbWFpbiwgdGhlDQo+ICAgZWdyZXNz IHdvdWxkbid0IGJlIGFibGUgdG8gaW50ZXJwcmV0IHRoZSBsYWJlbCB3aXRob3V0IGZpcnN0IGRl dGVybWluaW5nDQo+ICAgdGhlIGluZ3Jlc3MgSUdQIGRvbWFpbi4gIFRoZSBkcmFmdCBzYXlzIG5v dGhpbmcgYWJvdXQgaG93IHRoaXMgaXMgZG9uZS4NCj4gDQo+IEF0IHRoZSB2ZXJ5IGxlYXN0LCB0 aGlzIGRyYWZ0IG5lZWRzIHRvIHNwZWNpZnkgdGhlIGNoYXJhY3RlcmlzdGljcyBhIGRpc3RyaWJ1 dGlvbg0KPiBtZWNoYW5pc20gbXVzdCBoYXZlIGluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IGEgc291 cmNlIGxhYmVsIG5ldmVyIGdldHMNCj4gZGlzdHJpYnV0ZWQgb3V0c2lkZSB0aGUgImRvbWFpbiIg aW4gd2hpY2ggaXQgaXMgdW5pcXVlLiAgVGhlcmUgYWxzbyBuZWVkIHRvIGJlDQo+IGFzc3VyYW5j ZSB0aGF0IGEgZGF0YSBwYWNrZXQgY2FycnlpbmcgYSBzb3VyY2UgbGFiZWwgd2lsbCBuZXZlciBj YXJyeSB0aGUgc291cmNlDQo+IGxhYmVsIG91dHNpZGUgdGhlIHByb3BlciBkb21haW4uDQoNCj4g TWFjaD4gUmVnYXJkaW5nIHRvIHRoZSBhbGxvY2F0aW9uLCB0aGlzIGlzIHNhbWUgYXMgdGhlIElQ IGFkZHJlc3MNCj4gTWFjaD4gYWxsb2NhdGlvbg0KPiANCj4gSWYgYW4gYWxsb2NhdGlvbiBzY2hl bWUgaXMgdG8gaGF2ZSBtb3JlIHRoYW4gbG9jYWwgc2NvcGUsIGl0IHVzdWFsbHkgaGFzIHNvbWUg c29ydA0KPiBvZiBoaWVyYXJjaHkgdGhhdCBjYW4gYmUgdXNlZCB0byBwcmV2ZW50IGNvbGxpc2lv bnMuICBJUCBhZGRyZXNzZXMsIFJvdXRlDQo+IERpc3Rpbmd1aXNoZXJzLCBSb3V0ZSBUYXJnZXRz LCBhbGwgaGF2ZSBzb21lIGtpbmQgb2Ygc3RydWN0dXJlLg0KPiANCj4gPiBmb3IgYSBzaW5nbGUg b3BlcmF0b3IsIHRvIGd1YXJhbnRlZSB0aGUgdW5pcXVlbmVzcyBpcyByZWxldmFudCBlYXN5Lg0K PiANCj4gV2l0aCBubyBzdHJ1Y3R1cmUgYW5kIG5vICJkb21haW4gaWRlbnRpZmllciIgaW4gdGhl IHNvdXJjZSBsYWJlbCwgaXQgaXMgdmVyeSBlYXN5DQo+IGVuZCB1cCB3aXRoIG5vbi11bmlxdWUg bGFiZWxzIHdpdGhpbiBhIGRvbWFpbi4NCg0KSWYgeW91IHN0aWxsIGhhdmUgYSBjb25jZXJuIGFi b3V0IHRoZSB1bmlxdWVuZXNzIG9mIGZsYXQgaWRzIHdpdGhpbiBhIGRvbWFpbiwgeW91IGNvdWxk IGNob29zZSB0byBhbGxvY2F0ZSBzdWNoIGlkcyB0aHJvdWdoIGEgY2VudHJhbGl6ZWQgbWFwcGlu ZyBzZXJ2ZXIgKHNlZSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1pc2lzLWds b2JhbC1sYWJlbC1zaWQtYWR2LTAwKS4NCg0KPiBPbmUgbWlnaHQgYWxzbyBhc2sgd2h5IHRoZXJl IGlzIGEgbmVlZCB0byB1c2UgYSAyMC1iaXQgbGFiZWwgdG8gaWRlbnRpZnkgYSBub2RlLA0KPiBp bnN0ZWFkIG9mIHVzaW5nIHNvbWUgb3RoZXIgZm9ybWF0LiAgVGhlIGRyYWZ0IGRvZXNuJ3QgYWN0 dWFsbHkgc2VlbSB0byBhZGRyZXNzDQo+IHRoaXMgaXNzdWUsIGl0IGp1c3Qgc2F5cyAicmlnaHQg bm93IHlvdSBjYW4ndCBpZGVudGlmeSB0aGUgaW5ncmVzcywgd2UgbmVlZCB0bw0KPiBpZGVudGlm eSB0aGUgaW5ncmVzcywgdGhlcmVmb3JlIHdlIG5lZWQgdG8gaGF2ZSBhIDIwLWJpdCBsYWJlbCB0 aGF0IGlkZW50aWZpZXMgaXQiLg0KPiBJdCB3b3VsZCBiZSBnb29kIGlmIHRoZSBkcmFmdCBzYWlk IG1vcmUgYWJvdXQgd2h5IGEgc2luZ2xlIDIwLWJpdCB2YWx1ZSBpcyBuZWVkZWQNCj4gdG8gaWRl bnRpZnkgdGhlIGluZ3Jlc3Mgcm91dGVyLg0KDQo+IEJ5IHRoZSB3YXksICJzb3VyY2UgbGFiZWwi IGlzIGFuIHVuZm9ydHVuYXRlIGNob2ljZSBvZiB0ZXJtaW5vbG9neSBmb3IgYSBmaWVsZA0KPiB0 aGF0IGlkZW50aWZpZXMgYW4gaW5ncmVzcyBMU1IsIGFzIGZvbGtzIG91dHNpZGUgdGhlIFJvdXRp bmcgQXJlYSB3aWxsDQo+IGhhdmUgdHJvdWJsZSB0aGlua2luZyBvZiBhIHJvdXRlciBhcyB0aGUg InNvdXJjZSIgb2YgYSBwYWNrZXQuDQoNCldoYXQgYWJvdXQgSUlMIChJbmdyZXNzIElkZW50aWZp Y2F0aW9uIExhYmVsKT8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gDQo+IA0KPiANCg0K From nobody Fri May 16 03:05: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 E1DDA1A01F5 for ; Fri, 16 May 2014 03:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 H84CoutzoRtK for ; Fri, 16 May 2014 03:05:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBA21A0075 for ; Fri, 16 May 2014 03:05:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGV37868; Fri, 16 May 2014 10:05:26 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 11:04:44 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 11:05:24 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 16 May 2014 18:05:13 +0800 From: Xuxiaohu To: Mach Chen , Lizhong Jin , Gregory Mirsky Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPcE4ak8hnpUKxfE68iAjOcu0KIptCZoYAgACU69A= Date: Fri, 16 May 2014 10:05:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827271B@NKGEML512-MBS.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B7B12A5@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] 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/REYND1KqkjcNvWmGGfoJGjgYaJU Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Ross Callon Subject: [mpls] =?utf-8?b?562U5aSNOiAgTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtY2hl?= =?utf-8?q?n-mpls-source-label?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 10:05:39 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IE1hY2ggQ2hlbiBbbWFp bHRvOm1hY2guY2hlbkBodWF3ZWkuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTTlubQ15pyIMTbm l6UgMTc6MTANCj4g5pS25Lu25Lq6OiBMaXpob25nIEppbjsgR3JlZ29yeSBNaXJza3kNCj4g5oqE 6YCBOiBkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsQHRvb2xzLmlldGYub3JnOyBtcGxzQGll dGYub3JnOw0KPiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgUm9zcyBDYWxsb24NCj4g5Li7 6aKYOiBSRTogW21wbHNdIE1QTFMtUlQgcmV2aWV3IG9mIGRyYWZ0LWNoZW4tbXBscy1zb3VyY2Ut bGFiZWwNCj4gDQo+IEhpIExpemhvbmcsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMh DQo+IA0KPiBTZWUgbXkgcmVwbHkgaW5saW5lLi4uDQo+IA0KPiBTbmlwZWQuDQo+IA0KPiA+IEdJ TT4+IEkgdGhpbmsgdGhhdCBub3QgYWxsIExTUnMgaW4gYW4gSUdQIGRvbWFpbiBhcmUgcmVxdWly ZWQgdG8gYmUNCj4gPiBHSU0+PiBTTEMgYnV0IG9ubHkNCj4gPiBlbmQtcG9pbnRzIG9mIGFuIExT UC4gVGh1cywgaWYgYW4gTFNSIGlzIG5vdCBTTEMsIHRoZW4gU0wgY2Fubm90IGJlDQo+ID4gdXNl ZCBvbiBMU1BzIGl0IG9yaWdpbmF0ZXMvdGVybWluYXRlcy4gQ2hhbmdlIGluIFNMQywgSSBpbWFn aW5lLCBtYXkNCj4gPiBjb21lIGFzIHJlc3VsdCBvZiBTVyB1cGdyYWRlLiBUaG91Z2ggaXQgd291 bGQgdHJpZ2dlZCBmbG9vZCBvZiB1cGRhdGVzDQo+ID4gdGhhdCwgSU1PLCB3b3VsZCBiZSBvbmUt dGltZSBldmVudC4NCj4gPiBbTGl6aG9uZ10gaW4gYW4gTERQIG5ldHdvcmssIGV2ZXJ5IG5vZGUg d291bGQgYmUgcG9zc2libHkgdG8gYmUgZWdyZXNzIG9mIGFuDQo+IEZFQy4NCj4gPiBJbiB0aGUg ZHJhZnQsIGl0IHNheXM6DQo+ID4gQW4gTFNSIFggbWF5IHJlY2VpdmUgbXVsdGlwbGUgTGFiZWwg TWFwcGluZ3MgZm9yIGEgZ2l2ZW4NCj4gPg0KPiA+ICAgIEZFQyBGIGZyb20gaXRzIG5laWdoYm9y cy4gIEluIGl0cyB0dXJuLCBYIG1heSBhZHZlcnRpc2UgYSBMYWJlbA0KPiA+ICAgIE1hcHBpbmcg Zm9yIEYgdG8gaXRzIG5laWdoYm9ycy4gIElmIFggdW5kZXJzdGFuZHMgdGhlIFNMQyBUTFYsIGFu ZA0KPiA+IGlmDQo+ID4gICAgYW55IG9mIHRoZSBhZHZlcnRpc2VtZW50cyBpdCByZWNlaXZlZCBm b3IgRkVDIEYgZG9lcyBub3QgaW5jbHVkZQ0KPiA+IHRoZQ0KPiA+ICAgIFNMQyBUTFYsIFggTVVT VCBOT1QgaW5jbHVkZSB0aGUgU0xDIFRMViBpbiBpdHMgb3duIGFkdmVydGlzZW1lbnRzDQo+ID4g b2YNCj4gPiAgICBGLg0KPiA+DQo+ID4gSW4gRFUgbW9kZSwgdGhlIG1hcHBpbmcgYWR2ZXJ0aXNl bWVudCB3aWxsIGJlIGluZmx1ZW5jZWQgYnkgb3RoZXINCj4gPiByZWNlaXZlZCBhZHZlcnRpc2Vt ZW50LCB3aGljaCB3aWxsIGJyaW5nIG1vcmUgc2lnbmFsaW5nLiBUaGlzIGlzIG5vdA0KPiA+IG9u ZS10aW1lIGV2ZW50LCBhbnkgTERQIHNlc3Npb24gVVAvRE9XTiB3aWxsIGluZmx1ZW5jZSB0aGUg d2hvbGUNCj4gPiBzaWduYWxpbmcuIEJ1dCB3aHkgZG9uJ3QgeW91IGxpbWl0IHRoZSByZWNlaXZl ZCBhZHZlcnRpc2VtZW50IG9ubHkNCj4gPiBmcm9tIHRoZSBkb3duc3RyZWFtIG5vZGUsIG5vdCBh bGwgbm9kZXM/IE9ubHkgdGhlIHJlY2VpdmVkDQo+ID4gYWR2ZXJ0aXNlbWVudCBmcm9tIGRvd25z dHJlYW0gbm9kZSBkb2VzIG5vdCBTTEMgVExWLCBYIG11c3Qgbm90IGluY2x1ZGUNCj4gU0xDIFRM Vi4NCj4gDQo+IFRoZSBhYm92ZSBtZWNoYW5pc20gaXMgb3JpZ2luYWxseSBkZWZpbmVkIGZvciBF TEMsIGFuZCBJTUhPLCBmcm9tIHRoZQ0KPiBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIHBvaW50IG9m IHZpZXcsIHRoZXJlIGlzIG5vIGRpZmZlcmVudCBiZXR3ZWVuIEVMQyBhbmQgU0xDLg0KPiBBcyBz dGF0ZWQgaW4gdGhlIEFja25vd2xlZGdlbWVudHMgc2VjdGlvbiwgdGhlIFNMQyBuZWdvdGlhdGlv biBpcyByZWZlcnJlZCB0bw0KPiBFTEMgbmVnb3RpYXRpb24gbWVjaGFuaXNtLg0KPiANCj4gSWYg eW91IGhhdmUgYmV0dGVyIHN1Z2dlc3Rpb24sIHRoYXQgd2lsbCBiZSBhcHByZWNpYXRlZC4NCg0K VGhlIGRvd25zdHJlYW0gbm9kZSBjb3VsZCBiZWNvbWUgYW4gdXBzdHJlYW0gbm9kZSwgYW5kIHZp Y2UgdmVyc2UuIFRoZXJlZm9yZSwgSSBiZWxpZXZlIHRoZSBjdXJyZW50IGRlc2NyaXB0aW9uIGlz IG5vIHByb2JsZW0uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+ID4NCj4gPiBTZWN0aW9u IDYuMS4yLCA2LjEuMi4zDQo+ID4gU2luY2UgUlNWUC1URSBMU1AgZG9lcyBub3QgaGF2ZSB0aGUg bWVhc3VyZW1lbnQgcHJvYmxlbSBsaXN0ZWQgaW4gdGhpcw0KPiA+IGRyYWZ0LCB3aHkgd2UgbmVl ZCB0byBkbyBSU1ZQLVRFIGV4dGVuc2lvbj8gTVAtQkdQIGlzIG5vdCB1c2VkIHRvDQo+ID4gc2V0 dXAgTVAyUCAvIE1QMk1QIExTUCwgdGhlbiB3aHkgd2UgbmVlZCB0aGUgZXh0ZW5zaW9uPyBEaWQg SSBtaXNzDQo+IHNvbWV0aGluZz8NCj4gPiBHSU0+PiBJIHRoaW5rIHRoYXQgUlNWUC1URSBMU1Ag d2l0aCBsYWJlbCBtZXJnZSBhbmQgUEhQIHN0aWxsIGhhdmUNCj4gPiBHSU0+PiBpc3N1ZXMNCj4g PiBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LiBQZXJoYXBzIG9ubHkgTVBMUy1UUCBjb25zdHJ1 Y3RzIGhhdmUNCj4gPiBkZXRlcm1pbmlzbSBvZiB0cmFuc3BvcnQgbmV0d29yayBhbmQgbWF5IG5v dCBoYXZlIHRoaXMgcHJvYmxlbS4NCj4gPiBbTGl6aG9uZ10gUEhQIGNvdWxkIGJlIGRpc2FibGVk IGZvciBSU1ZQLVRFIExTUC4gV2hpY2ggY2FzZSBoYXMgbGFiZWwNCj4gPiBtZXJnZSBmb3IgUlNW UC1URSBMU1A/IEFueXdheSwgaWYgeW91IHRoaW5rIFJTVlAtVEUgYWxzbyBoYXMgaXNzdWUsDQo+ ID4geW91IHNob3VsZCBzYXkgdGhhdCBpbiBzZWN0aW9uIDEuIEhvd2V2ZXIsIHVzaW5nIHNvdXJj ZSBsYWJlbCB0byBkbyBMTQ0KPiA+IGZvciBSU1ZQLVRFIExTUCBtYXkgbm90IGJlIGhlbHBmdWws IHNpbmNlIHRoZSBSU1ZQLVRFIGxhYmVsIGlzIG1vcmUNCj4gPiBhY2N1cmF0ZSB0byBpZGVudGlm eSBhbiBMU1AsIGluY2x1ZGluZyBzb3VyY2UgKyBkZXN0aW5hdGlvbiArIHR1bm5lbCBJRCArIExT UCBJRA0KPiArIFBIQiwgZXRjLg0KPiANCj4gSWYgdGhlIFBIUCBpcyBkaXNhYmxlZCwgdGhlbiBz b3VyY2UgbGFiZWwgZm9yIFJTUFYtVEUgbWF5IG5vdCBiZSBuZWVkZWQuIElmDQo+IHBlb3BsZSB0 aGluayBSU1ZQLVRFIGNhc2UgaXMgbm90IGEgdmFsaWQgY2FzZSwgd2UgY291bGQgcmVtb3ZlIGl0 Lg0KPiANCj4gQlRXLCBwbGVhc2UgaGF2ZSBhIGxvb2sgYXQgdGhlIGxhc3QgcGFyYWdyYXBoIG9m IHNlY3Rpb24gMyBvZg0KPiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmct bDN2cG4tcG0tYW5hbHlzaXMtMDIjc2VjdGlvbi0zICkgLCBpdA0KPiB0YWxrcyBhIGNhc2UgdGhh dCBldmVuIGZvciBSU1ZQLVRFLCB0aGUgc291cmNlIGxhYmVsIG1heSBhbHNvIG5lZWRlZC4NCj4g DQo+IFRoYW5rcywNCj4gTWFjaA0KPiANCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPiBMaXpob25nDQo+ IA0KPiBTbmlwZWQuDQo= From nobody Fri May 16 08:13: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 5F0881A007C for ; Fri, 16 May 2014 08:13:16 -0700 (PDT) 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_OFF=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 psT1V3cjX6vp for ; Fri, 16 May 2014 08:13:14 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8547D1A00C0 for ; Fri, 16 May 2014 08:13:14 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id hl10so1767465igb.0 for ; Fri, 16 May 2014 08:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HOELovSH8bKoYfj3cIxkHp0nC+XGeSKLvQC1+Q94smg=; b=LAbpbP8oWEjlpWiQG/ZfbCvygm+egUqjWxE0ac6sn9cfZiUpOr/tSmXH1REFXhx7wZ Q/qTYTtbeHUoxyJi5UQrARrV8NhgR5gaI7ywW0GvPit3p+yBDWIQAVUeBBu/Nd/cfXoT U2gz/7wX75OP+R2IBi/2d2HQPnZG1xZx3SchGhzvJwZdB8egWsawMg4855xUloEBHM4F 6GvEsHbhVtDi4S3Rtx4xcuJfji0mwbkwEw1erOzTEcStIqiMUugnXDlqk08Cb9HEgckF 7RNcPBMtie56DT+mult1nuOynSyFOj3Zsonlucr1sd+TUeNtNzoSEMMJ1cEN/rKJ8CCb oMNw== MIME-Version: 1.0 X-Received: by 10.50.114.4 with SMTP id jc4mr20561404igb.33.1400253186910; Fri, 16 May 2014 08:13:06 -0700 (PDT) Received: by 10.42.95.208 with HTTP; Fri, 16 May 2014 08:13:06 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF1121B7B12A5@eusaamb103.ericsson.se> Date: Fri, 16 May 2014 23:13:06 +0800 Message-ID: From: Lizhong Jin To: Mach Chen Content-Type: multipart/alternative; boundary=047d7b2e0983cd2e4304f985d953 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8_MsJxbXZOg91aTqXtqWn_1yyTQ Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 15:13:16 -0000 --047d7b2e0983cd2e4304f985d953 Content-Type: text/plain; charset=UTF-8 Hi Mach, Inline below. Thanks. Lizhong On Friday, May 16, 2014, Mach Chen wrote: > Hi Lizhong, > > Thanks for your comments! > > See my reply inline... > > Sniped. > > > GIM>> I think that not all LSRs in an IGP domain are required to be > > GIM>> SLC but only > > end-points of an LSP. Thus, if an LSR is not SLC, then SL cannot be > > used on LSPs it originates/terminates. Change in SLC, I imagine, may > > come as result of SW upgrade. Though it would trigged flood of updates > > that, IMO, would be one-time event. > > [Lizhong] in an LDP network, every node would be possibly to be egress > of an FEC. > > In the draft, it says: > > An LSR X may receive multiple Label Mappings for a given > > > > FEC F from its neighbors. In its turn, X may advertise a Label > > Mapping for F to its neighbors. If X understands the SLC TLV, and > > if > > any of the advertisements it received for FEC F does not include > > the > > SLC TLV, X MUST NOT include the SLC TLV in its own advertisements > > of > > F. > > > > In DU mode, the mapping advertisement will be influenced by other > > received advertisement, which will bring more signaling. This is not > > one-time event, any LDP session UP/DOWN will influence the whole > > signaling. But why don't you limit the received advertisement only > > from the downstream node, not all nodes? Only the received > > advertisement from downstream node does not SLC TLV, X must not include > SLC TLV. > > The above mechanism is originally defined for ELC, and IMHO, from the > capability negotiation point of view, there is no different between ELC and > SLC. As stated in the Acknowledgements section, the SLC negotiation is > referred to ELC negotiation mechanism. > > If you have better suggestion, that will be appreciated. > [Lizhong] I know you borrow the text from RFC6790. My suggestion is, only when the received advertisement from downstream node (not any node) does not include SLC TLV, X must not include SLC TLV. That will improve the signaling, right? The LDP signaling flapping of non-downstream advertisement will not influence the upstream advertisement. > > > Section 6.1.2, 6.1.2.3 > > Since RSVP-TE LSP does not have the measurement problem listed in this > > draft, why we need to do RSVP-TE extension? MP-BGP is not used to > > setup MP2P / MP2MP LSP, then why we need the extension? Did I miss > something? > > GIM>> I think that RSVP-TE LSP with label merge and PHP still have > > GIM>> issues > > described in the document. Perhaps only MPLS-TP constructs have > > determinism of transport network and may not have this problem. > > [Lizhong] PHP could be disabled for RSVP-TE LSP. Which case has label > > merge for RSVP-TE LSP? Anyway, if you think RSVP-TE also has issue, > > you should say that in section 1. However, using source label to do LM > > for RSVP-TE LSP may not be helpful, since the RSVP-TE label is more > > accurate to identify an LSP, including source + destination + tunnel ID > + LSP ID + PHB, etc. > > If the PHP is disabled, then source label for RSPV-TE may not be needed. > If people think RSVP-TE case is not a valid case, we could remove it. > > BTW, please have a look at the last paragraph of section 3 of ( > http://tools.ietf.org/html/draft-zheng-l3vpn-pm-analysis-02#section-3 ) , > it talks a case that even for RSVP-TE, the source label may also needed. > [Lizhong] Thanks for the link. What I want to say is, if you believe RSVP-TE has issue, then explicitly say that in section 1. In current text, you said, RSVP-TE is OK in section 1, but you still extend RSVP-TE protocol, that is confusing. And the same issue to MP-BGP extension. > Thanks, > Mach > > > > > Regards > > Lizhong > > Sniped. > --047d7b2e0983cd2e4304f985d953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mach,
Inline below. Thanks.

Lizhong

= On Friday, May 16, 2014, Mach Chen <mach.chen@huawei.com> wrote:
Hi Lizhong,

Thanks for your comments!

See my reply inline...

Sniped.

> GIM>> I think that not all LSRs in an IGP domain are required to= be
> GIM>> SLC but only
> end-points of an LSP. Thus, if an LSR is not SLC, then SL cannot be > used on LSPs it originates/terminates. Change in SLC, I imagine, may > come as result of SW upgrade. Though it would trigged flood of updates=
> that, IMO, would be one-time event.
> [Lizhong] in an LDP network, every node would be possibly to be egress= of an FEC.
> In the draft, it says:
> An LSR X may receive multiple Label Mappings for a given
>
> =C2=A0 =C2=A0FEC F from its neighbors. =C2=A0In its turn, X may advert= ise a Label
> =C2=A0 =C2=A0Mapping for F to its neighbors. =C2=A0If X understands th= e SLC TLV, and
> if
> =C2=A0 =C2=A0any of the advertisements it received for FEC F does not = include
> the
> =C2=A0 =C2=A0SLC TLV, X MUST NOT include the SLC TLV in its own advert= isements
> of
> =C2=A0 =C2=A0F.
>
> In DU mode, the mapping advertisement will be influenced by other
> received advertisement, which will bring more signaling. This is not > one-time event, any LDP session UP/DOWN will influence the whole
> signaling. But why don't you limit the received advertisement only=
> from the downstream node, not all nodes? Only the received
> advertisement from downstream node does not SLC TLV, X must not includ= e SLC TLV.

The above mechanism is originally defined for ELC, and IMHO, from the capab= ility negotiation point of view, there is no different between ELC and SLC.= As stated in the Acknowledgements section, the SLC negotiation is referred= to ELC negotiation mechanism.

If you have better suggestion, that will be appreciated.
[Lizhong] I know you borrow the text from RFC6790. =C2=A0My suggestion i= s, only when the received advertisement from downstream node (not any node)= does not include SLC TLV, X must not include SLC TLV. That will improve th= e signaling, right? The LDP signaling flapping of non-downstream advertisem= ent will not influence the upstream advertisement.

>
> Section 6.1.2, 6.1.2.3
> Since RSVP-TE LSP does not have the measurement problem listed in this=
> draft, why we need to do RSVP-TE extension? MP-BGP is not used to
> setup MP2P / MP2MP LSP, then why we need the extension? Did I miss som= ething?
> GIM>> I think that RSVP-TE LSP with label merge and PHP still ha= ve
> GIM>> issues
> described in the document. Perhaps only MPLS-TP constructs have
> determinism of transport network and may not have this problem.
> [Lizhong] PHP could be disabled for RSVP-TE LSP. Which case has label<= br> > merge for RSVP-TE LSP? Anyway, if you think RSVP-TE also has issue, > you should say that in section 1. However, using source label to do LM=
> for RSVP-TE LSP may not be helpful, since the RSVP-TE label is more > accurate to identify an LSP, including source + destination + tunnel I= D + LSP ID + PHB, etc.

If the PHP is disabled, then source label for RSPV-TE may not be needed. If= people think RSVP-TE case is not a valid case, we could remove it.

BTW, please have a look at the last paragraph of section 3 of (http://tools.ietf.org/html/draft-zheng-l3vpn-pm-analysis-02#se= ction-3 ) , it talks a case that even for RSVP-TE, the source label may= also needed.
[Lizhong] Thanks for the link. What I want to say is, if = you believe RSVP-TE has issue, then explicitly say that in section 1. In cu= rrent text, you said, RSVP-TE is OK in section 1, but you still extend RSVP= -TE protocol, that is confusing. And the same issue to MP-BGP extension.


Thanks,
Mach

>
> Regards
> Lizhong

Sniped.
--047d7b2e0983cd2e4304f985d953-- From nobody Fri May 16 22:12: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 44C881A00D7 for ; Fri, 16 May 2014 22:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGZTbRUYMgOi for ; Fri, 16 May 2014 22:12:26 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC661A008E for ; Fri, 16 May 2014 22:12:26 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.34.106]) (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 AF876180203E for ; Sat, 17 May 2014 07:12:16 +0200 (CEST) Message-ID: <5376EFAC.7010906@pi.nu> Date: Sat, 17 May 2014 07:12:12 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <8770.1400250056@sandelman.ca> In-Reply-To: <8770.1400250056@sandelman.ca> X-Forwarded-Message-Id: <8770.1400250056@sandelman.ca> Content-Type: multipart/mixed; boundary="------------020309060907030705060204" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gimlFmfISucSPbO_mOijLSS04Cs Subject: [mpls] Fwd: NomCom 2014-2015 Call for Volunteers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 05:12:29 -0000 This is a multi-part message in MIME format. --------------020309060907030705060204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please consider volunteering for the IETF nominating committee. Broad community participation is important for our process. /Loa -------- Original Message -------- Subject: NomCom 2014-2015 Call for Volunteers Date: Fri, 16 May 2014 10:20:56 -0400 From: Michael Richardson Reply-To: mcr+nomcom@sandelman.ca To: ietf@ietf.org The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org --------------020309060907030705060204 Content-Type: application/pgp-signature; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIg KEdOVS9MaW51eCkNCg0KaVFFVkF3VUJVM1lleDRDTGNQdmQwTjFsQVFMYVVRZ0FwbUt6elh4 Tk55aFhvcDY1VkxaVnFjL3dKL1BBY0xvcw0KWTBlY1lneFY5SHJ3UGF6QkdaMDU0M0NPTGkv Zm15M3dIMVhqY1QwK3VqSnRkcmZGMTZxODNMSStucEVvclV1MA0KS3lYclAwOVM2bWhlRkF6 Q3VkUk1tQ1UzektIUzdqK3FxNEFHMGhFeUo0Q0pUVnhiMEl5MEpDMzVTaDcxRW5kVA0Kb0R2 T29oRXVUbHAwdnFrZUg3LzNPVnRDekxmcnZoRXFKMDNNWERYZ1BGaE8vb2JDTk9EM3cxdC9u TWZBOGhjcg0KUGxQOVBGQVl0dEdWMWtBLzEvTllhM1NYUDljdUo3NjJMb2NGNDFoaUhsMU5Y dkVYdXZjYVZIV3dtWUlqQ05aVw0KYzR5SkV3bkhkcWUreFVKTFlZUHhvY0ZwT0dWTENuOE4w djExaGt1bmVFS0QvdWVkMEV0ZzV3PT0NCj1CZlY5DQotLS0tLUVORCBQR1AgU0lHTkFUVVJF LS0tLS0NCg== --------------020309060907030705060204-- From nobody Sun May 18 22:43: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 62E841A02F0 for ; Sun, 18 May 2014 22:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t43qBQfIwvCq for ; Sun, 18 May 2014 22:43:50 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7274E1A02EE for ; Sun, 18 May 2014 22:43:50 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.34.106]) (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 CA5811802AD1; Mon, 19 May 2014 07:43:46 +0200 (CEST) Message-ID: <53799A0E.4060605@pi.nu> Date: Mon, 19 May 2014 07:43:42 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.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/ugck1QZAuAnE7TVcIo-ttp_WHok Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: [mpls] Implementations of 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: Mon, 19 May 2014 05:43:52 -0000 Working Group, draft-ietf-mpls-lsp-ping-relay-reply has been updated after working group last call. All the authors have responded that as far as they know all IPRs has been disclosed. We are almost ready to send the document to the IESG with a request for publication. In preparing the shepherd write-up we need information on existing implementations. This is to start a poll for implementations of draft-ietf-mpls-lsp-ping-relay-reply. If you have an implementation please respond to the mailing-list or directly to the wg-chairs. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon May 19 02:43: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 DA3C91A0336 for ; Mon, 19 May 2014 02:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB3NyXoN5Q81 for ; Mon, 19 May 2014 02:43:46 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82AB1A032A for ; Mon, 19 May 2014 02:43:46 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.34.106]) (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 77DED1802AD1; Mon, 19 May 2014 11:43:44 +0200 (CEST) Message-ID: <5379D24B.3010206@pi.nu> Date: Mon, 19 May 2014 11:43:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <53799A0E.4060605@pi.nu> In-Reply-To: <53799A0E.4060605@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/otwTEmG-9L3jC6dboa_RJoJ_uqo Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: Re: [mpls] Implementations of 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: Mon, 19 May 2014 09:43:49 -0000 Folks, Sorry - this was a bit hasty; the first paragraph should say draft-ietf-mpls-lsp-ping-relay-reply has been updated after a chair review. We are almost ready to start a wglc. In parallel we will start an implementation poll. Sorry for the confusion, I will start the wglc in another mail in a few minutes. The implementation poll is still on! /Loa On 2014-05-19 07:43, Loa Andersson wrote: > Working Group, > > draft-ietf-mpls-lsp-ping-relay-reply has been updated after working > group last call. All the authors have responded that as far as they > know all IPRs has been disclosed. We are almost ready to send the > document to the IESG with a request for publication. > > In preparing the shepherd write-up we need information on existing > implementations. > > This is to start a poll for implementations of > draft-ietf-mpls-lsp-ping-relay-reply. > > If you have an implementation please respond to the mailing-list > or directly to the wg-chairs. > > /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon May 19 02:49: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 CAC761A0346 for ; Mon, 19 May 2014 02:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsEES-SCU7Wt for ; Mon, 19 May 2014 02:49:36 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B981A032F for ; Mon, 19 May 2014 02:49:35 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.34.106]) (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 4F9471802AD1; Mon, 19 May 2014 11:49:33 +0200 (CEST) Message-ID: <5379D3A8.5020507@pi.nu> Date: Mon, 19 May 2014 11:49:28 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.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/N9cL2dCQ1DuUM3qGCQmzABw0r10 Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: [mpls] 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: Mon, 19 May 2014 09:49:37 -0000 Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-relay-reply. There are two IPR disclosures against this document. The author has stated that he is unaware of any other IPRs that relate to this document. Please send your comments to the mpls wg mailing list (mpls@ietf.org). This working group last call ends June 2, 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 Mon May 19 15: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 6AE0E1A0404 for ; Mon, 19 May 2014 15:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z6nFK0JLenfo for ; Mon, 19 May 2014 15:10:43 -0700 (PDT) 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 30DF21A03C3 for ; Mon, 19 May 2014 15:10:43 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-ee-537a2f4dd8c7 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A4.68.11744.D4F2A735; Mon, 19 May 2014 18:20:29 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Mon, 19 May 2014 18:10:40 -0400 From: Sriganesh Kini To: Loa Andersson , Curtis Villamizar , Xuxiaohu , "thomas.morin@orange.com" Thread-Topic: MPLS-RT review of draft-tsaad-mpls-p2mp-loose-path-reopt Thread-Index: AQHPXimYbzXLKJja6Eq7kSygg5PJ0psd6QCAgCqGuAA= Date: Mon, 19 May 2014 22:10:40 +0000 Message-ID: In-Reply-To: <5356727F.8080908@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3FE3BD643A9C1B4C904BB38195725D85@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyuXRPgq6vflWwweHFshaHD0xnt3jf85bV 4t/cOcwWd3Z9YbX4fmkJi8WtpStZLTbsO8pmsfX8KkYHDo/WZ3tZPVqOvGX1WLLkJ5PH4i9+ Hi3PTrJ5zJrexubx5fJntgD2KC6blNSczLLUIn27BK6MV5/kChaLVnz4sYO1gfGyQBcjJ4eE gIlEb8dTFghbTOLCvfVsXYxcHEICRxklPi97zQLhLGeUuNr+F6yKTcBI4sLd+WAJEYFZjBKH tnQzgTjMArOZJGbe+sgGUiUs4Cpx/s87ZhBbRMBN4nrvFTYI20piwrWXrCA2i4CqRP/WaWA2 r4CFRPeKPWD1nEDx73+vg8UZgW76fmoNE4jNLCAucevJfCaIWwUkluw5zwxhi0q8fPwPrF5U QE/i8J7XrBBxRYl9/dPZIXr1JG5MncIGYVtLbLtzE2qmtsSyha+ZIW4QlDg58wnLBEbxWUjW zULSPgtJ+ywk7bOQtC9gZF3FyFFanFqWm25kuIkRGMXHJNgcdzAu+GR5iFGAg1GJh1fhWmWw EGtiWXFl7iFGaQ4WJXHeuSeBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhglr94Kawpamfj6 5j1P/n2z//f+3v1HoHiqP+tR1u+CMz6oP3raxiPgd1DkrM+GMtMVU3cY9pd/45x3Krz+/iWx ozNa/kmnmQtPSi/tlLO1Fr1p1R1jZtOUI9fjFn9GYmZTxqWS6EyFPWt8DTZJKGfVtKst2vjA eMXVwzwrd83Yl7f9q2rdQ0slluKMREMt5qLiRADOet3awwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xFve7on_8YgeECzmFMsOGUfm38k Cc: "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-tsaad-mpls-p2mp-loose-path-reopt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 22:10:45 -0000 Hello, Some review comments are below. Overall, the draft is addressing a useful-problem but is not coherent. I think the problem statement has to be clearly defined and terminology fixed before the draft proceeds to WG acceptance call. 1. Abstract should state that the specific limitation being addressed is one of tree-optimization as opposed to the individual sub-LSP re-optimization that is already defined. 2. The "egress border" node used in Pg-3 bullet-1 should be defined. I am assuming you intended to say mid-point LSR of RFC 4736 ? 3. Pg-3 last para. RFC 4736 states that reoptimization is for a preferable path i.e. shorter path. This should be re-defined for a P2MP LSP so that the notion of preferable is clear. This is critical to define the problem statement. 4. Pg-4 bullet-1. What is the 'query' being referred to here? Is it path re-evaluation request ? 5. Pg-4 sec 1. A figure to illustrate the problems would be very useful. 6. Pg-5 section-3 last para. "...re-evaluating loosely expanded paths of all S2L sub-LSP(s)...". Shouldn't the PathErr be sent even if a single S2L sub-LSP can be re-optimized. Why should 'all' be re-evaluated ? 7. Do the procedures in this draft guarantee 'global optimization' ? Thanks Sri On 4/22/14 6:45 AM, "Loa Andersson" wrote: >All, > >I was to conservative sending this out, authors, co-chairs and >wg secretary should have been copied. > >/Loa > >On 2014-04-22 14:51, Loa Andersson wrote: >> Curtis, Xiaohu, Sri, Thomas, >> >> You have been selected as an MPLS Review team reviewers for >> draft-tsaad-mpls-p2mp-loose-path-reopt. >> >> Note to authors: You have been CC=B9d 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=B9t >> 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 >> secretary, and CC=B9d to the MPLS WG email list. If necessary, comments >> may be sent privately to only the WG chairs. >> >> Are you able to review this draft by May 7, 2014? >> >> 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 Tue May 20 07:11: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 667201A037D for ; Tue, 20 May 2014 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwcoU1QuclEc for ; Tue, 20 May 2014 07:11:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 365F61A0719 for ; Tue, 20 May 2014 07:11:04 -0700 (PDT) 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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140520141104.23182.43844.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 07:11:04 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/DZD0X-WXPvmlPnJnxTMOh65Lxhw Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:11:06 -0000 Changed milestone "Submit draft-ietf-mpls-lsp-ping-relay-reply for publication", set due date to August 2014 from April 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Tue May 20 08:50: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 50C0C1A0774 for ; Tue, 20 May 2014 08:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KMJ7IAd5pJC for ; Tue, 20 May 2014 08:50:24 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE251A0771 for ; Tue, 20 May 2014 08:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10028; q=dns/txt; s=iport; t=1400601023; x=1401810623; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=uPeu7TTLJNDfKg/pamp/ghGYQ6Mthuog079HejJ+bBg=; b=IOuSkeS6LyhHZwi8apx0DQaK7rRVkxAmT4t7S9bCKHbmnYBQHLzzPhk/ vvBTCO/TqFT6TKUQT6MyECWBB4PAnc0PLvzjvnoG3lX1Jk6pH88R6S62o qAA8iFNs07DVPQjfSp3l42yA0tdDLtCphSuP0zDWAaGK1399MbOuAZB67 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAMN4e1OtJssW/2dsb2JhbABZgkKBFcRuAYEydIIlAQEBBC06EQEQCxEEAQEBCRYIBwkDAgECATQJCAYBDAEFAgEBiD0NtUGeEheOLCIGAQaEOgSZaJMggzls X-IronPort-AV: E=Sophos; i="4.98,874,1392163200"; d="scan'208,217"; a="51695085" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 20 May 2014 15:50:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4KFoLWJ011079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 May 2014 15:50:21 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s4KFoKuU012058; Tue, 20 May 2014 16:50:20 +0100 (BST) Message-ID: <537B79BC.9080006@cisco.com> Date: Tue, 20 May 2014 16:50:20 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Eric Gray , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <53455996.9060407@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A55453@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632A55453@eusaamb107.ericsson.se> Content-Type: multipart/alternative; boundary="------------000505000504080403080809" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gP-zuxKqY-7kRQ4YN9p11FY9TRk Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return 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, 20 May 2014 15:50:27 -0000 This is a multi-part message in MIME format. --------------000505000504080403080809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Apropos the above, the proposal in the draft is simple and satisfies a need that an operator has requested us to address. In this case I do not think a complete test protocol is needed or justified, and in any case would be a lot more effort to implement compared to the proposal on the table. I would like to understand how best to move forward with this. - Stewart On 10/04/2014 15:06, Eric Gray wrote: > > I agree with the port reviewers. A well-known port would have been a > target. > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Wednesday, April 09, 2014 10:31 AM > *To:* Eric Gray; Gregory Mirsky; > draft-bryant-mpls-oam-udp-return@tools.ietf.org > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > *Importance:* High > > On 09/04/2014 13:58, Eric Gray wrote: > > Stewart, > > Well, you're adding 4 bytes to handle the case where the response > is to be > > returned using UDP. This is in addition to the address > information already included > > in the message as defined by RFC 6374. > > Sure > > It's certainly arguable that this new information does not need to be > carried > > in the test messages, assuming that there might be a control protocol > used instead. > > > > The question as to whether or not this is "heavy-weight" depends on how > > many additional ways one might envision returning the response. > > Well I am not convinced that you would want to send it over TCP. > We already have a way to return it over MPLS - via LSP association > or via the use of a first hop label encoded in the address field. > That leaves UDP/IP which this draft deals with. > > Our first thoughts were BTW to request a UDP port, and we submitted > a port request, but the port reviewers suggested that we should find a > way to do it using dynamic ports, and that is what the draft describes. > > Stewart > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------000505000504080403080809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Apropos the above, the proposal in the draft is simple and
satisfies a need that an operator has requested us to address.

In this case I do not think a complete test protocol is needed or justified,
and in any case would be a lot more effort to implement compared
to the proposal on the table.

I would like to understand how best to move forward with this.

- Stewart



On 10/04/2014 15:06, Eric Gray wrote:

I agree with the port reviewers.  A well-known port would have been a target.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Wednesday, April 09, 2014 10:31 AM
To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
Importance: High

 

On 09/04/2014 13:58, Eric Gray wrote:

Stewart,

 

                Well, you're adding 4 bytes to handle the case where the response is to be

returned using UDP.  This is in addition to the address information already included

in the message as defined by RFC 6374.

Sure

 

                It's certainly arguable that this new information does not need to be carried

in the test messages, assuming that there might be a control protocol used instead.



 

                The question as to whether or not this is "heavy-weight" depends on how

many additional ways one might envision returning the response.

Well I am not convinced that you would want to send it over TCP.
We already have a way to return it over MPLS - via LSP association
or via the use of a first hop label encoded in the address field.
That leaves UDP/IP which this draft deals with.

Our first thoughts were BTW to request a UDP port, and we submitted
a port request, but the port reviewers suggested that we should find a
way to do it using dynamic ports, and that is what the draft describes.

Stewart



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------000505000504080403080809-- From nobody Tue May 20 10:13: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 2F4751A014D; Tue, 20 May 2014 10:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh4jFJ6p00hW; Tue, 20 May 2014 10:13:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7893E1A026B; Tue, 20 May 2014 10:13:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140520171306.26849.70774.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 10:13:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Qt8Ck5b4yd9F50ZcwY8rTBwpFuI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-akiya-mpls-lsp-ping-reply-mode-simple-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 17:13:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification Authors : Nobo Akiya George Swallow Carlos Pignataro Loa Andersson Mach(Guoyi) Chen Filename : draft-akiya-mpls-lsp-ping-reply-mode-simple-02.txt Pages : 9 Date : 2014-05-20 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document adds one value to the Reply Mode field to indicate reverse LSP. This document also adds an optional TLV which can carry ordered list of Reply Mode values. This document updates RFC4379. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-reply-mode-simple/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 20 10:20: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 A421E1A037D for ; Tue, 20 May 2014 10:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK6z04mpYJ5z for ; Tue, 20 May 2014 10:20:05 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9421A0107 for ; Tue, 20 May 2014 10:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1972; q=dns/txt; s=iport; t=1400606404; x=1401816004; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=0xYOz486AHnRtV05qyWsTgAPp/fRkTbgbl1fQMYmSW4=; b=cYXn2XjgEV3HTtY/wRaxdWT69Kg/Ze38RC0hTL0hH5LoEnKmNcUD40bL MSw00zqZ9elk8ib+nExxVV1gnjSrgP4tPOqEW638LRhmxe9gq2rGw7Hke GCLdc4iTtYDfNzZdqmTGAtmOApPCPzMpP6zBvwWSVahADdm5ad22+rbUY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAB2Oe1OtJA2K/2dsb2JhbABZgmUhUViCacEyARmBAxZ0giUBAQEEIxFDAhIBCBoCBiACBDAVBgEGBAEEAQ0NAYg4AQyvKqRlF4EqjHMxgnw2gRUEmyWRY4F4gUBtgUM X-IronPort-AV: E=Sophos;i="4.98,875,1392163200"; d="scan'208";a="45549983" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 20 May 2014 17:20:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4KHK4JD013080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 May 2014 17:20:04 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.0123.003; Tue, 20 May 2014 12:20:03 -0500 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" , "Ross Callon (rcallon@juniper.net)" Thread-Topic: New Version Notification for draft-akiya-mpls-lsp-ping-reply-mode-simple-02.txt Thread-Index: Ac90TvYVo/WPSUAdTOy78/vdb+B4Nw== Date: Tue, 20 May 2014 17:20:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4DNU02nqJhOAWBFLxURzcoRpGwM Cc: Loa Andersson Subject: [mpls] FW: New Version Notification for draft-akiya-mpls-lsp-ping-reply-mode-simple-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: Tue, 20 May 2014 17:20:07 -0000 SEkgTVBMUyBXRywNCg0KV2UgaGF2ZSBhZGRyZXNzZWQgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGFu ZCBwdWJsaXNoZWQgLTAyLiBXZSB3b3VsZCBsaWtlIHRvIGtlZXAgdGhpcyBkb2N1bWVudCBvbiB0 aGUgdGFibGUgZm9yIGEgc2hvcnQgYXdoaWxlLCBhbmQgdGhlbiBwcm9jZWVkIHRvIGFzayB0aGUg Y2hhaXIgdG8gdGFrZSBpdCB0aHJvdWdoIHRoZSBXRyBhZG9wdGlvbiBwcm9jZXNzLiBGdXJ0aGVy IGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KLU5vYm8sIG9uIGJlaGFsZiBvZiBhdXRob3Jz DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmctcmVw bHktbW9kZS1zaW1wbGUtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IE5vYm8gQWtpeWEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBsZQ0KUmV2aXNpb246CTAy DQpUaXRsZToJCUxhYmVsIFN3aXRjaGVkIFBhdGggKExTUCkgUGluZy9UcmFjZXJvdXRlIFJlcGx5 IE1vZGUgU2ltcGxpZmljYXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTQtMDUtMjANCkdyb3VwOgkJ bXBscw0KUGFnZXM6CQk5DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBsZS0w Mi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1ha2l5YS1tcGxzLWxzcC1waW5nLXJlcGx5LW1vZGUtc2ltcGxlLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmct cmVwbHktbW9kZS1zaW1wbGUtMDINCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1ha2l5YS1tcGxzLWxzcC1waW5nLXJlcGx5LW1vZGUtc2ltcGxl LTAyDQoNCkFic3RyYWN0Og0KICAgVGhlIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChN UExTKSBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApDQogICBQaW5nIGFuZCBUcmFjZXJvdXRlIHVz ZSB0aGUgUmVwbHkgTW9kZSBmaWVsZCB0byBzaWduYWwgdGhlIG1ldGhvZCB0bw0KICAgYmUgdXNl ZCBpbiB0aGUgTVBMUyBlY2hvIHJlcGx5LiAgVGhpcyBkb2N1bWVudCBhZGRzIG9uZSB2YWx1ZSB0 byB0aGUNCiAgIFJlcGx5IE1vZGUgZmllbGQgdG8gaW5kaWNhdGUgcmV2ZXJzZSBMU1AuICBUaGlz IGRvY3VtZW50IGFsc28gYWRkcyBhbg0KICAgb3B0aW9uYWwgVExWIHdoaWNoIGNhbiBjYXJyeSBv cmRlcmVkIGxpc3Qgb2YgUmVwbHkgTW9kZSB2YWx1ZXMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgdXBk YXRlcyBSRkM0Mzc5Lg0K From nobody Tue May 20 22:01: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 94B201A0277 for ; Tue, 20 May 2014 22:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDn__kcShJEU for ; Tue, 20 May 2014 22:00:58 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C6F1A048E for ; Tue, 20 May 2014 22:00:57 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.14.118]) (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 B4F171800905; Wed, 21 May 2014 07:00:53 +0200 (CEST) Message-ID: <537C3303.5000206@pi.nu> Date: Wed, 21 May 2014 07:00:51 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: stbryant@cisco.com, Eric Gray , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <53455996.9060407@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A55453@eusaamb107.ericsson.se> <537B79BC.9080006@cisco.com> In-Reply-To: <537B79BC.9080006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8G9kU9ljoVKUr50vPxMnemYderE Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 05:01:02 -0000 Stewart, I can give you the more formal part of the answer on how to proceed. - if the authors think this is ready for wg adoption, they should tell the chairs - the chairs will the start the following process -- a chair review to see if we agree with the authors that it is time to start the wg adoption process (usually results in a set of comments that need to be address) -- IPR poll -- MPLS-RT review (more comments to be addressed) -- wg adoption poll /Loa On 2014-05-20 17:50, Stewart Bryant wrote: > Apropos the above, the proposal in the draft is simple and > satisfies a need that an operator has requested us to address. > > In this case I do not think a complete test protocol is needed or justified, > and in any case would be a lot more effort to implement compared > to the proposal on the table. > > I would like to understand how best to move forward with this. > > - Stewart > > > > On 10/04/2014 15:06, Eric Gray wrote: >> >> I agree with the port reviewers. A well-known port would have been a >> target. >> >> *From:*Stewart Bryant [mailto:stbryant@cisco.com] >> *Sent:* Wednesday, April 09, 2014 10:31 AM >> *To:* Eric Gray; Gregory Mirsky; >> draft-bryant-mpls-oam-udp-return@tools.ietf.org >> *Cc:* mpls@ietf.org >> *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return >> *Importance:* High >> >> On 09/04/2014 13:58, Eric Gray wrote: >> >> Stewart, >> >> Well, you're adding 4 bytes to handle the case where the response >> is to be >> >> returned using UDP. This is in addition to the address >> information already included >> >> in the message as defined by RFC 6374. >> >> Sure >> >> It's certainly arguable that this new information does not need to be >> carried >> >> in the test messages, assuming that there might be a control protocol >> used instead. >> >> >> >> The question as to whether or not this is "heavy-weight" depends on how >> >> many additional ways one might envision returning the response. >> >> Well I am not convinced that you would want to send it over TCP. >> We already have a way to return it over MPLS - via LSP association >> or via the use of a first hop label encoded in the address field. >> That leaves UDP/IP which this draft deals with. >> >> Our first thoughts were BTW to request a UDP port, and we submitted >> a port request, but the port reviewers suggested that we should find a >> way to do it using dynamic ports, and that is what the draft describes. >> >> Stewart >> > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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 May 20 22:31: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 051FC1A07D9 for ; Tue, 20 May 2014 22:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaUfU7FYgqqV for ; Tue, 20 May 2014 22:31:33 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1821A049D for ; Tue, 20 May 2014 22:31:33 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.14.118]) (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 CAF811800905; Wed, 21 May 2014 07:31:29 +0200 (CEST) Message-ID: <537C3A2E.40700@pi.nu> Date: Wed, 21 May 2014 07:31:26 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: stbryant@cisco.com, Eric Gray , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <53455996.9060407@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A55453@eusaamb107.ericsson.se> <537B79BC.9080006@cisco.com> In-Reply-To: <537B79BC.9080006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UgvUJ0Exxh0YCNAbQAWC5ygxg4s Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 05:31:35 -0000 Stewart, Redaing the Solution Overview in your document I find: "The Return Address TLV and the Return UDP PORT TLV carried in the MPLS-PM query message are used to specify to the Responder how to return the response message." I would have thought that the MPLS-PM query message would be defined in RFC 6474, but I can't find it. Where is it defined? Is it a joint name for: Loss Measurement Message, Delay Measurement Message, and Combined Loss/Delay Measurement Message? /Loa On 2014-05-20 17:50, Stewart Bryant wrote: > Apropos the above, the proposal in the draft is simple and > satisfies a need that an operator has requested us to address. > > In this case I do not think a complete test protocol is needed or justified, > and in any case would be a lot more effort to implement compared > to the proposal on the table. > > I would like to understand how best to move forward with this. > > - Stewart > > > > On 10/04/2014 15:06, Eric Gray wrote: >> >> I agree with the port reviewers. A well-known port would have been a >> target. >> >> *From:*Stewart Bryant [mailto:stbryant@cisco.com] >> *Sent:* Wednesday, April 09, 2014 10:31 AM >> *To:* Eric Gray; Gregory Mirsky; >> draft-bryant-mpls-oam-udp-return@tools.ietf.org >> *Cc:* mpls@ietf.org >> *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return >> *Importance:* High >> >> On 09/04/2014 13:58, Eric Gray wrote: >> >> Stewart, >> >> Well, you're adding 4 bytes to handle the case where the response >> is to be >> >> returned using UDP. This is in addition to the address >> information already included >> >> in the message as defined by RFC 6374. >> >> Sure >> >> It's certainly arguable that this new information does not need to be >> carried >> >> in the test messages, assuming that there might be a control protocol >> used instead. >> >> >> >> The question as to whether or not this is "heavy-weight" depends on how >> >> many additional ways one might envision returning the response. >> >> Well I am not convinced that you would want to send it over TCP. >> We already have a way to return it over MPLS - via LSP association >> or via the use of a first hop label encoded in the address field. >> That leaves UDP/IP which this draft deals with. >> >> Our first thoughts were BTW to request a UDP port, and we submitted >> a port request, but the port reviewers suggested that we should find a >> way to do it using dynamic ports, and that is what the draft describes. >> >> Stewart >> > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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 Wed May 21 06:29: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 44C1F1A067E for ; Wed, 21 May 2014 06:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4KnJAtomRAH for ; Wed, 21 May 2014 06:29:51 -0700 (PDT) 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 874B81A0665 for ; Wed, 21 May 2014 06:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3202; q=dns/txt; s=iport; t=1400678990; x=1401888590; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k048ADqCRF0LmeOxvotFTZsCyiAeN2F7ma9rtmZ/9Ps=; b=X1WpcgPfp3DM0s/g5I0TVXlIisEB0GKsEeXtUk+6wMeRWZWFzDarW7SG eq6km5lE9LP/KNJTrpb9ujiq9AmWB95pHRLqROB+/R4vkSemsRxujd1Wo WFlY0T2LVKxx5m5omMfxjj0CqNefreqo53U/pK/OUFxR8HQ/XOWKcwyLz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAOypfFOtJssW/2dsb2JhbABZg1e9N4c7AYEgdIIlAQEBBAEBATUvBwoBEAsRBAEBAQkWCAcJAwIBAgEVHwkIBgEMAQUCAQEXiCYNtmGeZBeOLCIHBoQ6AQOZbpMkgzls X-IronPort-AV: E=Sophos;i="4.98,880,1392163200"; d="scan'208";a="56885467" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 21 May 2014 13:29:47 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4LDTlwQ011136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2014 13:29:48 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s4LDTk8N001480; Wed, 21 May 2014 14:29:47 +0100 (BST) Message-ID: <537CAA4A.2000209@cisco.com> Date: Wed, 21 May 2014 14:29:46 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Loa Andersson , Eric Gray , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <53455996.9060407@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A55453@eusaamb107.ericsson.se> <537B79BC.9080006@cisco.com> <537C3A2E.40700@pi.nu> In-Reply-To: <537C3A2E.40700@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/SSLas6pHxQDUH1q1D80zKL7nEag Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return 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, 21 May 2014 13:29:52 -0000 This should be clearer in the new version. Stewart On 21/05/2014 06:31, Loa Andersson wrote: > Stewart, > > Redaing the Solution Overview in your document I find: > > "The Return Address TLV and the Return UDP PORT TLV carried in the > MPLS-PM query message are used to specify to the Responder how to > return the response message." > > I would have thought that the MPLS-PM query message would be defined > in RFC 6474, but I can't find it. Where is it defined? > > Is it a joint name for: > > Loss Measurement Message, Delay Measurement Message, and Combined > Loss/Delay Measurement Message? > > /Loa > > > On 2014-05-20 17:50, Stewart Bryant wrote: >> Apropos the above, the proposal in the draft is simple and >> satisfies a need that an operator has requested us to address. >> >> In this case I do not think a complete test protocol is needed or >> justified, >> and in any case would be a lot more effort to implement compared >> to the proposal on the table. >> >> I would like to understand how best to move forward with this. >> >> - Stewart >> >> >> >> On 10/04/2014 15:06, Eric Gray wrote: >>> >>> I agree with the port reviewers. A well-known port would have been a >>> target. >>> >>> *From:*Stewart Bryant [mailto:stbryant@cisco.com] >>> *Sent:* Wednesday, April 09, 2014 10:31 AM >>> *To:* Eric Gray; Gregory Mirsky; >>> draft-bryant-mpls-oam-udp-return@tools.ietf.org >>> *Cc:* mpls@ietf.org >>> *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return >>> *Importance:* High >>> >>> On 09/04/2014 13:58, Eric Gray wrote: >>> >>> Stewart, >>> >>> Well, you're adding 4 bytes to handle the case where the response >>> is to be >>> >>> returned using UDP. This is in addition to the address >>> information already included >>> >>> in the message as defined by RFC 6374. >>> >>> Sure >>> >>> It's certainly arguable that this new information does not need to be >>> carried >>> >>> in the test messages, assuming that there might be a control protocol >>> used instead. >>> >>> >>> >>> The question as to whether or not this is "heavy-weight" depends on how >>> >>> many additional ways one might envision returning the response. >>> >>> Well I am not convinced that you would want to send it over TCP. >>> We already have a way to return it over MPLS - via LSP association >>> or via the use of a first hop label encoded in the address field. >>> That leaves UDP/IP which this draft deals with. >>> >>> Our first thoughts were BTW to request a UDP port, and we submitted >>> a port request, but the port reviewers suggested that we should find a >>> way to do it using dynamic ports, and that is what the draft describes. >>> >>> Stewart >>> >> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Wed May 21 07:51: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 5B80B1A0336 for ; Wed, 21 May 2014 07:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUEtbpCBzImL for ; Wed, 21 May 2014 07:51:29 -0700 (PDT) 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 5C4D51A006E for ; Wed, 21 May 2014 07:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=921; q=dns/txt; s=iport; t=1400683884; x=1401893484; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tcqzCLDsr/lzWbUwvBSBcNQkQKw+AHKTKQ233g8+7Rw=; b=mKioS2wIMWMBS3u6NeDn3GNMIWUQLnynMmRSyBy7Gm7uucRvmUnL7tFM /E7SYlyRfWa0kN50X5V/p9VreRzid/IDxnKBofm1UVkXDWEMzWKKAuFFQ V7APil0Wx8A9ybzvFALjDlmTevw0vyh9RMIFvmewy+xniqyz6hcTC0MZo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEALC8fFOtJssW/2dsb2JhbABZxTiDEQGBInSCJQEBAQQ4QAEQCxgJFg8JAwIBAgFFBgEMAQcBAYg9tx2eaReOTgeEQAEDmW6TJIM5 X-IronPort-AV: E=Sophos;i="4.98,880,1392163200"; d="scan'208";a="56957699" 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; 21 May 2014 14:51:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4LEpLl3028691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2014 14:51:22 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s4LEpLaI008081; Wed, 21 May 2014 15:51:21 +0100 (BST) Message-ID: <537CBD69.1050108@cisco.com> Date: Wed, 21 May 2014 15:51:21 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Loa Andersson , Eric Gray , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <53455996.9060407@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A55453@eusaamb107.ericsson.se> <537B79BC.9080006@cisco.com> <537C3303.5000206@pi.nu> In-Reply-To: <537C3303.5000206@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/MJcMGIrkVuNV0in-YltVKakp7kg Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return 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, 21 May 2014 14:51:32 -0000 On 21/05/2014 06:00, Loa Andersson wrote: > Stewart, > > I can give you the more formal part of the answer on how to > proceed. > > - if the authors think this is ready for wg adoption, they > should tell the chairs I have uploaded a new version, and I think it is ready for adoption. > > - the chairs will the start the following process > -- a chair review to see if we agree with the authors that > it is time to start the wg adoption process (usually > results in a set of comments that need to be address) Your comments were addressed in version 1, plus a few clarifications that I considered consequential to these comments. > -- IPR poll No IPR from this author. > > -- MPLS-RT review (more comments to be addressed) That sounds a bit pessimistic. > -- wg adoption poll We had some comments on the list but none so far are actionable on this document. - Stewart From nobody Wed May 21 08:12: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 256301A0719 for ; Wed, 21 May 2014 08:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvrIB3FkRNgy for ; Wed, 21 May 2014 08:12:15 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C36A1A06D7 for ; Wed, 21 May 2014 08:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7338; q=dns/txt; s=iport; t=1400685134; x=1401894734; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=pqul1Hw5+yMTWiGEgynzKvjiwc5Q9BKkeA2T3FsfUGs=; b=MDkRzEpuVOooDTu/jhWuytSWo2hQk513Mqb7fa2uht9znqx1u89mAVsI mURiNEC2kZSAAA5an1bfQhUVsmAYfhEboM7ChDXOkG2G8+zwNvmcggX6S S0OmFYFwO9qMz+57Gjb++uNFMNeUGGieMowXpoQNHU5IrboOizMUaMfxg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEANPBfFOtJssW/2dsb2JhbABZgkLCdoMRAYEidIIlAQEBBC06EQEQCxgJFg8JAwIBAgFFBgEMAQcBAYg9tyCeaBeOTgeEQASZbpMkgzk X-IronPort-AV: E=Sophos; i="4.98,880,1392163200"; d="scan'208,217"; a="52870529" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 21 May 2014 15:12:11 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4LFCBjw002756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2014 15:12:11 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s4LFCAVt009560; Wed, 21 May 2014 16:12:10 +0100 (BST) Message-ID: <537CC24A.2020803@cisco.com> Date: Wed, 21 May 2014 16:12:10 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Eric Gray , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> Content-Type: multipart/alternative; boundary="------------070901000606000008060207" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/uPTBAjxCDNIgDDUC6fKtVqO4HyE Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return 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, 21 May 2014 15:12:19 -0000 This is a multi-part message in MIME format. --------------070901000606000008060207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/04/2014 13:58, Eric Gray wrote: > > Stewart, > > Well, you're adding 4 bytes to handle the case where the response is to be > > returned using UDP. This is in addition to the address information > already included > > in the message as defined by RFC 6374. > > It's certainly arguable that this new information does not need to be > carried > > in the test messages, assuming that there might be a control protocol > used instead. > > The question as to whether or not this is "heavy-weight" depends on how > > many additional ways one might envision returning the response. > > I suspect this is the "bigger puzzle" that Greg refers to... > Eric In terms of bytes which seems to be the focus of your initial para and considering the packet loss case, the base message is 84 bytes. Add an ACH, a delivery label and a GAL that is 96 bytes. It will probably go over Ethernet so that is 110 bytes. Considering the IPv4 case, and noting that the address object is already an agreed TLV the total goes to 118 bytes. So the additional UDP port object which is 4 bytes is a little over 3% If you take the address in IPv6 and the UDP compared to base without an address the increase is 20/110 which is 18% which is a little irritating but not out of this world. In contrasting this with any other approach you would need to compare the per packet measurement overhead with the session maintenance overhead of the other method. My assumption is that for any measurement request there would only be one method of responding. Can you see a deployment scenario where it would be beneficial to give the responder a choice of methods of responding in every request? - Stewart --------------070901000606000008060207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/04/2014 13:58, Eric Gray wrote:

Stewart,

 

                Well, you're adding 4 bytes to handle the case where the response is to be

returned using UDP.  This is in addition to the address information already included

in the message as defined by RFC 6374.

 

                It's certainly arguable that this new information does not need to be carried

in the test messages, assuming that there might be a control protocol used instead.

 

                The question as to whether or not this is "heavy-weight" depends on how

many additional ways one might envision returning the response.

 

                I suspect this is the "bigger puzzle" that Greg refers to…

Eric

In terms of bytes which seems to be the focus of your initial para
and considering the packet loss case, the base message is 84 bytes.
Add an ACH, a delivery label and a GAL that is 96 bytes. It will
probably go over Ethernet so that is 110 bytes.

Considering the IPv4 case, and noting that the address object
is already an agreed TLV the total goes to 118 bytes. So the
additional UDP port object which is 4 bytes is a little over 3%
If you take the address in IPv6 and the UDP compared to base
without an address the increase is 20/110 which is 18% which
is a little irritating but not out of this world.

In contrasting this with any other approach you would need
to compare the per packet measurement overhead with the
session maintenance overhead of the other method.

My assumption is that for any measurement request there
would only be one method of responding. Can you see a
deployment scenario where it would be beneficial to give
the responder a choice of methods of responding in every
request?

- Stewart
--------------070901000606000008060207-- From nobody Wed May 21 17:59: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 A20361A000F for ; Wed, 21 May 2014 17:59:30 -0700 (PDT) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYtQAI3A_hxz for ; Wed, 21 May 2014 17:59:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DF81A000B for ; Wed, 21 May 2014 17:59:28 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-3f-537cfc2d829a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.16.27529.E2CFC735; Wed, 21 May 2014 21:19:10 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 21 May 2014 20:59:26 -0400 From: Gregory Mirsky To: "stbryant@cisco.com" , Eric Gray , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPU+saEJtSSVJZq0yj4ZIvBeRSWJsJgiEAgEInKQCAAFwCQA== Date: Thu, 22 May 2014 00:59:25 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> In-Reply-To: <537CC24A.2020803@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_7347100B5761DC41A166AC17F22DF1121B7C0A12eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLrHW1fvT02wwf53YhaTvr1htri1dCWr xbmncxgdmD2m/N7I6rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZfTd+8lWsCm84tjru2wN jB3eXYycHBICJhKfW9axQthiEhfurWfrYuTiEBI4yihxqmEPlLOcUeLK+yVMIFVsAkYSLzb2 sIMkRAR2MUpMWj0LqIqDg1lAWeLUXRmQGmEBB4nlcx8xg9giAo4SHxacY4WwnSReX3vKCGKz CKhKHGjrZAGxeQV8JZb8XM4Osew8o8TlVdvBZnIKaEo0dluA1DACXff91BqwG5gFxCVuPZnP BHG1gMSSPeeZIWxRiZeP/0F9oyQxaSnEXmaBfIl7p7ZB7RKUODnzCcsERtFZSEbNQlI2C0kZ RFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XIUVqcWpabbmSwiREYa8ck2HR3MO55aXmI UYCDUYmHN2FjTbAQa2JZcWXuIUZpDhYlcV7tm1XBQgLpiSWp2ampBalF8UWlOanFhxiZODil Ghg5eLV3HjR27o61Ku97KHveLPCM8nbF911/t8/dYv/K13PNnNtbandse9beEMTXc8q6R6zx y7ybm7T+31N+lO8k8Ov+9OUHNvMGl/uejylaMoP129Nsnw07l/8Iu7LxB//0C9bvSkxn3Z3Y cyJfRfGTRY/A3C3+c3j9LpqLm5yPeVkzO3yjmNYfJZbijERDLeai4kQAXaRJ8JYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1yJhO8GtPK-N6yOni6PwCkmhTdk Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 00:59:30 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7C0A12eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, I think that need for the extension you've proposed is indication that per = query control approach taken in RFC 6374 may not be the most efficient in l= onger run. I think that establishing a test session through dedicated Comma= nd message, as extension/update to RFCs 6374/6375, is possible and is more = flexible way. And I think that maintaining a session would make upload of m= easurement results more efficient when compared with uploading one measurem= ent at the time. And though LMAP framework concentrates on performance measurement in mas= sive IP access networks its model may be used as reference. I believe that = there're plausible scenarios when multiple Collectors request upload of mea= surement results from an Measurement Agent. Regards, Greg From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, May 21, 2014 8:12 AM To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.= org Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return On 09/04/2014 13:58, Eric Gray wrote: Stewart, Well, you're adding 4 bytes to handle the case where the re= sponse is to be returned using UDP. This is in addition to the address information already= included in the message as defined by RFC 6374. It's certainly arguable that this new information does not = need to be carried in the test messages, assuming that there might be a control protocol used = instead. The question as to whether or not this is "heavy-weight" de= pends on how many additional ways one might envision returning the response. I suspect this is the "bigger puzzle" that Greg refers to..= . Eric In terms of bytes which seems to be the focus of your initial para and considering the packet loss case, the base message is 84 bytes. Add an ACH, a delivery label and a GAL that is 96 bytes. It will probably go over Ethernet so that is 110 bytes. Considering the IPv4 case, and noting that the address object is already an agreed TLV the total goes to 118 bytes. So the additional UDP port object which is 4 bytes is a little over 3% If you take the address in IPv6 and the UDP compared to base without an address the increase is 20/110 which is 18% which is a little irritating but not out of this world. In contrasting this with any other approach you would need to compare the per packet measurement overhead with the session maintenance overhead of the other method. My assumption is that for any measurement request there would only be one method of responding. Can you see a deployment scenario where it would be beneficial to give the responder a choice of methods of responding in every request? - Stewart --_000_7347100B5761DC41A166AC17F22DF1121B7C0A12eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stewart,=

I think that need for = the extension you’ve proposed is indication that per query control ap= proach taken in RFC 6374 may not be the most efficient in longer run. I thi= nk that establishing a test session through dedicated Command message, as extension/update to RFCs 6374/6375, is possi= ble and is more flexible way. And I think that maintaining a session would = make upload of measurement results more efficient when compared with upload= ing one measurement at the time.

And though LMAP framework concentrates on performance measurement in massive IP ac= cess networks its model may be used as reference. I believe that there̵= 7;re plausible scenarios when multiple Collectors request upload of measure= ment results from an Measurement Agent.

 

   &nbs= p;            Regard= s,

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

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Wednesday, May 21, 2014 8:12 AM
To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tool= s.ietf.org
Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

 

On 09/04/2014 13:58, Eric Gray wrote:

Stewart,

 

   &nbs= p;            Well, = you're adding 4 bytes to handle the case where the response is to be=

returned using UDP.&nb= sp; This is in addition to the address information already included<= o:p>

in the message as defi= ned by RFC 6374.

 

   &nbs= p;            It's c= ertainly arguable that this new information does not need to be carried

in the test messages, = assuming that there might be a control protocol used instead.

 

   &nbs= p;            The qu= estion as to whether or not this is "heavy-weight" depends on how

many additional ways o= ne might envision returning the response.

 

   &nbs= p;            I susp= ect this is the "bigger puzzle" that Greg refers to…=

Eric

In terms of bytes which seems to be the focus of your initial para
and considering the packet loss case, the base message is 84 bytes.
Add an ACH, a delivery label and a GAL that is 96 bytes. It will
probably go over Ethernet so that is 110 bytes.

Considering the IPv4 case, and noting that the address object
is already an agreed TLV the total goes to 118 bytes. So the
additional UDP port object which is 4 bytes is a little over 3%
If you take the address in IPv6 and the UDP compared to base
without an address the increase is 20/110 which is 18% which
is a little irritating but not out of this world.

In contrasting this with any other approach you would need
to compare the per packet measurement overhead with the
session maintenance overhead of the other method.

My assumption is that for any measurement request there
would only be one method of responding. Can you see a
deployment scenario where it would be beneficial to give
the responder a choice of methods of responding in every
request?

- Stewart

--_000_7347100B5761DC41A166AC17F22DF1121B7C0A12eusaamb103erics_-- From nobody Thu May 22 03:13: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 4CA7F1A007E for ; Thu, 22 May 2014 03:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 mb3SJsErCO4w for ; Thu, 22 May 2014 03:13:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F281A0066 for ; Thu, 22 May 2014 03:13:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEK56678; Thu, 22 May 2014 10:13:21 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 May 2014 11:12:54 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 May 2014 11:13:06 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 22 May 2014 18:12:53 +0800 From: Xuxiaohu To: Lizhong Jin , Mach Chen Thread-Topic: MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPcRlkg0SQ2M7Na0ef9K4HkZvfCJtMZwmQ Date: Thu, 22 May 2014 10:12:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827AEF6@NKGEML512-MBS.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B7B12A5@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827AEF6NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-Ue5-s78xnGQ0CaUhfJJyPAOT7A Cc: "draft-chen-mpls-source-label@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Ross Callon , "mpls@ietf.org" Subject: [mpls] =?utf-8?b?562U5aSNOiBNUExTLVJUIHJldmlldyBvZiBkcmFmdC1jaGVu?= =?utf-8?q?-mpls-source-label?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 10:13:30 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827AEF6NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCuWPkeS7tuS6ujogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpoby5qaW5AZ21haWwuY29tXQ0K 5Y+R6YCB5pe26Ze0OiAyMDE05bm0NeaciDE25pelIDIzOjEzDQrmlLbku7bkuro6IE1hY2ggQ2hl bg0K5oqE6YCBOiBHcmVnb3J5IE1pcnNreTsgZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1sYWJlbEB0 b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7 IFJvc3MgQ2FsbG9uDQrkuLvpopg6IFJlOiBNUExTLVJUIHJldmlldyBvZiBkcmFmdC1jaGVuLW1w bHMtc291cmNlLWxhYmVsDQoNCkhpIE1hY2gsDQpJbmxpbmUgYmVsb3cuIFRoYW5rcy4NCg0KTGl6 aG9uZw0KDQpPbiBGcmlkYXksIE1heSAxNiwgMjAxNCwgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVh d2VpLmNvbTxtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIExpemhvbmcs DQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCg0KU2VlIG15IHJlcGx5IGlubGluZS4uLg0K DQpTbmlwZWQuDQoNCj4gR0lNPj4gSSB0aGluayB0aGF0IG5vdCBhbGwgTFNScyBpbiBhbiBJR1Ag ZG9tYWluIGFyZSByZXF1aXJlZCB0byBiZQ0KPiBHSU0+PiBTTEMgYnV0IG9ubHkNCj4gZW5kLXBv aW50cyBvZiBhbiBMU1AuIFRodXMsIGlmIGFuIExTUiBpcyBub3QgU0xDLCB0aGVuIFNMIGNhbm5v dCBiZQ0KPiB1c2VkIG9uIExTUHMgaXQgb3JpZ2luYXRlcy90ZXJtaW5hdGVzLiBDaGFuZ2UgaW4g U0xDLCBJIGltYWdpbmUsIG1heQ0KPiBjb21lIGFzIHJlc3VsdCBvZiBTVyB1cGdyYWRlLiBUaG91 Z2ggaXQgd291bGQgdHJpZ2dlZCBmbG9vZCBvZiB1cGRhdGVzDQo+IHRoYXQsIElNTywgd291bGQg YmUgb25lLXRpbWUgZXZlbnQuDQo+IFtMaXpob25nXSBpbiBhbiBMRFAgbmV0d29yaywgZXZlcnkg bm9kZSB3b3VsZCBiZSBwb3NzaWJseSB0byBiZSBlZ3Jlc3Mgb2YgYW4gRkVDLg0KPiBJbiB0aGUg ZHJhZnQsIGl0IHNheXM6DQo+IEFuIExTUiBYIG1heSByZWNlaXZlIG11bHRpcGxlIExhYmVsIE1h cHBpbmdzIGZvciBhIGdpdmVuDQo+DQo+ICAgIEZFQyBGIGZyb20gaXRzIG5laWdoYm9ycy4gIElu IGl0cyB0dXJuLCBYIG1heSBhZHZlcnRpc2UgYSBMYWJlbA0KPiAgICBNYXBwaW5nIGZvciBGIHRv IGl0cyBuZWlnaGJvcnMuICBJZiBYIHVuZGVyc3RhbmRzIHRoZSBTTEMgVExWLCBhbmQNCj4gaWYN Cj4gICAgYW55IG9mIHRoZSBhZHZlcnRpc2VtZW50cyBpdCByZWNlaXZlZCBmb3IgRkVDIEYgZG9l cyBub3QgaW5jbHVkZQ0KPiB0aGUNCj4gICAgU0xDIFRMViwgWCBNVVNUIE5PVCBpbmNsdWRlIHRo ZSBTTEMgVExWIGluIGl0cyBvd24gYWR2ZXJ0aXNlbWVudHMNCj4gb2YNCj4gICAgRi4NCj4NCj4g SW4gRFUgbW9kZSwgdGhlIG1hcHBpbmcgYWR2ZXJ0aXNlbWVudCB3aWxsIGJlIGluZmx1ZW5jZWQg Ynkgb3RoZXINCj4gcmVjZWl2ZWQgYWR2ZXJ0aXNlbWVudCwgd2hpY2ggd2lsbCBicmluZyBtb3Jl IHNpZ25hbGluZy4gVGhpcyBpcyBub3QNCj4gb25lLXRpbWUgZXZlbnQsIGFueSBMRFAgc2Vzc2lv biBVUC9ET1dOIHdpbGwgaW5mbHVlbmNlIHRoZSB3aG9sZQ0KPiBzaWduYWxpbmcuIEJ1dCB3aHkg ZG9uJ3QgeW91IGxpbWl0IHRoZSByZWNlaXZlZCBhZHZlcnRpc2VtZW50IG9ubHkNCj4gZnJvbSB0 aGUgZG93bnN0cmVhbSBub2RlLCBub3QgYWxsIG5vZGVzPyBPbmx5IHRoZSByZWNlaXZlZA0KPiBh ZHZlcnRpc2VtZW50IGZyb20gZG93bnN0cmVhbSBub2RlIGRvZXMgbm90IFNMQyBUTFYsIFggbXVz dCBub3QgaW5jbHVkZSBTTEMgVExWLg0KDQpUaGUgYWJvdmUgbWVjaGFuaXNtIGlzIG9yaWdpbmFs bHkgZGVmaW5lZCBmb3IgRUxDLCBhbmQgSU1ITywgZnJvbSB0aGUgY2FwYWJpbGl0eSBuZWdvdGlh dGlvbiBwb2ludCBvZiB2aWV3LCB0aGVyZSBpcyBubyBkaWZmZXJlbnQgYmV0d2VlbiBFTEMgYW5k IFNMQy4gQXMgc3RhdGVkIGluIHRoZSBBY2tub3dsZWRnZW1lbnRzIHNlY3Rpb24sIHRoZSBTTEMg bmVnb3RpYXRpb24gaXMgcmVmZXJyZWQgdG8gRUxDIG5lZ290aWF0aW9uIG1lY2hhbmlzbS4NCg0K SWYgeW91IGhhdmUgYmV0dGVyIHN1Z2dlc3Rpb24sIHRoYXQgd2lsbCBiZSBhcHByZWNpYXRlZC4N CltMaXpob25nXSBJIGtub3cgeW91IGJvcnJvdyB0aGUgdGV4dCBmcm9tIFJGQzY3OTAuICBNeSBz dWdnZXN0aW9uIGlzLCBvbmx5IHdoZW4gdGhlIHJlY2VpdmVkIGFkdmVydGlzZW1lbnQgZnJvbSBk b3duc3RyZWFtIG5vZGUgKG5vdCBhbnkgbm9kZSkgZG9lcyBub3QgaW5jbHVkZSBTTEMgVExWLCBY IG11c3Qgbm90IGluY2x1ZGUgU0xDIFRMVi4gVGhhdCB3aWxsIGltcHJvdmUgdGhlIHNpZ25hbGlu ZywgcmlnaHQ/IFRoZSBMRFAgc2lnbmFsaW5nIGZsYXBwaW5nIG9mIG5vbi1kb3duc3RyZWFtIGFk dmVydGlzZW1lbnQgd2lsbCBub3QgaW5mbHVlbmNlIHRoZSB1cHN0cmVhbSBhZHZlcnRpc2VtZW50 Lg0KDQpbWGlhb2h1XSBTTEMgVExWIGlzIHVzZWQgdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgZWdy ZXNzIGhhcyB0aGUgY2FwYWJpbGl0eSBvZiBwcm9jZXNzaW5nIHRoZSBTTC4gSGVuY2UgaXQgZG9l c27igJl0IG1hdHRlciB3aGV0aGVyIHRoZSBTTEMgVExWIGlzIHJlY2VpdmVkIGZyb20gYSBkb3du c3RyZWFtIG5vZGUgb3IgYSBub24tZG93bnN0cmVhbSBub2RlLiBTaW5jZSB0aGVyZSBpcyBhIGNo YW5jZSB0aGF0IG9uZSBvZiB0aGUgZWdyZXNzZXMgb3JpZ2luYXRpbmcgdGhhdCBGRUMgZG9lc27i gJl0IHN1cHBvcnQgdGhlIFNMQywgaXTigJlzIHNhZmUgZm9yIFggdG8gbm90IGluY2x1ZGUgdGhl IFNMQyBUTFYgaW4gaXRzIGFkdmVydGlzZW1lbnQuIE90aGVyd2lzZSwgdGhlIHBhY2tldCB3aXRo IHRoZSBTTCBvbiB0aGUgZmx5IG1heSBiZSBkcm9wcGVkIGJ5IHRoZSBlZ3Jlc3Mgbm9kZSB3L28g dGhlIFNMQy4NCg0KPg0KPiBTZWN0aW9uIDYuMS4yLCA2LjEuMi4zDQo+IFNpbmNlIFJTVlAtVEUg TFNQIGRvZXMgbm90IGhhdmUgdGhlIG1lYXN1cmVtZW50IHByb2JsZW0gbGlzdGVkIGluIHRoaXMN Cj4gZHJhZnQsIHdoeSB3ZSBuZWVkIHRvIGRvIFJTVlAtVEUgZXh0ZW5zaW9uPyBNUC1CR1AgaXMg bm90IHVzZWQgdG8NCj4gc2V0dXAgTVAyUCAvIE1QMk1QIExTUCwgdGhlbiB3aHkgd2UgbmVlZCB0 aGUgZXh0ZW5zaW9uPyBEaWQgSSBtaXNzIHNvbWV0aGluZz8NCj4gR0lNPj4gSSB0aGluayB0aGF0 IFJTVlAtVEUgTFNQIHdpdGggbGFiZWwgbWVyZ2UgYW5kIFBIUCBzdGlsbCBoYXZlDQo+IEdJTT4+ IGlzc3Vlcw0KPiBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LiBQZXJoYXBzIG9ubHkgTVBMUy1U UCBjb25zdHJ1Y3RzIGhhdmUNCj4gZGV0ZXJtaW5pc20gb2YgdHJhbnNwb3J0IG5ldHdvcmsgYW5k IG1heSBub3QgaGF2ZSB0aGlzIHByb2JsZW0uDQo+IFtMaXpob25nXSBQSFAgY291bGQgYmUgZGlz YWJsZWQgZm9yIFJTVlAtVEUgTFNQLiBXaGljaCBjYXNlIGhhcyBsYWJlbA0KPiBtZXJnZSBmb3Ig UlNWUC1URSBMU1A/IEFueXdheSwgaWYgeW91IHRoaW5rIFJTVlAtVEUgYWxzbyBoYXMgaXNzdWUs DQo+IHlvdSBzaG91bGQgc2F5IHRoYXQgaW4gc2VjdGlvbiAxLiBIb3dldmVyLCB1c2luZyBzb3Vy Y2UgbGFiZWwgdG8gZG8gTE0NCj4gZm9yIFJTVlAtVEUgTFNQIG1heSBub3QgYmUgaGVscGZ1bCwg c2luY2UgdGhlIFJTVlAtVEUgbGFiZWwgaXMgbW9yZQ0KPiBhY2N1cmF0ZSB0byBpZGVudGlmeSBh biBMU1AsIGluY2x1ZGluZyBzb3VyY2UgKyBkZXN0aW5hdGlvbiArIHR1bm5lbCBJRCArIExTUCBJ RCArIFBIQiwgZXRjLg0KDQpJZiB0aGUgUEhQIGlzIGRpc2FibGVkLCB0aGVuIHNvdXJjZSBsYWJl bCBmb3IgUlNQVi1URSBtYXkgbm90IGJlIG5lZWRlZC4gSWYgcGVvcGxlIHRoaW5rIFJTVlAtVEUg Y2FzZSBpcyBub3QgYSB2YWxpZCBjYXNlLCB3ZSBjb3VsZCByZW1vdmUgaXQuDQoNCkJUVywgcGxl YXNlIGhhdmUgYSBsb29rIGF0IHRoZSBsYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDMgb2YgKGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZW5nLWwzdnBuLXBtLWFuYWx5c2lzLTAy I3NlY3Rpb24tMyApICwgaXQgdGFsa3MgYSBjYXNlIHRoYXQgZXZlbiBmb3IgUlNWUC1URSwgdGhl IHNvdXJjZSBsYWJlbCBtYXkgYWxzbyBuZWVkZWQuDQpbTGl6aG9uZ10gVGhhbmtzIGZvciB0aGUg bGluay4gV2hhdCBJIHdhbnQgdG8gc2F5IGlzLCBpZiB5b3UgYmVsaWV2ZSBSU1ZQLVRFIGhhcyBp c3N1ZSwgdGhlbiBleHBsaWNpdGx5IHNheSB0aGF0IGluIHNlY3Rpb24gMS4gSW4gY3VycmVudCB0 ZXh0LCB5b3Ugc2FpZCwgUlNWUC1URSBpcyBPSyBpbiBzZWN0aW9uIDEsIGJ1dCB5b3Ugc3RpbGwg ZXh0ZW5kIFJTVlAtVEUgcHJvdG9jb2wsIHRoYXQgaXMgY29uZnVzaW5nLiBBbmQgdGhlIHNhbWUg aXNzdWUgdG8gTVAtQkdQIGV4dGVuc2lvbi4NCg0KDQpUaGFua3MsDQpNYWNoDQoNCj4NCj4gUmVn YXJkcw0KPiBMaXpob25nDQoNClNuaXBlZC4NCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827AEF6NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gTGl6aG9uZyBKaW4gW21haWx0 bzpsaXpoby5qaW5AZ21haWwuY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTQ8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVT Ij41PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xNjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJF Ti1VUyI+IDIzOjEzPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IE1hY2ggQ2hlbjxicj4NCjwvc3Bhbj48Yj7m ioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBH cmVnb3J5IE1pcnNreTsgZHJhZnQtY2hlbi1tcGxzLXNvdXJjZS1sYWJlbEB0b29scy5pZXRmLm9y ZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IFJvc3MgQ2FsbG9u PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IFJlOiBNUExTLVJUIHJldmlldyBvZiBkcmFmdC1jaGVuLW1wbHMtc291 cmNlLWxhYmVsPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIE1h Y2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5JbmxpbmUgYmVsb3cuIFRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxpemhvbmc8YnI+DQo8YnI+DQpPbiBGcmlk YXksIE1heSAxNiwgMjAxNCwgTWFjaCBDaGVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFjaC5jaGVu QGh1YXdlaS5jb20iPm1hY2guY2hlbkBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhp IExpemhvbmcsPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzITxicj4NCjxicj4N ClNlZSBteSByZXBseSBpbmxpbmUuLi48YnI+DQo8YnI+DQpTbmlwZWQuPGJyPg0KPGJyPg0KJmd0 OyBHSU0mZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgbm90IGFsbCBMU1JzIGluIGFuIElHUCBkb21haW4g YXJlIHJlcXVpcmVkIHRvIGJlPGJyPg0KJmd0OyBHSU0mZ3Q7Jmd0OyBTTEMgYnV0IG9ubHk8YnI+ DQomZ3Q7IGVuZC1wb2ludHMgb2YgYW4gTFNQLiBUaHVzLCBpZiBhbiBMU1IgaXMgbm90IFNMQywg dGhlbiBTTCBjYW5ub3QgYmU8YnI+DQomZ3Q7IHVzZWQgb24gTFNQcyBpdCBvcmlnaW5hdGVzL3Rl cm1pbmF0ZXMuIENoYW5nZSBpbiBTTEMsIEkgaW1hZ2luZSwgbWF5PGJyPg0KJmd0OyBjb21lIGFz IHJlc3VsdCBvZiBTVyB1cGdyYWRlLiBUaG91Z2ggaXQgd291bGQgdHJpZ2dlZCBmbG9vZCBvZiB1 cGRhdGVzPGJyPg0KJmd0OyB0aGF0LCBJTU8sIHdvdWxkIGJlIG9uZS10aW1lIGV2ZW50Ljxicj4N CiZndDsgW0xpemhvbmddIGluIGFuIExEUCBuZXR3b3JrLCBldmVyeSBub2RlIHdvdWxkIGJlIHBv c3NpYmx5IHRvIGJlIGVncmVzcyBvZiBhbiBGRUMuPGJyPg0KJmd0OyBJbiB0aGUgZHJhZnQsIGl0 IHNheXM6PGJyPg0KJmd0OyBBbiBMU1IgWCBtYXkgcmVjZWl2ZSBtdWx0aXBsZSBMYWJlbCBNYXBw aW5ncyBmb3IgYSBnaXZlbjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtGRUMgRiBm cm9tIGl0cyBuZWlnaGJvcnMuICZuYnNwO0luIGl0cyB0dXJuLCBYIG1heSBhZHZlcnRpc2UgYSBM YWJlbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO01hcHBpbmcgZm9yIEYgdG8gaXRzIG5laWdoYm9y cy4gJm5ic3A7SWYgWCB1bmRlcnN0YW5kcyB0aGUgU0xDIFRMViwgYW5kPGJyPg0KJmd0OyBpZjxi cj4NCiZndDsgJm5ic3A7ICZuYnNwO2FueSBvZiB0aGUgYWR2ZXJ0aXNlbWVudHMgaXQgcmVjZWl2 ZWQgZm9yIEZFQyBGIGRvZXMgbm90IGluY2x1ZGU8YnI+DQomZ3Q7IHRoZTxicj4NCiZndDsgJm5i c3A7ICZuYnNwO1NMQyBUTFYsIFggTVVTVCBOT1QgaW5jbHVkZSB0aGUgU0xDIFRMViBpbiBpdHMg b3duIGFkdmVydGlzZW1lbnRzPGJyPg0KJmd0OyBvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0Yu PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gRFUgbW9kZSwgdGhlIG1hcHBpbmcgYWR2ZXJ0aXNlbWVu dCB3aWxsIGJlIGluZmx1ZW5jZWQgYnkgb3RoZXI8YnI+DQomZ3Q7IHJlY2VpdmVkIGFkdmVydGlz ZW1lbnQsIHdoaWNoIHdpbGwgYnJpbmcgbW9yZSBzaWduYWxpbmcuIFRoaXMgaXMgbm90PGJyPg0K Jmd0OyBvbmUtdGltZSBldmVudCwgYW55IExEUCBzZXNzaW9uIFVQL0RPV04gd2lsbCBpbmZsdWVu Y2UgdGhlIHdob2xlPGJyPg0KJmd0OyBzaWduYWxpbmcuIEJ1dCB3aHkgZG9uJ3QgeW91IGxpbWl0 IHRoZSByZWNlaXZlZCBhZHZlcnRpc2VtZW50IG9ubHk8YnI+DQomZ3Q7IGZyb20gdGhlIGRvd25z dHJlYW0gbm9kZSwgbm90IGFsbCBub2Rlcz8gT25seSB0aGUgcmVjZWl2ZWQ8YnI+DQomZ3Q7IGFk dmVydGlzZW1lbnQgZnJvbSBkb3duc3RyZWFtIG5vZGUgZG9lcyBub3QgU0xDIFRMViwgWCBtdXN0 IG5vdCBpbmNsdWRlIFNMQyBUTFYuPGJyPg0KPGJyPg0KVGhlIGFib3ZlIG1lY2hhbmlzbSBpcyBv cmlnaW5hbGx5IGRlZmluZWQgZm9yIEVMQywgYW5kIElNSE8sIGZyb20gdGhlIGNhcGFiaWxpdHkg bmVnb3RpYXRpb24gcG9pbnQgb2YgdmlldywgdGhlcmUgaXMgbm8gZGlmZmVyZW50IGJldHdlZW4g RUxDIGFuZCBTTEMuIEFzIHN0YXRlZCBpbiB0aGUgQWNrbm93bGVkZ2VtZW50cyBzZWN0aW9uLCB0 aGUgU0xDIG5lZ290aWF0aW9uIGlzIHJlZmVycmVkIHRvIEVMQyBuZWdvdGlhdGlvbiBtZWNoYW5p c20uPGJyPg0KPGJyPg0KSWYgeW91IGhhdmUgYmV0dGVyIHN1Z2dlc3Rpb24sIHRoYXQgd2lsbCBi ZSBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPltMaXpob25nXSBJIGtub3cgeW91IGJvcnJvdyB0 aGUgdGV4dCBmcm9tIFJGQzY3OTAuICZuYnNwO015IHN1Z2dlc3Rpb24gaXMsIG9ubHkgd2hlbiB0 aGUgcmVjZWl2ZWQgYWR2ZXJ0aXNlbWVudCBmcm9tIGRvd25zdHJlYW0gbm9kZSAobm90IGFueSBu b2RlKSBkb2VzIG5vdCBpbmNsdWRlIFNMQyBUTFYsIFggbXVzdCBub3QgaW5jbHVkZSBTTEMgVExW LiBUaGF0IHdpbGwgaW1wcm92ZSB0aGUNCiBzaWduYWxpbmcsIHJpZ2h0PyBUaGUgTERQIHNpZ25h bGluZyBmbGFwcGluZyBvZiBub24tZG93bnN0cmVhbSBhZHZlcnRpc2VtZW50IHdpbGwgbm90IGlu Zmx1ZW5jZSB0aGUgdXBzdHJlYW0gYWR2ZXJ0aXNlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W1hpYW9odV0gU0xDIFRMViBpcyB1c2VkIHRvIGluZGljYXRlIHdoZXRo ZXIgdGhlIGVncmVzcyBoYXMgdGhlIGNhcGFiaWxpdHkgb2YgcHJvY2Vzc2luZyB0aGUgU0wuIEhl bmNlIGl0IGRvZXNu4oCZdCBtYXR0ZXIgd2hldGhlciB0aGUgU0xDIFRMViBpcw0KIHJlY2VpdmVk IGZyb20gYSBkb3duc3RyZWFtIG5vZGUgb3IgYSBub24tZG93bnN0cmVhbSBub2RlLiBTaW5jZSB0 aGVyZSBpcyBhIGNoYW5jZSB0aGF0IG9uZSBvZiB0aGUgZWdyZXNzZXMgb3JpZ2luYXRpbmcgdGhh dCBGRUMgZG9lc27igJl0IHN1cHBvcnQgdGhlIFNMQywgaXTigJlzIHNhZmUgZm9yIFggdG8gbm90 IGluY2x1ZGUgdGhlIFNMQyBUTFYgaW4gaXRzIGFkdmVydGlzZW1lbnQuIE90aGVyd2lzZSwgdGhl IHBhY2tldCB3aXRoIHRoZSBTTCBvbiB0aGUNCiBmbHkgbWF5IGJlIGRyb3BwZWQgYnkgdGhlIGVn cmVzcyBub2RlIHcvbyB0aGUgU0xDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+DQomZ3Q7 IFNlY3Rpb24gNi4xLjIsIDYuMS4yLjM8YnI+DQomZ3Q7IFNpbmNlIFJTVlAtVEUgTFNQIGRvZXMg bm90IGhhdmUgdGhlIG1lYXN1cmVtZW50IHByb2JsZW0gbGlzdGVkIGluIHRoaXM8YnI+DQomZ3Q7 IGRyYWZ0LCB3aHkgd2UgbmVlZCB0byBkbyBSU1ZQLVRFIGV4dGVuc2lvbj8gTVAtQkdQIGlzIG5v dCB1c2VkIHRvPGJyPg0KJmd0OyBzZXR1cCBNUDJQIC8gTVAyTVAgTFNQLCB0aGVuIHdoeSB3ZSBu ZWVkIHRoZSBleHRlbnNpb24/IERpZCBJIG1pc3Mgc29tZXRoaW5nPzxicj4NCiZndDsgR0lNJmd0 OyZndDsgSSB0aGluayB0aGF0IFJTVlAtVEUgTFNQIHdpdGggbGFiZWwgbWVyZ2UgYW5kIFBIUCBz dGlsbCBoYXZlPGJyPg0KJmd0OyBHSU0mZ3Q7Jmd0OyBpc3N1ZXM8YnI+DQomZ3Q7IGRlc2NyaWJl ZCBpbiB0aGUgZG9jdW1lbnQuIFBlcmhhcHMgb25seSBNUExTLVRQIGNvbnN0cnVjdHMgaGF2ZTxi cj4NCiZndDsgZGV0ZXJtaW5pc20gb2YgdHJhbnNwb3J0IG5ldHdvcmsgYW5kIG1heSBub3QgaGF2 ZSB0aGlzIHByb2JsZW0uPGJyPg0KJmd0OyBbTGl6aG9uZ10gUEhQIGNvdWxkIGJlIGRpc2FibGVk IGZvciBSU1ZQLVRFIExTUC4gV2hpY2ggY2FzZSBoYXMgbGFiZWw8YnI+DQomZ3Q7IG1lcmdlIGZv ciBSU1ZQLVRFIExTUD8gQW55d2F5LCBpZiB5b3UgdGhpbmsgUlNWUC1URSBhbHNvIGhhcyBpc3N1 ZSw8YnI+DQomZ3Q7IHlvdSBzaG91bGQgc2F5IHRoYXQgaW4gc2VjdGlvbiAxLiBIb3dldmVyLCB1 c2luZyBzb3VyY2UgbGFiZWwgdG8gZG8gTE08YnI+DQomZ3Q7IGZvciBSU1ZQLVRFIExTUCBtYXkg bm90IGJlIGhlbHBmdWwsIHNpbmNlIHRoZSBSU1ZQLVRFIGxhYmVsIGlzIG1vcmU8YnI+DQomZ3Q7 IGFjY3VyYXRlIHRvIGlkZW50aWZ5IGFuIExTUCwgaW5jbHVkaW5nIHNvdXJjZSAmIzQzOyBkZXN0 aW5hdGlvbiAmIzQzOyB0dW5uZWwgSUQgJiM0MzsgTFNQIElEICYjNDM7IFBIQiwgZXRjLjxicj4N Cjxicj4NCklmIHRoZSBQSFAgaXMgZGlzYWJsZWQsIHRoZW4gc291cmNlIGxhYmVsIGZvciBSU1BW LVRFIG1heSBub3QgYmUgbmVlZGVkLiBJZiBwZW9wbGUgdGhpbmsgUlNWUC1URSBjYXNlIGlzIG5v dCBhIHZhbGlkIGNhc2UsIHdlIGNvdWxkIHJlbW92ZSBpdC48YnI+DQo8YnI+DQpCVFcsIHBsZWFz ZSBoYXZlIGEgbG9vayBhdCB0aGUgbGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAzIG9mICg8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGVuZy1sM3Zwbi1wbS1hbmFs eXNpcy0wMiNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16aGVuZy1sM3Zwbi1wbS1hbmFseXNpcy0wMiNzZWN0aW9uLTM8L2E+ICkgLCBp dCB0YWxrcyBhIGNhc2UgdGhhdA0KIGV2ZW4gZm9yIFJTVlAtVEUsIHRoZSBzb3VyY2UgbGFiZWwg bWF5IGFsc28gbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+W0xpemhvbmddIFRo YW5rcyBmb3IgdGhlIGxpbmsuIFdoYXQgSSB3YW50IHRvIHNheSBpcywgaWYgeW91IGJlbGlldmUg UlNWUC1URSBoYXMgaXNzdWUsIHRoZW4gZXhwbGljaXRseSBzYXkgdGhhdCBpbiBzZWN0aW9uIDEu IEluIGN1cnJlbnQgdGV4dCwgeW91IHNhaWQsIFJTVlAtVEUgaXMgT0sgaW4gc2VjdGlvbiAxLCBi dXQgeW91IHN0aWxsIGV4dGVuZCBSU1ZQLVRFIHByb3RvY29sLA0KIHRoYXQgaXMgY29uZnVzaW5n LiBBbmQgdGhlIHNhbWUgaXNzdWUgdG8gTVAtQkdQIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NClRoYW5rcyw8YnI+ DQpNYWNoPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkczxicj4NCiZndDsgTGl6aG9u Zzxicj4NCjxicj4NClNuaXBlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827AEF6NKGEML512MBSchi_-- From nobody Thu May 22 10:03: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 2C1B71A0228 for ; Thu, 22 May 2014 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.551 X-Spam-Level: X-Spam-Status: No, score=-9.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNPrw1cHG97R for ; Thu, 22 May 2014 10:03:22 -0700 (PDT) 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 6E8901A020B for ; Thu, 22 May 2014 10:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14837; q=dns/txt; s=iport; t=1400778200; x=1401987800; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=E1GhO2hRAVu2AG+ZmIbvrVUxrE/cHwvevGOYXQQaEtU=; b=j1uyz8oIbRUN1mvUTdV64Tj6hgiXM9O8sSj6ulFSaHiv5x1XzR20IZ9C iJNHgsd90ORZAk3Ni5PeZCMEZT3/318JnEbAab6OOwPYpBziPvmz9zSdR XJWDgQzXOhVZges4MQHLCmOBPgzgHQzuY5H9O1rVox8QTUjohxOUtK3J9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEACUtflOtJssW/2dsb2JhbABZgkKBF8UCAYEjdIIlAQEBBC06CwYBEAsRBAEBAQkWCAcJAwIBAgE0CQgGAQwBBQIBAYg9Dbg5nhYXjiwiBgEGhDoEmXGTJoM5bA X-IronPort-AV: E=Sophos; i="4.98,888,1392163200"; d="scan'208,217"; a="58355313" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 May 2014 17:03:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4MH3H4u015845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 17:03:18 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s4MH3Gga016769; Thu, 22 May 2014 18:03:17 +0100 (BST) Message-ID: <537E2DD7.4020901@cisco.com> Date: Thu, 22 May 2014 18:03:19 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gregory Mirsky , Eric Gray , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary="------------090002010002020603050209" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/f8RADfNGgrJt8EbdUaYnqZ1pWPU Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return 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, 22 May 2014 17:03:25 -0000 This is a multi-part message in MIME format. --------------090002010002020603050209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 22/05/2014 01:59, Gregory Mirsky wrote: > > Hi Stewart, > > I think that need for the extension you've proposed is indication that > per query control approach taken in RFC 6374 may not be the most > efficient in longer run. > Clearly I disagree. The proposed extension is a simple extension to an existing standards track specification. > > I think that establishing a test session through dedicated Command > message, as extension/update to RFCs 6374/6375, is possible and is > more flexible way. > You need to put a design on table and prove your point here. Do you have a draft I can read? > > And I think that maintaining a session would make upload of > measurement results more efficient when compared with uploading one > measurement at the time. > We make no comment about the upload, or any other relationship to an NMS, just the text protocol. > > And though LMAP framework > > concentrates on performance measurement in massive IP access networks > its model may be used as reference. I believe that there're plausible > scenarios when multiple Collectors request upload of measurement > results from an Measurement Agent. > Is there an IETF draft you can point me to? - Stewart > > Regards, > > Greg > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Wednesday, May 21, 2014 8:12 AM > *To:* Eric Gray; Gregory Mirsky; > draft-bryant-mpls-oam-udp-return@tools.ietf.org > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > On 09/04/2014 13:58, Eric Gray wrote: > > Stewart, > > Well, you're adding 4 bytes to handle the case where the response > is to be > > returned using UDP. This is in addition to the address > information already included > > in the message as defined by RFC 6374. > > It's certainly arguable that this new information does not need to > be carried > > in the test messages, assuming that there might be a control > protocol used instead. > > The question as to whether or not this is "heavy-weight" depends > on how > > many additional ways one might envision returning the response. > > I suspect this is the "bigger puzzle" that Greg refers to... > > Eric > > In terms of bytes which seems to be the focus of your initial para > and considering the packet loss case, the base message is 84 bytes. > Add an ACH, a delivery label and a GAL that is 96 bytes. It will > probably go over Ethernet so that is 110 bytes. > > Considering the IPv4 case, and noting that the address object > is already an agreed TLV the total goes to 118 bytes. So the > additional UDP port object which is 4 bytes is a little over 3% > If you take the address in IPv6 and the UDP compared to base > without an address the increase is 20/110 which is 18% which > is a little irritating but not out of this world. > > In contrasting this with any other approach you would need > to compare the per packet measurement overhead with the > session maintenance overhead of the other method. > > My assumption is that for any measurement request there > would only be one method of responding. Can you see a > deployment scenario where it would be beneficial to give > the responder a choice of methods of responding in every > request? > > - Stewart > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------090002010002020603050209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/05/2014 01:59, Gregory Mirsky wrote:

Hi Stewart,

I think that need for the extension you’ve proposed is indication that per query control approach taken in RFC 6374 may not be the most efficient in longer run.

Clearly I disagree. The proposed extension is a simple extension to an existing standards track specification.

I think that establishing a test session through dedicated Command message, as extension/update to RFCs 6374/6375, is possible and is more flexible way.

You need to put a design on table and prove your point here. Do you have a draft I can read?

And I think that maintaining a session would make upload of measurement results more efficient when compared with uploading one measurement at the time.

We make no comment about the upload, or any other relationship to an NMS, just the text protocol.

And though LMAP framework concentrates on performance measurement in massive IP access networks its model may be used as reference. I believe that there’re plausible scenarios when multiple Collectors request upload of measurement results from an Measurement Agent.

Is there an IETF draft you can point me to?

- Stewart

 

                Regards,

                                Greg

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Wednesday, May 21, 2014 8:12 AM
To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

 

On 09/04/2014 13:58, Eric Gray wrote:

Stewart,

 

                Well, you're adding 4 bytes to handle the case where the response is to be

returned using UDP.  This is in addition to the address information already included

in the message as defined by RFC 6374.

 

                It's certainly arguable that this new information does not need to be carried

in the test messages, assuming that there might be a control protocol used instead.

 

                The question as to whether or not this is "heavy-weight" depends on how

many additional ways one might envision returning the response.

 

                I suspect this is the "bigger puzzle" that Greg refers to…

Eric

In terms of bytes which seems to be the focus of your initial para
and considering the packet loss case, the base message is 84 bytes.
Add an ACH, a delivery label and a GAL that is 96 bytes. It will
probably go over Ethernet so that is 110 bytes.

Considering the IPv4 case, and noting that the address object
is already an agreed TLV the total goes to 118 bytes. So the
additional UDP port object which is 4 bytes is a little over 3%
If you take the address in IPv6 and the UDP compared to base
without an address the increase is 20/110 which is 18% which
is a little irritating but not out of this world.

In contrasting this with any other approach you would need
to compare the per packet measurement overhead with the
session maintenance overhead of the other method.

My assumption is that for any measurement request there
would only be one method of responding. Can you see a
deployment scenario where it would be beneficial to give
the responder a choice of methods of responding in every
request?

- Stewart



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------090002010002020603050209-- From nobody Thu May 22 11:10: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 2E17A1A0273 for ; Thu, 22 May 2014 11:10:48 -0700 (PDT) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My873LndCM7w for ; Thu, 22 May 2014 11:10:45 -0700 (PDT) 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 9A8C41A0274 for ; Thu, 22 May 2014 11:10:45 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-37-537deb633f4f Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1E.70.11744.36BED735; Thu, 22 May 2014 14:19:47 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Thu, 22 May 2014 14:10:33 -0400 From: Gregory Mirsky To: "stbryant@cisco.com" , Eric Gray , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPU+saEJtSSVJZq0yj4ZIvBeRSWJsJgiEAgEInKQCAAFwCQIABVWGA///Pf7A= Date: Thu, 22 May 2014 18:10:32 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> In-Reply-To: <537E2DD7.4020901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7C0FCEeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLonUDf5dW2wwd9puhaTvr1htri1dCWr xbmncxgdmD2m/N7I6rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZcy+/5Kt4FcLY8XGf78Z GxinF3cxcnJICJhINP1YxQRhi0lcuLeerYuRi0NI4CijxPb9y5lBEkICyxklHs9OBbHZBIwk XmzsYQcpEhHYxSgxafUsoA4ODmYBZYlTd2VAaoQFHCSWz30E1isi4CjxYcE5VgjbT2L12XeM IDaLgKpE6+5eFhCbV8BXYua1LYwQizcxSRz+OBmsiFNAU2LVhS6wIkag676fWgN2KbOAuMSt J/OhrhaQWLLnPDOELSrx8vE/VghbUWJf/3R2iPp8iZbP85gglglKnJz5hGUCo+gsJKNmISmb haQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLcxAiMtmMSbI47GBd8 sjzEKMDBqMTDu+BUbbAQa2JZcWXuIUZpDhYlcd4916qChQTSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTDyMeSeLjxYtT2QX6B24u2NkhG+5wqke3clPijc03lJ7HwBR73PW817nw/517/fwf0/ UvpQXkR4zH6pDxwH8/L3Sdydk3eaWei6gKB0wYx58QZv2tlnmS/Zv2d5hqjUp3dLH7KmLdtx Zm/8um9hfo0sAlG3c9r0375/F/px/s7eA9fZNRqW+vxVYinOSDTUYi4qTgQAHBRgdpcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hfosx2pjYUP7ZQDKESh-35vqksA Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:10:48 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7C0FCEeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, the LMAP framework is the link to the https://datatracker.ietf.org/doc/draf= t-ietf-lmap-framework/?include_text=3D1 Regards, Greg From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Thursday, May 22, 2014 10:03 AM To: Gregory Mirsky; Eric Gray; draft-bryant-mpls-oam-udp-return@tools.ietf.= org Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return On 22/05/2014 01:59, Gregory Mirsky wrote: Hi Stewart, I think that need for the extension you've proposed is indication that per = query control approach taken in RFC 6374 may not be the most efficient in l= onger run. Clearly I disagree. The proposed extension is a simple extension to an exis= ting standards track specification. I think that establishing a test session through dedicated Command message,= as extension/update to RFCs 6374/6375, is possible and is more flexible wa= y. You need to put a design on table and prove your point here. Do you have a = draft I can read? And I think that maintaining a session would make upload of measurement res= ults more efficient when compared with uploading one measurement at the tim= e. We make no comment about the upload, or any other relationship to an NMS, j= ust the text protocol. And though LMAP framework concentrates on performance measurement in mas= sive IP access networks its model may be used as reference. I believe that = there're plausible scenarios when multiple Collectors request upload of mea= surement results from an Measurement Agent. Is there an IETF draft you can point me to? - Stewart Regards, Greg From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, May 21, 2014 8:12 AM To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.= org Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return On 09/04/2014 13:58, Eric Gray wrote: Stewart, Well, you're adding 4 bytes to handle the case where the re= sponse is to be returned using UDP. This is in addition to the address information already= included in the message as defined by RFC 6374. It's certainly arguable that this new information does not = need to be carried in the test messages, assuming that there might be a control protocol used = instead. The question as to whether or not this is "heavy-weight" de= pends on how many additional ways one might envision returning the response. I suspect this is the "bigger puzzle" that Greg refers to..= . Eric In terms of bytes which seems to be the focus of your initial para and considering the packet loss case, the base message is 84 bytes. Add an ACH, a delivery label and a GAL that is 96 bytes. It will probably go over Ethernet so that is 110 bytes. Considering the IPv4 case, and noting that the address object is already an agreed TLV the total goes to 118 bytes. So the additional UDP port object which is 4 bytes is a little over 3% If you take the address in IPv6 and the UDP compared to base without an address the increase is 20/110 which is 18% which is a little irritating but not out of this world. In contrasting this with any other approach you would need to compare the per packet measurement overhead with the session maintenance overhead of the other method. My assumption is that for any measurement request there would only be one method of responding. Can you see a deployment scenario where it would be beneficial to give the responder a choice of methods of responding in every request? - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_7347100B5761DC41A166AC17F22DF1121B7C0FCEeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stewart,=

the LMAP framework is = the link to the https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/?include_text=3D= 1

 

   &nbs= p;            Regard= s,

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

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Thursday, May 22, 2014 10:03 AM
To: Gregory Mirsky; Eric Gray; draft-bryant-mpls-oam-udp-return@tool= s.ietf.org
Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

 

On 22/05/2014 01:59, Gregory Mirsky wrote:

Hi Stewart,

I think that need for = the extension you’ve proposed is indication that per query control ap= proach taken in RFC 6374 may not be the most efficient in longer run.

Clearly I disagree. The proposed ext= ension is a simple extension to an existing standards track specification.<= br>

I think that establish= ing a test session through dedicated Command message, as extension/update t= o RFCs 6374/6375, is possible and is more flexible way.

You need to put a design on table an= d prove your point here. Do you have a draft I can read?

And I think that maint= aining a session would make upload of measurement results more efficient wh= en compared with uploading one measurement at the time.

We make no comment about the upload,= or any other relationship to an NMS, just the text protocol.

And though LMAP framework concentrates on performance measurement in massive IP ac= cess networks its model may be used as reference. I believe that there̵= 7;re plausible scenarios when multiple Collectors request upload of measure= ment results from an Measurement Agent.

Is there an IETF draft you can point= me to?

- Stewart

 

   &nbs= p;            Regard= s,

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

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Wednesday, May 21, 2014 8:12 AM
To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

 

On 09/04/2014 13:58, Eric Gray wrote:

Stewart,

 

   &nbs= p;            Well, = you're adding 4 bytes to handle the case where the response is to be=

returned using UDP.&nb= sp; This is in addition to the address information already included<= o:p>

in the message as defi= ned by RFC 6374.

 

   &nbs= p;            It's c= ertainly arguable that this new information does not need to be carried

in the test messages, = assuming that there might be a control protocol used instead.

 

   &nbs= p;            The qu= estion as to whether or not this is "heavy-weight" depends on how

many additional ways o= ne might envision returning the response.

 

   &nbs= p;            I susp= ect this is the "bigger puzzle" that Greg refers to…=

Eric

In terms of bytes which seems to be the focus of your initial para
and considering the packet loss case, the base message is 84 bytes.
Add an ACH, a delivery label and a GAL that is 96 bytes. It will
probably go over Ethernet so that is 110 bytes.

Considering the IPv4 case, and noting that the address object
is already an agreed TLV the total goes to 118 bytes. So the
additional UDP port object which is 4 bytes is a little over 3%
If you take the address in IPv6 and the UDP compared to base
without an address the increase is 20/110 which is 18% which
is a little irritating but not out of this world.

In contrasting this with any other approach you would need
to compare the per packet measurement overhead with the
session maintenance overhead of the other method.

My assumption is that for any measurement request there
would only be one method of responding. Can you see a
deployment scenario where it would be beneficial to give
the responder a choice of methods of responding in every
request?

- Stewart




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

 
--_000_7347100B5761DC41A166AC17F22DF1121B7C0FCEeusaamb103erics_-- From nobody Thu May 22 15:29: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 C6F221A02A5 for ; Thu, 22 May 2014 15:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhA5h6yElZzz for ; Thu, 22 May 2014 15:29:45 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FEC1A0226 for ; Thu, 22 May 2014 15:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4406; q=dns/txt; s=iport; t=1400797783; x=1402007383; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uU/c4I0yijg/oXRMtFyf2cO+KWPpu0jHi6eXAmwKJpI=; b=ev60rGjB4QgPSjMTDYQ5v2uPlIsYdRqoldx3CWqRjLYAulKal98QukTh fgAe1kV/7FIgokUPhtMhWlHc5JZuCFbi91fmDlBTWhDnDJcC7hmjoL0ff RqJNCpq2kmoT5vhHR1W8UU3fzJSWCa48h8+uCZDPspi80uKah2thluUDJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAAh5flOtJssW/2dsb2JhbABZg1nFAwGBI3SCJQEBAQQyAQUvCwcQCxEEAQEBCR4HDwI1CQgGAQwBBQIBAYg9Dbh4njQXjiwiBwaEOgSZcZMmgzls X-IronPort-AV: E=Sophos;i="4.98,890,1392163200"; d="scan'208";a="54552019" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 22 May 2014 22:29:41 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4MMTfeq019932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 22:29:41 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s4MMTabG027574; Thu, 22 May 2014 23:29:37 +0100 (BST) Message-ID: <537E7A53.50707@cisco.com> Date: Thu, 22 May 2014 23:29:39 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gregory Mirsky , Eric Gray , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/GVSBm4nCY4p6cBL6EquhpPjrtz8 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return 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, 22 May 2014 22:29:46 -0000 That is way outside the scale and scope of this measurement. Stewart On 22/05/2014 19:10, Gregory Mirsky wrote: > > Hi Stewart, > > the LMAP framework is the link to the > https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/?include_text=1 > > Regards, > > Greg > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Thursday, May 22, 2014 10:03 AM > *To:* Gregory Mirsky; Eric Gray; > draft-bryant-mpls-oam-udp-return@tools.ietf.org > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > On 22/05/2014 01:59, Gregory Mirsky wrote: > > Hi Stewart, > > I think that need for the extension you’ve proposed is indication > that per query control approach taken in RFC 6374 may not be the > most efficient in longer run. > > Clearly I disagree. The proposed extension is a simple extension to an > existing standards track specification. > > I think that establishing a test session through dedicated Command > message, as extension/update to RFCs 6374/6375, is possible and is > more flexible way. > > You need to put a design on table and prove your point here. Do you > have a draft I can read? > > And I think that maintaining a session would make upload of > measurement results more efficient when compared with uploading one > measurement at the time. > > We make no comment about the upload, or any other relationship to an > NMS, just the text protocol. > > And though LMAP framework > > concentrates on performance measurement in massive IP access networks > its model may be used as reference. I believe that there’re plausible > scenarios when multiple Collectors request upload of measurement > results from an Measurement Agent. > > Is there an IETF draft you can point me to? > > - Stewart > > Regards, > > Greg > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Wednesday, May 21, 2014 8:12 AM > *To:* Eric Gray; Gregory Mirsky; > draft-bryant-mpls-oam-udp-return@tools.ietf.org > > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > On 09/04/2014 13:58, Eric Gray wrote: > > Stewart, > > Well, you're adding 4 bytes to handle the case where the response > is to be > > returned using UDP. This is in addition to the address information > already included > > in the message as defined by RFC 6374. > > It's certainly arguable that this new information does not need to > be carried > > in the test messages, assuming that there might be a control > protocol used instead. > > The question as to whether or not this is "heavy-weight" depends > on how > > many additional ways one might envision returning the response. > > I suspect this is the "bigger puzzle" that Greg refers to… > > Eric > > In terms of bytes which seems to be the focus of your initial para > and considering the packet loss case, the base message is 84 bytes. > Add an ACH, a delivery label and a GAL that is 96 bytes. It will > probably go over Ethernet so that is 110 bytes. > > Considering the IPv4 case, and noting that the address object > is already an agreed TLV the total goes to 118 bytes. So the > additional UDP port object which is 4 bytes is a little over 3% > If you take the address in IPv6 and the UDP compared to base > without an address the increase is 20/110 which is 18% which > is a little irritating but not out of this world. > > In contrasting this with any other approach you would need > to compare the per packet measurement overhead with the > session maintenance overhead of the other method. > > My assumption is that for any measurement request there > would only be one method of responding. Can you see a > deployment scenario where it would be beneficial to give > the responder a choice of methods of responding in every > request? > > - Stewart > > > > > -- > 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 From nobody Fri May 23 06:47:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FB61A0196 for ; Fri, 23 May 2014 06:47:50 -0700 (PDT) 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_52=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 XniYBvq76WLc for ; Fri, 23 May 2014 06:47:49 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F991A00EF for ; Fri, 23 May 2014 06:47:48 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-cd-537f01a778cf Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7C.3F.27529.7A10F735; Fri, 23 May 2014 10:07:03 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 23 May 2014 09:47:39 -0400 From: Eric Gray To: "stbryant@cisco.com" , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPdQcJZ0y8Hhq70US8I/RdC07quZtM1WrpgABV0wCAAEhlgIAAtT8A Date: Fri, 23 May 2014 13:47:38 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> <537E7A53.50707@cisco.com> In-Reply-To: <537E7A53.50707@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXSPt+5yxvpgg1/NFhaTvr1htmg+MIvN 4tbSlawW557OYXRg8ZjyeyOrx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CV0bP7AlvBccOK izeesDUw7lTvYuTkkBAwkWhcdZUFwhaTuHBvPVsXIxeHkMBRRolfl16xQzjLGSXOPepmB6li E9CQOHZnLSOILSJwjFFi81ENEJtZoE7iS+8WZhBbWMBBYvncR8wQNY4SHxacY4Ww3STuvVoM to1FQFVi5YzlYDavgK/E+iU/mCGWTWaWWLPxDBNIglNAXeLS/GawIkag876fWsMEsUxc4taT +UwQZwtILNlznhnCFpV4+fgfK4StJDFpKcRiZgEdiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmM YrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtjECIyjYxJsujsY97y0PMQowMGoxMO74FRt sBBrYllxZe4hRmkOFiVxXu2bVcFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGNcdkOmL8mCP 2PHEXULBd/nWvA91tibPzKL2WK2YtJTxuHALr2qmzwHrAO4pm4VEAqSfc1ks/PJ214t3r25e 3bvORn5DND/XrclL3ewqVTP6I+uK0jtlXM9ZeG6acO1k92Kp38XM6mELj2uZyC6VeFneHrnu 2Wm7gjfG588URP3hMVDpnl2UoMRSnJFoqMVcVJwIAHc9f4mEAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9AmlFaywMOy9lVgq4ApAeNwkZAE Cc: "mpls@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:47:50 -0000 Stewart, I disagree with the characterization of a reference to the LMAP approach a= s=20 "way outside the scale and scope of this measurement." It may require more energy than any of us have, but the LMAP Framework draft merely defines a generic protocol model. It is certainly possible to= define the limited subset of messages required specifically for this application, whil= e leaving the possibility of defining others to be done later, if needed. That approach establishes roughly the same "scale and scope" as does your proposal, without requiring changes to every implementation's forwarding pl= ane to process one more bit of information. Perhaps - if we dig around a bit - we can find someone who does have the energy to work on this? Two of the authors of the LMAP draft are your coll= eagues after all. One issue is that you mention a customer requirement. Yet, if you looked at the LMAP draft (which I assume you did), you must have noticed the autho= r list also includes folks from BT and AT&T (as well as Universidad Carlos III Mad= rid, and Cisco). Perhaps it is a good idea to determine if your approach would meet their requirements as well? Isn't it worth checking with other customers to determine if they are okay= =20 with the approach in your draft, and possibly trying to find someone with e= nergy=20 (and bandwidth) to pursue a quick proposal (scoped to this specific measure= ment=20 and based on LMAP) - if it turns out some customers would prefer that appro= ach? -- Eric -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Thursday, May 22, 2014 6:30 PM To: Gregory Mirsky; Eric Gray; draft-bryant-mpls-oam-udp-return@tools.ietf.= org Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return Importance: High That is way outside the scale and scope of this measurement. Stewart On 22/05/2014 19:10, Gregory Mirsky wrote: > > Hi Stewart, > > the LMAP framework is the link to the > https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/?include_te > xt=3D1 > > Regards, > > Greg > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Thursday, May 22, 2014 10:03 AM > *To:* Gregory Mirsky; Eric Gray; > draft-bryant-mpls-oam-udp-return@tools.ietf.org > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > On 22/05/2014 01:59, Gregory Mirsky wrote: > > Hi Stewart, > > I think that need for the extension you've proposed is indication > that per query control approach taken in RFC 6374 may not be the > most efficient in longer run. > > Clearly I disagree. The proposed extension is a simple extension to an=20 > existing standards track specification. > > I think that establishing a test session through dedicated Command=20 > message, as extension/update to RFCs 6374/6375, is possible and is=20 > more flexible way. > > You need to put a design on table and prove your point here. Do you=20 > have a draft I can read? > > And I think that maintaining a session would make upload of=20 > measurement results more efficient when compared with uploading one=20 > measurement at the time. > > We make no comment about the upload, or any other relationship to an=20 > NMS, just the text protocol. > > And though LMAP framework > ext=3D1> concentrates on performance measurement in massive IP access=20 > networks its model may be used as reference. I believe that there're=20 > plausible scenarios when multiple Collectors request upload of=20 > measurement results from an Measurement Agent. > > Is there an IETF draft you can point me to? > > - Stewart > > Regards, > > Greg > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Wednesday, May 21, 2014 8:12 AM > *To:* Eric Gray; Gregory Mirsky; > draft-bryant-mpls-oam-udp-return@tools.ietf.org > > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > On 09/04/2014 13:58, Eric Gray wrote: > > Stewart, > > Well, you're adding 4 bytes to handle the case where the response > is to be > > returned using UDP. This is in addition to the address information > already included > > in the message as defined by RFC 6374. > > It's certainly arguable that this new information does not need to > be carried > > in the test messages, assuming that there might be a control > protocol used instead. > > The question as to whether or not this is "heavy-weight" depends > on how > > many additional ways one might envision returning the response. > > I suspect this is the "bigger puzzle" that Greg refers to... > > Eric > > In terms of bytes which seems to be the focus of your initial para and=20 > considering the packet loss case, the base message is 84 bytes. > Add an ACH, a delivery label and a GAL that is 96 bytes. It will=20 > probably go over Ethernet so that is 110 bytes. > > Considering the IPv4 case, and noting that the address object is=20 > already an agreed TLV the total goes to 118 bytes. So the additional=20 > UDP port object which is 4 bytes is a little over 3% If you take the=20 > address in IPv6 and the UDP compared to base without an address the=20 > increase is 20/110 which is 18% which is a little irritating but not=20 > out of this world. > > In contrasting this with any other approach you would need to compare=20 > the per packet measurement overhead with the session maintenance=20 > overhead of the other method. > > My assumption is that for any measurement request there would only be=20 > one method of responding. Can you see a deployment scenario where it=20 > would be beneficial to give the responder a choice of methods of=20 > responding in every request? > > - Stewart > > > > > -- > For corporate legal information go to: > =20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > =20 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Fri May 23 08:18: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 B78B81A0667 for ; Fri, 23 May 2014 08:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ5xJv9avvyg for ; Fri, 23 May 2014 08:18:29 -0700 (PDT) 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 D455B1A0666 for ; Fri, 23 May 2014 08:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=242; q=dns/txt; s=iport; t=1400858307; x=1402067907; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uJt2bDWYe8faHpltm1ACiRdsCawHUIFuhtxmYqEm9bc=; b=WtM4KimgzUeyB3znmnSbeK2SskDtDYmYxA/aSFFQn0G0mNdW9PFSCGZZ fg7zQ+dWSkBe8E0AG4TxoJa5kRY6rjBVfH+F1Lsgzv7ZgNrQJsK++/V4x uvpNmxU9rIfSTcUbxZ3h5dAFtXsPhonEu3K7+Ctx+aSnashV7dLeKgVV9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAP9lf1OtJssW/2dsb2JhbABayHgBgR50giYBAQQ4QAEQCyEWDwkDAgECAUUGAQwBBwEBiD25c54rF45SB4RAAQOZcpMngzk X-IronPort-AV: E=Sophos;i="4.98,894,1392163200"; d="scan'208";a="59530662" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 23 May 2014 15:18:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4NFIOFg003490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 15:18:24 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s4NFIMAC004845; Fri, 23 May 2014 16:18:22 +0100 (BST) Message-ID: <537F66C3.4070203@cisco.com> Date: Fri, 23 May 2014 16:18:27 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Eric Gray , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> <537E7A53.50707@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aqZ5dm7-B-DRvB8GmduZctNKPQU Cc: "mpls@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 15:18:30 -0000 Eric I think the onus is on you as the objector to provide me with a pointer to a specific protocol alternative not a framework, or to show why this simple addition of four bytes will not work in the manner that I describe. Stewart From nobody Fri May 23 08:47: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 2DD761A0537 for ; Fri, 23 May 2014 08:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 B9q4wN0CNYMX for ; Fri, 23 May 2014 08:47:14 -0700 (PDT) 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 7A70B1A015C for ; Fri, 23 May 2014 08:47:14 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-60-537f1b39f4a0 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4C.64.11744.93B1F735; Fri, 23 May 2014 11:56:09 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 23 May 2014 11:47:09 -0400 From: Eric Gray To: "stbryant@cisco.com" , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPdQcJZ0y8Hhq70US8I/RdC07quZtM1WrpgABV0wCAAEhlgIAAtT8AgABknID//71acA== Date: Fri, 23 May 2014 15:47:08 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AC1249@eusaamb107.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> <537E7A53.50707@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> <537F66C3.4070203@cisco.com> In-Reply-To: <537F66C3.4070203@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPrK6ldH2wwapNOhaTvr1htmg+MIvN 4tbSlawW557OYXRg8ZjyeyOrx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CV8bn9NEvBGsGK u0+uMzYwvuLtYuTkkBAwkVj/8hUrhC0mceHeejYQW0jgKKPEtNfCXYxcQPZyRon7aycxgiTY BDQkjt1ZC2aLCBxjlNh8VAPEZhaok/jSu4UZxBYWcJBYPvcRM0SNo8SHBedYIewwiWmn7rOD 2CwCqhKNKxaAxXkFfCX+t+1ghFj8jVniVrcsiM0poCmx/uMJJhCbEei476fWMEHsEpe49WQ+ E8TRAhJL9pxnhrBFJV4+/gf1jJLEpKUQe5kFdCQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrN QjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chwEyMwho5JsDnuYFzwyfIQowAHoxIP74JTtcFC rIllxZW5hxilOViUxHn3XKsKFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4zaxHqHeuieCf 10ZaO2b+CdRcmz8/+49d9O6PXgsF19zgPD8xbs+2N65fOj506CXNyDtRNVNSkj23t/HZw7kf 1G+LZzY+X3tt8Szb7mMuyWedDdbVNlsdubZ7f3eRc/GB+Zu/vSt9ITJxZbS4orIDM8NbF/6W mfYWiZcMY+vdRWx/TzgQEHpAiaU4I9FQi7moOBEAXpIB/4ICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/A57ftYRT8ntPDz-rZ8le_7QhDPI Cc: "mpls@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 15:47:16 -0000 Stewart, I understand your point. But the question is not whether or not it will w= ork,=20 but rather whether or not there is consensus to do it this way. On any given day, it is trivial to come up with any number of approaches for doing something (whatever that something is) that will _work_ - which i= s not the same as saying that we should all pour energy into any of those ideas. I also understand the pressures associated with customer requirements, but don't see why the customer(s) behind your requirements should have the last= word on which approach should be used - based solely on those requirements. That approach leads to a point-solution that has a definite non-zero cost.= As a general approach, the continuous generation of point solutions has its ow= n scaling issues. It is my hope that someone will have the energy to put together a draft to propose an alternative based on LMAP. I personally do not have either the = energy or the bandwidth. In fact, I don't have the bandwidth or the energy to con= tinue in=20 this discussion. I sincerely hope and intend this will be my last post on= this topic. If there is insufficient interest in developing the scaled-down version of= an LMAP-based proposal - either within the MPLS working group, or among the LM= AP framework authors - before the Toronto meeting, or there is not a number of= like objections raised on the MPLS mailing list, then it would seem that the WG = default=20 consensus is to proceed with your draft. Believe it or not, I personally can live with that. -- Eric -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Friday, May 23, 2014 11:18 AM To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.= org Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return Importance: High Eric I think the onus is on you as the objector to provide me with a pointer to = a specific protocol alternative not a framework, or to show why this simple= addition of four bytes will not work in the manner that I describe. Stewart From nobody Fri May 23 10:14: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 AF49A1A073F for ; Fri, 23 May 2014 10:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 S15WA28kiN8a for ; Fri, 23 May 2014 10:13:59 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 347381A06DF for ; Fri, 23 May 2014 10:13:59 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 3B7DE554C52; Fri, 23 May 2014 13:15:56 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 56D63F03A0; Fri, 23 May 2014 13:13:57 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 23 May 2014 13:13:57 -0400 From: "MORTON, ALFRED C (AL)" To: Eric Gray , "stbryant@cisco.com" , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Date: Fri, 23 May 2014 13:13:55 -0400 Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPdQcJZ0y8Hhq70US8I/RdC07quZtM1WrpgABV0wCAAEhlgIAAtT8AgABknID//71acIAAG3vg Message-ID: <2845723087023D4CB5114223779FA9C8017992C1F2@njfpsrvexg8.research.att.com> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> <537E7A53.50707@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> <537F66C3.4070203@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1249@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AC1249@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6ayUgkTTzpm2vb4c7EoImNKo0t8 Cc: "mpls@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 17:14:00 -0000 Eric, Stewart, It seems to me (after scanning the draft) that the MPLS-PLDM could be=20 treated as the out-of-scope measurement traffic/protocol in the LMAP Framework Figure 1 below (Where IPPM is currently used as the=20 out-of-scope example): ^ | Active +-------------+ IPPM +---------------+ Measurement | Measurement | Scope | Measurement |<------------>| Peer | | | Agent | Traffic +-------------+ v +------->| | ^ | +---------------+ | | ^ | | | Instruction | | Report | | | +-----------------+ | | | | | | | v LMAP | +------------+ +------------+ Scope | | Controller | | Collector | | | +------------+ +------------+ v | ^ ^ | ^ | | | | | | | +----------+ | | | | | v | +------------+ +----------+ +--------+ +----------+ |=20 |Bootstrapper| |Subscriber|--->| data |<---|repository| Out +------------+ |parameter | |analysis| +----------+ of |database | | tools | Scope +----------+ +--------+ | =20 | The MPLS-PLDM Querier could be co-located with a Measurement Agent, and assuming the Querier performs all the coordination, including arranging to return the response message to a port co-located with the same Measurement Agent (or configuration takes the role of signaling), then the MPLS-PLDM responder=20 could be treated as a Measurement Peer. The LMAP Control and Report protocols provision and collect results from the Querier, taking the role of a "management system" mentioned in the draft. hope this helps, Al > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Friday, May 23, 2014 11:47 AM > To: stbryant@cisco.com; Gregory Mirsky; draft-bryant-mpls-oam-udp- > return@tools.ietf.org > Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return >=20 > Stewart, >=20 > I understand your point. But the question is not whether or not it > will work, > but rather whether or not there is consensus to do it this way. >=20 > On any given day, it is trivial to come up with any number of > approaches > for doing something (whatever that something is) that will _work_ - which > is not the > same as saying that we should all pour energy into any of those ideas. >=20 > I also understand the pressures associated with customer > requirements, but > don't see why the customer(s) behind your requirements should have the > last word > on which approach should be used - based solely on those requirements. >=20 > That approach leads to a point-solution that has a definite non-zero > cost. As > a general approach, the continuous generation of point solutions has its > own scaling > issues. >=20 > It is my hope that someone will have the energy to put together a > draft to > propose an alternative based on LMAP. I personally do not have either th= e > energy > or the bandwidth. In fact, I don't have the bandwidth or the energy to > continue in > this discussion. I sincerely hope and intend this will be my last post > on this topic. >=20 > If there is insufficient interest in developing the scaled-down > version of an > LMAP-based proposal - either within the MPLS working group, or among the > LMAP > framework authors - before the Toronto meeting, or there is not a number > of like > objections raised on the MPLS mailing list, then it would seem that the W= G > default > consensus is to proceed with your draft. >=20 > Believe it or not, I personally can live with that. >=20 > -- > Eric >=20 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, May 23, 2014 11:18 AM > To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp- > return@tools.ietf.org > Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > Importance: High >=20 > Eric >=20 > I think the onus is on you as the objector to provide me with a pointer t= o > a specific protocol alternative not a framework, or to show why this > simple addition of four bytes will not work in the manner that I describe= . >=20 > Stewart From nobody Sat May 24 17:14: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 EA1F81A0178 for ; Sat, 24 May 2014 17:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TX7yiSKnaj34 for ; Sat, 24 May 2014 17:14:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86241A0173 for ; Sat, 24 May 2014 17:14:35 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-df-5380e5f80be7 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F4.A6.27529.8F5E0835; Sat, 24 May 2014 20:33:29 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Sat, 24 May 2014 20:14:23 -0400 From: Gregory Mirsky To: "MORTON, ALFRED C (AL)" , Eric Gray , "stbryant@cisco.com" , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPU+saEJtSSVJZq0yj4ZIvBeRSWJsJgiEAgEInKQCAAFwCQIABVWGA///Pf7CAAIuugIABAHwAgAAZX4CAAAgEAIAAGD+AgAHBszA= Date: Sun, 25 May 2014 00:14:22 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7C2C04@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> <537E7A53.50707@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> <537F66C3.4070203@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1249@eusaamb107.ericsson.se> <2845723087023D4CB5114223779FA9C8017992C1F2@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017992C1F2@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPrO7Ppw3BBucns1psPTaR0WLStzfM Fs0HZrFZ3Fq6ktXi3NM5jA6sHi/75zB6TPm9kdVjyZKfTB5fLn9mC2CJ4rJJSc3JLEst0rdL 4MpYe9694IJRxdytv5kbGM8qdTFyckgImEicevSDHcIWk7hwbz1bFyMXh5DAUUaJ3Xe2MEI4 yxklPq3pBatiEzCSeLGxB8wWEXjBKPH1lzuIzSxQJ/GldwsziC0s4CCxfO4jZogaR4kPC86x QthlEn3nbjGC2CwCqhLtayaCzeEV8JX4/qeJCWJZG6vElzsn2EASnAJhEquX3GQCsRmBzvt+ ag0TxDJxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rBC2ksSc19eYIep1JBbs/sQGYWtLLFv4mhli saDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyipGjtDi1LDfdyGATIzCyjkmw6e5g3PPS8hCj AAejEg+vwr2GYCHWxLLiytxDjNIcLErivNo3q4KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MMp5Tz7Jxcn9NkD5Xg3n9JavFj1/s6quCVzb8EpZqslpygwXplTVRdv2eSSaVmbKJkfvqRcK uvVg5rRtfSJ161N33tW1unPBZvWe6xpHr7yb3ORj8vij1t+SwxIcH8o5Ny3rm/8k7tfR40ce 7lvse93J/OfzF8bWNys3/fRyy07Jf9R6zNay96gSS3FGoqEWc1FxIgBZgNH6jQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6P47hdTXfPoIl6uMJomfqrRsuqw Cc: "mpls@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 25 May 2014 00:14:38 -0000 Dear Al, thank you for your analysis of the draft and its correlation with the LMAP = framework. I think that the RFC 6374 gives option for the responder, Measurement Peer = (MP) in LMAP framework terminology, to send measurement result to an arbitr= ary destination, not only to the Querier, Measurement Agent (MA). Though su= ch scenario is not considered for MP in the LMAP framework, I believe we ca= n still refer to that node as Data Collector because MA instructed MP perha= ps based on information received from the Measurement Controller. During our discussion Stewart asked if there could be case of multiple Data= Collectors for the given Measurement Task. That is when I referred to the = LMAP framework as I believe that it allows to associate multiple Data Coll= ectors with the Measurement Task. Is my understanding correct? Regards, Greg -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Friday, May 23, 2014 10:14 AM To: Eric Gray; stbryant@cisco.com; Gregory Mirsky; draft-bryant-mpls-oam-ud= p-return@tools.ietf.org Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return Eric, Stewart, It seems to me (after scanning the draft) that the MPLS-PLDM could be treat= ed as the out-of-scope measurement traffic/protocol in the LMAP Framework F= igure 1 below (Where IPPM is currently used as the out-of-scope example): ^ | Active +-------------+ IPPM +---------------+ Measurement | Measurement | Scope | Measurement |<------------>| Peer | | | Agent | Traffic +-------------+ v +------->| | ^ | +---------------+ | | ^ | | | Instruction | | Report | | | +-----------------+ | | | | | | | v LMAP | +------------+ +------------+ Scope | | Controller | | Collector | | | +------------+ +------------+ v | ^ ^ | ^ | | | | | | | +----------+ | | | | | v | +------------+ +----------+ +--------+ +----------+ |=20 |Bootstrapper| |Subscriber|--->| data |<---|repository| Out +------------+ |parameter | |analysis| +----------+ of |database | | tools | Scope +----------+ +--------+ | =20 | The MPLS-PLDM Querier could be co-located with a Measurement Agent, and ass= uming the Querier performs all the coordination, including arranging to ret= urn the response message to a port co-located with the same Measurement Age= nt (or configuration takes the role of signaling), then the MPLS-PLDM respo= nder could be treated as a Measurement Peer. The LMAP Control and Report p= rotocols provision and collect results from the Querier, taking the role of= a "management system" mentioned in the draft. hope this helps, Al > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Friday, May 23, 2014 11:47 AM > To: stbryant@cisco.com; Gregory Mirsky; draft-bryant-mpls-oam-udp-=20 > return@tools.ietf.org > Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return >=20 > Stewart, >=20 > I understand your point. But the question is not whether or not it=20 > will work, but rather whether or not there is consensus to do it this=20 > way. >=20 > On any given day, it is trivial to come up with any number of=20 > approaches for doing something (whatever that something is) that will=20 > _work_ - which is not the same as saying that we should all pour=20 > energy into any of those ideas. >=20 > I also understand the pressures associated with customer=20 > requirements, but don't see why the customer(s) behind your=20 > requirements should have the last word on which approach should be=20 > used - based solely on those requirements. >=20 > That approach leads to a point-solution that has a definite non-zero=20 > cost. As a general approach, the continuous generation of point=20 > solutions has its own scaling issues. >=20 > It is my hope that someone will have the energy to put together a=20 > draft to propose an alternative based on LMAP. I personally do not=20 > have either the energy or the bandwidth. In fact, I don't have the=20 > bandwidth or the energy to continue in > this discussion. I sincerely hope and intend this will be my last post > on this topic. >=20 > If there is insufficient interest in developing the scaled-down=20 > version of an LMAP-based proposal - either within the MPLS working=20 > group, or among the LMAP framework authors - before the Toronto=20 > meeting, or there is not a number of like objections raised on the=20 > MPLS mailing list, then it would seem that the WG default consensus =20 > is to proceed with your draft. >=20 > Believe it or not, I personally can live with that. >=20 > -- > Eric >=20 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, May 23, 2014 11:18 AM > To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-=20 > return@tools.ietf.org > Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > Importance: High >=20 > Eric >=20 > I think the onus is on you as the objector to provide me with a=20 > pointer to a specific protocol alternative not a framework, or to show=20 > why this simple addition of four bytes will not work in the manner that I= describe. >=20 > Stewart From nobody Sun May 25 18:28:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C611A041E; Sun, 25 May 2014 18:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghtE5OorkWof; Sun, 25 May 2014 18:28:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4F11A0416; Sun, 25 May 2014 18:28:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140526012804.11562.88930.idtracker@ietfa.amsl.com> Date: Sun, 25 May 2014 18:28:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/nN3qclKnNaYj9rRihdi-GhHFfMo Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-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: Mon, 26 May 2014 01:28:06 -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 Hello Cryptographic Authentication Authors : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-06.txt Pages : 14 Date : 2014-05-24 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-hello-crypto-auth-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 Tue May 27 03:59: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 EA5341A00A6 for ; Tue, 27 May 2014 03:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9LkCe7BF6vS for ; Tue, 27 May 2014 03:59:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A9F631A0099 for ; Tue, 27 May 2014 03:59:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9609418000F; Tue, 27 May 2014 03:59:17 -0700 (PDT) To: danfrost@cisco.com, stbryant@cisco.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: <20140527105917.9609418000F@rfc-editor.org> Date: Tue, 27 May 2014 03:59:17 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gtiLG94PRJ7mXdH0eXEIKrxrRMo Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC6374 (4000) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 10:59:52 -0000 The following errata report has been submitted for RFC6374, "Packet Loss and Delay Measurement for MPLS Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6374&eid=4000 -------------------------------------- Type: Technical Reported by: Stewart Bryant Section: 3.5 Original Text ------------- Upon receipt of a query message including an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code. Corrected Text -------------- In this specification an object that is classed as mandatory is one that the responder MUST either support or respond to indicating that it does not support. Thus upon receipt of a query message including an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code. Note that the term mandatory does not indicate mandatory to implement or mandatory to send. Notes ----- In discussion on the MPLS list there was concern about the meaning of the term "mandatory" in this RFC. The use of the term is somewhat unusual in an IETF context, but the quoted original text makes it clear that there is no requirement to implement mandatory objects, only to respond to the reception of one if it is not supported. Instructions: ------------- This errata 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. -------------------------------------- RFC6374 (draft-ietf-mpls-loss-delay-04) -------------------------------------- Title : Packet Loss and Delay Measurement for MPLS Networks Publication Date : September 2011 Author(s) : D. Frost, S. Bryant Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed May 28 05:57: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 9B80F1A0986 for ; Wed, 28 May 2014 05:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-h1ZSVPGMGQ for ; Wed, 28 May 2014 05:57:31 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CABC1A0982 for ; Wed, 28 May 2014 05:57:31 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.94.254.248]) (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 4D65B18013DA; Wed, 28 May 2014 14:57:20 +0200 (CEST) Message-ID: <5385DD2B.1080106@pi.nu> Date: Wed, 28 May 2014 14:57:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: RFC Errata System , Dan Frost , stbryant@cisco.com, akatlas@gmail.com, adrian@olddog.co.uk, swallow@cisco.com, rcallon@juniper.net References: <20140527105917.9609418000F@rfc-editor.org> In-Reply-To: <20140527105917.9609418000F@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bs_g0o7UnDO2jzeFnVD-j2dPETQ Cc: mpls@ietf.org Subject: Re: [mpls] [Technical Errata Reported] RFC6374 (4000) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:57:33 -0000 Folks, I think this errata is correct. Since I was the document shepherd for RFC 6374 and Stewart is one of the authors, I don't think either of should be part of verifying the Errata, which I think fall back to Adrian. /Loa On 2014-05-27 12:59, RFC Errata System wrote: > The following errata report has been submitted for RFC6374, > "Packet Loss and Delay Measurement for MPLS Networks". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6374&eid=4000 > > -------------------------------------- > Type: Technical > Reported by: Stewart Bryant > > Section: 3.5 > > Original Text > ------------- > Upon receipt of a query message including an unrecognized mandatory > TLV object, the recipient MUST respond with an Unsupported Mandatory > TLV Object error code. > > Corrected Text > -------------- > In this specification an object that is classed as mandatory is > one that the responder MUST either support or respond to indicating > that it does not support. Thus upon receipt of a query message > including an unrecognized mandatory TLV object, the recipient > MUST respond with an Unsupported Mandatory TLV Object error > code. Note that the term mandatory does not indicate mandatory > to implement or mandatory to send. > > Notes > ----- > In discussion on the MPLS list there was concern about the meaning > of the term "mandatory" in this RFC. The use of the term is > somewhat unusual in an IETF context, but the quoted original > text makes it clear that there is no requirement to implement > mandatory objects, only to respond to the reception of one if > it is not supported. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC6374 (draft-ietf-mpls-loss-delay-04) > -------------------------------------- > Title : Packet Loss and Delay Measurement for MPLS Networks > Publication Date : September 2011 > Author(s) : D. Frost, S. Bryant > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > -- 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 May 28 07:18:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6CF1A014A; Wed, 28 May 2014 07:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmszLGXHNHHa; Wed, 28 May 2014 07:18:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B9D2D1A0141; Wed, 28 May 2014 07:18:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AABC9180204; Wed, 28 May 2014 07:18:02 -0700 (PDT) To: stbryant@cisco.com, danfrost@cisco.com, stbryant@cisco.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140528141802.AABC9180204@rfc-editor.org> Date: Wed, 28 May 2014 07:18:02 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/crh-PtJxp7J0pkZySAKP50lNfwE Cc: mpls@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Errata Verified] RFC6374 (4000) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:18:41 -0000 The following errata report has been verified for RFC6374, "Packet Loss and Delay Measurement for MPLS Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6374&eid=4000 -------------------------------------- Status: Verified Type: Technical Reported by: Stewart Bryant Date Reported: 2014-05-27 Verified by: Alia Atlas (IESG) Section: 3.5 Original Text ------------- Upon receipt of a query message including an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code. Corrected Text -------------- In this specification an object that is classed as mandatory is one that the responder MUST either support or respond to indicating that it does not support. Thus upon receipt of a query message including an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code. Note that the term mandatory does not indicate mandatory to implement or mandatory to send. Notes ----- In discussion on the MPLS list there was concern about the meaning of the term "mandatory" in this RFC. The use of the term is somewhat unusual in an IETF context, but the quoted original text makes it clear that there is no requirement to implement mandatory objects, only to respond to the reception of one if it is not supported. -------------------------------------- RFC6374 (draft-ietf-mpls-loss-delay-04) -------------------------------------- Title : Packet Loss and Delay Measurement for MPLS Networks Publication Date : September 2011 Author(s) : D. Frost, S. Bryant Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed May 28 12:23:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC71A0225 for ; Wed, 28 May 2014 12:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 DF-OcDo6JCYt for ; Wed, 28 May 2014 12:22:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9550B1A0171 for ; Wed, 28 May 2014 12:22:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEQ43188; Wed, 28 May 2014 19:22:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 20:22:17 +0100 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 20:22:49 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML702-CHM.china.huawei.com ([169.254.4.7]) with mapi id 14.03.0158.001; Wed, 28 May 2014 12:22:45 -0700 From: Huaimo Chen To: =?iso-8859-1?Q?Vitkovsk=FD_Adam?= , Autumn Liu , Yimin Shen , Ross Callon , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaKXRNui9++LYwkadb4wi40bsvZs4Na6wgB4OFeA= Date: Wed, 28 May 2014 19:22:44 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C71D50@SJCEML701-CHM.china.huawei.com> References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C66B35@SJCEML703-CHM.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EA9F4@EX01.swan.local> In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011EA9F4@EX01.swan.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.113] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C71D50SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PanLdnC0bsMtECY1_xrQshznubQ Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:23:03 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C71D50SJCEML701CHMchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adam, Thanks for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Vitkovsk=FD Adam [mailto:adam.vitkovsky@swan.sk] Sent: Friday, May 09, 2014 8:38 AM To: Huaimo Chen; Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hello Huaimo, I'd like to discuss some thoughts regarding the very much appreciated rsvp = egress protection idea. 5.2. Intermediate Node and PLR Behavior The PLR (upstream node of the primary egress) tries to get the backup egress from EGRESS_BACKUP in the egress backup descriptor list if the Path message contains the list. If the PLR can not get it, the PLR tries to find the backup egress, which is not the primary egress but has the same IP address as the destination IP address of the LSP. -maybe the procedures proposed in: Segment Routing Use Cases draft-filsfils-rtgwg-segment-routing-use-cases-02 3.2. Protecting a node segment upon the failure of its -can be leveraged to determine all the backup egress candidates for the par= ticular LSP primary egress node. Or the VPN backup label can be used to signal backup egress candidate capab= ility to the LSP head-end LSP head-end can than include this list of candidates in the EGRESS_BACKUP = object of the PATH msg. So this list can be then used by the PLR to select one or multiple best bac= kup egress nodes. The constrained SPF could be run to determine one or multiple backup egress= nodes among all the backup egress node candidates. The particular PLR can tan build backup LSPs to one or multiple backup egre= ss nodes [Huaimo]: It seems that section 3.2. in draft-filsfils-rtgwg-segment-routi= ng-use-cases-02 talks about a similar case, and provides protection against= end point failure in the context of segment routing. Regarding to determining a backup egress for a primary egress node of an LS= P, it may be given by a user through configuration; it may also be selected= /computed automatically by another component such as PCE. 5.2.2. Signaling for Facility Protection For a number of primary P2P LSPs going through the same PLR to the same primary egress, the primary egress of these LSPs may be protected by one backup LSP from the PLR to the backup egress designated for protecting the primary egress With multiple backup egress candidates: For the P2P LSPs going through the same PLR to the same primary egress node -the PLR could distribute these onto several backup egress nodes based on t= he LSP constrains satisfied by the path to each of the backup egress nodes. [Huaimo]: It seems that the facility protection is normally used to provid= e protection against link/node failure for multiple LSPs going through the = same link/node using one backup LSP (i.e., using one backup LSP to protect = multiple primary LSPs). It is also possible to use one backup LSP to protect one primary LSP agains= t a node/link failure. 5.2.4. PLR Procedures during Local Repair Moreover, the PLR lets the upstream part of the primary LSP stay after the primary egress fails. The downstream part of the primary LSP from the PLR to the primary egress SHOULD be removed. Please consider topology: [CE]$$$$[PE1]*****[P1]****[PLR]****[PE2]$$$$[CE] |-------| $ | $ [P2]------[PE3]$$$$$$$$ In the above topology for the primary path from PE1 to PE2 via P1 and PLR A backup path is built from PLR to PE3 via P1 and P2 In case the PE2 fails the traffic destined for PE2 has to go via P1 to PLR = and then back to P1 and then to P2 and PE3 In this case it is desirable for the LSP head-end PE1 to signal a new path = from PE1 to PE4 via P and PE3 [Huaimo]: This is an interesting scenario. Local protection is normally tem= porary. After receiving the notification of the failure, the ingress node o= f the LSP may re-compute a path and setup a new LSP along the path, which i= s globally optimal. Adam Vitkovsky CCIP=AE CCNP=AE Certified Network Architecture Department SWAN a.s. Borsk=E1 6, 841 04 Bratislava 4 adam.vitkovsky@swan.sk GSM: + 421 903 423 800 www.swan.sk From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Huaimo Chen Sent: Monday, May 05, 2014 11:06 PM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_5316A0AB3C851246A7CA5758973207D445C71D50SJCEML701CHMchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Adam,

 <= /p>

Thanks for your comments!

My answers/explanations are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Vitkovsk= =FD Adam [mailto:adam.vitkovsky@swan.sk]
Sent: Friday, May 09, 2014 8:38 AM
To: Huaimo Chen; Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org<= br> Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hello Huaimo,

 

I’d like to discuss some thoughts re= garding the very much appreciated rsvp egress protection idea.<= /o:p>

 

5.2. Intermediate Node and PLR Behavior

   The PLR (upstream node of the primary egress)= tries to get the backup

   egress from EGRESS_BACKUP in the egress backu= p descriptor list if the

   Path message contains the list.  If the = PLR can not get it, the PLR

   tries to find the backup egress, which is not= the primary egress but

   has the same IP address as the destination IP= address of the LSP.

 

-maybe the procedures  proposed in:

Segment Routing Use Cases
           draft-fil=
sfils-rtgwg-segment-routing-use-cases-02
           &nbs=
p;   3.2.  Protecting a node segment upon the failure of its=

 

-can be leveraged to determine all the bac= kup egress candidates for the particular LSP primary egress node.

Or the VPN backup label can be used to sig= nal backup egress candidate capability to the LSP head-end

LSP head-end can than include this list of= candidates in the EGRESS_BACKUP object of the PATH msg.<= /p>

So this list can be then used by the PLR t= o select one or multiple best backup egress nodes.  =

The constrained SPF could be run to determ= ine one or multiple backup egress nodes among all the backup egress node ca= ndidates.

The particular PLR can tan build backup LS= Ps to one or multiple backup egress nodes

 

[Huaimo]:  It seems = that section 3.2. in draft-filsfils-rtgwg-segment-routing-use-cases-02 talk= s about a similar case, and provides protection against end point failure in the context of segment routing.

Regarding to determining = a backup egress for a primary egress node of an LSP, it may be given by a u= ser through configuration; it may also be selected/computed automatically by another component such as PCE.

 <= /p>

 <= /p>

5.2.2. Signaling for Facility Protection

   For a number of primary P2P LSPs going through the same P=
LR to the
   same primary egress, the primary egress of these LSPs may=
 be
   protected by one backup LSP from the PLR to the backup eg=
ress
   designated for protecting the primary egress

 


With multiple backup egress candidates:


For the P2P LSPs going through the same PL=
R to the same primary egress node


-the PLR could distribute these onto sever=
al backup egress nodes based on the LSP constrains satisfied by the path to=
 each of the backup egress nodes.



 


 [Huaimo]: It seems =
that the facility protection is normally used to provide protection against=
 link/node
 failure for multiple LSPs going through the same link/node using one backu=
p LSP (i.e., using one backup LSP to protect multiple primary LSPs).



It is also possible to us=
e one backup LSP to protect one primary LSP against a node/link failure.


 


5.2.4. PLR Procedures during Local Repair<=
/span>


   Moreover, the PLR lets the upstream part of the primary L=
SP stay


   after the primary egress fails.  The downstream part=
 of the primary


   LSP from the PLR to the primary egress SHOULD be removed.=



 


Please consider topology:


[CE]$$$$[PE1]*****[P1]****[PLR]****[PE2]$$$$[CE]<=
/o:p>


           =
        |-------|    =
;          $<=
/o:p>


           =
        |    &n=
bsp;            =
;    $


           =
       [P2]------[PE3]$$$$$$$$ &nbs=
p;    



 


In the above topology for the primary path=
 from PE1 to PE2 via P1 and PLR


A backup path is built from PLR to PE3 via=
 P1 and P2


In case the PE2 fails the traffic destined=
 for PE2 has to go via P1 to PLR and then back to P1 and then to P2 and PE3=



In this case it is desirable for the LSP h=
ead-end PE1 to signal a new path from PE1 to PE4 via P and PE3<=
/o:p>


 


[Huaimo]: This is an inte=
resting scenario. Local protection is normally temporary. After receiving t=
he notification of the failure, the ingress node of the
 LSP may re-compute a path and setup a new LSP along the path, which is glo=
bally optimal.


 


 


Adam Vitkovsky
CCIP=AE
CCNP=AE
Cert=
ified


Network Architecture Department


SWAN a.s.


Borsk=E1 6, 841 04 Bratislava 4


adam.vitkovsky@swan.sk


GSM: + 421 903 423 800


www.swa=
n.sk


 


 


 


 


 <=
/p>

 <=
/p>







From: mpls [mailto:mpls-bounces@ietf.org]
On Behalf Of Huaimo Chen

Sent: Monday, May 05, 2014 11:06 PM

To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org

Subject: [mpls] draft-ietf-mpls-rsvp-egress-protection-00






 


Hi Autumn,


 <=
/p>

Can you elaborate a little bit on “the egress protection of p2p LS=
P needs to be addressed specifically with the draft.”?


 


Best Regards,=



Huaimo<=
/p>





From: mpls [mailto:mpls-bounces@ietf.org]
On Behalf Of Autumn Liu

Sent: Friday, March 14, 2014 9:03 PM

To: Yimin Shen; Ross Callon; mpls@i=
etf.org

Cc: mpls-chairs@tools.=
ietf.org;
dr=
aft-chen-mpls-p2mp-egress-protection@tools.ietf.org

Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad=
option draft-chen-mpls-p2mp-egress-protection-11






 


 <=
/p>

I am ok with the name cha=
nge, and agree with Yimin that the egress protection of p2p LSP needs to be=
 addressed specifically with the draft.


-Autumn=



 <=
/p>





From: mpls [mailto:mpls-bounces@ietf.org]
On Behalf Of Yimin Shen

Sent: Friday, March 14, 2014 4:14 PM

To: Yimin Shen; Ross Callon; mpls@i=
etf.org

Cc: mpls-chairs@tools.=
ietf.org;
dr=
aft-chen-mpls-p2mp-egress-protection@tools.ietf.org

Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad=
option draft-chen-mpls-p2mp-egress-protection-11






 


Hi chairs, authors,


 <=
/p>

To help make this draft m=
ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe=
rentiate the problems faced by P2MP LSPs and P2P LSPs, and also
 to discuss specifically the set of problems of P2P LSPs, which are imposed=
 by inner labels (i.e. service labels).



 <=
/p>

Of course, a complete sol=
ution for P2P LSP egress protection will require extensions to Layer-2/3 VP=
N service label distribution protocols, which may be out
 of the scope of RSVP and this draft. However, since these extensions have =
already been addressed by some existing IETF work and drafts, this draft co=
uld refer to them in the text.




 <=
/p>

Thanks,=



 <=
/p>

/Yimin<=
/p>

 <=
/p>





 
--_000_5316A0AB3C851246A7CA5758973207D445C71D50SJCEML701CHMchi_-- From nobody Wed May 28 18:05: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 C828E1A6F28 for ; Wed, 28 May 2014 18:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YNpt-0muRBJ for ; Wed, 28 May 2014 18:05:22 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e: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 1E9E51A0836 for ; Wed, 28 May 2014 18:05:22 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so12119094pbb.39 for ; Wed, 28 May 2014 18:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KKDl4puE4TySvns0oqodX33yhqnjv3k7WLdUZqiDO3o=; b=Xx/4kwg7FBLEDjyVIisPALuMKON0i9adlSQ5HAozR0FtYvxJ14/zjy6r8+6X/AkTRu iZoMWti4evAywqyxFT1nJOGi3RXipBap/vw6oqgLIdWJ2y5UXihzfTOWPPA3F+5HCFlP 7o6Re/cCGCGD1QDQGWdNbncft8LUY1b2bzZXIrxuZ2mPU4cTiBK4F6JVjMSCB0Trqi7H x3rfAMvIM36+H4AcJOJUiMDss6e7+oxfQbJJ6Z9X4qWgY9TBfpiVsw5mBoTFtZu3fQX6 CCU0INeshpkvWVhp4ZKYp2iXarRke5KNgLIb/numDLvPG0DgQyDCHxvLuDCNL34Sdmi9 wLvQ== X-Received: by 10.66.122.36 with SMTP id lp4mr4312093pab.82.1401325518452; Wed, 28 May 2014 18:05:18 -0700 (PDT) Received: from [192.168.1.6] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id vn13sm20047628pab.8.2014.05.28.18.05.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 18:05:17 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sam Aldrin In-Reply-To: Date: Wed, 28 May 2014 18:04:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52C795FE.7060801@pi.nu> To: Mach Chen , Qin Wu X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_1iwInpKCUE-Sb4PORBDI0culEE Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 01:05:24 -0000 Hi Mach and Qin, Please find response to comments embedded with ##RESP. Sorry it took a while to respond but here it is anyway. Let know if you have any further questions. We would like to make edits, = close all open items and submit a new version of the draft to complete = LC. Comments from Qin: #1 Hi, authors: Have a quick look at this draft, It is not clear to me why proxy LSR = doesn't need to wait for The result of MPLS echo rely and then send MPLS proxy ping reply? I know the draft says the receivers process the MPLS echo request, = sending their MPLS echo replies directly back to the initiator, however why bypass = proxy LSR? What about MPLS echo request initiating by proxy LSR is lost? How does = the initiator=20 know the lost of MPLS echo request or reply? What am I missing? ##RESP: LSP ping is designed with initiator initiating the request and = maintaining the state for the same. All the transit or responding router = do not maintain any state. Requiring Proxy LSRs to manage relaying the = response would require it to maintain state for the entire transaction, = including requiring the a timeout to be supplied by the initiator. This = will require the change in architecture, which this draft is definitely = not intending to do. #2 Also it is not very clear to me how to use reply mode 5, although the = draft says " If the Reply Mode of the message header is 1 or is 5 and no errors or modifications have occurred no MPLS proxy ping reply is sent. " ##RESP: There is no mention of reply mode 5. Which document are you = referring to? The document refers only to mode 1, where, no reply SHOULD = be sent for that mode. If the Reply Mode of the Proxy Request message header is "1 - do not reply", no MPLS proxy ping reply is sent. Otherwise an MPLS proxy ping reply message or MPLS echo request should be sent as described below. #3 It looks to me if no MPLS proxy ping rely needs to be sent, why define = reply mode 5? ###RESP: No mention of reply mode 5. If you are referring to reply mode = 1, the question is for RFC4379. All I can say is, it is there to check = unidirectional errors.=20 #4 Also there are a lot of nits and typos that need to be fixed, s/ limiting the the number/ limiting the number s/ motivaton/ motivation s/ and and all autho-rization/ and all authorization s/ Pprocedures/ Procedures s/ sub-objexts/ sub-objects s/ modificatons /modifications s/ decribed/ described s/ assigments/assignments ##RESP: Ack #5 In section 5.2, there is no definition of reply to address field, I = think it should be defined as initiator address ##RESP: This is the address the echo reply should be sent to, most = likely the initiator, but could be something else. We will add text for = the field. #6 For Downstream Mapping objects, it is better to add a reference to = RFC4379. The references [McstPing] [mLDP] are now outdated and need to be updated = to the corresponding RFC. ##RESP - Ack. Will add references. Regards! -Qin =20 =3D=3D=3D=3D=3D=3D 2) =46rom Mach Chen Hi Authors, I just reviewed the draft, here are my comments, hope this help. General comments: It would be better if you could adjust the structure of the draft to put = Section 3 behind Section 5. Then the reader will not need to check = definitions of the Messages and TLVs in the back and then return back = keep reading the document. ##RESP - I feel it is good to have description before the actual format = definition. Either case, one has to go back and forth to understand = completely. Is there any hard preference to your suggestion? Specific comments: 1. Section 2 If the source address of the MPLS echo request is not to be set to the Proxy Request source address, the initiator must include a Reply-to Address TLV containing the source address to use in the MPLS echo request. Why we need the Reply-to Address TLV? Which address will be included in = the Reply-to Address TLV? If the address is neither the initiror or the = proxy LSR, this may import some security isses? ##RESP: We added this TLV for a reason, which at that time, was needed. = =46rom what we see now, the requestor IP will be used. Hence, this TLV = will be removed. 2. Section 3.1 2.1=20 "The message MUST contain a Target FEC Stack that describes the FEC being tested. The topmost FEC in the target FEC stack is used at the Proxy LSR to lookup the MPLS label stack that will be used to encapsulate the MPLS echo request packet. " Seems that it only needs to carry the topmost FEC, and no need to carry = other FECs. And even if carried, it does not make sense. Right? ##RESP: reused existing target fec stack, don=92t want to restrict to = topmost FEC in case there are future uses.=20 2.2 =20 s /MPLS Proxy Ping message/MPLS proxy ping request message, need to look = through the document to make them consistent.=20 ##RESP - Ack. 3. Section 3.1 the sixth paragraph: "The Proxy Request reply mode is set with one of the reply modes defined in [RFC4379] as appropriate." Is the reply mode here referred to the reply mode of the MPLS proxy = request, or the reply mode of the Proxy Echo Parameter. I think it's the = former, right?=20 And section 5.1 said: "The MPLS Proxy Echo request echo header's Reply Mode should be set to = "Reply with Proxy Info"." Seems they are self-contradictory here.=20 ##RESP - Not really. Sec 3 is describing the reply mode should use one = of the modes defined in RFC4379. While Sec 5.1 is talking about the = request to query info from proxy LSR. 4. Section 3.1 the last second paragraph: s /DDSMAP)/(DDSMAP) ##RESP - Ack 5. Section 3.2, in the middle of the fourth paragraph. "Other filters on FECs or MPLS echo request contents MAY be applied." For a Proxy LSR, it will not receive any MPLS echo request, should it be = the MPLS proxy ping request here? ##RESP: The sentence is talking about proxy LSR sending MPLS echo = request, not receiving. 6. Section 3.2.1 6.1 In the middle of third paragraph: "If the Proxy LSR is a Budnode but not requested to return a Proxy reply, the Proxy LSR should send packets to the downstream neighbors (no Echo reply is sent to the Proxy Initiator to indicate that the Proxy LSR is an egress). =20 " What packets will be sent to the downstream neighbors? ##RESP: =93MPLS Echo Request=94 6.2=20 If there is no DS/DDMAPs returned, how does the initiator determine the = proxy LSR is budnode or egress? ##RESP: wanted to have the same behavior when injecting a LSP Ping at an = egress. When we ping from a bud node, if we don=92t typically get an = echo reply from ourselves, so we wanted to provide the ability for the = Proxy requester to decide whether they want a proxy reply to by send = back in response to a proxy request. is_egress return code used to = indicate proxy lsr also an egress. 6.3 Last paragraph, last sentence s / M2MP leaf /MP2MP leaf ##RESP - ack 7. Section 3.2.4.1 7.1 What's is "base MPLS echo request"? I suggest to remove the "base" = here. ##RESP: Seems fine to remove. 7.2=20 "If the Explicit Differentiated Services Code Point (DSCP) flag is set, the Requested DSCP byte is examined. If the setting is permitted then the DSCP byte of the IP header of the MPLS Echo Request message is set to that value. If the Proxy LSR does not permit explicit control for the DSCP byte, the MPLS Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be included in any MPLS proxy ping reply message to indicate why an Echo Request was not sent. The return code MUST be set to , "Proxy ping parameters need to be modified". If the Explicit DSCP flag is not set, the Proxy LSR should set the Echo Request DSCP settings to the value normally used to source LSP ping packets." I am not sure whether this is the right choice to let the Proxy LSR to = control whether the DSCP is permitted or not. IMO, this permission = should be controlled by the Receiver or Responder. ##RESP: This section is referring to the DSCP settings in the MPLS echo = request label stack and ip header not the reply dscp. When initiating = LSP pings, the sender of the lsp ping controls this setting, so it was = felt that it be valuable to allow the sender of the proxy request to = control this subject to restrictions imposed at the Proxy LSR. 8. Section 3.2.4.2 "If any additional labels are pushed onto the stack, their TTLs are set to 255." what's this case? Can you clarify more about the case? ##RESP: Don=92t want to requester have have control of the ttls for = tunnels not relevant to the FEC being tested. 9. Section 4.2 " The MPLS proxy ping request message MAY contain the following TLVs: " You may also need to contain the Type 21 and 22 TLV. ##RESP: okay, we=92ll add these tlv=92s to the list of tlv=92s to be = included in the proxy request for including into the echo requests. 10.Section 5.1 s /MPLS Proxy Echo Request message /MPLS proxy ping request message, = same as the above comment 2.2 ##RESP - ack Best regards, Mach Cheers -sam >=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Saturday, January 04, 2014 1:03 PM >> To: mpls@ietf.org >> Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org >> Subject: [mpls] Working group last call on = draft-ietf-mpls-proxy-lsp-ping >>=20 >> Working Group, >>=20 >> this is to start a two week working group last call on >> draft-ietf-mpls-proxy-lsp-ping-01.txt >>=20 >> Please send your comments to working group mailing lists = (mpls@ietf.org). >>=20 >> We will do an IPR poll on this document in parallel thee wglc. >>=20 >> There are three IPRs disclosures that relates to this document. >>=20 >> The working group last call will end Friday January 20, 2914. >>=20 >> /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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From nobody Thu May 29 04:26: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 5ADED1A08BD; Thu, 29 May 2014 04:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8THKk2GNCMUV; Thu, 29 May 2014 04:26:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB141A01B3; Thu, 29 May 2014 04:26:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529112647.10193.53341.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 04:26:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/j-Xb9j-nezyL69v0K_TSFbaYtUo Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-psc-updates-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, 29 May 2014 11:26:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Updates to MPLS Transport Profile Linear Protection Author : Eric Osborne Filename : draft-ietf-mpls-psc-updates-06.txt Pages : 11 Date : 2014-05-29 Abstract: This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC6378. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-psc-updates-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-psc-updates-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 Thu May 29 05:06: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 05BB01A08D3; Thu, 29 May 2014 05:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnRsV0G2HNmt; Thu, 29 May 2014 05:06:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8741A0687; Thu, 29 May 2014 05:06:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529120641.32258.9.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 05:06:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4MvtHfmTPGJkxkH6kfjJIBpnuLg Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-extended-admin-group-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:06:45 -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 : Extended Administrative Groups in MPLS-TE Author : Eric Osborne Filename : draft-ietf-mpls-extended-admin-group-07.txt Pages : 7 Date : 2014-05-29 Abstract: MPLS-TE advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS (RFC5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-extended-admin-group-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-extended-admin-group-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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 29 07:02: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 DC05A1A08F1; Thu, 29 May 2014 07:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmzBzRXZb1bm; Thu, 29 May 2014 07:02:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D89A1A094A; Thu, 29 May 2014 07:02:12 -0700 (PDT) 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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529140212.1275.78468.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 07:02:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hrvO7R0Egj4OH8HfmSz6ZWTinWc Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Updates to MPLS Transport Profile Linear Protection' to Proposed Standard (draft-ietf-mpls-psc-updates-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, 29 May 2014 14:02:16 -0000 The IESG has approved the following document: - 'Updates to MPLS Transport Profile Linear Protection' (draft-ietf-mpls-psc-updates-06.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-psc-updates/ Technical Summary This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC6378. Working Group Summary The document was well reviewed in the working group and by ITU-T SG15 experts. There is a general agreement that these updates of RFC 6378 is necessary. The working group process were smooth, the document were reviewed by he MPLS Review Team. There have been no controversies, but some constructive discussion on what should go in this document and what belongs in draft-ietf-mpls-tp-psc-itu. Document Quality There are implementations of RFC 6378, that is why this update is urgent. We know that the implementations we know have included the updates specified in this document, in fact this is where the updates originated. The document received several reviews during IETF last call and some updates were made arising from the GenArt review of draft-ietf-mpls-tp-psc-itu Personnel Adrian Farrel is the responsible AD. Loa Andersson is the document Shepherd. From nobody Thu May 29 07:12: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 7A24C1A097C; Thu, 29 May 2014 07:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIiovrdfoULL; Thu, 29 May 2014 07:12:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 961FC1A0981; Thu, 29 May 2014 07:12:36 -0700 (PDT) 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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529141236.14802.30127.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 07:12:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mRvNRCqLkUAn7GTFT6CQOdDoW98 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Extended Administrative Groups in MPLS-TE' to Proposed Standard (draft-ietf-mpls-extended-admin-group-07.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:12:46 -0000 The IESG has approved the following document: - 'Extended Administrative Groups in MPLS-TE' (draft-ietf-mpls-extended-admin-group-07.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-extended-admin-group/ Technical Summary MPLS-TE advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV of the Link TLV. This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS (RFC5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. Working Group Summary There is a general agreement in the working group that this is needed. There have been comments during the discussion in the working group and the working last call, but all them contributing to improving the document. Document Quality Currently we are aware of one commercial implementation. Personnel Adrian Farrel is the Responsible AD. Loa Andersson is the document shepherd From nobody Thu May 29 09:22: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 12CBE1A0459 for ; Thu, 29 May 2014 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1br9kcqrN6l6 for ; Thu, 29 May 2014 09:22:47 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6D81A0177 for ; Thu, 29 May 2014 09:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10796; q=dns/txt; s=iport; t=1401380564; x=1402590164; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=boI28SobxCNL7H6N3tZNjDqAsUTv6/SbshKwlfqyFlc=; b=Wb0sGdLvphCaJWITFW0/jaiRTHLmS8rc0hJ57Y3zDeUBlYHwzXUpq0k5 xmMULiXGXRCdvg4o055O1/Iof4mneBEGAMhXKCw1CJ1y+O4WoHaEbLhTK +qbSan0Mt//GqRZO4hMUAjS0+M2og9wU+wnN4rl1x5aRLn7s65x0qCfkO U=; X-IronPort-AV: E=Sophos;i="4.98,934,1392163200"; d="scan'208";a="328921416" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 29 May 2014 16:22:43 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4TGMhfG024962; Thu, 29 May 2014 16:22:43 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id EC46B4E; Thu, 29 May 2014 12:22:42 -0400 (EDT) From: Eric Rosen To: Mach Chen In-reply-to: Your message of Fri, 16 May 2014 06:46:52 -0000. Date: Thu, 29 May 2014 12:22:42 -0400 Message-ID: <30111.1401380562@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/U_R7Nd3SbpEGkFDPPjl-3h62V9w Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:22:50 -0000 Mach> My point is that the distribution mechanisms should be defined in Mach> separate documents I don't think anyone is really concerned right now with the number of documents used to define the "source label" mechanisms. The issue at hand is whether the "source label" proposal is architecturally sound. Any proposal that uses scoped identifiers has to provide mechanisms that prevent the identifiers from leaking out of their intended scope, either via the control plane or the data plane. Right now there is no draft or set of drafts that we can look at to see how the scoping is enforced. The source-label draft is just one piece of the architecture, and I don't think it can be accepted until we can determine whether the architecture can be completed. If one looks at the two proposed distribution mechanisms for which there are internet drafts (draft-chen-isis-source-label and draft-chen-ospf-source-label), we see that these two proposals only distribute the labels within a single IGP domain. Since the scope of a source label is not restricted to a single IGP domain, we can conclude that these two proposals are not, by themselves, adequate. The drafts also don't seem to have any procedures for dealing with the case where two nodes advertise the same source label. Mach> There may need other solutions (e.g., BGP extensions) for the Mach> distribution in that case. This should be discussed when we start to Mach> define the distribution mechanisms. I think we need to see the proposal for the BGP extensions before the source-label draft can be considered. That is, I don't think the WG should accept the SL draft until some progress has been made in defining the distribution mechanisms. Xiaohu> the SL advertisement could be done by a centralized mapping server Sure, one could imagine a provisioning system that knows exactly which egress LSRs need to know the source labels for which ingress LSRs, and would provision the LSR accordingly. However, unless the draft is going to say that source labels MUST NOT be used unless there is such provisioning system, this doesn't really help. Also, this doesn't address the issue of source labels in the data plane leaking outside the domain. Eric> The ingress would have know, not only that the egress is capable of Eric> processing the source label, but that the egress will interpret the Eric> source label in the proper scope. The draft doesn't address the issue Eric> of how to ensure that ingress and egress agree on the intended scope Eric> of the label. Mach> For single domain case, the SLC will be only exchanged among the LSRs Mach> within the domain, when the ingress knows the egress can support SLC, Mach> it implicit indicates that the egress will interpret the SL in the Mach> same scope of itself. Mach> Actually, even for multiple domains, it is still the case, since SL Mach> will be used across domains, the SL space should be shared by the Mach> domains. The question is, how does the ingress LSR know that the egress LSR is in the same domain, or in a domain that shares the same SL space? I think you're assuming that the capability advertisement from the egress will not cross the domain boundary. Given that assumption, if an ingress LSR sees an SL capability advertisement from an egress LSR, the ingress could assume that the egress is in the same domain. However, the SLC signaling mechanisms described in the draft do not prevent the SL Capability signal from crossing a domain boundary. On the contrary, the mechanisms described in the draft will cause the SLC to be signaled from egress to ingress with no regard for domain boundaries. Consider, for instance, the LDP extensions. From section 6.1.1: "If all the advertised Mappings for F include the SLC TLV, then X MUST advertise its Mapping for F with the SLC TLV." This will cause the SLC to go from egress to ingress, with no regard for domain boundaries. Perhaps the above should say "MAY advertise", and should have some discussion of policy. Section 6.1.2 proposes a BGP path attribute to signal the SL Capability: "When Border Gateway Protocol (BGP) [RFC4271] is used for distributing Network Layer Reachability Information (NLRI) as described in, for example, [RFC3107], [RFC4364], the BGP UPDATE message may include the SLC attribute as part of the Path Attributes. This is an optional, transitive BGP attribute of value TBD3. The inclusion of this attribute with an NLRI indicates that the advertising BGP router can process Source Labels as an egress LSR for all routes in that NLRI. ... Suppose a BGP speaker T receives an UPDATE U with the SLC attribute. T has two choices. T can simply re-advertise U with the SLC attribute if either of the following is true: B1: T does not change the NEXT_HOP attribute OR B2: T simply swaps labels without popping the entire label stack and processing the payload below." Note that if the SLC attribute is an optional transitive attribute, then if T does not understand this attribute, T will pass it along even if conditions B1 and B2 do not hold. (Perhaps the attribute needs to be non-transitive.) B2 is a little hard to understand. Let P be the prefix in the NLRI of update U. I think the intention is that the SLC attribute be left on by T if each of T's installed routes to P has the SLC attribute. (B2 as written seems to be about the data plane, but the context of this section is the control plane.) Even if B1 does hold, it may still be incorrect for router T to pass along the SLC. For example, suppose the data path from R1 to R2 is as follows: R1---ASBR1---ASBR2---R2 but suppose that R1 and R2 exchange VPN routes through a different path: R1---T1---T2---R2 where T1 and T2 aren't in the data path at all. This could occur in an "option C" type of interconnect. (RFC4364 section 10 option c.) Suppose that R1 and R2 are in different domains. T1 and T2 would leave the next hop unchanged. When R1 has data to send to P, it would find R2 to be the next hop, and then would do recursive route resolution to find that ASBR1 is its next hop to R2. In this scenario, R1's route to P would have the SLC attribute, but R2 would not properly interpret R1's source label. To make this work at all, you'd have to mandate that the SLC attribute be attached to a route that travels along the data path (i.e., goes through the ASBRs), and there would have to be policy at the ASBRs that strips off the SLC if the ASBRs are at a domain boundary. The proper behavior when recursive route resolution is done would also have to be specified. I'm having some trouble understanding the following paragraph from the draft: "However, if T changes the NEXT_HOP attribute for U and in the data plane pops the entire label stack to process the payload, T MAY include an SLC attribute for UPDATE U' if both of the following are true:" C1: T sets the NEXT_HOP attribute of U' to itself AND C2: T can process source labels. Otherwise, T MUST remove the SLC attribute." The term UPDATE U' doesn't appear to have been defined anywhere, though I assume this is meant to be the update you get when you take Update U and change the next hop. Does the phrase "and in the data plane pops the entire label stack to process the payload" mean that T is the egress LSR for the prefix in U's NLRI? If so, I don't think this entire paragraph is needed, as T will be originating an Update for that prefix, and will include the SLC attribute if necessary. Eric> With no structure and no "domain identifier" in the source label, it Eric> is very easy end up with non-unique labels within a domain. Mach> There are also many non-structure cases, for example, Router ID, Mach> Segment ID, VE ID of BGP VPLS Mach> (http://tools.ietf.org/html/rfc4761#section-3.4.4 ), they work fine. I have to admit that I have always regarded the VPLS VE IDs as a very bad idea. However, they do have a well-defined scope, namely a single VPLS. RT-based mechanisms are used to constrain their distribution so that they don't leak unintentionally into other VPLSes. And the VE IDs do not appear in the data packets. These characteristics make it possible to get away with an unstructured identifier space. SLs don't seem to have a well-defined scope, or a well-defined distribution mechanism, and they do get carried by data packets. Leakage out of the intended domain is thus much more of a problem. So I don't think SLs can be compared to VPLS VE IDs. With regard to router ids, if you've ever followed any of the vituperative discussions that arise when router ids are discussed (e.g., when discussing whether a 32-bit id is appropriate for an IPv6-based protocol), you'll see that there are quite a few issues in the management of that numbering space. Mach> In addition, even for your RT example, for L3VPN inter-AS scenario, Mach> the RT has to be considered as single space, the domain identifier Mach> does not help here. RTs are structured so that a SP can allocate RT values that are globally unique, not just unique within a domain. So a "domain identifier" is not needed. I believe it is true that some SPs use RTs that are not globally unique, but that is a choice they have made for themselves, not a choice that is forced upon them by the architecture. Eric> One might also ask why there is a need to use a 20-bit label to Eric> identify a node, instead of using some other format. Mach> We are talking about identifying the source of an LSP, and the label Mach> stack is the MPLS header and there are only labels, then seems that a Mach> label to identify the ingress LSR is a naturally choice. A couple of other possibilities come readily to mind: - Treat the SLI as the bottom of the stack, and follow it with a 32-bit address (or even a 128-bit address) of the ingress. (Or maybe use something based on the "generic associated channel".) - Use two label stack entries and stuff a 32-bit "router id" in them, using more per-packet overhead but eliminating the need to manage a 20-bit domain-wide numbering space. But perhaps the use case is easier to implement if the SL fits into the same 20 bits usually used for labels. If so, that would be worth mentioning. With regard to the name, Xiaohu> What about IIL (Ingress Identification Label)? I do like that better. However, getting all the details right is going to be a lot of work, especially for something that has only one use case, and a controversial one at that. From nobody Thu May 29 16:26: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 5FA041A06E5; Thu, 29 May 2014 16:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtlWN8_wPvCW; Thu, 29 May 2014 16:25:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B990D1A030D; Thu, 29 May 2014 16:25:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C5D84180093; Thu, 29 May 2014 16:25:15 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140529232515.C5D84180093@rfc-editor.org> Date: Thu, 29 May 2014 16:25:15 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/P0y33G9w4sPqZdvGYEQGV7JspZ4 Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7214 on Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 23:25:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7214 Title: Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry Author: L. Andersson, C. Pignataro Status: Standards Track Stream: IETF Date: May 2014 Mailbox: loa@mail01.huawei.com, cpignata@cisco.com Pages: 7 Characters: 12382 Updates: RFC 5586, RFC 6374, RFC 6378, RFC 6427, RFC 6428 I-D Tag: draft-ietf-mpls-moving-iana-registries-04.txt URL: http://www.rfc-editor.org/rfc/rfc7214.txt RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586. This document also updates RFCs 6374, 6378, 6427, and 6428. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu May 29 17:22: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 3F4101A06AC for ; Thu, 29 May 2014 17:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jW5AUbBWEu8n for ; Thu, 29 May 2014 17:21:55 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683A41A02B5 for ; Thu, 29 May 2014 17:21:55 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-40-53877ef4bbd5 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 49.4F.27529.4FE77835; Thu, 29 May 2014 20:39:49 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Thu, 29 May 2014 20:21:49 -0400 From: Autumn Liu To: Huaimo Chen , Yimin Shen , "Ross Callon" , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaSWCEEuEYsttJkWkfWQejQJT9Zs3aVgQgAnfm4CAFxqR0A== Date: Fri, 30 May 2014 00:21:49 +0000 Message-ID: References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C66C94@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C68100@SJCEML703-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C68100@SJCEML703-CHM.china.huawei.com> Accept-Language: zh-CN, 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_E4F89EAEF1386F42AA8E6FB5C35399A61C14A994eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt+7XuvZgg4U7hS22Pr3CaHFr6UpW i78rrrBYbF/+jcWBxaPlyFtWjyVLfjJ5XG+6yh7AHMVlk5Kak1mWWqRvl8CVcbx/NUvB1v+M FesabrI1MO59yNjFyMEhIWAi8WtlURcjJ5ApJnHh3no2EFtI4CijxL73dl2MXED2ckaJ9ZNf sIAk2AS0JPbtf8cOkhARmMAo8fLPVXaQQcICZhKb31uB1IgImEtcu3CADcJ2kvj94Tk7iM0i oCqx7vwKMJtXwFdixo23zBDLlrFK9L6NARnDKRAmMWGJMEiYUUBWYtqj+0wgNrOAuMStJ/OZ IO4UkFiy5zwzhC0q8fLxP1YIW0li0tJzrBD1+RIzmz+wQKwSlDg58wnLBEaRWUhGzUJSNgtJ GURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqWm25ksIkRGFvHJNh0dzDueWl5 iFGAg1GJh1eBtT1YiDWxrLgy9xCjNAeLkjiv9s2qYCGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MvP2tYY2LGP/N132Zc8TixPofd9y7ZKfUTw3NjPSe3xYTVS9ooXCqNPo557tVCp0Tg3ru /3622EikdLLfE5nIo2cv1J7PWxswbcvf1h+vMyLFX+f57RBn2tYd2hhnGbZV5PTTBVcUFvyf vfYxlyp/2Luf9jPLHzrdOF6+O69kxZnFP+JPFWxNUmIpzkg01GIuKk4EAFu/ZaSOAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/WEe6KKS3T7lRUqUPM23F9UaI3h4 Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:22:01 -0000 --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C14A994eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, Thanks for your reply. Please see my comments inline. -Autumn From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Wednesday, May 14, 2014 8:17 PM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Thanks for your questions! My answers are inline below. Best Regards, Huaimo From: Autumn Liu [mailto:autumn.liu@ericsson.com] Sent: Thursday, May 08, 2014 8:44 PM To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Huaimo, I have some questions. 1) How Inner label (vpn label) acquired on primary egress node is sent= to backup egress node? Via PATH message for backup LSP? which object is us= ed? How this label is processed? How this label is maintained? [Huaimo] An inner label (such as VPN label) allocated on the primary egress= node may be sent to the backup egress node in one of a few ways. One way i= s to use BGP to send the inner label to the backup egress node from the pri= mary egress node. Alternatively, the inner label may be sent from the prima= ry egress node to the upstream node of the primary egress node through an E= GRESS-BACKUP object in RESV message and then the upstream node sends the in= ner label to the backup egress node via an EGRESS-BACKUP object in the PAT= H message for the backup LSP. When the backup egress node receives the inne= r label as a UA label originally from the primary egress, it adds a forward= ing entry with the label into the LFIB for the primary egress node. When th= e backup egress node receives a packet from the backup LSP, it uses the top= label as a context label to find the LFIB for the primary egress node and = the inner label to deliver the packet to the same destination as the primar= y egress node according to the LFIB. Note that exactly how the inner label is sent from the primary egress node = to the backup egress node is out of scope for this document. I understand that this is out of scope of this document, but it is still no= t clear to me how inner label is going to be processed, maintained and prog= rammed. If bgp is used to send the inner label from primary egress node to = backup egress node, how bgp know there is backup egress node? Even this is = possible, the egress protection on the rsvp level should make this transpar= ent to bgp and any other applications using rsvp. If the alternative way yo= u described is used, it seems that rsvp will program a bgp entry in forward= ing plane, I don't think this is desired behavior either. 2) How PLR can acquire a path to backup egress node, its address is th= e same as primary egress node? [Huaimo] PLR gets the backup egress node first and then computes a path fro= m the PLR to the backup egress node. The backup egress node may be configur= ed by an operator on the ingress of the primary LSP. If it is configured, t= he ingress will include the backup egress node in the PATH message through = using EGRESS_BACKUP object. If the backup egress node is not given by the o= perator, the PLR tries to find the backup egress node, which is not the pri= mary egress node but has the same IP address as the destination IP address = of the LSP. Note that the primary egress node and the backup egress node S= HOULD have a same local address configured, and the cost to the local addre= ss on the backup egress node SHOULD be much bigger than the cost to the loc= al address on the primary egress node. The question is not about knowing the backup egress node, it is how to get = a route to backup egress node given the fact that the backup egress node ha= s the same address of the primary egress node. 3) Does PLR sends the PATH message for primary LSP to backup egress no= de? [Huaimo] No. Then how the state of primary LSP on upstream node of the primary egress no= de is maintained after failure occurs? Thanks, Autumn From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, May 06, 2014 5:20 AM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, It is not clear for me what you mean with "the egress protection of p2p= LSP needs to be addressed specifically with the draft." Can you please supply some text that addresses the issue(s) you mention= ed. Best Regards, Huaimo From: Huaimo Chen Sent: Monday, May 05, 2014 5:05 PM To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org Subject: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C14A994eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

 

Thanks for your reply. Plea= se see my comments inline.

-Autumn

 <= /p>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Wednesday, May 14, 2014 8:17 PM
To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Autumn,

 <= /p>

Thanks for your questions!

My answers are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Autumn L= iu [mailto:autumn.liu@ericsson.c= om]
Sent: Thursday, May 08, 2014 8:44 PM
To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Huaimo,

 

I have some questions.

1= )   &= nbsp;  How Inner label (vpn label) acq= uired on primary egress node is sent to backup egress node? Via PATH messag= e for backup LSP? which object is used? How this label is processed? How this label is maintained?

[Huaimo] An inner label (= such as VPN label) allocated on the primary egress node may be sent to the = backup egress node in one of a few ways. One way is to use BGP to send the inner label to the backup egress node from the primary egr= ess node. Alternatively, the inner label may be sent from the primary egres= s node to the upstream node of the primary egress node through an EGRESS-BA= CKUP object in RESV message and then the upstream node sends the inner label to the backup egress node via=  an EGRESS-BACKUP object in the PATH message for the backup LSP. When= the backup egress node receives the inner label as a UA label originally f= rom the primary egress, it adds a forwarding entry with the label into the LFIB for the primary egress node. When the b= ackup egress node receives a packet from the backup LSP, it uses the top la= bel as a context label to find the LFIB for the primary egress node and the= inner label to deliver the packet to the same destination as the primary egress node according to the LFIB. =  

Note that exactly how the= inner label is sent from the primary egress node to the backup egress node= is out of scope for this document.

 <= /p>

I understand that this is o= ut of scope of this document, but it is still not clear to me how inner lab= el is going to be processed, maintained and programmed. If bgp is used to send the inner label from primary egress node to backup = egress node, how bgp know there is backup egress node? Even this is possibl= e, the egress protection on the rsvp level should make this transparent to = bgp and any other applications using rsvp. If the alternative way you described is used, it seems that rsvp wil= l program a bgp entry in forwarding plane, I don’t think this is desi= red behavior either.

 

2) &= nbsp;    How PLR can acquire= a path to backup egress node, its address is the same as primary egress no= de?

[Huaimo] PLR gets the bac= kup egress node first and then computes a path from the PLR to the backup e= gress node. The backup egress node may be configured by an operator on the ingress of the primary LSP. If it is configured, the in= gress will include the backup egress node in the PATH message through using= EGRESS_BACKUP object. If the backup egress node is not given by the operat= or, the PLR tries to find the backup egress node, which is not the primary egress node but has the same IP addr= ess as the destination IP address of the LSP.  Note that the primary e= gress node and the backup egress node SHOULD have a same local address conf= igured, and the cost to the local address on the backup egress node SHOULD be much bigger than the cost to the local= address on the primary egress node.

 <= /p>

The question is not about k= nowing the backup egress node, it is how to get a route to backup egress no= de given the fact that the backup egress node has the same address of the primary egress node.

 

3) &= nbsp;    Does PLR sends the = PATH message for primary LSP to backup egress node?

[Huaimo] No.

 <= /p>

Then how the state of primary LSP on up= stream node of the primary egress node is maintained after failure occurs?<= o:p>

Thanks,

Autumn

 <= /span>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Tuesday, May 06, 2014 5:20 AM
To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Autumn,

 

    It is not clear for me what yo= u mean with “the egress protection of p2p LSP needs to be addressed s= pecifically with the draft.”

    Can you please supply some tex= t that addresses the issue(s) you mentioned.

 

Best Regards,

Huaimo

From: Huaimo C= hen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: draft-ietf-mpls-rsvp-egress-protection-00=

 

Hi Autumn,

 <= /p>

Can you elaborate a little bit on “the egress protection of p2p LS= P needs to be addressed specifically with the draft.”?

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

 <= /p>

I am ok with the name cha= nge, and agree with Yimin that the egress protection of p2p LSP needs to be= addressed specifically with the draft.

-Autumn=

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

Hi chairs, authors,<= /o:p>

 <= /p>

To help make this draft m= ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe= rentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed= by inner labels (i.e. service labels).

 <= /p>

Of course, a complete sol= ution for P2P LSP egress protection will require extensions to Layer-2/3 VP= N service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have = already been addressed by some existing IETF work and drafts, this draft co= uld refer to them in the text.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 

--_000_E4F89EAEF1386F42AA8E6FB5C35399A61C14A994eusaamb103erics_-- From nobody Thu May 29 19: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 B4E181A077F; Thu, 29 May 2014 19:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud-8ffvk8u7E; Thu, 29 May 2014 19:10:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 444601A0721; Thu, 29 May 2014 19:10:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140530021024.7021.55736.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 19:10:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PepCFEJR5yzf3JuSMZHZj6w6MsQ Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-07.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, 30 May 2014 02:10:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Hello Cryptographic Authentication Authors : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-07.txt Pages : 14 Date : 2014-05-29 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-hello-crypto-auth-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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 30 06:27: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 EFCC11A6F62 for ; Fri, 30 May 2014 06:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JivGMT9qy9TN for ; Fri, 30 May 2014 06:27:12 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704211A6FF3 for ; Fri, 30 May 2014 06:27:12 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.94.254.248]) (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 73B7D1801294; Fri, 30 May 2014 15:27:05 +0200 (CEST) Message-ID: <53888725.1050907@pi.nu> Date: Fri, 30 May 2014 15:27:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "" References: <20140530021024.7021.55736.idtracker@ietfa.amsl.com> In-Reply-To: <20140530021024.7021.55736.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140530021024.7021.55736.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/prOapton6qpWJaB8ZoXO61SNXrE Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org" Subject: [mpls] New version of draft-ietf-mpls-ldp-hello-crypto-auth-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: Fri, 30 May 2014 13:27:14 -0000 Working Group, During the IANA review of draft-ietf-mpls-ldp-hello-crypto-auth we discovered what Adrian call a snafu*. The document assigns a new LDP TLV and the text in most of document is correct, however in the IANA section we did not point to the LDP TLVs, but to LSP Ping TLVs. This has been corrected in the new version. The document shepherd (me) and the responsible AD (Adrian) has discussed this and agree that this is minor and we don't need to issue a new wglc. /Loa * Note: I'm considering asking Adrian to explain the meaning of "snafu", at e.g. the rtgwg meeting next IETF. For the time being my understanding is that snafus is nothing that we want in our documents, or a word that the RFC Editor under normal circumstances would allow us to use. -------- Original Message -------- Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-07.txt Date: Thu, 29 May 2014 19:10:24 -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 directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Hello Cryptographic Authentication Authors : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-07.txt Pages : 14 Date : 2014-05-29 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-hello-crypto-auth-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.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 Fri May 30 10:13: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 E32B81A09F1; Fri, 30 May 2014 10:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aae53OY_D7n; Fri, 30 May 2014 10:13:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F091A011D; Fri, 30 May 2014 10:13:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140530171341.29039.39097.idtracker@ietfa.amsl.com> Date: Fri, 30 May 2014 10:13:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dTV0gi29OXNpBpNAZAaZjp-IygI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-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: Fri, 30 May 2014 17:13: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 : Requirements for MPLS-TP Shared Mesh Protection Authors : Yaacov Weingarten Sam Aldrin Ping Pan Jeong-dong Ryoo Greg Mirsky Filename : draft-ietf-mpls-smp-requirements-05.txt Pages : 14 Date : 2014-05-30 Abstract: This document presents the basic network objectives for the behavior of shared mesh protection (SMP) which are not based on control plane support. This is an expansion of the basic requirements presented in RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This document is to be used as a basis for the definition of any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-smp-requirements-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 Fri May 30 10:21: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 3BDF11A09CE for ; Fri, 30 May 2014 10:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKDd1YCzRxPo for ; Fri, 30 May 2014 10:21:17 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5673A1A09CC for ; Fri, 30 May 2014 10:21:17 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so1916772pad.23 for ; Fri, 30 May 2014 10:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=8AVfJoHQB69FqkpZe3PjbefnovKEPK5bT3Y3ByLqD9M=; b=vUmR0NGhl2u7nNJqezDOQXhETz+hjk+omvu8xDt3VlSdkyd2lt4/tIajV1pbngXoWR HV7eoSGYw9NR412A33h+yawF+DbTaniy+OKo4p71kjPE8tNV31m83Kr7r70SZgbZYqSe LCkMeBIpPyOjO+5DF5At52n3I+4HZEcZD8bNvIte4Rq4Iz9Xa03E/7zX3PPwovZsdFot QblfqfFJctsohK1zNEiqjD7LnL7BpD3qD4pOhaDldb0+Zt/7k4B9MTmPx5FP82g+VveG S9NeoK3NOuivy8mPPPhwidTCwOhPleOKPuvbw1Dij4PoTpHkRpiXysx0iFfajkdMO8mF a1SQ== X-Received: by 10.68.254.5 with SMTP id ae5mr20116281pbd.83.1401470473109; Fri, 30 May 2014 10:21:13 -0700 (PDT) Received: from [192.168.1.6] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id fk4sm21369401pab.23.2014.05.30.10.21.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 10:21:12 -0700 (PDT) From: Sam Aldrin Content-Type: multipart/alternative; boundary="Apple-Mail=_0C8C9906-876E-463C-B46B-798B9E0689EA" Message-Id: <6D64F584-7079-49A7-8807-A21146918CE6@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Fri, 30 May 2014 10:21:10 -0700 References: <20140530171341.29039.39097.idtracker@ietfa.amsl.com> To: mpls , mhartley@cisco.com X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2rZTEe0tD7jcV3-LwI2KoF10JVI Cc: draft-ietf-mpls-smp-requirements@tools.ietf.org Subject: [mpls] Fwd: I-D Action: draft-ietf-mpls-smp-requirements-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: Fri, 30 May 2014 17:21:24 -0000 --Apple-Mail=_0C8C9906-876E-463C-B46B-798B9E0689EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Everyone, We have published a new version of SMP requirements draft. Thanks to Matt Hartley for providing English review comments, which we = have incorporated changes accordingly, into this version. Kindly review the document and provide comments, if any, at the = earliest. Cheers -sam Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-05.txt > Date: May 30, 2014 at 10:13:41 AM PDT > To: i-d-announce@ietf.org > Cc: mpls@ietf.org >=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 : Requirements for MPLS-TP Shared Mesh = Protection > Authors : Yaacov Weingarten > Sam Aldrin > Ping Pan > Jeong-dong Ryoo > Greg Mirsky > Filename : draft-ietf-mpls-smp-requirements-05.txt > Pages : 14 > Date : 2014-05-30 >=20 > Abstract: > This document presents the basic network objectives for the behavior > of shared mesh protection (SMP) which are not based on control plane > support. This is an expansion of the basic requirements presented in > RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC > 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". > This document is to be used as a basis for the definition of any > mechanism that would be used to implement SMP for MPLS-TP data = paths, > in networks that delegate executive action for resiliency to the = data > plane. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-smp-requirements-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.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 --Apple-Mail=_0C8C9906-876E-463C-B46B-798B9E0689EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Everyone,

We have published a new version of SMP = requirements draft.
Thanks to Matt Hartley for providing = English review comments, which we have incorporated changes accordingly, = into this version.

Kindly review the document = and provide comments, if any, at the = earliest.

Cheers
-sam
Begin forwarded message:

Subject: = [mpls] I-D = Action: draft-ietf-mpls-smp-requirements-05.txt
Date: May 30, 2014 at 10:13:41 AM = PDT

<= br>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 =           : = Requirements for MPLS-TP Shared Mesh Protection
=        Authors =         : Yaacov Weingarten
=             &n= bsp;           &nbs= p;Sam Aldrin
=             &n= bsp;           &nbs= p;Ping Pan
=             &n= bsp;           &nbs= p;Jeong-dong Ryoo
=             &n= bsp;           &nbs= p;Greg Mirsky
= Filename        : = draft-ietf-mpls-smp-requirements-05.txt
Pages =           : = 14
= Date =            : = 2014-05-30

Abstract:
  This document presents the = basic network objectives for the behavior
  of shared mesh = protection (SMP) which are not based on control plane
=   support. This is an expansion of the basic requirements = presented in
  RFC 5654 "Requirements for the Transport = Profile of MPLS" and RFC
  6372 "MPLS Transport Profile = (MPLS-TP) Survivability Framework".
  This document is to = be used as a basis for the definition of any
  mechanism = that would be used to implement SMP for MPLS-TP data paths,
=   in networks that delegate executive action for resiliency to = the data
  plane.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/
There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-05
<= br>A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-smp-requirements= -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

= --Apple-Mail=_0C8C9906-876E-463C-B46B-798B9E0689EA--