From loa@pi.nu Sat Feb 1 01:17: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 364B61A8032 for ; Sat, 1 Feb 2014 01:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbX8GCCegifT for ; Sat, 1 Feb 2014 01:17:43 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 140B51A1F66 for ; Sat, 1 Feb 2014 01:17:43 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.101.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 02DB6180150F; Sat, 1 Feb 2014 10:17:36 +0100 (CET) Message-ID: <52ECBBAA.2030008@pi.nu> Date: Sat, 01 Feb 2014 17:17:30 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: [mpls] Recalling draft-ietf-mpls-tp-te-mib X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 09:17:44 -0000 Adrian, Can you please return the draft-ietf-mpls-tp-te-mib to the mpls working group for further work. /Loa mpls working group co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From gdaley@au.logicalis.com Sun Feb 2 15:33: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 5C9541A013B; Sun, 2 Feb 2014 15:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.535, 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 1xqbq1I-33_H; Sun, 2 Feb 2014 15:32:58 -0800 (PST) Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5A31A1A0139; Sun, 2 Feb 2014 15:32:57 -0800 (PST) Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp2.au.logicalis.com with ESMTP; 03 Feb 2014 10:32:53 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Mon, 3 Feb 2014 10:32:51 +1100 From: Greg Daley To: "'l.wood@surrey.ac.uk'" , "stbryant@cisco.com" , "jnc@mercury.lcs.mit.edu" , "ietf@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard Thread-Index: AQHPHfHxZzPPQlRcgk6ua2U45NfiYJqd1tSwgAAZgQCAAAuhgIAEl8gA Date: Sun, 2 Feb 2014 23:32:50 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D992817FDD8F3@sdcexchms.au.logicalis.com> References: <20140130193200.7BBD018C1C1@mercury.lcs.mit.edu> <72381AF1F18BAE4F890A0813768D992817FDAB19@sdcexchms.au.logicalis.com>, <52EB800E.2090102@cisco.com> <290E20B455C66743BE178C5C84F1240847E63346FE@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346FE@EXMB01CMS.surrey.ac.uk> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Last Call: (Encapsulating MPLS in UDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 23:33:01 -0000 I think it is feasible, but I haven't looked too hard into whether people w= ant to achieve this, and what the impact is on the control plane. Greg Daley > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: Friday, 31 January 2014 10:33 PM > To: stbryant@cisco.com; Greg Daley; jnc@mercury.lcs.mit.edu; ietf@ietf.or= g; > mpls@ietf.org > Subject: RE: [mpls] Last Call: (Encapsula= ting > MPLS in UDP) to Proposed Standard >=20 > RFC 6773. which requires a full udp checksum for nat traversal. >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: ietf [ietf-bounces@ietf.org] On Behalf Of Stewart Bryant > [stbryant@cisco.com] > Sent: 31 January 2014 10:50 > To: Greg Daley; 'Noel Chiappa'; ietf@ietf.org; mpls@ietf.org > Subject: Re: [mpls] Last Call: (Encapsula= ting > MPLS in UDP) to Proposed Standard >=20 > On 30/01/2014 22:44, Greg Daley wrote: > > Of course, in order to get the protocols to pass legacy firewall > > inspection, UDP encapsulation may be required, and companies would > > have to actually implement the protocol... Greg Daley > > gdaley@au.logicalis.com > So UDP/DCCP/MPLS ? >=20 > Stewart From huubatwork@gmail.com Mon Feb 3 06:37:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD62F1A00F9 for ; Mon, 3 Feb 2014 06:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 7OHUPpZA8Xok for ; Mon, 3 Feb 2014 06:37:40 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDB41A00F4 for ; Mon, 3 Feb 2014 06:37:39 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id z12so11714652wgg.18 for ; Mon, 03 Feb 2014 06:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+wYguO3GdLDtk+H4IL/d/nMkYLJC1UREHgM6V1DLpvM=; b=DBc2Fbf6l+JGlw6TMX5cqkXPZstSQfO6nD3zuAIJoASL1/4Unn35sdigT+0n1GvcST m92PdMtKsUKLpETsFsnoVwfvUj5B90OwXsAcL71XH8UV/B2UZgqhe5JYTJhSIuw6Kx4y aHD+M+WqWHC+vo7iwenWI1mQoksRlZB2VeEzPE74y64eVcvOIQqNpQa0qY1Q68AD8mie jvhYFVw44RdB6XVT7jfzlwyCzURVARo15SeKtjJ9TshI4YZBVyJtFst3VoCPhP28mPQl wgoEtIpdNqWrYk/kQcBXs3oMfoJJliQ91VG1VzIFpsgnjHUXoJya++XNfLWG9GPZLphd PDbQ== X-Received: by 10.180.149.206 with SMTP id uc14mr8990967wib.44.1391438259547; Mon, 03 Feb 2014 06:37:39 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id gt6sm10962715wib.8.2014.02.03.06.37.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 06:37:39 -0800 (PST) Message-ID: <52EFA9BC.2020009@gmail.com> Date: Mon, 03 Feb 2014 15:37:48 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401311734.s0VHY8U5082068@maildrop2.v6ds.occnc.com> In-Reply-To: <201401311734.s0VHY8U5082068@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Fwd: I-D Action: draft-zulr-mpls-tp-linear-protection-switching-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:37:41 -0000 Hello Curtis, You wrote: > See inline. ----8<--- snipped >>> This document is a product of a joint Internet Engineering Task Force >>> (IETF) / International Telecommunications Union Telecommunications >>> Standardization Sector (ITU-T) effort to include an MPLS Transport >>> Profile within the IETF MPLS and PWE3 architectures to support the >>> capabilities and functionalities of a packet transport network as >>> defined by the ITU-T. > > The above paragraph is not true since this is not a product of an IETF > WG nor is it related to the agreed upon process between ITU-T and > IETF. Therefore the paragraph should be removed. Thank you. We have removed this paragraph in draft-zulr-mpls-tp-linear-protection-switching-10 which was uploaded some moments ago. Regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From nobo@cisco.com Mon Feb 3 07:44: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 B85441A0155 for ; Mon, 3 Feb 2014 07:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.635 X-Spam-Level: X-Spam-Status: No, score=-8.635 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 Q76uTFbl5QC9 for ; Mon, 3 Feb 2014 07:44:11 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8A1A0195 for ; Mon, 3 Feb 2014 07:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39413; q=dns/txt; s=iport; t=1391442251; x=1392651851; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OKFjMKENKQ02ngcNROmVKVVYENiC1IN/pxPZcEOnuD4=; b=dSbHS4ubtGT5TTKxOhIrTnU0ImtF5iD5ZGaYGqXMlM56fRkwh0wcTjui LB9P19SppffnwNJeU6ilRI/vdiSwTc8KSN7B3jkm6JzMPofKga9fpVxUJ yJIgLDmxImBsQBueVfDNiA5Gw/oakwB2+lODwIU+c7CkxOYiWuB5KxQhn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAJq471KtJXHA/2dsb2JhbABZgkgjIThXvgiBChZ0giUBAQEEJwY6BAMLEAIBCBEEAQELFgEGBzIUCQgBAQQOBQgTh2oBzRUXjiYBEQEfMQYBBoMegRQEiRGhOoMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,773,1384300800"; d="scan'208,217";a="17545019" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-2.cisco.com with ESMTP; 03 Feb 2014 15:44:10 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s13FiADZ004915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 15:44:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 09:44:09 -0600 From: "Nobo Akiya (nobo)" To: "stephane.litkowski@orange.com" , "draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org" Thread-Topic: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Thread-Index: Ac8eiGlrtXECT+cBRj6dlLARCPe0TACY6r2A Date: Mon, 3 Feb 2014 15:44:09 +0000 Message-ID: References: <11094_1391177507_52EBAF23_11094_2718_1_EEE55384044474429A926C625D0FCC8109A301097D@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <11094_1391177507_52EBAF23_11094_2718_1_EEE55384044474429A926C625D0FCC8109A301097D@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.83] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DF55D27xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org" Subject: Re: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 03 Feb 2014 15:44:15 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DF55D27xmbalnx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephane, et al, Adding authors of draft-ravisingh-mpls-el-for-seamless-mpls as I believe th= ere's benefit in creating a consistent solution. I strongly believe (and hope) that we do not want to go with a solution whe= re label stack has multiple ELI/EL at any point in time. Increase in label = stack size is concerning, but multiple ELI/EL becomes more concerning from = OAM perspective, i.e. it becomes very difficult to compute EL to traverse s= pecific path. Thus, I also think solution 3.3 described in draft-kini-mpls-= entropy-label-src-stacked-tunnels is the best idea. But there is one issue. Q: How does LSR, popping the outer label, determine whether it needs to car= ry over ELI/EL (re-insert ELI/EL below exposed top label)? Section 5.3.2 of draft-ravisingh-mpls-el-for-seamless-mpls states: At an ingress LER, the router SHOULD not insert an (ELI+EL) for an LSP if the packet already contains an ELI. This ensures that for a data packet on a hierarchy of LSPs, there will be only 1 instance of an (ELI+EL). This helps to prevent the issue of section 4.3.1. Taking the example from draft-ravisingh-mpls-el-for-seamless-mpls ... S1 D1 \ --------- / A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE / --------- \ S2 D2 In the above topology, let there be the following LSPs: L1: B->D L2: A->E, tunneled through LSP L1 L3: S1->D1, tunneled through LSP L2 L4: S2->D2, tunneled through LSP L2 Let's say: (1) S1 does not push ELI/EL. (2) A pushes ELI/EL. (3) B does not push ELI/EL, since label stack already contains ELI/EL. Behavior so far aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless-m= pls (snippet above). Ideally what should happen is: (4) D pops ELI/EL, and pushes (or carries over) ELI/EL below exposed top= label. (5) E pops ELI/EL, and _does not_ push ELI/EL below exposed top label. (6) D1 receives data without any ELI/EL (as expected). How does nodes D and E determine the right behavior? >From what I've read in the two drafts, I don't see how this behavior is det= ermined. If we can address this issue, I think solution is applicable to Segment Rou= ting label stack with ELI/EL, meaning behavior can apply to solution 3.3 of= draft-kini-mpls-entropy-label-src-stacked-tunnels. One possibility is to make use of TC or TTL of EL to keep track of carry-ov= er number. Meaning: When ELI/EL is not inserted in a new tunnel because ELI/EL exists in the la= bel stack, then: - Increment carry-over number. - Move ELI/EL to below top label. When data terminates a tunnel, then: - Decrement carry-over number. - If (carry-over !=3D 0) re-insert ELI/EL to below exposed top label= . I'm no hardware expert either, and not sure if something like above can be = implemented. But if possible, then ELI/EL pushed in SR network can pre-set = carry-over number to certain value to ensure it is carried over below top l= abel all the way though, and there is only one ELI/EL at any given time. All this to say, I think there's a benefit in discussing this topic further= , with both drafts in mind. -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@o= range.com Sent: Friday, January 31, 2014 9:12 AM To: draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Hi Authors, I would like to know if you are progressing on this draft ? Entropy label support for stacked tunnels would be mandatory for us, so I w= ould like to support the work on this topic to have a working solution as s= oon as possible. Regarding the solutions you are proposing in the current version, there is = none perfect one, and unfortunately all have drawbacks. The compatibility (on LSR) with current generation of hardwares may be "goo= d" (mandatory ?) for the target solution. In your document , solution =A73.3 "re-usable EL for a stack of tunnels" so= unds for me to be the best base idea. I'm just wondering what would be the = hardware impact of doing the reinsertion of ELI at tunnel end . Could this = be done in one pass ? (IMHO, this may be possible, as today we are able to = pop or swap + push FRR headers) As you are three different vendors as co-au= thor, did you already evaluate such impact on your hardwares ? (I'm not exp= ecting details on the mailing list, but I would be interested by details un= icast to me and just yes/no on the the list) To be exhaustive in listing solutions, did you think about leaving the EL/E= LI at top of the stack ? I think there is already a case where a special la= bel may be kept at top of the stack (MPLS Router alert). What would be needed : - each hop need to advertise is ability to process EL, if nexthop ca= nnot process EL, it should be removed when forwarded to nexthop (there shou= ld be the same requirement for re-usable EL) I don't think this is really different from re-usable EL in the concept : - reusable EL : process top level forwarding label, if popped and ne= xt label is EL, pop ELI/EL and next label L, push pack ELI/EL and then L (w= e need to swap positions between ELI/EL and L) if nexthop is able to proces= s EL. - top level EL : process top level ELI, ELI is recognized, ELI/EL is= removed, forwarding is done on forwarding label, ELI/EL is pushed back in = nexthop is able to process EL. In term of operations, I think that top level EL may be simpler , but as I'= m not hardware coder, may be I'm wrong ... moreover it may be similar to MP= LS Router alert processing. Your thoughts ? Stephane ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CECE764681BE964CBE1DFF78F3CDD3941DF55D27xmbalnx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stephane, et al,

 

Adding authors of draft-ravisingh-mpls-el-for-seamless-mpls as I believe = there’s benefit in creating a consistent solution.<= /p>

 

I strongly believe (and hope) that we do not want to go with a solution w= here label stack has multiple ELI/EL at any point in time. Increase in labe= l stack size is concerning, but multiple ELI/EL becomes more concerning from OAM perspective, i.e. it becomes very = difficult to compute EL to traverse specific path. Thus, I also think solut= ion 3.3 described in draft-kini-mpls-entropy-label-src-stacked-tunnels is t= he best idea. But there is one issue.

 

Q: How does LSR, popping the outer label, determine whether it needs to c= arry over ELI/EL (re-insert ELI/EL below exposed top label)?

 

Section 5.3.2 of draft-ravisingh-mpls-el-for-seamless-mpls states:

 

  At an ingress LER, the router SHOULD not insert an (ELI+EL) for an

 = ;  LSP if the packet already contains an ELI.

 = ;  This ensures that for a data packet on a hierarchy of LSPs, there

 = ;  will be only 1 instance of an (ELI+EL). This helps to prevent t= he

 = ;  issue of section 4.3.1.

 

Taking the example from draft-ravisingh-mpls-el-for-seamless-mpls …=

 

 = ;            &n= bsp;  S1          &n= bsp;       D1

 = ;            &n= bsp;    \    ---------    /

 = ;            &n= bsp;     A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=

 = ;            &n= bsp;    /    ---------    \

 = ;            &n= bsp;  S2          &n= bsp;       D2

=  

 = ;  In the above topology, let there be the following LSPs:<= /span>

=  

 = ;       L1: B->D

 = ;       L2: A->E, tunneled through LSP L1<= o:p>

 = ;       L3: S1->D1, tunneled through LSP L= 2

 = ;       L4: S2->D2, tunneled through LSP L= 2

 

Let’s say:

(1)    S1 does not push ELI/EL.

(2)    A pushes ELI/EL.

(3)    B does not push ELI/EL, since label stack already contains ELI/EL= .

 

Behavior so far aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless= -mpls (snippet above). Ideally what should happen is:

 

(4)    D pops ELI/EL, and pushes (or carries over) ELI/EL below exposed = top label.

(5)    E pops ELI/EL, and _does not_ push ELI/EL below exposed to= p label.

(6)    D1 receives data without any ELI/EL (as expected).

 

How does nodes D and E determine the right behavior?

From what I’ve read in the two drafts, I don’t see how this b= ehavior is determined.

 

If we can address this issue, I think solution is applicable to Segment R= outing label stack with ELI/EL, meaning behavior can apply to solution 3.3 = of draft-kini-mpls-entropy-label-src-stacked-tunnels.

 

One possibility is to make use of TC or TTL of EL to keep track of carry-= over number. Meaning:

 

When ELI/EL is not inserted in a new tunnel because ELI/EL exists in the = label stack, then:

= -        Increment carry-over number.

= -        Move ELI/EL to below top label.

When data terminates a tunnel, then:

= -        Decrement carry-over number.

= -        If (carry-over !=3D 0) re-insert ELI/EL to below exposed top labe= l.

 

I’m no hardware expert either, and not sure if something like above= can be implemented. But if possible, then ELI/EL pushed in SR network can = pre-set carry-over number to certain value to ensure it is carried over below top label all the way though, and there= is only one ELI/EL at any given time.

 

All this to say, I think there’s a benefit in discussing this topic= further, with both drafts in mind.

 

-Nobo

 

mpls = [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Friday, January 31, 2014 9:12 AM
To: draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org=
Cc: mpls@ietf.org
Subject: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels

 

Hi Authors,

 

 

I would like to know if you are= progressing on this draft ?

Entropy label support for stack= ed tunnels would be mandatory for us, so I would like to support the work o= n this topic to have a working solution as soon as possible.

 

 

Regarding the solutions you are= proposing in the current version, there is none perfect one, and unfortuna= tely all have drawbacks.

The compatibility (on LSR) with= current generation of hardwares may be “good” (mandatory ?) fo= r the target solution.

 

In your document , solution =A7= 3.3 “re-usable EL for a stack of tunnels” sounds for me to be t= he best base idea. I’m just wondering what would be the hardware impa= ct of doing the reinsertion of ELI at tunnel end . Could this be done in one pass ? (IMHO, this may be possible, as today we are ab= le to pop or swap + push FRR headers) As you are three different vendor= s as co-author, did you already evaluate such impact on your hardwares ? (I= ’m not expecting details on the mailing list, but I would be interested by details unicast to me and just yes/no o= n the the list)

 

To be exhaustive in listing sol= utions, did you think about leaving the EL/ELI at top of the stack ? I thin= k there is already a case where a special label may be kept at top of the s= tack (MPLS Router alert).

What would be needed :

-  =       each hop need to advert= ise is ability to process EL, if nexthop cannot process EL, it should be re= moved when forwarded to nexthop (there should be the same requirement for r= e-usable EL)

I don’t think this is rea= lly different from re-usable EL in the concept :

-  =       reusable EL : process t= op level forwarding label, if popped and next label is EL, pop ELI/EL and n= ext label L, push pack ELI/EL and then L (we need to swap positions between= ELI/EL and L) if nexthop is able to process EL.

-  =       top level EL : process = top level ELI, ELI is recognized, ELI/EL is removed, forwarding is done on = forwarding label, ELI/EL is pushed back in nexthop is able to process EL.

 

In term of operations, I think = that top level EL may be simpler , but as I’m not hardware coder, may= be I’m wrong … moreover it may be similar to MPLS Router alert= processing.

 

 

Your thoughts ?

 

 

Stephane

 

=  

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_CECE764681BE964CBE1DFF78F3CDD3941DF55D27xmbalnx01ciscoc_-- From loa@pi.nu Mon Feb 3 21:24:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852EF1A02D6 for ; Mon, 3 Feb 2014 21:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FylX2qK7pJWI for ; Mon, 3 Feb 2014 21:24:04 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A343E1A0365 for ; Mon, 3 Feb 2014 21:24:03 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.87.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1F403180150F; Tue, 4 Feb 2014 06:24:00 +0100 (CET) Message-ID: <52F07968.4090309@pi.nu> Date: Tue, 04 Feb 2014 13:23:52 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <52DC89C3.3030003@pi.nu> In-Reply-To: <52DC89C3.3030003@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: [mpls] Closed wglc - Re: working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 05:24:06 -0000 Working Group, This working group last call has been closed. There have been comments can the editors please update, confirm with reviewers that the comments are satisfactorily addressed and re-post a new version. /Loa for the mpls wg co-chairs On 2014-01-20 10:28, Loa Andersson wrote: > Working Group, > > This is to start a two week working group last call on > draft-ietf-mpls-tp-psc-itu. > > Please find the document at: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > The document editors has also supplied a "diff-list" between > version -00 and -01 at: > http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html > > ITU-T SG15 has advised us that this document is a necessary reference > for documents that is planned to go into the ITU-T approval process > from the SG15 meeting end of March / beginning of April. Editors, > authors and chairs has put in quite an effort to make this document > ready. The schedule is very tight. > > We are now doing several review steps in parallel > > - the normal working group last call, please send your comments to the > mpls working group mailing list (mpls@ietf.org) > - the working group chairs reviewed this document as part of the > mpls-rt review, normally we do a wg chair review before starting the > wglc, this review will now take place in parallel > - after the wglc and publication request there is an AD evaluation, > this will now also take place in parallel with the wglc > > The editors and authors are advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to > post the new version of the draft until the wglc is closed and the > comments are resolved. > > This working group last call ends February 3rd. > > /Loa > for the MPLS WG co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Mon Feb 3 21:54:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADB81A01F9 for ; Mon, 3 Feb 2014 21:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbWy7ZuOkEJT for ; Mon, 3 Feb 2014 21:54:24 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5C1A035E for ; Mon, 3 Feb 2014 21:54:24 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.87.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 32D65180150F; Tue, 4 Feb 2014 06:54:21 +0100 (CET) Message-ID: <52F08085.9000907@pi.nu> Date: Tue, 04 Feb 2014 13:54:13 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-extended-admin-group@tools.ietf.org Subject: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 05:54:29 -0000 Working Group, This is to initiate a working group last call on draft-ietf-mpls-extended-admin-group-02. There are no IPR disclosures against this document. The author has stated that he is unaware of any 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 Feb 18, 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 loa@pi.nu Mon Feb 3 22:55: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 29C501A0381 for ; Mon, 3 Feb 2014 22:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck5c9QW_WaDp for ; Mon, 3 Feb 2014 22:55:32 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3463D1A0360 for ; Mon, 3 Feb 2014 22:55:32 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.87.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D7319180150F; Tue, 4 Feb 2014 07:55:29 +0100 (CET) Message-ID: <52F08ED9.5050509@pi.nu> Date: Tue, 04 Feb 2014 14:55:21 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 06:55:35 -0000 Working Group, We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the working group for more work. We have a series of comments that are mostly for clarification. However the main reason for recalling the document is that there is one point where we need to confirm working group consensus. The IETF, the working group and the MIB Doctors are today very reluctant to produce read-write MIB modules. The current draft is read-write for a few objects, this is based on a consensus call for an earlier discussion, however the consensus call was not clear. It can be taken to mean both that we want to go with read-write objects and that we want to see read-only. Is it clear that it has been interpreted differently by different individuals. The authors and chairs have discussed the issue and we have a rough consensus that we want the MIB module(s) to be read-only. We therefore are asking the working group if this is OK for the MIB module(s) in the current document. Please indicate Support or Oppose for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only. Please send your comments to the working group mailing list before February 18, 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 gregory.mirsky@ericsson.com Mon Feb 3 22:57: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 5FEAF1A0377 for ; Mon, 3 Feb 2014 22:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 W5NfxmfRqdRe for ; Mon, 3 Feb 2014 22:57:46 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0E41C1A0371 for ; Mon, 3 Feb 2014 22:57:46 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-cf-52f08f6af455 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 96.31.11484.A6F80F25; Tue, 4 Feb 2014 07:57:46 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Tue, 4 Feb 2014 01:57:45 -0500 From: Gregory Mirsky To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only Thread-Index: AQHPIXYesXn4mo3lhUGkAdgFd1aZ35qkqakA Date: Tue, 4 Feb 2014 06:57:44 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B75E0BC@eusaamb103.ericsson.se> References: <52F08ED9.5050509@pi.nu> In-Reply-To: <52F08ED9.5050509@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPuG5W/4cgg/0HlC22/Z7MbvFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoEr48e6BvaCHv6K 32teszUwtvN0MXJySAiYSGz+u5ARwhaTuHBvPVsXIxeHkMARRolzl56zQjjLGCXW7WkDq2IT MJJ4sbGHHcQWEbCT2PjqHyNIEbPADEaJ9jUzwBLCAqESmxuvMkMUhUn8vT2LFcI2kri74SUT iM0ioCLx5/ErsHpeAV+JqU+WgtlCQPE7e3vA6jkFVCXaeyCWMQKd9/3UGrBeZgFxiVtP5jNB nC0gsWTPeWYIW1Ti5eN/rBC2osS+/unsEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYxWYh GTsLScssJC2zkLQsYGRZxchRWpxalptuZLiJERhHxyTYHHcwLvhkeYhRmoNFSZz3y1vnICGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2MOd8Ujs5x5X946kLs8YdNvju5XmRteF53VFPsUvJ/ x6uNt98YM9zVFH31ZnXWdLe3fU5Vjw+nRhs/aPgTkRPhG+YddWuzr/J3runlr7katL6FPTua yVkiY7HZ651gfnXF3iOnnjtPPtfbpLjB/hcLyz9j2+sv33RefsfrLxac1vJdf3rO4dlNSizF GYmGWsxFxYkAjoEYp3ECAAA= Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 06:57:48 -0000 yes/support read-only MIB Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, February 03, 2014 10:55 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-te-mib@tools.ietf.org Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-= only Working Group, We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the workin= g group for more work. We have a series of comments that are mostly for cla= rification. However the main reason for recalling the document is that ther= e is one point where we need to confirm working group consensus. The IETF, the working group and the MIB Doctors are today very reluctant to= produce read-write MIB modules. The current draft is read-write for a few = objects, this is based on a consensus call for an earlier discussion, howev= er the consensus call was not clear. It can be taken to mean both that we w= ant to go with read-write objects and that we want to see read-only. Is it = clear that it has been interpreted differently by different individuals. The authors and chairs have discussed the issue and we have a rough consens= us that we want the MIB module(s) to be read-only. We therefore are asking the working group if this is OK for the MIB module(s) in the current document. Please indicate Support or Oppose for th= is MIB (draft-ietf-mpls-tp-te-mib) to be read-only. Please send your comments to the working group mailing list before February= 18, 2014. Loa for the MPLS wg chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ryoo@etri.re.kr Mon Feb 3 23:58: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 828191A02A2 for ; Mon, 3 Feb 2014 23:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RP_MATCHES_RCVD=-0.535, 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 k6oTBd1kIkxC for ; Mon, 3 Feb 2014 23:58:15 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA181A018D for ; Mon, 3 Feb 2014 23:58:15 -0800 (PST) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Feb 2014 16:58:16 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP3.etri.info ([169.254.157.203]) with mapi id 14.01.0355.002; Tue, 4 Feb 2014 16:58:13 +0900 From: "Ryoo, Jeong-dong" To: "Zhangxian (Xian)" , "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Thread-Topic: working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPFYhnPxX4EfDenE+JJCp9uCTk/JqbfWRAgAlVBdY= Date: Tue, 4 Feb 2014 07:58:13 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B5D93@SMTP2.etri.info> References: In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5D93SMTP2etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 07:58:18 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5D93SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBYaWFuLg0KDQpJIGFtIGxvb2tpbmcgZm9yd2FyZCB0byBzZWVpbmcgeW91ciBjb21t ZW50cyBzb29uLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIDogIlpoYW5neGlhbiAoWGlhbikiIDx6aGFu Zy54aWFuQGh1YXdlaS5jb20+DQpTZW50IDogMjAxNC0wMS0yOSAxODozNjo0NSAoICswOTowMCAp DQpUbyA6IG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMtdHAt cHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMu aWV0Zi5vcmc+DQpDYyA6DQpTdWJqZWN0IDogW21wbHNdIEZXOiB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMQ0KDQpJJ3ZlIHJldmlld2VkIHRoZSBk b2N1bWVudCBhbmQgb25seSBmb3VuZCBtaW5vciBncmFtbWF0aWNhbCBpc3N1ZXMuIFRodXMsIEkg YmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCkR1 ZSB0byBDaGluZXNlIE5ldyBZZWFyIGJyZWFrLCBwbGVhc2UgZXhwZWN0IG15IGdyYW1tYXRpY2Fs IHN1Z2dlc3Rpb25zL2NvbW1lbnRzIGNvbWUgYWZ0ZXIgdGhlIFdHIExDIChhZnRlciBJIHRyYW5z Y3JpcHQgbXkgbm90ZXMgZnJvbSB0aGUgaGFyZC1jb3B5IHZlcnNpb24gdG8gYW4gZWxlY3Ryb25p YyBvbmUpLg0KDQpSZWdhcmRzLA0KWGlhbg0KDQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tLS0tDQpGcm9tOiBMb2EgQW5kZXJzc29uDQpUbzogbXBsc0BpZXRmLm9yZw0KQ0M6IG1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnICwNCiwNCmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRv b2xzLmlldGYub3JnDQosIFZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pDQoNCg0KV29ya2luZyBH cm91cCwNCg0KVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIG9uDQpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS4NCg0KUGxlYXNlIGZpbmQgdGhlIGRv Y3VtZW50IGF0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHUvDQoNClRoZSBkb2N1bWVudCBlZGl0b3JzIGhhcyBhbHNvIHN1cHBsaWVk IGEgImRpZmYtbGlzdCIgYmV0d2Vlbg0KdmVyc2lvbiAtMDAgYW5kIC0wMSBhdDoNCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTEzMzguaHRtbA0K DQpJVFUtVCBTRzE1IGhhcyBhZHZpc2VkIHVzIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBhIG5lY2Vz c2FyeSByZWZlcmVuY2UNCmZvciBkb2N1bWVudHMgdGhhdCBpcyBwbGFubmVkIHRvIGdvIGludG8g dGhlIElUVS1UIGFwcHJvdmFsIHByb2Nlc3MNCmZyb20gdGhlIFNHMTUgbWVldGluZyBlbmQgb2Yg TWFyY2ggLyBiZWdpbm5pbmcgb2YgQXByaWwuIEVkaXRvcnMsDQphdXRob3JzIGFuZCBjaGFpcnMg aGFzIHB1dCBpbiBxdWl0ZSBhbiBlZmZvcnQgdG8gbWFrZSB0aGlzIGRvY3VtZW50DQpyZWFkeS4g VGhlIHNjaGVkdWxlIGlzIHZlcnkgdGlnaHQuDQoNCldlIGFyZSBub3cgZG9pbmcgc2V2ZXJhbCBy ZXZpZXcgc3RlcHMgaW4gcGFyYWxsZWwNCg0KLSB0aGUgbm9ybWFsIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZQ0KbXBscyB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZykNCi0gdGhlIHdvcmtpbmcgZ3JvdXAgY2hh aXJzIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUNCm1wbHMtcnQgcmV2aWV3 LCBub3JtYWxseSB3ZSBkbyBhIHdnIGNoYWlyIHJldmlldyBiZWZvcmUgc3RhcnRpbmcgdGhlDQp3 Z2xjLCB0aGlzIHJldmlldyB3aWxsIG5vdyB0YWtlIHBsYWNlIGluIHBhcmFsbGVsDQotIGFmdGVy IHRoZSB3Z2xjIGFuZCBwdWJsaWNhdGlvbiByZXF1ZXN0IHRoZXJlIGlzIGFuIEFEIGV2YWx1YXRp b24sDQp0aGlzIHdpbGwgbm93IGFsc28gdGFrZSBwbGFjZSBpbiBwYXJhbGxlbCB3aXRoIHRoZSB3 Z2xjDQoNClRoZSBlZGl0b3JzIGFuZCBhdXRob3JzIGFyZSBhZHZpc2VkIHRvIHRyeSB0byByZXNv bHZlIGFzIG1hbnkgb2YgdGhlDQpjb21tZW50cyBhcyBwb3NzaWJsZSAob24gdGhlIG1haWxpbmcg bGlzdCkgYXMgdGhleSBjb21lIGluLCBidXQgbm90IHRvDQpwb3N0IHRoZSBuZXcgdmVyc2lvbiBv ZiB0aGUgZHJhZnQgdW50aWwgdGhlIHdnbGMgaXMgY2xvc2VkIGFuZCB0aGUNCmNvbW1lbnRzIGFy ZSByZXNvbHZlZC4NCg0KVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIEZlYnJ1YXJ5 IDNyZC4NCg0KL0xvYQ0KZm9yIHRoZSBNUExTIFdHIGNvLWNoYWlycw0KLS0NCg0KDQpMb2EgQW5k ZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NClNlbmlvciBNUExTIEV4cGVydCBs b2FAcGkubnUNCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpIHBob25lOiArNDYgNzM5 IDgxIDIxIDY0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5D93SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5UaGFua3MsIFhpYW4uPC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdCI+SSBhbSBsb29raW5nIGZvcndhcmQgdG8gc2VlaW5nIHlvdXIgY29tbWVudHMg c29vbi48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2 IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+SmVvbmctZG9uZzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPjxicj4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi IGlkPSJNYWlsU2lnbiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPjxiPkZyb20gOiA8L2I+JnF1b3Q7Wmhhbmd4aWFuIChYaWFuKSZxdW90OyAmbHQ7emhh bmcueGlhbkBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxNC0wMS0yOSAxODoz Njo0NSAoICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21w bHNAaWV0Zi5vcmcmZ3Q7LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9y ZyAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+Q2MgOiA8L2I+PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5bbXBsc10gRlc6IHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxPGJyPg0KPGJyPg0KSSd2 ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnQgYW5kIG9ubHkgZm91bmQgbWlub3IgZ3JhbW1hdGljYWwg aXNzdWVzLiBUaHVzLCBJIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1 YmxpY2F0aW9uLjxicj4NCjxicj4NCkR1ZSB0byBDaGluZXNlIE5ldyBZZWFyIGJyZWFrLCBwbGVh c2UgZXhwZWN0IG15IGdyYW1tYXRpY2FsIHN1Z2dlc3Rpb25zL2NvbW1lbnRzIGNvbWUgYWZ0ZXIg dGhlIFdHIExDIChhZnRlciBJIHRyYW5zY3JpcHQgbXkgbm90ZXMgZnJvbSB0aGUgaGFyZC1jb3B5 IHZlcnNpb24gdG8gYW4gZWxlY3Ryb25pYyBvbmUpLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0K WGlhbjxicj4NCjxicj4NCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08YnI+DQpG cm9tOiBMb2EgQW5kZXJzc29uIDxMT0FAUEkuTlU+PGJyPg0KVG86IG1wbHNAaWV0Zi5vcmcgPE1Q TFNASUVURi5PUkc+PGJyPg0KQ0M6IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIDxNUExTLUNI QUlSU0BUT09MUy5JRVRGLk9SRz4sIDxicj4NCjxNUExTLUFEU0BUT09MUy5JRVRGLk9SRz48TVBM Uy1BRFNAVE9PTFMuSUVURi5PUkc+LCA8YnI+DQpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0 b29scy5pZXRmLm9yZyA8YnI+DQo8RFJBRlQtSUVURi1NUExTLVRQLVBTQy1JVFVAVE9PTFMuSUVU Ri5PUkc+LCBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKSA8YnI+DQo8TUFSVElOLlZJR09VUkVV WEBBTENBVEVMLUxVQ0VOVC5DT00+PGJyPg0KPGJyPg0KV29ya2luZyBHcm91cCw8YnI+DQo8YnI+ DQpUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb248 YnI+DQpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS48YnI+DQo8YnI+DQpQbGVhc2UgZmluZCB0 aGUgZG9jdW1lbnQgYXQ6PGJyPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUvPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50IGVkaXRvcnMg aGFzIGFsc28gc3VwcGxpZWQgYSAmcXVvdDtkaWZmLWxpc3QmcXVvdDsgYmV0d2Vlbjxicj4NCnZl cnNpb24gLTAwIGFuZCAtMDEgYXQ6PGJyPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL21wbHMvY3VycmVudC9tc2cxMTMzOC5odG1sPGJyPg0KPGJyPg0KSVRVLVQgU0cxNSBo YXMgYWR2aXNlZCB1cyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgYSBuZWNlc3NhcnkgcmVmZXJlbmNl PGJyPg0KZm9yIGRvY3VtZW50cyB0aGF0IGlzIHBsYW5uZWQgdG8gZ28gaW50byB0aGUgSVRVLVQg YXBwcm92YWwgcHJvY2Vzczxicj4NCmZyb20gdGhlIFNHMTUgbWVldGluZyBlbmQgb2YgTWFyY2gg LyBiZWdpbm5pbmcgb2YgQXByaWwuIEVkaXRvcnMsPGJyPg0KYXV0aG9ycyBhbmQgY2hhaXJzIGhh cyBwdXQgaW4gcXVpdGUgYW4gZWZmb3J0IHRvIG1ha2UgdGhpcyBkb2N1bWVudDxicj4NCnJlYWR5 LiBUaGUgc2NoZWR1bGUgaXMgdmVyeSB0aWdodC48YnI+DQo8YnI+DQpXZSBhcmUgbm93IGRvaW5n IHNldmVyYWwgcmV2aWV3IHN0ZXBzIGluIHBhcmFsbGVsPGJyPg0KPGJyPg0KLSB0aGUgbm9ybWFs IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRo ZTxicj4NCm1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpPGJy Pg0KLSB0aGUgd29ya2luZyBncm91cCBjaGFpcnMgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZTxicj4NCm1wbHMtcnQgcmV2aWV3LCBub3JtYWxseSB3ZSBkbyBhIHdnIGNoYWly IHJldmlldyBiZWZvcmUgc3RhcnRpbmcgdGhlPGJyPg0Kd2dsYywgdGhpcyByZXZpZXcgd2lsbCBu b3cgdGFrZSBwbGFjZSBpbiBwYXJhbGxlbDxicj4NCi0gYWZ0ZXIgdGhlIHdnbGMgYW5kIHB1Ymxp Y2F0aW9uIHJlcXVlc3QgdGhlcmUgaXMgYW4gQUQgZXZhbHVhdGlvbiw8YnI+DQp0aGlzIHdpbGwg bm93IGFsc28gdGFrZSBwbGFjZSBpbiBwYXJhbGxlbCB3aXRoIHRoZSB3Z2xjPGJyPg0KPGJyPg0K VGhlIGVkaXRvcnMgYW5kIGF1dGhvcnMgYXJlIGFkdmlzZWQgdG8gdHJ5IHRvIHJlc29sdmUgYXMg bWFueSBvZiB0aGU8YnI+DQpjb21tZW50cyBhcyBwb3NzaWJsZSAob24gdGhlIG1haWxpbmcgbGlz dCkgYXMgdGhleSBjb21lIGluLCBidXQgbm90IHRvPGJyPg0KcG9zdCB0aGUgbmV3IHZlcnNpb24g b2YgdGhlIGRyYWZ0IHVudGlsIHRoZSB3Z2xjIGlzIGNsb3NlZCBhbmQgdGhlPGJyPg0KY29tbWVu dHMgYXJlIHJlc29sdmVkLjxicj4NCjxicj4NClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwg ZW5kcyBGZWJydWFyeSAzcmQuPGJyPg0KPGJyPg0KL0xvYTxicj4NCmZvciB0aGUgTVBMUyBXRyBj by1jaGFpcnM8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uIGVtYWlsOiBs b2FAbWFpbDAxLmh1YXdlaS5jb208YnI+DQpTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51PGJy Pg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICYjNDM7NDYgNzM5IDgx IDIxIDY0PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8 YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5D93SMTP2etriinfo_-- From loa@pi.nu Tue Feb 4 01:21: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 8E6351A03D2 for ; Tue, 4 Feb 2014 01:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eCwV_mARUZD for ; Tue, 4 Feb 2014 01:21:26 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9171A03A1 for ; Tue, 4 Feb 2014 01:21:26 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.87.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 12B61180150F; Tue, 4 Feb 2014 10:21:23 +0100 (CET) Message-ID: <52F0B10B.8000307@pi.nu> Date: Tue, 04 Feb 2014 17:21:15 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Ryoo, Jeong-dong" , "Zhangxian (Xian)" , "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B5D93@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B5D93@SMTP2.etri.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:21:29 -0000 Jeong-dong, Please don't hold the posting of the version updated after working group last call, waiting only for the comments from Xian. Instead fold her comments in as IETF Last Call comments and post a new version when the IETF LC ends. Xian, we appreciate your comments, but I hope it will be OK to take care of them as IETF Last Call comments. /Loa On 2014-02-04 15:58, Ryoo, Jeong-dong wrote: > Thanks, Xian. > I am looking forward to seeing your comments soon. > Best regards, > Jeong-dong > > > ------------------------------------------------------------------------ > *From : *"Zhangxian (Xian)" > *Sent : *2014-01-29 18:36:45 ( +09:00 ) > *To : *mpls@ietf.org , > draft-ietf-mpls-tp-psc-itu@tools.ietf.org > > *Cc : * > *Subject : *[mpls] FW: working group last call draft-ietf-mpls-tp-psc-itu-01 > > I've reviewed the document and only found minor grammatical issues. > Thus, I believe that the document is ready for publication. > > Due to Chinese New Year break, please expect my grammatical > suggestions/comments come after the WG LC (after I transcript my notes > from the hard-copy version to an electronic one). > > Regards, > Xian > > -------- Original Message -------- > From: Loa Andersson > To: mpls@ietf.org > CC: mpls-chairs@tools.ietf.org , > , > draft-ietf-mpls-tp-psc-itu@tools.ietf.org > , VIGOUREUX, MARTIN (MARTIN) > > > Working Group, > > This is to start a two week working group last call on > draft-ietf-mpls-tp-psc-itu. > > Please find the document at: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > The document editors has also supplied a "diff-list" between > version -00 and -01 at: > http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html > > ITU-T SG15 has advised us that this document is a necessary reference > for documents that is planned to go into the ITU-T approval process > from the SG15 meeting end of March / beginning of April. Editors, > authors and chairs has put in quite an effort to make this document > ready. The schedule is very tight. > > We are now doing several review steps in parallel > > - the normal working group last call, please send your comments to the > mpls working group mailing list (mpls@ietf.org) > - the working group chairs reviewed this document as part of the > mpls-rt review, normally we do a wg chair review before starting the > wglc, this review will now take place in parallel > - after the wglc and publication request there is an AD evaluation, > this will now also take place in parallel with the wglc > > The editors and authors are advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to > post the new version of the draft until the wglc is closed and the > comments are resolved. > > This working group last call ends February 3rd. > > /Loa > for the MPLS WG co-chairs > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ryoo@etri.re.kr Tue Feb 4 01:53: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 489CE1A03B8 for ; Tue, 4 Feb 2014 01:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.454 X-Spam-Level: X-Spam-Status: No, score=-101.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 aWZ1spZAoR4z for ; Tue, 4 Feb 2014 01:53:29 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9402E1A0388 for ; Tue, 4 Feb 2014 01:53:28 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Feb 2014 18:53:29 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Tue, 4 Feb 2014 18:53:24 +0900 From: "Ryoo, Jeong-dong" To: Yaacov Weingarten Thread-Topic: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPFYdUrouQjghEKkymdYiVWJN87pqYdiKAgAF3azmAATDvgIAJwqaK Date: Tue, 4 Feb 2014 09:53:24 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DCF@SMTP2.etri.info> References: <52DC89C3.3030003@pi.nu> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3DCC@SMTP2.etri.info>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DCFSMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:53:33 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DCFSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFhY292LCBhZ2FpbiB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQpEdWUgdG8gdGhlIGx1YXIg TmV3IFllYXIgYnJlYWssIEkgd2FzIGEgbGl0dGxlIGJlaGluZC4NClBsZWFzZSBzZWUgbXkgcmVz cG9uc2VzIHN0YXJ0aW5nIHdpdGggW0pSXQ0KSmVvbmctZG9uZw0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpGcm9tIDogIllhYWNvdiBXZWluZ2FydGVuIiA8d3lhYWNvdkBn bWFpbC5jb20+DQpTZW50IDogMjAxNC0wMS0yOSAyMTo0NzowOSAoICswOTowMCApDQpUbyA6IFJ5 b28sIEplb25nLWRvbmcgPHJ5b29AZXRyaS5yZS5rcj4NCkNjIDogTG9hIEFuZGVyc3NvbiA8bG9h QHBpLm51PiwgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4sIG1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29s cy5pZXRmLm9yZz4NClN1YmplY3QgOiBSZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxDQoNCkplb25nLWRvbmcsIGhpDQoNClRoYW5r IHlvdSBmb3IgeW91ciBkZXRhaWxlZCByZXBseSB0byBteSBjb21tZW50cyAtIHNvbWUgY291bnRl ciBjb21tZW50cyBhcHBlYXIgYmVsb3cgcHJlZml4ZWQgYnkgInl3Pj4iLg0KDQpJbiBhZGRpdGlv biwgSSB3b3VsZCBsaWtlIHRvIGFkZCB0aGUgZm9sbG93aW5nIGNvbW1lbnQgLSByZWdhcmRpbmcg dGhlIG5vdGVzIG9uIHRoZSBTdGF0ZSB0YWJsZXMgYW5kIGVzcGVjaWFsbHkgbm90ZSAjMS4gSW4g dGhpcyBub3RlIHlvdSBzdGF0ZSJSZS1ldmFsdWF0ZSB0byBkZXRlcm1pbmUgZmluYWwgc3RhdGUg YXMgaWYgdGhlIExFUiBpcyBpbiB0aGUgTm9ybWFsIHN0YXRlLiIgVGhpcyBuZWVkcyBtb3JlIGNs YXJpZmljYXRpb24sIElNTywgc2luY2UgdGhpcyBjb3VsZCBiZSByZWFkIGFzIHN0YXRpbmcgdGhh dCBpZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIHRyaWdnZXIgdGhlbiByZW1haW4gaW4g dGhlIGN1cnJlbnQgc3RhdGUhDQpUaGVyZWZvcmUgSSB0aGluayB0aGF0IHlvdSBzaG91bGQgZXhw bGljaXRseSBzdGF0ZSAiUmUtZXZhbHVhdGUgdG8gZGV0ZXJtaW5lIGZpbmFsIHN0YXRlIGFzIGlm IHRoZSBMRVIgaXMgaW4gdGhlIE5vcm1hbCBzdGF0ZS4gSWYgdGhlcmUgYXJlIG5vIGFjdGl2ZSB0 cmlnZ2VycywgdGhlIExFUiBlbnRlcnMgTm9ybWFsIFN0YXRlLiIgKE9uIHRoZSBhc3N1bXB0aW9u IHRoYXQgdGhpcyBpcyB0aGUgaW50ZW50aW9uISkgU2ltaWxhciBjb3JyZWN0aW9ucyBzaG91bGQg YmUgY29uc2lkZXJlZCBmb3Igbm90ZXMgMiwzLDUuDQpbSlJdIFllcywgSSBhZ3JlZSB3aXRoIHlv dS4gVGhhdCB3YXMgdGhlIGludGVudGlvbiwgYnV0IGN1cnJlbnQgZGVzY3JpcHRpb24gaXMgbm90 IGNvbXBsZXRlLiBJdCBzaG91bGQgYmUgY29ycmVjdGVkIGluIG5leHQgdmVyc2lvbiBhcyB5b3Ug c3VnZ2VzdGVkLg0KDQoNClRoYW54LA0KeWFhY292DQoNCg0KT24gVHVlLCBKYW4gMjgsIDIwMTQg YXQgMTE6NDEgQU0sIFJ5b28sIEplb25nLWRvbmcgPHJ5b29AZXRyaS5yZS5rcjxtYWlsdG86cnlv b0BldHJpLnJlLmtyPj4gd3JvdGU6DQpZYWFjb3YsDQpBZ2FpbiwgdGhhbmtzIGZvciB0aGUgY29t bWVudHMuDQpJIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgaGVscCBvbiB0aGlzIGRvY3VtZW50Lg0K VGhlIGZvbGxvd2luZ3MgYXJlIG15IHJlc3BvbnNlcyB0byB5b3VyIGNvbW1lbnRzOg0KPT09PT09 PT0NCiMxLiBZZXMsIHlvdSBkZXNjcmliZWQgdGhlIGNvcnJlY3QgYmVoYXZpb3Igb2YgTVMtVy4g QXMgeW91IGluZGljYXRlZCwgTVMgYW5kIEVYRVIgYXJlIHN1cHBvc2VkIHRvIGJlIGlnbm9yZWQg d2hpbGUgTVMtVyBpcyBpbiBlZmZlY3QuDQp5dz4+IEkgdGhpbmsgdGhhdCBpZiB0aGlzIGlzIHRo ZSBjYXNlIHRoYXQgaXQgYmUgZXhwbGljaXRseSBzdGF0ZWQgaW4gdGhlIHRleHQuDQpbSlJdIFRo ZSBuZXh0IHZlcnNpb24gb2YgZHJhZnQgc2hvdWxkIGhhdmUgdGhpcy4NCg0KIzIuIFRoaXMgZG9j dW1lbnQgZG9lcyBub3QgbW9kaWZ5IHRoZSBvcGVyYXRpb24gb2YgdGhlIHNlbGVjdG9yIGRlc2Ny aWJlZCBpbiBSRkM2Mzc4LiBBY2NvcmRpbmcgdG8gUkZDNjM3OCwgdGhlIHNlbGVjdG9yIHNlbGVj dHMgdGhlIHRyYWZmaWMgZnJvbSBvbmx5IG9uZSBvZiB0aGUgcGF0aHMgbm8gbWF0dGVyIGlmIHRo ZSBwcm90ZWN0aW9uIGFyY2hpdGVjdHVyZSBpcyAxOjEgb3IgMSsxLiBJZiB5b3UgdGhpbmsgaXQg aXMgYXBwcm9wcmlhdGUgdG8gbWFrZSB0aGlzIGNsZWFyLCB0aGVuIHdlIGNhbiBhZGQgc29tZXRo aW5nIGxpa2U6DQrigJxUaGlzIGRvY3VtZW50IGRvZXMgbm90IG1vZGlmeSB0aGUgb3BlcmF0aW9u IG9mIHRoZSBzZWxlY3RvciBhdCB0aGUgc2luayBMRVIgZGVzY3JpYmVkIGluIFJGQyA2Mzc4LiBU aGUgc2VsZWN0b3IgYXQgdGhlIHNpbmsgTEVSIGNob29zZXMgZWl0aGVyIHRoZSB3b3JraW5nIG9y IHByb3RlY3Rpb24gcGF0aCBmcm9tIHdoaWNoIHRvIHJlY2VpdmUgdGhlIG5vcm1hbCB0cmFmZmlj IGluIGJvdGggMToxIGFuZCAxKzEgYXJjaGl0ZWN0dXJlcy4gVGhlIHBvc2l0aW9uIG9mIHRoZSBz ZWxlY3RvciwgaS5lLiwgd2hpY2ggcGF0aCB0byByZWNlaXZlIHRoZSB0cmFmZmljLCBpcyBkZXRl cm1pbmVkIGJ5IHRoZSBQU0MgcHJvdG9jb2wgaW4gYmlkaXJlY3Rpb25hbCBzd2l0Y2hpbmcgb3Ig YnkgdGhlIGxvY2FsIGlucHV0IGluIHVuaWRpcmVjdGlvbmFsIHN3aXRjaGluZy7igJ0NCkFzIGEg bWF0dGVyIG9mIGZhY3QsIGFjY29yZGluZyB0byBSRkMgNDQyNyAoYW5kIGFsbCB0aGUgSVRVLVQg cHJvdGVjdGlvbiBkb2N1bWVudHMpLCBhIHNlbGVjdG9yIHJlZmVycyB0byB0aGUgZW50aXR5IGF0 IHRoZSBzaW5rIG5vZGUgb25seS4gRm9yIHRoZSBzb3VyY2Ugbm9kZSwgYSBicmlkZ2UgaXMgdXNl ZCB0byBjaG9vc2Ugd2hpY2ggcGF0aCAob25lIG9mIHR3byBwYXRocyBpbiAxOjEsIG9yIGJvdGgg cGF0aHMgaW4gMSsxKSB0byB0cmFuc21pdCB0aGUgdHJhZmZpYy4gVGhlcmVmb3JlLCDigJx0aGUg c2VsZWN0b3IgaW4gdGhlIHNpbmsgTEVS4oCdIGlzIHJlZHVuZGFudCBhbmQgc2hvdWxkIGhhdmUg YmVlbiByZXBsYWNlZCB3aXRoIGp1c3Qg4oCcdGhlIHNlbGVjdG9y4oCdLiBCdXQsIHRoZSBkZXNj cmlwdGlvbnMgb2YgdGhlIHNlbGVjdG9yIGFuZCBicmlkZ2UgaW4gUkZDIDYzNzggYXJlIHNvbWV3 aGF0IGRpZmZlcmVudC4gSW4gUkZDIDYzNzgsIHRoZSBzZWxlY3RvciBpcyB1c2VkIGZvciBib3Ro IHRyYW5zbWl0dGluZyBhbmQgcmVjZWl2aW5nIHRoZSB0cmFmZmljLCB3aGlsZSB0aGUgYnJpZGdl IGlzIHVzZWQgZm9yIHRyYW5zbWl0dGluZyBvbmx5LiBUaGUgZGVzY3JpcHRpb25zIGluIFJGQyA2 Mzc4IGFyZSBub3QgcXVpdGUgYWxpZ25lZCB3aXRoIFJGQyA0NDI3IChhbmQgb3RoZXIgSVRVLVQg ZG9jcykuDQojMy4gQWdhaW4sIHRoaXMgaXMgZHVlIHRvIHRoZSBkaWZmZXJlbnQgdW5kZXJzdGFu ZGluZyBvbiB0aGUgc2VsZWN0b3IuIElmIHlvdSBzdGljayB0byB0aGUgdGVybWlub2xvZ3kgZGVm aW5lZCBpbiBSRkMgNDQyNyBhbmQgSVRVLVQsIHRoZW4geW91IG1heSBub3QgaGF2ZSB0aGUgaXNz dWUgd2l0aCBjdXJyZW50IHNlbnRlbmNlcy4gSW4gdGhlIG1lYW50aW1lLCBhcyBJIGRpZCBpbiAj MiwgSSBjYW4gYWRkIOKAnGluIHRoZSBzaW5rIExFUuKAnSBhZnRlciBldmVyeSDigJx0aGUgc2Vs ZWN0b3LigJ0uIEluIG90aGVyIHdvcmRzLCAidGhlIHBhdGggZnJvbSB3aGljaCB0aGUgc2VsZWN0 b3IgZG9lcyBub3Qgc2VsZWN0IHRoZSB1c2VyIGRhdGEgdHJhZmZpYyIgY2FuIGJlIHJlcGxhY2Vk IHdpdGgg4oCcInRoZSBwYXRoIGZyb20gd2hpY2ggdGhlIHNlbGVjdG9yIGF0IHRoZSBzaW5rIExF UiBkb2VzIG5vdCBzZWxlY3QgdGhlIHVzZXIgZGF0YSB0cmFmZmljIg0KeXc+PiBJIGRpZCBub3Qg aGF2ZSBhIHByb2JsZW0gd2l0aCB0aGUgInNlbGVjdG9yIiB0ZXJtaW5vbG9neSBteSBwcm9ibGVt IHdhcyB3aXRoIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgU0QgcHJvdGVjdGlvbiBiZWhhdmlvciBp biBzZWN0aW9uIDcuMy4gWW91IHN0YXRlIHRoZXJlIHRoYXQgdGhlIHByb3RlY3Rpb24gaXMgcHJv dmlkZWQgYnkgImEgc2VsZWN0b3IgYnJpZGdlIGR1cGxpY2F0aW5nIHVzZXIgZGF0YSB0cmFmZmlj IiAgdGhlbiBsYXRlciAidGhlIExFUiBTSEFMTCBkdXBsaWNhdGUgdXNlciBkYXRhIHRyYWZmaWMg YW5kIFNIQUxMIGZlZWQgdG8gYm90aC4uLiIgSG93ZXZlciwgdGhlcmUgaXMgbm8gZGVzY3JpcHRp b24gb2Ygd2hhdCB0aGUgc2VsZWN0b3IgYXQgdGhlIHJlY2VpdmluZyBlbmQgaXMgZG9pbmcuDQpU aGVyZWZvcmUsIG15IGNvbmNsdXNpb24gaXMgdGhhdCB0aGUgcmVjZWl2aW5nIGVuZCBzZWxlY3Rz IGluY29taW5nIGRhdGEgdHJhZmZpYyBmb3JtIGVpdGhlciB0aGUgd29ya2luZyBvciBwcm90ZWN0 aW9uIHBhdGggb24gYSBwZXItcGFja2V0IGJhc2lzLCBpLmUuIHBhY2tldCMxLTUgbWF5IGJlIHNl bGVjdGVkIGZyb20gdGhlIHdvcmtpbmcgcGF0aCwgd2hpbGUgcGFja2V0IzYtNyBtYXkgYmUgc2Vs ZWN0ZWQgZnJvbSB0aGUgcHJvdGVjdGlvbiBwYXRoLCBhbmQgcGFja2V0IzgtMTAgZnJvbSB3b3Jr aW5nLCBhbmQgc28gb24uIElzIHRoaXMgY29ycmVjdD8gQW5kIGlmIGl0IGlzIG5vdCBjb3JyZWN0 IGNvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSB0ZXh0IHRoYXQgcHJlY2x1ZGVzIHRoaXMgYmVoYXZp b3IuDQpUaGUgbmV4dCBzdGVwIHRvIG15IHF1ZXN0aW9uIGlzIHRoZW4gLSBpZiB0aGlzIGRlc2Ny aXB0aW9uIGlzIGNvcnJlY3QgdGhlbiB0aGVyZSBpcyBubyAic3RhbmRieSIgcGF0aCBzaW5jZSB0 aGUgc2VsZWN0b3IgKGF0IHRoZSBzaW5rIExFUikgbWF5IHN3aXRjaCBpbnRlcm1pdHRlbnRseSAo YmFzZWQgb24gdGhlIHF1YWxpdHkgb2YgdGhlIHRyYW5zbWlzc2lvbiBhdCB0aGF0IHBvaW50IGlu IHRpbWUpIGJldHdlZW4gdGhlIHR3byBwYXRocy4gU28gY2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB0 aGUgZGVmaW5pdGlvbj8NCltKUl0gVGhlIHNlbGVjdG9yIGlzIHRoZSBzYW1lIGFzIHRoZSBvbmUg aW4gUkZDNjM3OC4NClRoZSBwb3NpdGlvbiBvZiB0aGUgc2VsZWN0b3IgaXMgZGV0ZXJtaW5lZCBi eSB0aGUgUFNDIHByb3RvY29sIGluIGJpZGlyZWN0aW9uYWwgc3dpdGNoaW5nLg0KV2hlbiBTRC1X IGlzIGRldGVjdGVkIGluIHRoZSBOb3JtYWwgc3RhdGUsIHRoZSBsb2NhbCBMRVIgY2hhbmdlcyBp dHMgc2VsZWN0b3IgcG9zaXRpb24gdG8gdGhlIHByb3RlY3Rpb24gcGF0aCwgc2VuZHMgdGhlIHRy YWZmaWMgdG8gYm90aCBwYXRocywgYW5kIHRyYW5zbWl0cyBTRC1XIG1lc3NhZ2UuDQpXaGVuIHRo ZSBTRC1XIG1lc3NhZ2UgYXJyaXZlcyBhdCB0aGUgcmVtb3RlIExFUiwgdGhlIHJlbW90ZSBMRVIg Y2hhbmdlcyBpdCBzZWxlY3RvciBwb3NpdGlvbiB0byB0aGUgcHJvdGVjdGlvbiBwYXRoLCBhbmQg c2VuZHMgdGhlIHRyYWZmaWMgdG8gYm90aCBwYXRocy4NCk5vdywgdGhlIGJlaGF2aW9yIHdpbGwg Y29udGludWUgdW50aWwgYW55IG5ldyBoaWdoZXIgcmVxdWVzdCBvY2N1cnMuIEkuZS4sIG5vIGZ1 cnRoZXIgY2hhbmdlIG9mIHRoZSBzZWxlY3RvciBwb3NpdGlvbiB1bnRpbCBhbnkgbmV3IGhpZ2hl ciBwcmlvcml0eSByZXF1ZXN0IGNvbWVzIGluLg0KDQpBdCB0aGUgdGltZSBTRC1XIG9jY3VycmVk IGF0IHRoZSBsb2NhbCBMRVIsIHRoZSBzdGFuZGJ5IHBhdGggd2FzIHRoZSBwcm90ZWN0aW9uIHBh dGggYXMgdGhlIHRyYWZmaWMgd2FzIHNlbGVjdGVkIGZyb20gdGhlIHdvcmtpbmcgcGF0aCBpbiB0 aGUgTm9ybWFsIHN0YXRlLg0KQWZ0ZXIgdHdvIExFUnMgYWN0IG9uIFNELVcsIHRoZSB3b3JraW5n IHBhdGggYmVjb21lcyB0aGUgc3RhbmRieSBwYXRoIGFzIHRoZSB0cmFmZmljIGlzIHNlbGVjdGVk IGZyb20gdGhlIHByb3RlY3Rpb24gcGF0aC4NCg0KVGhlIG9wZXJhdGlvbiB5b3UgZGVzY3JpYmVk IHdpdGggcGFja2V0IG51bWJlcnMgaXMgbm90IHRoZSBiZWhhdmlvciBpbiB0aGUgZG9jdW1lbnQu DQpXZSBhY3R1YWxseSB3YW50ZWQgdG8gYXZvaWQgc3VjaCBhIHNpdHVhdGlvbiAodHJhZmZpYyBm bGFwcGluZykgYnkgdXNpbmcgdGhpcyBicmlkZ2Ugd2l0aCBwYWNrZXQgZHVwbGljYXRpb24uDQpC dXQsIGFnYWluIHRoZSBzZWxlY3RvciBpcyB0aGUgc2FtZSBhcyB0aGUgb25lIGluIFJGQzYzNzgg YW5kIG90aGVyIElUVS1UIFJlY3MuDQoNCg0KDQojNC4gVGhlIGFjdGlvbiBvbiB3aGljaCBwYXRo IHRoZSBMRVIgc2hvdWxkIHNlbmQgdGhlIHRyYWZmaWMgaXMgdGhlIHNhbWUsIGJ1dCB0aGUgc2lu ayBub2RlIHNob3VsZCBkZXRlcm1pbmUgZnJvbSB3aGljaCBwYXRoIHRoZSB0cmFmZmljIHNob3Vs ZCBiZSByZWNlaXZlZC4gSW4gb3JkZXIgdG8gZGV0ZXJtaW5lIHRoZSBwb3NpdGlvbiBvZiB0aGUg c2VsZWN0b3IgKmF0IHRoZSBzaW5rIG5vZGUqLCB3ZSBuZWVkIHRvIHJlc29sdmUgdGhlIGNvbmZs aWN0Lg0KeXc+PiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhhdCBpdCBpcyBvbmx5IHRoZSBy ZWNlaXZpbmcgTEVSIHRoYXQgY2FuIGRldGVybWluZSBhbmQgZ2VuZXJhdGUgdGhlIFNEIHNpbmNl IHRoZSBqdWRnZW1lbnQgb2YgYSBkZWdyYWRlIGluIHRoZSByZWNwdGlvbiBub3QgaW4gdGhlIHRy YW5zbWlzc2lvbiwgaXNuJ3QgdGhpcyB0cnVlPyBBbmQgYWdhaW4gdGhpcyBpcyByZWxhdGVkIHRv IHRoZSBpbmNvbXBsZXRlIGRlc2NyaXB0aW9uIG9mIHRoZSBiZWhhdmlvciBvZiB0aGUgc2luayBM RVIgaW4gdGhlIHByb3RlY3Rpb24gZnJvbSBTRCBiZWhhdmlvci4NCiM1LiBJIHRvdGFsbHkgYWdy ZWUgd2l0aCB5b3UuIFBsZWFzZSBzZWUgbXkgZWFybGllciBlbWFpbCBvbiB2ZXJzaW9uIG51bWJl ci4NCiM2LiBZb3VyIGltcHJlc3Npb24gb24gdGhlIGxpbmVhciBwcm90ZWN0aW9uIGlzIHRoZSBz YW1lIGFzIG1pbmUuIFRoaXMgc2VjdGlvbiBuZWVkcyB0byBiZSByZXdyaXR0ZW4uIEluIG15IG9w aW5pb24sIHdlIHNob3VsZCBub3QgdXNlIHRoZSB0ZXJtLCB0aGUgbGlmZSBvZiBQU0Mgc2Vzc2lv bi4gQXMgSSBtZW50aW9uZWQgaW4gbXkgZW1haWwgcmVzcG9uZGluZyB0byB0aGUgQUQgUmV2aWV3 IGNvbW1lbnRzLCBTZWN0aW9uIDkgc2hvdWxkIGJlIHJld3JpdHRlbiAob3IgcmVtb3ZlZCBpZiB3 ZSBjYW4gY2hhbmdlIHRoZSB2ZXJzaW9uIG51bWJlcikuIEluIG15IG9waW5pb24sIHlvdXIgc3Vn Z2VzdGlvbiBpbiAjNSBpcyBhbHNvIGJldHRlciB0aGFuIGFzIGlzIG5vdy4NCiM3LiBJIHRvdGFs bHkgYWdyZWUgd2l0aCB5b3Ugb24gY2hhbmdpbmcgdGhlIHZlcnNpb24gbnVtYmVyLg0KIzguIFdl IGZvbGxvd2VkIHRoZSBzYW1lIGdyb3VwaW5nIGFzIGluIFJGQyA2Mzc4LiBJbiBTZWN0aW9uIDQu My4zLjIgb2YgUkZDIDYzNzgsIHRoZSBzZWNvbmQgcGFyYWdyYXBoIHNheXM6DQpUaGUgcHJvdGVj dGlvbiBkb21haW4gd2lsbCBleGl0IHRoZSBVbmF2YWlsYWJsZSBzdGF0ZSBhbmQgcmV2ZXJ0IHRv DQp0aGUgTm9ybWFsIHN0YXRlIHdoZW4gZWl0aGVyIHRoZSBvcGVyYXRvciBjbGVhcnMgdGhlIExv Y2tvdXQgY29tbWFuZA0Kb3IgdGhlIHByb3RlY3Rpb24gcGF0aCByZWNvdmVycyBmcm9tIHRoZSBz aWduYWwgZmFpbCBvciBkZWdyYWRlZA0Kc2l0dWF0aW9uLg0KQmFzZWQgdXBvbiB0aGlzLCB3ZSBw dXQgU0QtUCBpbiBVbmF2YWlsYWJsZSBzdGF0ZS4gQXMgeW91IGtub3csIHRoZSBuYW1lIG9mIHRo ZSBzdGF0ZSBkb2VzIG5vdCBhZmZlY3QgdGhlIGFjdGlvbiB0YWtlbiBieSB0aGUgUFNDIHByb2Nl c3MuIFdoYXQgYWZmZWN0cyB0aGUgYWN0aW9uIGlzIHRoZSBleHRlbmRlZCBzdGF0ZSwgd2hpY2gg c2hvd3MgdGhlIHJlcXVlc3QgYW5kIHRoZSBzb3VyY2Ugb2YgdGhlIHJlcXVlc3QuIElmIHlvdSB3 YW50IHRvIHN1Z2dlc3QgYW55IG90aGVyIGFwcHJvcHJpYXRlIHN0YXRlLCBJIGFtIHJlYWR5IHRv IGhlYXIuDQo9PT09PT09PT09PQ0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbSA6ICJZYWFjb3YgV2VpbmdhcnRl biIgPHd5YWFjb3ZAZ21haWwuY29tPG1haWx0bzp3eWFhY292QGdtYWlsLmNvbT4+DQpTZW50IDog MjAxNC0wMS0yOCAwNToxMjoxNiAoICswOTowMCApDQpUbyA6IExvYSBBbmRlcnNzb24gPGxvYUBw aS5udTxtYWlsdG86bG9hQHBpLm51Pj4NCkNjIDogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4gPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PiwgbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiA8bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn Pj4sIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4gPGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dUB0b29scy5pZXRmLm9yZz4+LCA8bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMt YWRzQHRvb2xzLmlldGYub3JnPj4NClN1YmplY3QgOiBSZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxDQoNCkhpIGFsbCwNCg0KSSBo YXZlIHJlYWQgdGhyb3VnaCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhpcyBkcmFmdCBhbmQgaGF2 ZSBhIG51bWJlciBvZiBjb21tZW50cyBhbmQgcXVlc3Rpb25zIHJlZ2FyZGluZyB0aGlzIGRvY3Vt ZW50LiBXaGlsZSwgaW4gZ2VuZXJhbCwgSSBmZWVsIHRoYXQgdGhlIGV4dGVuc2lvbnMgdG8gdGhl IGJlaGF2aW9yIG9mIFJGQzYzNzggYXJlIGFwcHJvcHJpYXRlLCBJIGZpbmQgdGhhdCB0aGlzIGRv Y3VtZW50IGlzIHN0aWxsIGluIG5lZWQgb2YgcmVmaW5lbWVudCBpbiBpdHMgbGFuZ3VhZ2UgYW5k IGNsYXJpdHkgb2YgdGhlIGZ1bmN0aW9uYWxpdHkuIFdoaWxlIHNvbWUgb2YgdGhlIGFkZGl0aW9u YWwgZnVuY3Rpb25hbGl0eSBpcyBkZXNjcmliZWQsIHRoZXJlIGFyZSBkaWZmZXJlbnQgY2FzZXMg b2YgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyBlaXRoZXIgbm90IGRlc2NyaWJlZCBvciBpcyBy YXRoZXIgY29uZnVzaW5nLg0KDQpPbmUgYmFzaWMgcXVlc3Rpb24gaXMgLSBDb25zaWRlcmluZyB0 aGF0IHRoaXMgZHJhZnQgaXMgcHJvcG9zaW5nIGNoYW5nZXMgdG8gdGhlIGJhc2ljIG9wZXJhdGlv biBvZiB0aGUgUFNDIHByb3RvY29sLCBMb2NhbCBSZXF1ZXN0IExvZ2ljLCBhbmQgdGhlIFBTQyBD b250cm9sIExvZ2ljLCBJIHdvdWxkIGhhdmUgdGhvdWdodCB0aGF0IHRoZSBQU0MgVmVyc2lvbiBu dW1iZXIgc2hvdWxkIGNoYW5nZSEgV2h5IHRoZW4sIGlzIHRoZXJlIG5vIG1lbnRpb24gb2YgY2hh bmdpbmcgdGhlIHZlcnNpb24gdG8gYWxsb3cgbmV0d29ya3MgdGhhdCBzdXBwb3J0IHRoZSBmdW5j dGlvbmFsaXR5IGRlc2NyaWJlZCBpbiBSRkM2Mzc4IHRvIGNvbnRpbnVlIHRvIG9wZXJhdGU/DQoN ClJlZ2FyZGluZyB0aGUgZnVuY3Rpb25hbGl0eSBwcm9wb3NlZCBpbiB0aGUgZHJhZnQsIEkgaGF2 ZSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgLQ0KDQogIDEuICAoZm9yIGNs YXJpZmljYXRpb24pIFJlZ2FyZGluZyB0aGUgZnVuY3Rpb25hbGl0eSBvZiBNUy1XLCB3aGF0IGlz IHRoZSBmdW5jdGlvbmFsaXR5IGlmIHRoZSBkYXRhLXRyYWZmaWMgaXMgY3VycmVudGx5IG9uIHRo ZSB3b3JraW5nIHBhdGg/IFNpbmNlIHRoZSBwdXJwb3NlIG9mIHRoZSBjb21tYW5kIGlzIHRvIG1v dmUgdGhlIHRyYWZmaWMgdG8gdGhlIHdvcmtpbmcgcGF0aCwgc2hvdWxkbid0IGl0IGJlIGlnbm9y ZWQ/IEhvd2V2ZXIsIGFjY29yZGluZyB0byB0aGUgU3RhdGUgVHJhbnNpdGlvbiBUYWJsZSBpbiBz ZWN0aW9uIDExLjEgLSBpZiB0aGUgTVMtVyBpcyByZWNlaXZlZCBieSBhIExFUiBpbiBOb3JtYWwg U3RhdGUgaXQgdHJhbnNmZXJzIHRvIFN3aXRjaGluZyBBZG1pbmlzdHJhdGl2ZSBTdGF0ZSEgVGhl IG1haW4gZWZmZWN0IHNlZW1zIHRvIGJlIHRvIGNhdXNlIHRoZSBMRVIgdG8gaWdub3JlIGluY29t aW5nIE1TIGFuZCBFWEVSIHJlcXVlc3RzICh0aGF0IGFyZSBub3QgaWdub3JlZCBpbiBOb3JtYWwg U3RhdGUpLg0KICAyLiAgUmVnYXJkaW5nIHRoZSBTRCBmdW5jdGlvbmFsaXR5IC0gYWZ0ZXIgYSBw cmV2aW91cyBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QgdGhlIGZ1bmN0aW9uYWxpdHkg d2hlbiBwcm90ZWN0aW5nIGZvciBTRCBzaXR1YXRpb25zIChkZXNjcmliZWQgaW4gU2VjdGlvbiA3 LjMpIHdhcyBjaGFuZ2VkIHRvIGVzc2VudGlhbGx5IHN3aXRjaCBvdmVyIHRvIHRoZSBMRVIgdHJh bnNtaXR0aW5nIHRoZSBwYWNrZXRzIG9uIGJvdGggdGhlIHdvcmtpbmcgYW5kIHByb3RlY3Rpb24g cGF0aHMgKGVzc2VudGlhbGx5IDErMSB0cmFuc21pc3Npb24pLiBIb3dldmVyLCB0aGVyZSBpcyB2 ZXJ5IGxpdHRsZSBkaXNjdXNzaW9uIG9mIGhvdyB0aGUgcmVjZWl2aW5nIExFUiBpcyBzdXBwb3Nl ZCB0byBzZWxlY3QgdGhlIGluY29taW5nIHBhY2tldHMgd2hpbGUgYXZvaWRpbmcgZHVwbGljYXRp b24gb2YgZGF0YS4gQ291bGQgcGxlYXNlIGVsYWJvcmF0ZSBvbiB0aGlzPw0KICAzLiAgUmVnYXJk aW5nIHRoZSBTRCBmdW5jdGlvbmFsaXR5IC0gYXMgbWVudGlvbmVkIGluIHRoZSBwcmV2aW91cyBw b2ludCwgd2hlbiBwcm90ZWN0aW5nIGZvciBTRCwgdGhlIHRyYW5zbWl0dGluZyBMRVIgZHVwbGlj YXRlcyB0aGUgcGFja2V0cyBvbiBib3RoIFcgJiBQIGFuZCB0aGUgcmVjZWl2aW5nIExFUiwgcHJl c3VtYWJseSwgcmVhZHMgdGhlIGRhdGEgZnJvbSBlaXRoZXIgcGF0aCwgYW5kIG1heSBjaG9vc2Ug ZGlmZmVyZW50bHkgZm9yIGRpZmZlcmVudCBwYWNrZXRzLiBIb3dldmVyLCBsYXRlciBpbiBzZWN0 aW9uIDcuNCAoYW5kIGFnYWluIGluIHNlY3Rpb24gMTAuMikgeW91IGludHJvZHVjZSBhIG5ldyBj b25jZXB0IG9mICJzdGFuZGJ5IHBhdGgiIGFzICJ0aGUgcGF0aCBmcm9tIHdoaWNoIHRoZSBzZWxl Y3RvciBkb2VzIG5vdCBzZWxlY3QgdGhlIHVzZXIgZGF0YSB0cmFmZmljIiBpbiByZWdhcmQgdG8g ZGV0ZXJtaW5pbmcgdGhlIHByaW9yaXR5IG9mICJjb25mbGljdGluZyIgU0QtVyBhbmQgU0QtUCB0 cmlnZ2Vycy4gQ2FuIHlvdSBjbGFyaWZ5IHdoaWNoIG9mIHRoZSB0d28gcGF0aHMgdGhhdCBhcmUg Ym90aCBjYXJyeWluZyB1c2VyIGRhdGEgaXMgdGhlIHN0YW5kYnkgcGF0aD8NCiAgNC4gIEZ1cnRo ZXIgcmVnYXJkaW5nIHRoZSBwb2ludCBvZiAiY29uZmxpY3RpbmciIFNEIHRyaWdnZXJzIC0gc2lu Y2UgdGhlIHByb3RlY3Rpb24gZnVuY3Rpb25hbGl0eSBvZiBTRCBpcyB0byBkdXBsaWNhdGUgdGhl IGRhdGEgb24gYm90aCBXICYgUCAtIHdoeSBpcyB0aGlzIGNvbnNpZGVyZWQgYSBjb25mbGljdCwg c2luY2UgdGhlIGFjdGlvbiBmb3IgYm90aCB3aWxsIGJlIGlkZW50aWNhbCAtIGNvbnRpbnVlIHRy YW5zbWl0dGluZyBvbiBib3RoIFcgJiBQLiBTb21lIG1vcmUgY2xhcmlmaWNhdGlvbiB3b3VsZCBo ZWxwLg0KICA1LiAgUmVnYXJkaW5nIHRoZSBBUFMgbW9kZSBhbmQgc3ViLWNhcGFiaWxpdGllcyAt IFlvdSBkZXNjcmliZSBpbiBzZWN0aW9uIDkuMSBob3cgYW4gTEVSIGNhbiBkZWNsYXJlIGl0c2Vs ZiB0byBzdXBwb3J0IG9ubHkgc29tZSBvZiB0aGUgY2FwYWJpbGl0aWVzIGludHJvZHVjZWQgaW4g dGhlIGRyYWZ0LCBhbmQgdGhlbiBkZXNjcmliZSB0aGUgQVBTICJtb2RlIiAoU2VjdGlvbiA5LjIu MikgYXMgZGVjbGFyYXRpb24gb2Ygc3VwcG9ydCBmb3IgYWxsIG9mIHRoZSBjYXBhYmlsaXRpZXMs IGkuZS4gRmxhZ3MgPSAweEY4MDAwMDAwLiBGcm9tIHRoaXMgcG9pbnQgb24gKGluIHBhcnRpY3Vs YXIgc2VjdGlvbiAxMSksIHlvdSBkZXNjcmliZSB0aGUgZnVuY3Rpb25hbGl0eSBmb3IgTEVSIHRo YXQgZGVjbGFyZSBGbGFncz0gZWl0aGVyIDB4MCwgb3IgMHhGODAwMDAwMCwgaG93ZXZlciwgdGhl cmUgaXMgbm8gZXhwbGFuYXRpb24gZm9yIHBhdGhzIHRoYXQgZGVjbGFyZSBzb21lIG90aGVyIHZh bHVlIG9mIEZsYWdzIChmb3IgZXhhbXBsZSwgMHg4MDAwMDAwIC0gc3VwcG9ydGluZyBvbmx5IHRo ZSBFWEVSIGZ1bmN0aW9uYWxpdHkpLiBJcyB0aGVyZSBhIHJlYXNvbiBmb3IgdGhpcz8gQXJlIHdl IGFzc3VtaW5nIHRoYXQgYWxsIHBhdGhzIHdpbGwgZWl0aGVyIHN1cHBvcnQgUFNDIG9yIEFQUyBt b2RlcyBvbmx5PyBJZiBzbywgd2h5IG5vdCBqdXN0IGhhdmUgdHdvIHZhbHVlcyBmb3IgRmxhZ3Mg cmF0aGVyIHRoYW4gdGhpcyBleHRlbnNpYmxlIGJpdCBtYXAgdmFsdWU/DQogIDYuICBSZWdhcmRp bmcgIlBTQyBzZXNzaW9ucyIgLSBJbiBzZWN0aW9uIDkuMyB5b3UgaW50cm9kdWNlIGEgbmV3IGNv bmNlcHQgb2YgUFNDIHNlc3Npb24sIHdpdGhvdXQgYW55IGRlZmluaXRpb24gb2Ygd2hlbiB0aGlz IHNlc3Npb24gYmVnaW5zIG9yIGVuZHMuIENvdWxkIHlvdSBlbGFib3JhdGUgb24gd2hhdCBpcyBt ZWFudCBieSB0aGUgImxpZmUgb2YgYSBQU0Mgc2Vzc2lvbiI/IFVudGlsIG5vdywgSSB3YXMgdW5k ZXIgdGhlIGltcHJlc3Npb24gdGhhdCBsaW5lYXIgcHJvdGVjdGlvbiBzdGFydGVkIHdpdGggdGhl IGNyZWF0aW9uIG9mIHRoZSBwcm90ZWN0aW9uIGRvbWFpbiBhbmQgY29udGludWVkIHVudGlsIHRo ZSBwYXRocyB3ZXJlIHRvcm4gZG93bi4gSXMgdGhpcyBpbmNvcnJlY3Q/DQogIDcuICBUaGVyZSBp cyBhIHN0YXRlbWVudCBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiBzZWN0aW9uIDkuMyB0aGF0 IHN0YXRlcyAiUkZDNjM3OCBkb2VzIG5vdCBkZWZpbmUgaG93IHRvIGhhbmRsZSBhbiB1bnJlY29n bml6ZWQgVExWLiIgQWN0dWFsbHksIHdoYXQgUkZDNjM3OCBkZWZpbmVzIGlzICJ0aGVyZSBhcmUg bm8gVExWIHVuaXRzIGRlZmluZWQgZm9yIHRoZSBiYXNpYyBQU0Mgb3BlcmF0aW9uIiBhbmQgdGhl cmVmb3JlIHRoZSBUTFZzIGFyZSBpZ25vcmVkLiBBbm90aGVyIHJlYXNvbiwgSU1PLCB0byBjaGFu Z2UgdGhlIHZlcnNpb24gbnVtYmVyIG9mIHRoZSBwcm90b2NvbCBpbiB0aGlzIGRyYWZ0Lg0KICA4 LiAgSXQgaXMgdW5jbGVhciB0byBtZSAtIHdoeSB3aGVuIHJlY2VpdmluZyBhIFNELVAgaW5kaWNh dGlvbiBpbiBOb3JtYWwgd2h5IHlvdSBjb25zaWRlciB0aGlzIHRvIGJlICJVbmF2YWlhYmxlIiBz aW5jZSB0aGUgYWN0aW9uIHRha2VuIGZvciBhbiBTRCBzaXR1YXRpb24gaXMgdG8gcG9zc2libHkg dHJhbnNtaXQgb24gYm90aCBXICYgUC4NCg0KSSBwbGFuIG9uIHN1Ym1pdHRpbmcgc29tZSBlZGl0 b3JpYWwgY29tbWVudHMgaW4gYSBmdXR1cmUgcG9zdCwgYnV0IHdvdWxkIGxpa2UgdG8gZ2V0IHNv bWUgY2xhcmlmaWNhdGlvbiBvbiB0aGVzZSBwb2ludHMgYmVmb3JlIHRoZSBkcmFmdCBhZHZhbmNl cyB0byBhY2NlcHRhbmNlLg0KDQpUaGFueCwNCnlhYWNvdg0KDQoNCk9uIE1vbiwgSmFuIDIwLCAy MDE0IGF0IDQ6MjggQU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51 Pj4gd3JvdGU6DQpXb3JraW5nIEdyb3VwLA0KDQpUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsg d29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1Lg0K DQpQbGVhc2UgZmluZCB0aGUgZG9jdW1lbnQgYXQ6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS8NCg0KVGhlIGRvY3VtZW50IGVkaXRv cnMgaGFzIGFsc28gc3VwcGxpZWQgYSAiZGlmZi1saXN0IiBiZXR3ZWVuDQp2ZXJzaW9uIC0wMCBh bmQgLTAxIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3Vy cmVudC9tc2cxMTMzOC5odG1sDQoNCklUVS1UIFNHMTUgaGFzIGFkdmlzZWQgdXMgdGhhdCB0aGlz IGRvY3VtZW50IGlzIGEgbmVjZXNzYXJ5IHJlZmVyZW5jZQ0KZm9yIGRvY3VtZW50cyB0aGF0IGlz IHBsYW5uZWQgdG8gZ28gaW50byB0aGUgSVRVLVQgYXBwcm92YWwgcHJvY2Vzcw0KZnJvbSB0aGUg U0cxNSBtZWV0aW5nIGVuZCBvZiBNYXJjaCAvIGJlZ2lubmluZyBvZiBBcHJpbC4gRWRpdG9ycywN CmF1dGhvcnMgYW5kIGNoYWlycyBoYXMgcHV0IGluIHF1aXRlIGFuIGVmZm9ydCB0byBtYWtlIHRo aXMgZG9jdW1lbnQNCnJlYWR5LiBUaGUgc2NoZWR1bGUgaXMgdmVyeSB0aWdodC4NCg0KV2UgYXJl IG5vdyBkb2luZyBzZXZlcmFsIHJldmlldyBzdGVwcyBpbiBwYXJhbGxlbA0KDQotIHRoZSBub3Jt YWwgd29ya2luZyBncm91cCBsYXN0IGNhbGwsIHBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8g dGhlDQogIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+KQ0KLSB0aGUgd29ya2luZyBncm91cCBjaGFpcnMgcmV2aWV3ZWQg dGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZQ0KICBtcGxzLXJ0IHJldmlldywgbm9ybWFsbHkg d2UgZG8gYSB3ZyBjaGFpciByZXZpZXcgYmVmb3JlIHN0YXJ0aW5nIHRoZQ0KICB3Z2xjLCB0aGlz IHJldmlldyB3aWxsIG5vdyB0YWtlIHBsYWNlIGluIHBhcmFsbGVsDQotIGFmdGVyIHRoZSB3Z2xj IGFuZCBwdWJsaWNhdGlvbiByZXF1ZXN0IHRoZXJlIGlzIGFuIEFEIGV2YWx1YXRpb24sDQogIHRo aXMgd2lsbCBub3cgYWxzbyB0YWtlIHBsYWNlIGluIHBhcmFsbGVsIHdpdGggdGhlIHdnbGMNCg0K VGhlIGVkaXRvcnMgYW5kIGF1dGhvcnMgYXJlIGFkdmlzZWQgdG8gdHJ5IHRvIHJlc29sdmUgYXMg bWFueSBvZiB0aGUNCmNvbW1lbnRzIGFzIHBvc3NpYmxlIChvbiB0aGUgbWFpbGluZyBsaXN0KSBh cyB0aGV5IGNvbWUgaW4sIGJ1dCBub3QgdG8NCnBvc3QgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBk cmFmdCB1bnRpbCB0aGUgd2dsYyBpcyBjbG9zZWQgYW5kIHRoZQ0KY29tbWVudHMgYXJlIHJlc29s dmVkLg0KDQpUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgRmVicnVhcnkgM3JkLg0K DQovTG9hDQpmb3IgdGhlIE1QTFMgV0cgY28tY2hhaXJzDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24g ICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0 bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAg ICAgICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xv Z2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUy MDczOSUyMDgxJTIwMjElMjA2ND4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBs c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K DQoNCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0KDQpTdGlsbCBsb29raW5nIGZvciBuZXcg b3Bwb3J0dW5pdHkNCg0KDQoNCi0tDQpUaGFueCBhbmQgQlIsDQp5YWFjb3YNCg0KU3RpbGwgbG9v a2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DCFSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5ZYWFjb3YsIGFnYWluIHRoYW5rcyBmb3ImbmJz cDt5b3VyIGNvbW1lbnRzLjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPkR1ZSB0byB0aGUgbHVhciBOZXcgWWVhciBicmVhaywgSSB3YXMgYSBsaXR0bGUgYmVoaW5k LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPlBsZWFzZSBzZWUgbXkgcmVz cG9uc2VzIHN0YXJ0aW5nIHdpdGggPGZvbnQgY29sb3I9IiMwMDAwZmYiPg0KW0pSXTxicj4NCjwv Zm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5KZW9uZy1kb25nPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxTaWduIj48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtZYWFjb3Yg V2VpbmdhcnRlbiZxdW90OyAmbHQ7d3lhYWNvdkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U2VudCA6 IDwvYj4yMDE0LTAxLTI5IDIxOjQ3OjA5ICggJiM0MzswOTowMCApPGJyPg0KPGI+VG8gOiA8L2I+ UnlvbywgSmVvbmctZG9uZyAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0Ozxicj4NCjxiPkNjIDogPC9i PkxvYSBBbmRlcnNzb24gJmx0O2xvYUBwaS5udSZndDssIG1wbHNAaWV0Zi5vcmcgJmx0O21wbHNA aWV0Zi5vcmcmZ3Q7LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmcmZ3Q7LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZyAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdCA6IDwvYj5SZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGRy YWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCIgZGlyPSJsdHIiPkplb25nLWRvbmcsIGhpDQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgZm9yIHlvdXIgZGV0YWlsZWQgcmVwbHkgdG8gbXkgY29t bWVudHMgLSBzb21lIGNvdW50ZXIgY29tbWVudHMgYXBwZWFyIGJlbG93IHByZWZpeGVkIGJ5ICZx dW90O3l3Jmd0OyZndDsmcXVvdDsuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbiBh ZGRpdGlvbiwgSSB3b3VsZCBsaWtlIHRvIGFkZCB0aGUgZm9sbG93aW5nIGNvbW1lbnQgLSByZWdh cmRpbmcgdGhlIG5vdGVzIG9uIHRoZSBTdGF0ZSB0YWJsZXMgYW5kIGVzcGVjaWFsbHkgbm90ZSAj MS4gSW4gdGhpcyBub3RlIHlvdSBzdGF0ZSZxdW90O1JlLWV2YWx1YXRlIHRvIGRldGVybWluZSBm aW5hbCBzdGF0ZSBhcyBpZiB0aGUgTEVSIGlzIGluIHRoZSBOb3JtYWwgc3RhdGUuJnF1b3Q7IFRo aXMgbmVlZHMgbW9yZSBjbGFyaWZpY2F0aW9uLCBJTU8sDQogc2luY2UgdGhpcyBjb3VsZCBiZSBy ZWFkIGFzIHN0YXRpbmcgdGhhdCBpZiB0aGVyZSBpcyBubyBjdXJyZW50bHkgYWN0aXZlIHRyaWdn ZXIgdGhlbiByZW1haW4gaW4gdGhlIGN1cnJlbnQgc3RhdGUhJm5ic3A7PC9kaXY+DQo8ZGl2PlRo ZXJlZm9yZSBJIHRoaW5rIHRoYXQgeW91IHNob3VsZCBleHBsaWNpdGx5IHN0YXRlICZxdW90O1Jl LWV2YWx1YXRlIHRvIGRldGVybWluZSBmaW5hbCBzdGF0ZSBhcyBpZiB0aGUgTEVSIGlzIGluIHRo ZSBOb3JtYWwgc3RhdGUuIElmIHRoZXJlIGFyZSBubyBhY3RpdmUgdHJpZ2dlcnMsIHRoZSBMRVIg ZW50ZXJzIE5vcm1hbCBTdGF0ZS4mcXVvdDsgKE9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhpcyBp cyB0aGUgaW50ZW50aW9uISkgU2ltaWxhciBjb3JyZWN0aW9ucw0KIHNob3VsZCBiZSBjb25zaWRl cmVkIGZvciBub3RlcyAyLDMsNS48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwZmYiPltK Ul0gWWVzLCBJIGFncmVlIHdpdGggeW91LiBUaGF0IHdhcyB0aGUgaW50ZW50aW9uLCBidXQgY3Vy cmVudCBkZXNjcmlwdGlvbiBpcyBub3QgY29tcGxldGUuIEl0IHNob3VsZCBiZSBjb3JyZWN0ZWQg aW4gbmV4dCB2ZXJzaW9uIGFzIHlvdSBzdWdnZXN0ZWQuPC9mb250PjwvZGl2Pg0KPGRpdj48YnI+ DQombmJzcDs8L2Rpdj4NCjxkaXY+VGhhbngsPC9kaXY+DQo8ZGl2PnlhYWNvdjwvZGl2Pg0KPGRp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gVHVlLCBKYW4gMjgsIDIwMTQgYXQgMTE6NDEgQU0sIFJ5b28sIEplb25nLWRv bmcgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpyeW9vQGV0cmkucmUua3Ii IHRhcmdldD0iX2JsYW5rIj5yeW9vQGV0cmkucmUua3I8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBz b2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIGNsYXNz PSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBG T05ULVNJWkU6IDEwcHQiPg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsIj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20g MGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj5ZYWFjb3YsPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5BZ2FpbiwgdGhhbmtzIGZvciB0aGUgY29tbWVudHMu DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPkkgcmVhbGx5IGFwcHJlY2lhdGUgeW91ciBoZWxwIG9uIHRoaXMgZG9jdW1lbnQuPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5UaGUg Zm9sbG93aW5ncyBhcmUgbXkgcmVzcG9uc2VzIHRvIHlvdXIgY29tbWVudHM6PC9mb250Pjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj49PT09PT09PTwv Zm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ IzEuIFllcywgeW91IGRlc2NyaWJlZCB0aGUgY29ycmVjdCBiZWhhdmlvciBvZiBNUy1XLiBBcyB5 b3UgaW5kaWNhdGVkLCBNUyBhbmQgRVhFUiBhcmUgc3VwcG9zZWQgdG8gYmUgaWdub3JlZCB3aGls ZSBNUy1XIGlzIGluIGVmZmVjdC48L2ZvbnQ+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pnl3Jmd0OyZndDsgSSB0 aGluayB0aGF0IGlmIHRoaXMgaXMgdGhlIGNhc2UgdGhhdCBpdCBiZSBleHBsaWNpdGx5IHN0YXRl ZCBpbiB0aGUgdGV4dC48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwZmYiPltKUl0gVGhl IG5leHQgdmVyc2lvbiBvZiBkcmFmdCBzaG91bGQgaGF2ZSB0aGlzLjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjog MHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiBjbGFzcz0iZ21haWxfcXVvdGUi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbDsgRk9OVC1TSVpFOiAxMHB0 Ij4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQiPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+IzIuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbW9kaWZ5IHRoZSBvcGVyYXRpb24gb2YgdGhl IHNlbGVjdG9yIGRlc2NyaWJlZCBpbiBSRkM2Mzc4LiBBY2NvcmRpbmcgdG8gUkZDNjM3OCwgdGhl IHNlbGVjdG9yIHNlbGVjdHMgdGhlIHRyYWZmaWMgZnJvbSBvbmx5IG9uZSBvZiB0aGUgcGF0aHMg bm8NCiBtYXR0ZXIgaWYgdGhlIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJlIGlzIDE6MSBvciAxJiM0 MzsxLiBJZiB5b3UgdGhpbmsgaXQgaXMgYXBwcm9wcmlhdGUgdG8gbWFrZSB0aGlzIGNsZWFyLCB0 aGVuIHdlIGNhbiBhZGQgc29tZXRoaW5nIGxpa2U6DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIiBsYW5nPSJFTi1VUyI+4oCcVGhpcyBkb2N1bWVu dCBkb2VzIG5vdCBtb2RpZnkgdGhlIG9wZXJhdGlvbiBvZiB0aGUgc2VsZWN0b3IgYXQgdGhlIHNp bmsgTEVSIGRlc2NyaWJlZCBpbiBSRkMgNjM3OC4gVGhlIHNlbGVjdG9yIGF0IHRoZSBzaW5rIExF UiBjaG9vc2VzIGVpdGhlciB0aGUgd29ya2luZw0KIG9yIHByb3RlY3Rpb24gcGF0aCBmcm9tIHdo aWNoIHRvIHJlY2VpdmUgdGhlIG5vcm1hbCB0cmFmZmljIGluIGJvdGggMToxIGFuZCAxJiM0Mzsx IGFyY2hpdGVjdHVyZXMuIFRoZSBwb3NpdGlvbiBvZiB0aGUgc2VsZWN0b3IsIGkuZS4sIHdoaWNo IHBhdGggdG8gcmVjZWl2ZSB0aGUgdHJhZmZpYywgaXMgZGV0ZXJtaW5lZCBieSB0aGUgUFNDIHBy b3RvY29sIGluIGJpZGlyZWN0aW9uYWwgc3dpdGNoaW5nIG9yIGJ5IHRoZSBsb2NhbCBpbnB1dCBp biB1bmlkaXJlY3Rpb25hbA0KIHN3aXRjaGluZy7igJ08L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QXMgYSBtYXR0ZXIgb2YgZmFjdCwgYWNjb3JkaW5n IHRvIFJGQyA0NDI3IChhbmQgYWxsIHRoZSBJVFUtVCBwcm90ZWN0aW9uIGRvY3VtZW50cyksIGEg c2VsZWN0b3IgcmVmZXJzIHRvIHRoZSBlbnRpdHkgYXQgdGhlIHNpbmsgbm9kZSBvbmx5LiBGb3Ig dGhlIHNvdXJjZSBub2RlLCBhIGJyaWRnZQ0KIGlzIHVzZWQgdG8gY2hvb3NlIHdoaWNoIHBhdGgg KG9uZSBvZiB0d28gcGF0aHMgaW4gMToxLCBvciBib3RoIHBhdGhzIGluIDEmIzQzOzEpIHRvIHRy YW5zbWl0IHRoZSB0cmFmZmljLiBUaGVyZWZvcmUsIOKAnHRoZSBzZWxlY3RvciBpbiB0aGUgc2lu ayBMRVLigJ0gaXMgcmVkdW5kYW50IGFuZCBzaG91bGQgaGF2ZSBiZWVuIHJlcGxhY2VkIHdpdGgg anVzdCDigJx0aGUgc2VsZWN0b3LigJ0uIEJ1dCwgdGhlIGRlc2NyaXB0aW9ucyBvZiB0aGUgc2Vs ZWN0b3IgYW5kIGJyaWRnZQ0KIGluIFJGQyA2Mzc4IGFyZSBzb21ld2hhdCBkaWZmZXJlbnQuIElu IFJGQyA2Mzc4LCB0aGUgc2VsZWN0b3IgaXMgdXNlZCBmb3IgYm90aCB0cmFuc21pdHRpbmcgYW5k IHJlY2VpdmluZyB0aGUgdHJhZmZpYywgd2hpbGUgdGhlIGJyaWRnZSBpcyB1c2VkIGZvciB0cmFu c21pdHRpbmcgb25seS4gVGhlIGRlc2NyaXB0aW9ucyBpbiBSRkMgNjM3OCBhcmUgbm90IHF1aXRl IGFsaWduZWQgd2l0aCBSRkMgNDQyNyAoYW5kIG90aGVyIElUVS1UIGRvY3MpLjwvZm9udD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAx cHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlh bDsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPHAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj4jMy4gQWdhaW4sIHRoaXMgaXMgZHVlIHRvIHRoZSBkaWZm ZXJlbnQgdW5kZXJzdGFuZGluZyBvbiB0aGUgc2VsZWN0b3IuIElmIHlvdSBzdGljayB0byB0aGUg dGVybWlub2xvZ3kgZGVmaW5lZCBpbiBSRkMgNDQyNyBhbmQgSVRVLVQsIHRoZW4geW91IG1heSBu b3QgaGF2ZSB0aGUgaXNzdWUgd2l0aA0KIGN1cnJlbnQgc2VudGVuY2VzLiBJbiB0aGUgbWVhbnRp bWUsIGFzIEkgZGlkIGluICMyLCBJIGNhbiBhZGQg4oCcaW4gdGhlIHNpbmsgTEVS4oCdIGFmdGVy IGV2ZXJ5IOKAnHRoZSBzZWxlY3RvcuKAnS4gSW4gb3RoZXIgd29yZHMsICZxdW90OzwvZm9udD48 L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIiBsYW5nPSJFTi1V UyI+dGhlIHBhdGggZnJvbSB3aGljaCB0aGUgc2VsZWN0b3IgZG9lcyBub3Qgc2VsZWN0IHRoZSB1 c2VyIGRhdGENCiB0cmFmZmljPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLr p5HsnYAg6rOg65SVIj4mcXVvdDsgY2FuIGJlIHJlcGxhY2VkIHdpdGgg4oCcJnF1b3Q7PC9mb250 Pjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciIGxhbmc9IkVO LVVTIj50aGUgcGF0aCBmcm9tIHdoaWNoIHRoZSBzZWxlY3RvciBhdCB0aGUgc2luayBMRVIgZG9l cyBub3Qgc2VsZWN0IHRoZSB1c2VyIGRhdGEgdHJhZmZpYzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+JnF1b3Q7PC9mb250Pjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj55dyZndDsmZ3Q7IEkgZGlkIG5vdCBoYXZlIGEgcHJvYmxlbSB3aXRoIHRoZSAmcXVvdDtzZWxl Y3RvciZxdW90OyB0ZXJtaW5vbG9neSBteSBwcm9ibGVtIHdhcyB3aXRoIHRoZSBkZXNjcmlwdGlv biBvZiB0aGUgU0QgcHJvdGVjdGlvbiBiZWhhdmlvciBpbiBzZWN0aW9uIDcuMy4gWW91IHN0YXRl IHRoZXJlIHRoYXQgdGhlIHByb3RlY3Rpb24gaXMgcHJvdmlkZWQgYnkgJnF1b3Q7YSBzZWxlY3Rv ciBicmlkZ2UgZHVwbGljYXRpbmcgdXNlciBkYXRhIHRyYWZmaWMmcXVvdDsgJm5ic3A7dGhlbiBs YXRlcg0KICZxdW90O3RoZSBMRVIgU0hBTEwgZHVwbGljYXRlIHVzZXIgZGF0YSB0cmFmZmljIGFu ZCBTSEFMTCBmZWVkIHRvIGJvdGguLi4mcXVvdDsgSG93ZXZlciwgdGhlcmUgaXMgbm8gZGVzY3Jp cHRpb24gb2Ygd2hhdCB0aGUgc2VsZWN0b3IgYXQgdGhlIHJlY2VpdmluZyBlbmQgaXMgZG9pbmcu PC9kaXY+DQo8ZGl2PlRoZXJlZm9yZSwgbXkgY29uY2x1c2lvbiBpcyB0aGF0IHRoZSByZWNlaXZp bmcgZW5kIHNlbGVjdHMgaW5jb21pbmcgZGF0YSB0cmFmZmljIGZvcm0gZWl0aGVyIHRoZSB3b3Jr aW5nIG9yIHByb3RlY3Rpb24gcGF0aCBvbiBhIHBlci1wYWNrZXQgYmFzaXMsIGkuZS4gcGFja2V0 IzEtNSBtYXkgYmUgc2VsZWN0ZWQgZnJvbSB0aGUgd29ya2luZyBwYXRoLCB3aGlsZSBwYWNrZXQj Ni03IG1heSBiZSBzZWxlY3RlZCBmcm9tIHRoZSBwcm90ZWN0aW9uDQogcGF0aCwgYW5kIHBhY2tl dCM4LTEwIGZyb20gd29ya2luZywgYW5kIHNvIG9uLiBJcyB0aGlzIGNvcnJlY3Q/IEFuZCBpZiBp dCBpcyBub3QgY29ycmVjdCBjb3VsZCB5b3UgcGxlYXNlIHByb3ZpZGUgdGV4dCB0aGF0IHByZWNs dWRlcyB0aGlzIGJlaGF2aW9yLjwvZGl2Pg0KPGRpdj5UaGUgbmV4dCBzdGVwIHRvIG15IHF1ZXN0 aW9uIGlzIHRoZW4gLSBpZiB0aGlzIGRlc2NyaXB0aW9uIGlzIGNvcnJlY3QgdGhlbiB0aGVyZSBp cyBubyAmcXVvdDtzdGFuZGJ5JnF1b3Q7IHBhdGggc2luY2UgdGhlIHNlbGVjdG9yIChhdCB0aGUg c2luayBMRVIpIG1heSBzd2l0Y2ggaW50ZXJtaXR0ZW50bHkgKGJhc2VkIG9uIHRoZSBxdWFsaXR5 IG9mIHRoZSB0cmFuc21pc3Npb24gYXQgdGhhdCBwb2ludCBpbiB0aW1lKSBiZXR3ZWVuIHRoZSB0 d28gcGF0aHMuDQogU28gY2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB0aGUgZGVmaW5pdGlvbj88L2Rp dj4NCjxkaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMDAwMGZmIj5bSlJdIFRoZSBzZWxlY3RvciZu YnNwO2lzIHRoZSBzYW1lIGFzIHRoZSBvbmUgaW4gUkZDNjM3OC4mbmJzcDsmbmJzcDs8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMDAwMGZmIj5UaGUgcG9zaXRpb24gb2YgdGhlIHNl bGVjdG9yIGlzIGRldGVybWluZWQgYnkgdGhlIFBTQyBwcm90b2NvbCBpbiBiaWRpcmVjdGlvbmFs IHN3aXRjaGluZy48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDBm ZiI+V2hlbiBTRC1XIGlzIGRldGVjdGVkIGluIHRoZSBOb3JtYWwgc3RhdGUsIHRoZSBsb2NhbCBM RVIgY2hhbmdlcyZuYnNwO2l0cyBzZWxlY3RvciZuYnNwO3Bvc2l0aW9uIHRvIHRoZSBwcm90ZWN0 aW9uIHBhdGgsIHNlbmRzIHRoZSB0cmFmZmljIHRvIGJvdGggcGF0aHMsJm5ic3A7YW5kIHRyYW5z bWl0cyBTRC1XIG1lc3NhZ2UuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDBm ZiI+V2hlbiB0aGUgU0QtVyBtZXNzYWdlIGFycml2ZXMgYXQgdGhlIHJlbW90ZSBMRVIsIHRoZSBy ZW1vdGUgTEVSIGNoYW5nZXMgaXQgc2VsZWN0b3IgcG9zaXRpb24gdG8gdGhlIHByb3RlY3Rpb24g cGF0aCwmbmJzcDthbmQgc2VuZHMgdGhlIHRyYWZmaWMgdG8gYm90aCBwYXRocy48L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMDAwMGZmIj5Ob3csIHRoZSBiZWhhdmlvciB3aWxsIGNv bnRpbnVlIHVudGlsIGFueSBuZXcmbmJzcDtoaWdoZXIgcmVxdWVzdCZuYnNwO29jY3Vycy4gSS5l Liwgbm8gZnVydGhlciBjaGFuZ2UmbmJzcDtvZiB0aGUgc2VsZWN0b3IgcG9zaXRpb24gdW50aWwg YW55IG5ldyBoaWdoZXIgcHJpb3JpdHkgcmVxdWVzdCBjb21lcyBpbi48L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGNvbG9yPSIjMDAwMGZmIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxmb250 IGNvbG9yPSIjMDAwMGZmIj5BdCB0aGUgdGltZSBTRC1XIG9jY3VycmVkIGF0IHRoZSBsb2NhbCBM RVIsIHRoZSBzdGFuZGJ5IHBhdGggd2FzIHRoZSBwcm90ZWN0aW9uIHBhdGggYXMgdGhlIHRyYWZm aWMgd2FzIHNlbGVjdGVkIGZyb20gdGhlIHdvcmtpbmcgcGF0aCBpbiB0aGUgTm9ybWFsIHN0YXRl LjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwZmYiPkFmdGVyIHR3byBMRVJz Jm5ic3A7YWN0IG9uJm5ic3A7U0QtVywgdGhlIHdvcmtpbmcgcGF0aCBiZWNvbWVzIHRoZSBzdGFu ZGJ5IHBhdGggYXMgdGhlIHRyYWZmaWMgaXMgc2VsZWN0ZWQgZnJvbSB0aGUgcHJvdGVjdGlvbiBw YXRoLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjwvZm9udD4mbmJz cDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+VGhlIG9wZXJhdGlv biB5b3UgZGVzY3JpYmVkIHdpdGggcGFja2V0IG51bWJlcnMmbmJzcDtpcyBub3QmbmJzcDt0aGUm bmJzcDtiZWhhdmlvciBpbiB0aGUgZG9jdW1lbnQuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBj b2xvcj0iIzAwMDBmZiI+V2UgYWN0dWFsbHkgd2FudGVkIHRvIGF2b2lkIHN1Y2ggYSBzaXR1YXRp b24gKHRyYWZmaWMgZmxhcHBpbmcpIGJ5IHVzaW5nIHRoaXMgYnJpZGdlIHdpdGggcGFja2V0IGR1 cGxpY2F0aW9uLg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+QnV0 LCBhZ2FpbiB0aGUgc2VsZWN0b3IgaXMgdGhlIHNhbWUgYXMgdGhlIG9uZSBpbiBSRkM2Mzc4IGFu ZCBvdGhlciBJVFUtVCBSZWNzLiZuYnNwOzwvZm9udD4mbmJzcDsmbmJzcDs8L2Rpdj4NCjxkaXY+ PGZvbnQgY29sb3I9IiMwMDAwZmYiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgY29s b3I9IiMwMDAwZmYiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHgg c29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiBjbGFz cz0iZ21haWxfcXVvdGUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbDsg Rk9OVC1TSVpFOiAxMHB0Ij4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+IzQuIFRoZSBhY3Rpb24gb24gd2hpY2ggcGF0aCB0aGUgTEVSIHNo b3VsZCBzZW5kIHRoZSB0cmFmZmljIGlzIHRoZSBzYW1lLCBidXQgdGhlIHNpbmsgbm9kZSBzaG91 bGQgZGV0ZXJtaW5lIGZyb20gd2hpY2ggcGF0aCB0aGUgdHJhZmZpYyBzaG91bGQgYmUgcmVjZWl2 ZWQuIEluIG9yZGVyIHRvDQogZGV0ZXJtaW5lIHRoZSBwb3NpdGlvbiBvZiB0aGUgc2VsZWN0b3Ig KmF0IHRoZSBzaW5rIG5vZGUqLCB3ZSBuZWVkIHRvIHJlc29sdmUgdGhlIGNvbmZsaWN0LjwvZm9u dD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+eXcmZ3Q7Jmd0OyBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhh dCBpdCBpcyBvbmx5IHRoZSByZWNlaXZpbmcgTEVSIHRoYXQgY2FuIGRldGVybWluZSBhbmQgZ2Vu ZXJhdGUgdGhlIFNEIHNpbmNlIHRoZSBqdWRnZW1lbnQgb2YgYSBkZWdyYWRlIGluIHRoZSByZWNw dGlvbiBub3QgaW4gdGhlIHRyYW5zbWlzc2lvbiwgaXNuJ3QgdGhpcyB0cnVlPyBBbmQgYWdhaW4g dGhpcyBpcyByZWxhdGVkIHRvIHRoZSBpbmNvbXBsZXRlIGRlc2NyaXB0aW9uIG9mDQogdGhlIGJl aGF2aW9yIG9mIHRoZSBzaW5rIExFUiBpbiB0aGUgcHJvdGVjdGlvbiBmcm9tIFNEIGJlaGF2aW9y LiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIw NCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1MRUZU OiAxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1J TFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiPg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFy aWFsIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+DQo8cCBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPiM1LiBJIHRvdGFsbHkgYWdyZWUgd2l0aCB5 b3UuIFBsZWFzZSBzZWUgbXkgZWFybGllciBlbWFpbCBvbiB2ZXJzaW9uIG51bWJlci4NCjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+IzYu IFlvdXIgaW1wcmVzc2lvbiBvbiB0aGUgbGluZWFyIHByb3RlY3Rpb24gaXMgdGhlIHNhbWUgYXMg bWluZS4gVGhpcyBzZWN0aW9uIG5lZWRzIHRvIGJlIHJld3JpdHRlbi4gSW4gbXkgb3Bpbmlvbiwg d2Ugc2hvdWxkIG5vdCB1c2UgdGhlIHRlcm0sIHRoZSBsaWZlIG9mIFBTQyBzZXNzaW9uLg0KIEFz IEkgbWVudGlvbmVkIGluIG15IGVtYWlsIHJlc3BvbmRpbmcgdG8gdGhlIEFEIFJldmlldyBjb21t ZW50cywgU2VjdGlvbiA5IHNob3VsZCBiZSByZXdyaXR0ZW4gKG9yIHJlbW92ZWQgaWYgd2UgY2Fu IGNoYW5nZSB0aGUgdmVyc2lvbiBudW1iZXIpLiBJbiBteSBvcGluaW9uLCB5b3VyIHN1Z2dlc3Rp b24gaW4gIzUgaXMgYWxzbyBiZXR0ZXIgdGhhbiBhcyBpcyBub3cuDQo8L2ZvbnQ+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPiM3LiBJIHRvdGFsbHkg YWdyZWUgd2l0aCB5b3Ugb24gY2hhbmdpbmcgdGhlIHZlcnNpb24gbnVtYmVyLjwvZm9udD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IExJTkUtSEVJR0hUOiBub3JtYWw7 IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4jOC4gV2UgZm9sbG93 ZWQgdGhlIHNhbWUgZ3JvdXBpbmcgYXMgaW4gUkZDIDYzNzguIEluIFNlY3Rpb24gNC4zLjMuMiBv ZiBSRkMgNjM3OCwgdGhlIHNlY29uZCBwYXJhZ3JhcGggc2F5czo8L2ZvbnQ+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBNQVJHSU46 IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIiIGxhbmc9IkVOLVVTIj5UaGUgcHJvdGVjdGlvbiBkb21h aW4gd2lsbCBleGl0IHRoZSBVbmF2YWlsYWJsZSBzdGF0ZSBhbmQgcmV2ZXJ0IHRvPC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBNQVJH SU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCI+DQo8c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIiIGxhbmc9IkVOLVVTIj50aGUgTm9ybWFsIHN0YXRl IHdoZW4gZWl0aGVyIHRoZSBvcGVyYXRvciBjbGVhcnMgdGhlIExvY2tvdXQgY29tbWFuZDwvc3Bh bj48L3A+DQo8cCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsg TUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiPg0KPHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIiBsYW5nPSJFTi1VUyI+b3IgdGhlIHByb3Rl Y3Rpb24gcGF0aCByZWNvdmVycyBmcm9tIHRoZSBzaWduYWwgZmFpbCBvciBkZWdyYWRlZDwvc3Bh bj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6IENvdXJpZXIiIGxh bmc9IkVOLVVTIj5zaXR1YXRpb24uPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPkJhc2VkIHVwb24gdGhpcywgd2UgcHV0IFNELVAgaW4gVW5hdmFpbGFi bGUgc3RhdGUuIEFzIHlvdSBrbm93LCB0aGUgbmFtZSBvZiB0aGUgc3RhdGUgZG9lcyBub3QgYWZm ZWN0IHRoZSBhY3Rpb24gdGFrZW4gYnkgdGhlIFBTQyBwcm9jZXNzLiBXaGF0IGFmZmVjdHMgdGhl IGFjdGlvbiBpcyB0aGUNCiBleHRlbmRlZCBzdGF0ZSwgd2hpY2ggc2hvd3MgdGhlIHJlcXVlc3Qg YW5kIHRoZSBzb3VyY2Ugb2YgdGhlIHJlcXVlc3QuIElmIHlvdSB3YW50IHRvIHN1Z2dlc3QgYW55 IG90aGVyIGFwcHJvcHJpYXRlIHN0YXRlLCBJIGFtIHJlYWR5IHRvIGhlYXIuDQo8L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPj09PT09PT09 PT09PC9mb250Pjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJpbSI+DQo8cCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj5CZXN0IHJlZ2FyZHMsPC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkplb25nLWRvbmc8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxicj4NCjxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8aHI+DQo8Yj5G cm9tIDogPC9iPiZxdW90O1lhYWNvdiBXZWluZ2FydGVuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86d3lhYWNvdkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj53eWFhY292QGdtYWlsLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDE0LTAxLTI4IDA1OjEyOjE2ICggJiM0MzswOTow MCApPGJyPg0KPGI+VG8gOiA8L2I+TG9hIEFuZGVyc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxv YUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4mZ3Q7PGJyPg0KPGI+Q2MgOiA8 L2I+PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGll dGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5tcGxzQGlldGYub3JnPC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZndDssDQo8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZzwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmll dGYub3JnPC9hPiZndDssDQo8dT48L3U+Jmx0OzxhIGhyZWY9Im1haWx0bzptcGxzLWFkc0B0b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtYWRzQHRvb2xzLmlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0IDogPC9iPlJlOiBbbXBsc10gd29ya2luZyBncm91cCBsYXN0IGNh bGwgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDE8YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2IGRpcj0ibHRyIj5IaSBhbGwsDQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5JIGhhdmUgcmVhZCB0aHJvdWdoIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGlz IGRyYWZ0IGFuZCBoYXZlIGEgbnVtYmVyIG9mIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgcmVnYXJk aW5nIHRoaXMgZG9jdW1lbnQuIFdoaWxlLCBpbiBnZW5lcmFsLCBJIGZlZWwgdGhhdCB0aGUgZXh0 ZW5zaW9ucyB0byB0aGUgYmVoYXZpb3Igb2YgUkZDNjM3OCBhcmUgYXBwcm9wcmlhdGUsIEkgZmlu ZCB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgc3RpbGwgaW4gbmVlZA0KIG9mIHJlZmluZW1lbnQgaW4g aXRzIGxhbmd1YWdlIGFuZCBjbGFyaXR5IG9mIHRoZSBmdW5jdGlvbmFsaXR5LiBXaGlsZSBzb21l IG9mIHRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgaXMgZGVzY3JpYmVkLCB0aGVyZSBhcmUg ZGlmZmVyZW50IGNhc2VzIG9mIHRoZSBmdW5jdGlvbmFsaXR5IHRoYXQgaXMgZWl0aGVyIG5vdCBk ZXNjcmliZWQgb3IgaXMgcmF0aGVyIGNvbmZ1c2luZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pk9uZSBiYXNpYyBxdWVzdGlvbiBpcyAtIENvbnNpZGVyaW5nIHRoYXQgdGhpcyBkcmFm dCBpcyBwcm9wb3NpbmcgY2hhbmdlcyB0byB0aGUgYmFzaWMgb3BlcmF0aW9uIG9mIHRoZSBQU0Mg cHJvdG9jb2wsIExvY2FsIFJlcXVlc3QgTG9naWMsIGFuZCB0aGUgUFNDIENvbnRyb2wgTG9naWMs IEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgdGhlIFBTQyBWZXJzaW9uIG51bWJlciBzaG91bGQg Y2hhbmdlISBXaHkgdGhlbiwgaXMgdGhlcmUgbm8gbWVudGlvbg0KIG9mIGNoYW5naW5nIHRoZSB2 ZXJzaW9uIHRvIGFsbG93IG5ldHdvcmtzIHRoYXQgc3VwcG9ydCB0aGUgZnVuY3Rpb25hbGl0eSBk ZXNjcmliZWQgaW4gUkZDNjM3OCB0byBjb250aW51ZSB0byBvcGVyYXRlPzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkaW5nIHRoZSBmdW5jdGlvbmFsaXR5IHByb3Bvc2VkIGlu IHRoZSBkcmFmdCwgSSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zIGFuZCBjb21tZW50cyAt PC9kaXY+DQo8ZGl2Pg0KPG9sPg0KPGxpPihmb3IgY2xhcmlmaWNhdGlvbikgUmVnYXJkaW5nIHRo ZSBmdW5jdGlvbmFsaXR5IG9mIE1TLVcsIHdoYXQgaXMgdGhlIGZ1bmN0aW9uYWxpdHkgaWYgdGhl IGRhdGEtdHJhZmZpYyBpcyBjdXJyZW50bHkgb24gdGhlIHdvcmtpbmcgcGF0aD8gU2luY2UgdGhl IHB1cnBvc2Ugb2YgdGhlIGNvbW1hbmQgaXMgdG8gbW92ZSB0aGUgdHJhZmZpYyB0byB0aGUgd29y a2luZyBwYXRoLCBzaG91bGRuJ3QgaXQgYmUgaWdub3JlZD8gSG93ZXZlciwgYWNjb3JkaW5nDQog dG8gdGhlIFN0YXRlIFRyYW5zaXRpb24gVGFibGUgaW4gc2VjdGlvbiAxMS4xIC0gaWYgdGhlIE1T LVcgaXMgcmVjZWl2ZWQgYnkgYSBMRVIgaW4gTm9ybWFsIFN0YXRlIGl0IHRyYW5zZmVycyB0byBT d2l0Y2hpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUhIFRoZSBtYWluIGVmZmVjdCBzZWVtcyB0byBi ZSB0byBjYXVzZSB0aGUgTEVSIHRvIGlnbm9yZSBpbmNvbWluZyBNUyBhbmQgRVhFUiByZXF1ZXN0 cyAodGhhdCBhcmUgbm90IGlnbm9yZWQgaW4gTm9ybWFsDQogU3RhdGUpLiA8L2xpPjxsaT5SZWdh cmRpbmcgdGhlIFNEIGZ1bmN0aW9uYWxpdHkgLSBhZnRlciBhIHByZXZpb3VzIGRpc2N1c3Npb24g b24gdGhlIG1haWxpbmcgbGlzdCB0aGUgZnVuY3Rpb25hbGl0eSB3aGVuIHByb3RlY3RpbmcgZm9y IFNEIHNpdHVhdGlvbnMgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMykgd2FzIGNoYW5nZWQgdG8g ZXNzZW50aWFsbHkgc3dpdGNoIG92ZXIgdG8gdGhlIExFUiB0cmFuc21pdHRpbmcgdGhlIHBhY2tl dHMgb24gYm90aCB0aGUgd29ya2luZw0KIGFuZCBwcm90ZWN0aW9uIHBhdGhzIChlc3NlbnRpYWxs eSAxJiM0MzsxIHRyYW5zbWlzc2lvbikuIEhvd2V2ZXIsIHRoZXJlIGlzIHZlcnkgbGl0dGxlIGRp c2N1c3Npb24gb2YgaG93IHRoZSByZWNlaXZpbmcgTEVSIGlzIHN1cHBvc2VkIHRvIHNlbGVjdCB0 aGUgaW5jb21pbmcgcGFja2V0cyB3aGlsZSBhdm9pZGluZyBkdXBsaWNhdGlvbiBvZiBkYXRhLiBD b3VsZCBwbGVhc2UgZWxhYm9yYXRlIG9uIHRoaXM/DQo8L2xpPjxsaT5SZWdhcmRpbmcgdGhlIFNE IGZ1bmN0aW9uYWxpdHkgLSBhcyBtZW50aW9uZWQgaW4gdGhlIHByZXZpb3VzIHBvaW50LCB3aGVu IHByb3RlY3RpbmcgZm9yIFNELCB0aGUgdHJhbnNtaXR0aW5nIExFUiBkdXBsaWNhdGVzIHRoZSBw YWNrZXRzIG9uIGJvdGggVyAmYW1wOyBQIGFuZCB0aGUgcmVjZWl2aW5nIExFUiwgcHJlc3VtYWJs eSwgcmVhZHMgdGhlIGRhdGEgZnJvbSBlaXRoZXIgcGF0aCwgYW5kIG1heSBjaG9vc2UgZGlmZmVy ZW50bHkgZm9yIGRpZmZlcmVudA0KIHBhY2tldHMuIEhvd2V2ZXIsIGxhdGVyIGluIHNlY3Rpb24g Ny40IChhbmQgYWdhaW4gaW4gc2VjdGlvbiAxMC4yKSB5b3UgaW50cm9kdWNlIGEgbmV3IGNvbmNl cHQgb2YgJnF1b3Q7c3RhbmRieSBwYXRoJnF1b3Q7IGFzICZxdW90O3RoZSBwYXRoIGZyb20gd2hp Y2ggdGhlIHNlbGVjdG9yIGRvZXMgbm90IHNlbGVjdCB0aGUgdXNlciBkYXRhIHRyYWZmaWMmcXVv dDsgaW4gcmVnYXJkIHRvIGRldGVybWluaW5nIHRoZSBwcmlvcml0eSBvZiAmcXVvdDtjb25mbGlj dGluZyZxdW90OyBTRC1XIGFuZCBTRC1QDQogdHJpZ2dlcnMuIENhbiB5b3UgY2xhcmlmeSB3aGlj aCBvZiB0aGUgdHdvIHBhdGhzIHRoYXQgYXJlIGJvdGggY2FycnlpbmcgdXNlciBkYXRhIGlzIHRo ZSBzdGFuZGJ5IHBhdGg/DQo8L2xpPjxsaT5GdXJ0aGVyIHJlZ2FyZGluZyB0aGUgcG9pbnQgb2Yg JnF1b3Q7Y29uZmxpY3RpbmcmcXVvdDsgU0QgdHJpZ2dlcnMgLSBzaW5jZSB0aGUgcHJvdGVjdGlv biBmdW5jdGlvbmFsaXR5IG9mIFNEIGlzIHRvIGR1cGxpY2F0ZSB0aGUgZGF0YSBvbiBib3RoIFcg JmFtcDsgUCAtIHdoeSBpcyB0aGlzIGNvbnNpZGVyZWQgYSBjb25mbGljdCwgc2luY2UgdGhlIGFj dGlvbiBmb3IgYm90aCB3aWxsIGJlIGlkZW50aWNhbCAtIGNvbnRpbnVlIHRyYW5zbWl0dGluZyBv biBib3RoIFcNCiAmYW1wOyBQLiBTb21lIG1vcmUgY2xhcmlmaWNhdGlvbiB3b3VsZCBoZWxwLiA8 L2xpPjxsaT5SZWdhcmRpbmcgdGhlIEFQUyBtb2RlIGFuZCBzdWItY2FwYWJpbGl0aWVzIC0gWW91 IGRlc2NyaWJlIGluIHNlY3Rpb24gOS4xIGhvdyBhbiBMRVIgY2FuIGRlY2xhcmUgaXRzZWxmIHRv IHN1cHBvcnQgb25seSBzb21lIG9mIHRoZSBjYXBhYmlsaXRpZXMgaW50cm9kdWNlZCBpbiB0aGUg ZHJhZnQsIGFuZCB0aGVuIGRlc2NyaWJlIHRoZSBBUFMgJnF1b3Q7bW9kZSZxdW90OyAoU2VjdGlv biA5LjIuMikgYXMgZGVjbGFyYXRpb24gb2Ygc3VwcG9ydCBmb3IgYWxsDQogb2YgdGhlIGNhcGFi aWxpdGllcywgaS5lLiBGbGFncyA9IDB4RjgwMDAwMDAuIEZyb20gdGhpcyBwb2ludCBvbiAoaW4g cGFydGljdWxhciBzZWN0aW9uIDExKSwgeW91IGRlc2NyaWJlIHRoZSBmdW5jdGlvbmFsaXR5IGZv ciBMRVIgdGhhdCBkZWNsYXJlIEZsYWdzPSBlaXRoZXIgMHgwLCBvciAweEY4MDAwMDAwLCBob3dl dmVyLCB0aGVyZSBpcyBubyBleHBsYW5hdGlvbiBmb3IgcGF0aHMgdGhhdCBkZWNsYXJlIHNvbWUg b3RoZXIgdmFsdWUgb2YgRmxhZ3MNCiAoZm9yIGV4YW1wbGUsIDB4ODAwMDAwMCAtIHN1cHBvcnRp bmcgb25seSB0aGUgRVhFUiBmdW5jdGlvbmFsaXR5KS4gSXMgdGhlcmUgYSByZWFzb24gZm9yIHRo aXM/IEFyZSB3ZSBhc3N1bWluZyB0aGF0IGFsbCBwYXRocyB3aWxsIGVpdGhlciBzdXBwb3J0IFBT QyBvciBBUFMgbW9kZXMgb25seT8gSWYgc28sIHdoeSBub3QganVzdCBoYXZlIHR3byB2YWx1ZXMg Zm9yIEZsYWdzIHJhdGhlciB0aGFuIHRoaXMgZXh0ZW5zaWJsZSBiaXQgbWFwIHZhbHVlPw0KPC9s aT48bGk+UmVnYXJkaW5nICZxdW90O1BTQyBzZXNzaW9ucyZxdW90OyAtIEluIHNlY3Rpb24gOS4z IHlvdSBpbnRyb2R1Y2UgYSBuZXcgY29uY2VwdCBvZiBQU0Mgc2Vzc2lvbiwgd2l0aG91dCBhbnkg ZGVmaW5pdGlvbiBvZiB3aGVuIHRoaXMgc2Vzc2lvbiBiZWdpbnMgb3IgZW5kcy4gQ291bGQgeW91 IGVsYWJvcmF0ZSBvbiB3aGF0IGlzIG1lYW50IGJ5IHRoZSAmcXVvdDtsaWZlIG9mIGEgUFNDIHNl c3Npb24mcXVvdDs/IFVudGlsIG5vdywgSSB3YXMgdW5kZXIgdGhlIGltcHJlc3Npb24NCiB0aGF0 IGxpbmVhciBwcm90ZWN0aW9uIHN0YXJ0ZWQgd2l0aCB0aGUgY3JlYXRpb24gb2YgdGhlIHByb3Rl Y3Rpb24gZG9tYWluIGFuZCBjb250aW51ZWQgdW50aWwgdGhlIHBhdGhzIHdlcmUgdG9ybiBkb3du LiBJcyB0aGlzIGluY29ycmVjdD8NCjwvbGk+PGxpPlRoZXJlIGlzIGEgc3RhdGVtZW50IGluIHRo ZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gOS4zIHRoYXQgc3RhdGVzICZxdW90O1JGQzYz NzggZG9lcyBub3QgZGVmaW5lIGhvdyB0byBoYW5kbGUgYW4gdW5yZWNvZ25pemVkIFRMVi4mcXVv dDsgQWN0dWFsbHksIHdoYXQgUkZDNjM3OCBkZWZpbmVzIGlzICZxdW90O3RoZXJlIGFyZSBubyBU TFYgdW5pdHMgZGVmaW5lZCBmb3IgdGhlIGJhc2ljIFBTQyBvcGVyYXRpb24mcXVvdDsgYW5kIHRo ZXJlZm9yZSB0aGUgVExWcyBhcmUNCiBpZ25vcmVkLiBBbm90aGVyIHJlYXNvbiwgSU1PLCB0byBj aGFuZ2UgdGhlIHZlcnNpb24gbnVtYmVyIG9mIHRoZSBwcm90b2NvbCBpbiB0aGlzIGRyYWZ0Lg0K PC9saT48bGk+SXQgaXMgdW5jbGVhciB0byBtZSAtIHdoeSB3aGVuIHJlY2VpdmluZyBhIFNELVAg aW5kaWNhdGlvbiBpbiBOb3JtYWwgd2h5IHlvdSBjb25zaWRlciB0aGlzIHRvIGJlICZxdW90O1Vu YXZhaWFibGUmcXVvdDsgc2luY2UgdGhlIGFjdGlvbiB0YWtlbiBmb3IgYW4gU0Qgc2l0dWF0aW9u IGlzIHRvIHBvc3NpYmx5IHRyYW5zbWl0IG9uIGJvdGggVyAmYW1wOyBQLjwvbGk+PC9vbD4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+SSBwbGFuIG9uIHN1Ym1pdHRpbmcgc29tZSBl ZGl0b3JpYWwgY29tbWVudHMgaW4gYSBmdXR1cmUgcG9zdCwgYnV0IHdvdWxkIGxpa2UgdG8gZ2V0 IHNvbWUgY2xhcmlmaWNhdGlvbiBvbiB0aGVzZSBwb2ludHMgYmVmb3JlIHRoZSBkcmFmdCBhZHZh bmNlcyB0byBhY2NlcHRhbmNlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbngs PC9kaXY+DQo8ZGl2PnlhYWNvdjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRy YSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIE1vbiwgSmFuIDIwLCAy MDE0IGF0IDQ6MjggQU0sIExvYSBBbmRlcnNzb24gPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhy ZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0 LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgUEFERElORy1M RUZUOiAxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+DQpXb3JraW5nIEdyb3VwLDxicj4NCjxicj4N ClRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbjxi cj4NCmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1Ljxicj4NCjxicj4NClBsZWFzZSBmaW5kIHRo ZSBkb2N1bWVudCBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnLzx1PjwvdT5kb2MvZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy08 dT48L3U+aXR1LzwvYT48YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQgZWRpdG9ycyBoYXMgYWxzbyBz dXBwbGllZCBhICZxdW90O2RpZmYtbGlzdCZxdW90OyBiZXR3ZWVuPGJyPg0KdmVyc2lvbiAtMDAg YW5kIC0wMSBhdDo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbXBscy9jdXJyZW50L21zZzExMzM4Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v d3d3LmlldGYub3JnL21haWwtPHU+PC91PmFyY2hpdmUvd2ViL21wbHMvY3VycmVudC88dT48L3U+ bXNnMTEzMzguaHRtbDwvYT48YnI+DQo8YnI+DQpJVFUtVCBTRzE1IGhhcyBhZHZpc2VkIHVzIHRo YXQgdGhpcyBkb2N1bWVudCBpcyBhIG5lY2Vzc2FyeSByZWZlcmVuY2U8YnI+DQpmb3IgZG9jdW1l bnRzIHRoYXQgaXMgcGxhbm5lZCB0byBnbyBpbnRvIHRoZSBJVFUtVCBhcHByb3ZhbCBwcm9jZXNz PGJyPg0KZnJvbSB0aGUgU0cxNSBtZWV0aW5nIGVuZCBvZiBNYXJjaCAvIGJlZ2lubmluZyBvZiBB cHJpbC4gRWRpdG9ycyw8YnI+DQphdXRob3JzIGFuZCBjaGFpcnMgaGFzIHB1dCBpbiBxdWl0ZSBh biBlZmZvcnQgdG8gbWFrZSB0aGlzIGRvY3VtZW50PGJyPg0KcmVhZHkuIFRoZSBzY2hlZHVsZSBp cyB2ZXJ5IHRpZ2h0Ljxicj4NCjxicj4NCldlIGFyZSBub3cgZG9pbmcgc2V2ZXJhbCByZXZpZXcg c3RlcHMgaW4gcGFyYWxsZWw8YnI+DQo8YnI+DQotIHRoZSBub3JtYWwgd29ya2luZyBncm91cCBs YXN0IGNhbGwsIHBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlPGJyPg0KJm5ic3A7IG1w bHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgKDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT4pPGJyPg0KLSB0aGUgd29ya2lu ZyBncm91cCBjaGFpcnMgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZTxicj4N CiZuYnNwOyBtcGxzLXJ0IHJldmlldywgbm9ybWFsbHkgd2UgZG8gYSB3ZyBjaGFpciByZXZpZXcg YmVmb3JlIHN0YXJ0aW5nIHRoZTxicj4NCiZuYnNwOyB3Z2xjLCB0aGlzIHJldmlldyB3aWxsIG5v dyB0YWtlIHBsYWNlIGluIHBhcmFsbGVsPGJyPg0KLSBhZnRlciB0aGUgd2dsYyBhbmQgcHVibGlj YXRpb24gcmVxdWVzdCB0aGVyZSBpcyBhbiBBRCBldmFsdWF0aW9uLDxicj4NCiZuYnNwOyB0aGlz IHdpbGwgbm93IGFsc28gdGFrZSBwbGFjZSBpbiBwYXJhbGxlbCB3aXRoIHRoZSB3Z2xjPGJyPg0K PGJyPg0KVGhlIGVkaXRvcnMgYW5kIGF1dGhvcnMgYXJlIGFkdmlzZWQgdG8gdHJ5IHRvIHJlc29s dmUgYXMgbWFueSBvZiB0aGU8YnI+DQpjb21tZW50cyBhcyBwb3NzaWJsZSAob24gdGhlIG1haWxp bmcgbGlzdCkgYXMgdGhleSBjb21lIGluLCBidXQgbm90IHRvPGJyPg0KcG9zdCB0aGUgbmV3IHZl cnNpb24gb2YgdGhlIGRyYWZ0IHVudGlsIHRoZSB3Z2xjIGlzIGNsb3NlZCBhbmQgdGhlPGJyPg0K Y29tbWVudHMgYXJlIHJlc29sdmVkLjxicj4NCjxicj4NClRoaXMgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgZW5kcyBGZWJydWFyeSAzcmQuPGJyPg0KPGJyPg0KL0xvYTxicj4NCmZvciB0aGUgTVBM UyBXRyBjby1jaGFpcnM8c3Bhbj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KLS0gPGJyPg0K PGJyPg0KPGJyPg0KTG9hIEFuZGVyc3NvbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VtYWls OiA8YSBocmVmPSJtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ DQpsb2FAbWFpbDAxLmh1YXdlaS5jb208L2E+PGJyPg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRh cmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29u c3VsdGFudCkgJm5ic3A7ICZuYnNwOyBwaG9uZTogPGEgaHJlZj0idGVsOiUyQjQ2JTIwNzM5JTIw ODElMjAyMSUyMDY0IiB0YXJnZXQ9Il9ibGFuayIgdmFsdWU9IiYjNDM7NDY3Mzk4MTIxNjQiPg0K JiM0Mzs0NiA3MzkgODEgMjEgNjQ8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPHU+PC91Pl9fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88dT48 L3U+bGlzdGluZm8vbXBsczwvYT48YnI+DQo8L2ZvbnQ+PC9zcGFuPjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCi0tIDxicj4N CjxkaXYgZGlyPSJsdHIiPlRoYW54IGFuZCBCUiwNCjxkaXY+eWFhY292PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48aT5TdGlsbCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHk8L2k+ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8YnI+DQo8ZGl2IGRpcj0ibHRyIj5U aGFueCBhbmQgQlIsDQo8ZGl2PnlhYWNvdjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ PGk+U3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5PC9pPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DCFSMTP2etriinfo_-- From ryoo@etri.re.kr Tue Feb 4 01:54: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 DAD1E1A03CE for ; Tue, 4 Feb 2014 01:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 ST5ehMepG6Wx for ; Tue, 4 Feb 2014 01:54:51 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id D21A71A0388 for ; Tue, 4 Feb 2014 01:54:50 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Feb 2014 18:54:52 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Tue, 4 Feb 2014 18:54:46 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "Zhangxian (Xian)" , "mpls@ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Thread-Topic: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: AQHPFYhnPxX4EfDenE+JJCp9uCTk/JqbfWRAgAlVBdb//4COgIAAoBf7 Date: Tue, 4 Feb 2014 09:54:45 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DED@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B5D93@SMTP2.etri.info>, <52F0B10B.8000307@pi.nu> In-Reply-To: <52F0B10B.8000307@pi.nu> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DEDSMTP2etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:54:54 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DEDSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLCB0aGFua3MuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb20g OiAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4NClNlbnQgOiAyMDE0LTAyLTA0IDE4OjIxOjI4 ICggKzA5OjAwICkNClRvIDogUnlvbywgSmVvbmctZG9uZyA8cnlvb0BldHJpLnJlLmtyPiwgWmhh bmd4aWFuIChYaWFuKSA8emhhbmcueGlhbkBodWF3ZWkuY29tPiwgbXBsc0BpZXRmLm9yZyA8bXBs c0BpZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIDxk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4NCkNjIDoNClN1YmplY3Qg OiBSZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGRyYWZ0LWlldGYtbXBscy10cC1w c2MtaXR1LTAxDQoNCkplb25nLWRvbmcsDQoNClBsZWFzZSBkb24ndCBob2xkIHRoZSBwb3N0aW5n IG9mIHRoZSB2ZXJzaW9uIHVwZGF0ZWQgYWZ0ZXIgd29ya2luZw0KZ3JvdXAgbGFzdCBjYWxsLCB3 YWl0aW5nIG9ubHkgZm9yIHRoZSBjb21tZW50cyBmcm9tIFhpYW4uIEluc3RlYWQNCmZvbGQgaGVy IGNvbW1lbnRzIGluIGFzIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIGFuZCBwb3N0IGEgbmV3IHZl cnNpb24NCndoZW4gdGhlIElFVEYgTEMgZW5kcy4NCg0KWGlhbiwNCg0Kd2UgYXBwcmVjaWF0ZSB5 b3VyIGNvbW1lbnRzLCBidXQgSSBob3BlIGl0IHdpbGwgYmUgT0sgdG8gdGFrZSBjYXJlDQpvZiB0 aGVtIGFzIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzLg0KDQovTG9hDQoNCk9uIDIwMTQtMDItMDQg MTU6NTgsIFJ5b28sIEplb25nLWRvbmcgd3JvdGU6DQo+IFRoYW5rcywgWGlhbi4NCj4gSSBhbSBs b29raW5nIGZvcndhcmQgdG8gc2VlaW5nIHlvdXIgY29tbWVudHMgc29vbi4NCj4gQmVzdCByZWdh cmRzLA0KPiBKZW9uZy1kb25nDQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAqRnJvbSA6ICoi Wmhhbmd4aWFuIChYaWFuKSINCj4gKlNlbnQgOiAqMjAxNC0wMS0yOSAxODozNjo0NSAoICswOTow MCApDQo+ICpUbyA6ICptcGxzQGlldGYub3JnICwNCj4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1p dHVAdG9vbHMuaWV0Zi5vcmcNCj4NCj4gKkNjIDogKg0KPiAqU3ViamVjdCA6ICpbbXBsc10gRlc6 IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAxDQo+ DQo+IEkndmUgcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGFuZCBvbmx5IGZvdW5kIG1pbm9yIGdyYW1t YXRpY2FsIGlzc3Vlcy4NCj4gVGh1cywgSSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJl YWR5IGZvciBwdWJsaWNhdGlvbi4NCj4NCj4gRHVlIHRvIENoaW5lc2UgTmV3IFllYXIgYnJlYWss IHBsZWFzZSBleHBlY3QgbXkgZ3JhbW1hdGljYWwNCj4gc3VnZ2VzdGlvbnMvY29tbWVudHMgY29t ZSBhZnRlciB0aGUgV0cgTEMgKGFmdGVyIEkgdHJhbnNjcmlwdCBteSBub3Rlcw0KPiBmcm9tIHRo ZSBoYXJkLWNvcHkgdmVyc2lvbiB0byBhbiBlbGVjdHJvbmljIG9uZSkuDQo+DQo+IFJlZ2FyZHMs DQo+IFhpYW4NCj4NCj4gLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KPiBGcm9t OiBMb2EgQW5kZXJzc29uDQo+IFRvOiBtcGxzQGlldGYub3JnDQo+IENDOiBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZyAsDQo+ICwNCj4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMu aWV0Zi5vcmcNCj4gLCBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKQ0KPg0KPg0KPiBXb3JraW5n IEdyb3VwLA0KPg0KPiBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBs YXN0IGNhbGwgb24NCj4gZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUuDQo+DQo+IFBsZWFzZSBm aW5kIHRoZSBkb2N1bWVudCBhdDoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUvDQo+DQo+IFRoZSBkb2N1bWVudCBlZGl0b3JzIGhh cyBhbHNvIHN1cHBsaWVkIGEgImRpZmYtbGlzdCIgYmV0d2Vlbg0KPiB2ZXJzaW9uIC0wMCBhbmQg LTAxIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJy ZW50L21zZzExMzM4Lmh0bWwNCj4NCj4gSVRVLVQgU0cxNSBoYXMgYWR2aXNlZCB1cyB0aGF0IHRo aXMgZG9jdW1lbnQgaXMgYSBuZWNlc3NhcnkgcmVmZXJlbmNlDQo+IGZvciBkb2N1bWVudHMgdGhh dCBpcyBwbGFubmVkIHRvIGdvIGludG8gdGhlIElUVS1UIGFwcHJvdmFsIHByb2Nlc3MNCj4gZnJv bSB0aGUgU0cxNSBtZWV0aW5nIGVuZCBvZiBNYXJjaCAvIGJlZ2lubmluZyBvZiBBcHJpbC4gRWRp dG9ycywNCj4gYXV0aG9ycyBhbmQgY2hhaXJzIGhhcyBwdXQgaW4gcXVpdGUgYW4gZWZmb3J0IHRv IG1ha2UgdGhpcyBkb2N1bWVudA0KPiByZWFkeS4gVGhlIHNjaGVkdWxlIGlzIHZlcnkgdGlnaHQu DQo+DQo+IFdlIGFyZSBub3cgZG9pbmcgc2V2ZXJhbCByZXZpZXcgc3RlcHMgaW4gcGFyYWxsZWwN Cj4NCj4gLSB0aGUgbm9ybWFsIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLCBwbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZQ0KPiBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0ICht cGxzQGlldGYub3JnKQ0KPiAtIHRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlDQo+IG1wbHMtcnQgcmV2aWV3LCBub3JtYWxseSB3ZSBk byBhIHdnIGNoYWlyIHJldmlldyBiZWZvcmUgc3RhcnRpbmcgdGhlDQo+IHdnbGMsIHRoaXMgcmV2 aWV3IHdpbGwgbm93IHRha2UgcGxhY2UgaW4gcGFyYWxsZWwNCj4gLSBhZnRlciB0aGUgd2dsYyBh bmQgcHVibGljYXRpb24gcmVxdWVzdCB0aGVyZSBpcyBhbiBBRCBldmFsdWF0aW9uLA0KPiB0aGlz IHdpbGwgbm93IGFsc28gdGFrZSBwbGFjZSBpbiBwYXJhbGxlbCB3aXRoIHRoZSB3Z2xjDQo+DQo+ IFRoZSBlZGl0b3JzIGFuZCBhdXRob3JzIGFyZSBhZHZpc2VkIHRvIHRyeSB0byByZXNvbHZlIGFz IG1hbnkgb2YgdGhlDQo+IGNvbW1lbnRzIGFzIHBvc3NpYmxlIChvbiB0aGUgbWFpbGluZyBsaXN0 KSBhcyB0aGV5IGNvbWUgaW4sIGJ1dCBub3QgdG8NCj4gcG9zdCB0aGUgbmV3IHZlcnNpb24gb2Yg dGhlIGRyYWZ0IHVudGlsIHRoZSB3Z2xjIGlzIGNsb3NlZCBhbmQgdGhlDQo+IGNvbW1lbnRzIGFy ZSByZXNvbHZlZC4NCj4NCj4gVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIEZlYnJ1 YXJ5IDNyZC4NCj4NCj4gL0xvYQ0KPiBmb3IgdGhlIE1QTFMgV0cgY28tY2hhaXJzDQo+IC0tDQo+ DQo+DQo+IExvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5p b3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51DQo+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRh bnQpIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQoNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiBlbWFp bDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51DQpI dWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DEDSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsIHRoYW5rcy48YnI+DQo8YnI+DQo8ZGl2 IGlkPSJNYWlsU2lnblNlbnQiPjxicj4NCjwvZGl2Pg0KPGhyIHRhYmluZGV4PSItMSI+DQo8Yj5G cm9tIDogPC9iPiZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0O2xvYUBwaS5udSZndDs8YnI+ DQo8Yj5TZW50IDogPC9iPjIwMTQtMDItMDQgMTg6MjE6MjggKCAmIzQzOzA5OjAwICk8YnI+DQo8 Yj5UbyA6IDwvYj5SeW9vLCBKZW9uZy1kb25nICZsdDtyeW9vQGV0cmkucmUua3ImZ3Q7LCBaaGFu Z3hpYW4gKFhpYW4pICZsdDt6aGFuZy54aWFuQGh1YXdlaS5jb20mZ3Q7LCBtcGxzQGlldGYub3Jn ICZsdDttcGxzQGlldGYub3JnJmd0OywgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMu aWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnJmd0 Ozxicj4NCjxiPkNjIDogPC9iPjxicj4NCjxiPlN1YmplY3QgOiA8L2I+UmU6IFttcGxzXSB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMTxicj4NCjxi cj4NCkplb25nLWRvbmcsPGJyPg0KPGJyPg0KUGxlYXNlIGRvbid0IGhvbGQgdGhlIHBvc3Rpbmcg b2YgdGhlIHZlcnNpb24gdXBkYXRlZCBhZnRlciB3b3JraW5nPGJyPg0KZ3JvdXAgbGFzdCBjYWxs LCB3YWl0aW5nIG9ubHkgZm9yIHRoZSBjb21tZW50cyBmcm9tIFhpYW4uIEluc3RlYWQ8YnI+DQpm b2xkIGhlciBjb21tZW50cyBpbiBhcyBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyBhbmQgcG9zdCBh IG5ldyB2ZXJzaW9uPGJyPg0Kd2hlbiB0aGUgSUVURiBMQyBlbmRzLjxicj4NCjxicj4NClhpYW4s PGJyPg0KPGJyPg0Kd2UgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzLCBidXQgSSBob3BlIGl0IHdp bGwgYmUgT0sgdG8gdGFrZSBjYXJlPGJyPg0Kb2YgdGhlbSBhcyBJRVRGIExhc3QgQ2FsbCBjb21t ZW50cy48YnI+DQo8YnI+DQovTG9hPGJyPg0KPGJyPg0KT24gMjAxNC0wMi0wNCAxNTo1OCwgUnlv bywgSmVvbmctZG9uZyB3cm90ZTo8YnI+DQomZ3Q7IFRoYW5rcywgWGlhbi48YnI+DQomZ3Q7IEkg YW0gbG9va2luZyBmb3J3YXJkIHRvIHNlZWluZyB5b3VyIGNvbW1lbnRzIHNvb24uPGJyPg0KJmd0 OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyBKZW9uZy1kb25nPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgKkZyb20gOiAqJnF1b3Q7Wmhhbmd4 aWFuIChYaWFuKSZxdW90OyA8WkhBTkcuWElBTkBIVUFXRUkuQ09NPjxicj4NCiZndDsgKlNlbnQg OiAqMjAxNC0wMS0yOSAxODozNjo0NSAoICYjNDM7MDk6MDAgKTxicj4NCiZndDsgKlRvIDogKm1w bHNAaWV0Zi5vcmcgPE1QTFNASUVURi5PUkc+LDxicj4NCiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRw LXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc8YnI+DQomZ3Q7IDxEUkFGVC1JRVRGLU1QTFMtVFAtUFND LUlUVUBUT09MUy5JRVRGLk9SRz48YnI+DQomZ3Q7ICpDYyA6ICo8YnI+DQomZ3Q7ICpTdWJqZWN0 IDogKlttcGxzXSBGVzogd29ya2luZyBncm91cCBsYXN0IGNhbGwgZHJhZnQtaWV0Zi1tcGxzLXRw LXBzYy1pdHUtMDE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ3ZlIHJldmlld2VkIHRoZSBkb2N1bWVu dCBhbmQgb25seSBmb3VuZCBtaW5vciBncmFtbWF0aWNhbCBpc3N1ZXMuPGJyPg0KJmd0OyBUaHVz LCBJIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLjxi cj4NCiZndDs8YnI+DQomZ3Q7IER1ZSB0byBDaGluZXNlIE5ldyBZZWFyIGJyZWFrLCBwbGVhc2Ug ZXhwZWN0IG15IGdyYW1tYXRpY2FsPGJyPg0KJmd0OyBzdWdnZXN0aW9ucy9jb21tZW50cyBjb21l IGFmdGVyIHRoZSBXRyBMQyAoYWZ0ZXIgSSB0cmFuc2NyaXB0IG15IG5vdGVzPGJyPg0KJmd0OyBm cm9tIHRoZSBoYXJkLWNvcHkgdmVyc2lvbiB0byBhbiBlbGVjdHJvbmljIG9uZSkuPGJyPg0KJmd0 Ozxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IFhpYW48YnI+DQomZ3Q7PGJyPg0KJmd0OyAt LS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBMb2EgQW5k ZXJzc29uPGJyPg0KJmd0OyBUbzogbXBsc0BpZXRmLm9yZzxicj4NCiZndDsgQ0M6IG1wbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnICw8YnI+DQomZ3Q7ICw8YnI+DQomZ3Q7IGRyYWZ0LWlldGYtbXBs cy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPGJyPg0KJmd0OyAsIFZJR09VUkVVWCwgTUFSVElO IChNQVJUSU4pPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFdvcmtpbmcgR3JvdXAsPGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIG9uPGJyPg0KJmd0OyBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2UgZmluZCB0aGUgZG9jdW1lbnQgYXQ6PGJyPg0KJmd0OyBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0 dS88YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZG9jdW1lbnQgZWRpdG9ycyBoYXMgYWxzbyBzdXBw bGllZCBhICZxdW90O2RpZmYtbGlzdCZxdW90OyBiZXR3ZWVuPGJyPg0KJmd0OyB2ZXJzaW9uIC0w MCBhbmQgLTAxIGF0Ojxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL21wbHMvY3VycmVudC9tc2cxMTMzOC5odG1sPGJyPg0KJmd0Ozxicj4NCiZndDsgSVRVLVQg U0cxNSBoYXMgYWR2aXNlZCB1cyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgYSBuZWNlc3NhcnkgcmVm ZXJlbmNlPGJyPg0KJmd0OyBmb3IgZG9jdW1lbnRzIHRoYXQgaXMgcGxhbm5lZCB0byBnbyBpbnRv IHRoZSBJVFUtVCBhcHByb3ZhbCBwcm9jZXNzPGJyPg0KJmd0OyBmcm9tIHRoZSBTRzE1IG1lZXRp bmcgZW5kIG9mIE1hcmNoIC8gYmVnaW5uaW5nIG9mIEFwcmlsLiBFZGl0b3JzLDxicj4NCiZndDsg YXV0aG9ycyBhbmQgY2hhaXJzIGhhcyBwdXQgaW4gcXVpdGUgYW4gZWZmb3J0IHRvIG1ha2UgdGhp cyBkb2N1bWVudDxicj4NCiZndDsgcmVhZHkuIFRoZSBzY2hlZHVsZSBpcyB2ZXJ5IHRpZ2h0Ljxi cj4NCiZndDs8YnI+DQomZ3Q7IFdlIGFyZSBub3cgZG9pbmcgc2V2ZXJhbCByZXZpZXcgc3RlcHMg aW4gcGFyYWxsZWw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIHRoZSBub3JtYWwgd29ya2luZyBncm91 cCBsYXN0IGNhbGwsIHBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlPGJyPg0KJmd0OyBt cGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKTxicj4NCiZndDsg LSB0aGUgd29ya2luZyBncm91cCBjaGFpcnMgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0 IG9mIHRoZTxicj4NCiZndDsgbXBscy1ydCByZXZpZXcsIG5vcm1hbGx5IHdlIGRvIGEgd2cgY2hh aXIgcmV2aWV3IGJlZm9yZSBzdGFydGluZyB0aGU8YnI+DQomZ3Q7IHdnbGMsIHRoaXMgcmV2aWV3 IHdpbGwgbm93IHRha2UgcGxhY2UgaW4gcGFyYWxsZWw8YnI+DQomZ3Q7IC0gYWZ0ZXIgdGhlIHdn bGMgYW5kIHB1YmxpY2F0aW9uIHJlcXVlc3QgdGhlcmUgaXMgYW4gQUQgZXZhbHVhdGlvbiw8YnI+ DQomZ3Q7IHRoaXMgd2lsbCBub3cgYWxzbyB0YWtlIHBsYWNlIGluIHBhcmFsbGVsIHdpdGggdGhl IHdnbGM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZWRpdG9ycyBhbmQgYXV0aG9ycyBhcmUgYWR2 aXNlZCB0byB0cnkgdG8gcmVzb2x2ZSBhcyBtYW55IG9mIHRoZTxicj4NCiZndDsgY29tbWVudHMg YXMgcG9zc2libGUgKG9uIHRoZSBtYWlsaW5nIGxpc3QpIGFzIHRoZXkgY29tZSBpbiwgYnV0IG5v dCB0bzxicj4NCiZndDsgcG9zdCB0aGUgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHVudGlsIHRo ZSB3Z2xjIGlzIGNsb3NlZCBhbmQgdGhlPGJyPg0KJmd0OyBjb21tZW50cyBhcmUgcmVzb2x2ZWQu PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIEZl YnJ1YXJ5IDNyZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAvTG9hPGJyPg0KJmd0OyBmb3IgdGhlIE1Q TFMgV0cgY28tY2hhaXJzPGJyPg0KJmd0OyAtLTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBMb2EgQW5kZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208YnI+DQomZ3Q7IFNl bmlvciBNUExTIEV4cGVydCBsb2FAcGkubnU8YnI+DQomZ3Q7IEh1YXdlaSBUZWNobm9sb2dpZXMg KGNvbnN1bHRhbnQpIHBob25lOiAmIzQzOzQ2IDczOSA4MSAyMSA2NDxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG1wbHNAaWV0Zi5vcmc8 YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG1w bHNAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBsczxicj4NCiZndDs8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5k ZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208YnI+DQpTZW5pb3IgTVBMUyBFeHBl cnQgbG9hQHBpLm51PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6 ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B5DEDSMTP2etriinfo_-- From grkwon@dasannetworks.com Tue Feb 4 01:57:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21C11A03CE for ; Tue, 4 Feb 2014 01:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.606 X-Spam-Level: ** X-Spam-Status: No, score=2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FSL_HELO_BARE_IP_2=1.54, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, X_IP=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 EGcUl7tf_zDp for ; Tue, 4 Feb 2014 01:57:42 -0800 (PST) Received: from mail.dasannetworks.com (ds.dasannetworks.com [125.132.45.10]) by ietfa.amsl.com (Postfix) with ESMTP id 146C21A02BC for ; Tue, 4 Feb 2014 01:57:41 -0800 (PST) Received: from 10.60.250.56 (10.60.250.56 [10.60.250.56]) by mail.dasannetworks.com (WBlock.pss 3.6.24) with ESMTP id ; Tue, 4 Feb 2014 20:22:00 +0900 Received: from DS04.dasannetworks.com ([10.0.0.11]) by CAS03.dasannetworks.com ([10.60.250.56]) with mapi id 14.01.0339.001; Tue, 4 Feb 2014 18:57:03 +0900 From: =?ks_c_5601-1987?B?R3llUm9rIEd3dW4gKLHHsOi3zyk=?= To: "'mpls@ietf.org'" Thread-Topic: Re:[mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read- only Thread-Index: Ac8hjxzl8ghaPRZWRrGC5FfpauSBvQ== Date: Tue, 4 Feb 2014 09:57:02 +0000 Message-ID: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.73.0.87] Content-Type: multipart/alternative; boundary="_000_F918BC4881E38F4E8B67A4523EDB38D2118600DS04dasannetworks_" MIME-Version: 1.0 X-IP: 10.60.250.56 X-FROM-DOMAIN: dasannetworks.com X-FROM-EMAIL: grkwon@dasannetworks.com X-Mailman-Approved-At: Tue, 04 Feb 2014 05:07:24 -0800 Cc: "'mpls-chairs@tools.ietf.org'" , "'draft-ietf-mpls-tp-te-mib@tools.ietf.org'" Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read- only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 10:00:02 -0000 --_000_F918BC4881E38F4E8B67A4523EDB38D2118600DS04dasannetworks_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Tm8vb3Bwb3NlIHRvIG1ha2UgYXMgUmVhZC1vbmx5IG1pYi4NCg0KSW4gb3VyIHByb2R1Y3RzIHdl IGV4dGVuc2l2ZWx5IHVzZSBSL1cgb2JqZWN0IG9mIFRFIG1pYi4gV2UgYWxzbyBoYXZlIE5NUy9F TVMgdGhhdCB1c2UgVEUgcmVhZC13cml0ZSBPYmplY3RzDQoNCg0KDQpCZXN0IFJlZ2FyZHMNCg0K R3d1bg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogbXBscyBbbWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvYSBBbmRlcnNzb24NCg0K U2VudDogTW9uZGF5LCBGZWJydWFyeSAwMywgMjAxNCAxMDo1NSBQTQ0KDQpUbzogbXBsc0BpZXRm Lm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCg0KQ2M6IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IGRyYWZ0LWlldGYtbXBscy10 cC10ZS1taWJAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC10ZS1taWJA dG9vbHMuaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFttcGxzXSBzZWVraW5nIGNvbnNlbnN1cyBvbiBt YWtpbmcgZHJhZnQtaWV0Zi1tcGxzLXRwLXRlLW1pYiByZWFkLSBvbmx5DQoNCg0KDQpXb3JraW5n IEdyb3VwLA0KDQoNCg0KV2UgaGF2ZSBqdXN0IHJlY2FsbGVkIGRyYWZ0LWlldGYtbXBscy10cC10 ZS1taWIgZnJvbSB0aGUgSUVTRyB0byB0aGUgd29ya2luZyBncm91cCBmb3IgbW9yZSB3b3JrLiBX ZSBoYXZlIGEgc2VyaWVzIG9mIGNvbW1lbnRzIHRoYXQgYXJlIG1vc3RseSBmb3IgY2xhcmlmaWNh dGlvbi4gSG93ZXZlciB0aGUgbWFpbiByZWFzb24gZm9yIHJlY2FsbGluZyB0aGUgZG9jdW1lbnQg aXMgdGhhdCB0aGVyZSBpcyBvbmUgcG9pbnQgd2hlcmUgd2UgbmVlZCB0byBjb25maXJtIHdvcmtp bmcgZ3JvdXAgY29uc2Vuc3VzLg0KDQoNCg0KVGhlIElFVEYsIHRoZSB3b3JraW5nIGdyb3VwIGFu ZCB0aGUgTUlCIERvY3RvcnMgYXJlIHRvZGF5IHZlcnkgcmVsdWN0YW50IHRvIHByb2R1Y2UgcmVh ZC13cml0ZSBNSUIgbW9kdWxlcy4gVGhlIGN1cnJlbnQgZHJhZnQgaXMgcmVhZC13cml0ZSBmb3Ig YSBmZXcgb2JqZWN0cywgdGhpcyBpcyBiYXNlZCBvbiBhIGNvbnNlbnN1cyBjYWxsIGZvciBhbiBl YXJsaWVyIGRpc2N1c3Npb24sIGhvd2V2ZXIgdGhlIGNvbnNlbnN1cyBjYWxsIHdhcyBub3QgY2xl YXIuIEl0IGNhbiBiZSB0YWtlbiB0byBtZWFuIGJvdGggdGhhdCB3ZSB3YW50IHRvIGdvIHdpdGgg cmVhZC13cml0ZSBvYmplY3RzIGFuZCB0aGF0IHdlIHdhbnQgdG8gc2VlIHJlYWQtb25seS4gSXMg aXQgY2xlYXIgdGhhdCBpdCBoYXMgYmVlbiBpbnRlcnByZXRlZCBkaWZmZXJlbnRseSBieSBkaWZm ZXJlbnQgaW5kaXZpZHVhbHMuDQoNCg0KDQpUaGUgYXV0aG9ycyBhbmQgY2hhaXJzIGhhdmUgZGlz Y3Vzc2VkIHRoZSBpc3N1ZSBhbmQgd2UgaGF2ZSBhIHJvdWdoIGNvbnNlbnN1cyB0aGF0IHdlIHdh bnQgdGhlIE1JQiBtb2R1bGUocykgdG8gYmUgcmVhZC1vbmx5Lg0KDQoNCg0KV2UgdGhlcmVmb3Jl IGFyZSBhc2tpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgaWYgdGhpcyBpcyBPSyBmb3IgdGhlIE1JQg0K DQptb2R1bGUocykgaW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQuIFBsZWFzZSBpbmRpY2F0ZSBTdXBw b3J0IG9yIE9wcG9zZSBmb3IgdGhpcyBNSUIgKGRyYWZ0LWlldGYtbXBscy10cC10ZS1taWIpIHRv IGJlIHJlYWQtb25seS4NCg0KDQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGJlZm9yZSBGZWJydWFyeSAxOCwgMjAxNC4NCg0KDQoN CkxvYQ0KDQpmb3IgdGhlIE1QTFMgd2cgY2hhaXJzDQoNCi0tDQoNCg0KDQoNCg0KTG9hIEFuZGVy c3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208 bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbT4NCg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAg ICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCg0KSHVhd2Vp IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCm1wbHMg bWFpbGluZyBsaXN0DQoNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQptcGxzIG1haWxpbmcgbGlzdA0K DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K --_000_F918BC4881E38F4E8B67A4523EDB38D2118600DS04dasannetworks_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

No/oppose to make as Read-on= ly mib.

In our products we extensive= ly use R/W object of TE mib. We also have NMS/EMS that use TE read-write Ob= jects

 

Best Regards

Gwun

 

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

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson

Sent: Monday, February 03, 2= 014 10:55 PM

To: mpls@ietf.org

Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-te-mib@tools.ietf.org

Subject: [mpls] seeking cons= ensus on making draft-ietf-mpls-tp-te-mib read- only

 

Working Group,

 

We have just recalled draft-= ietf-mpls-tp-te-mib from the IESG to the working group for more work. We ha= ve a series of comments that are mostly for clarification. However the main= reason for recalling the document is that there is one point where we need to confirm working group consensus.<= o:p>

 

The IETF, the working group = and the MIB Doctors are today very reluctant to produce read-write MIB modu= les. The current draft is read-write for a few objects, this is based on a = consensus call for an earlier discussion, however the consensus call was not clear. It can be taken to mean both tha= t we want to go with read-write objects and that we want to see read-only. = Is it clear that it has been interpreted differently by different individua= ls.

 

The authors and chairs have = discussed the issue and we have a rough consensus that we want the MIB modu= le(s) to be read-only.

 

We therefore are asking the = working group if this is OK for the MIB

module(s) in the current doc= ument. Please indicate Support or Oppose for this MIB (draft-ietf-mpls-tp-t= e-mib) to be read-only.

 

Please send your comments to= the working group mailing list before February 18, 2014.=

 

Loa

for the MPLS wg chairs<= /o:p>

--

 

 

Loa Andersson  &nb= sp;            =          email: loa@mail01.huawei.com

Senior MPLS Expert &nbs= p;            &= nbsp;           loa@pi.nu

Huawei Technologies (consult= ant)     phone: +46 739 81 21 64<= /p>

____________________________= ___________________

mpls mailing list=

mpls@ietf.org

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

____________________________= ___________________

mpls mailing list=

mpls@ietf.org

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

 

--_000_F918BC4881E38F4E8B67A4523EDB38D2118600DS04dasannetworks_-- From tnadeau@lucidvision.com Tue Feb 4 05:59:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529391A012C for ; Tue, 4 Feb 2014 05:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BtF_Q5EeLA6 for ; Tue, 4 Feb 2014 05:59:43 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 512871A00E4 for ; Tue, 4 Feb 2014 05:59:43 -0800 (PST) Received: from [10.9.247.162] (mobile-166-137-187-011.mycingular.net [166.137.187.11]) by lucidvision.com (Postfix) with ESMTP id 7DB3A26DBA01; Tue, 4 Feb 2014 08:59:42 -0500 (EST) References: <52F08ED9.5050509@pi.nu> Mime-Version: 1.0 (1.0) In-Reply-To: <52F08ED9.5050509@pi.nu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <62A2449F-AB3E-4CBA-93A6-A7147EE587E3@lucidvision.com> X-Mailer: iPhone Mail (11B554a) From: "Thomas D. Nadeau" Date: Tue, 4 Feb 2014 05:59:40 -0800 To: Loa Andersson Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 13:59:45 -0000 I support removal of all writable objects in this MIB. Tom=20 > On Feb 3, 2014, at 10:55 PM, Loa Andersson wrote: >=20 > Working Group, >=20 > We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the > working group for more work. We have a series of comments that are > mostly for clarification. However the main reason for recalling the > document is that there is one point where we need to confirm working > group consensus. >=20 > The IETF, the working group and the MIB Doctors are today very reluctant > to produce read-write MIB modules. The current draft is read-write for a f= ew objects, this is based on a consensus call for an earlier > discussion, however the consensus call was not clear. It can be taken > to mean both that we want to go with read-write objects and that we > want to see read-only. Is it clear that it has been interpreted > differently by different individuals. >=20 > The authors and chairs have discussed the issue and we have a rough > consensus that we want the MIB module(s) to be read-only. >=20 > We therefore are asking the working group if this is OK for the MIB > module(s) in the current document. Please indicate Support or Oppose > for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only. >=20 > Please send your comments to the working group mailing list before > February 18, 2014. >=20 > Loa > for the MPLS wg chairs > --=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 >=20 From martin.vigoureux@alcatel-lucent.com Tue Feb 4 06:45: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 BCA5F1A012C for ; Tue, 4 Feb 2014 06:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 XQDdeQyOAGUQ for ; Tue, 4 Feb 2014 06:45:22 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 220BE1A0100 for ; Tue, 4 Feb 2014 06:45:22 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s14EjJQZ009136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 08:45:20 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s14EjGSM018427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 15:45:17 +0100 Received: from [172.27.205.227] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Feb 2014 15:45:16 +0100 Message-ID: <52F0FCFB.200@alcatel-lucent.com> Date: Tue, 4 Feb 2014 15:45:15 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Slots requests for MPLS WG sessions - IETF 89 - London X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 14:45:23 -0000 All, it is time we start building the MPLS WG agenda for London. The current IETF agenda, still subject to change, is available at: https://datatracker.ietf.org/meeting/89/agenda.html The MPLS WG sessions are, for the moment, scheduled on: Tuesday, March 4, Afternoon Session I, 13:00-14:00 and Thursday, March 6, Afternoon Sessions II & III, 15:20-16:50 and 17:00-18:30 Please send *me* (replying to this e-mail and copying the co-chairs) your request for a presentation slot, indicating: draft name, speaker and desired duration (covering presentation + Q&As) *as well as* what the objective of the presentation is, and what has changed since last time in case of non 00 individual drafts. Please send the requests before the 16th of February. Thank you Martin From muly_i@rad.com Tue Feb 4 06:49: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 8ED661A0124 for ; Tue, 4 Feb 2014 06:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCk5mVdPRmbj for ; Tue, 4 Feb 2014 06:49:12 -0800 (PST) Received: from rad.co.il (mailrelay01-ib1.rad.com [94.188.133.165]) by ietfa.amsl.com (Postfix) with ESMTP id 796561A0100 for ; Tue, 4 Feb 2014 06:49:11 -0800 (PST) Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with RC4-SHA encrypted SMTP; 4 Feb 2014 16:48:57 +0200 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 4 Feb 2014 16:49:06 +0200 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Tue, 4 Feb 2014 16:49:06 +0200 From: Muly Ilan To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only Thread-Index: AQHPIXYk24FW4ft2EUCWup+uSeelLJqlK3Gw Date: Tue, 4 Feb 2014 14:49:06 +0000 Message-ID: <60814a444d6343b5bc3eab5bbe181a3f@exrad6.ad.rad.co.il> References: <52F08ED9.5050509@pi.nu> In-Reply-To: <52F08ED9.5050509@pi.nu> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.114.24.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A010203.52F0FDE3.00FB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 (Unknown) Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 14:49:13 -0000 Oppose. In our implementation we need read-write/read-create access for the TE and = LSR extensions. Specifically, the new functionality provided by mplsIdGlobalId, mplsIdNodeI= d and mplsTunnelExtNodeConfigTable can only be realized by read-write/read-= create objects. Regards, Muly Ilan -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, February 04, 2014 8:55 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-te-mib@tools.ietf.org Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-= only Working Group, We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the workin= g group for more work. We have a series of comments that are mostly for cla= rification. However the main reason for recalling the document is that ther= e is one point where we need to confirm working group consensus. The IETF, the working group and the MIB Doctors are today very reluctant to= produce read-write MIB modules. The current draft is read-write for a few = objects, this is based on a consensus call for an earlier discussion, howev= er the consensus call was not clear. It can be taken to mean both that we w= ant to go with read-write objects and that we want to see read-only. Is it = clear that it has been interpreted differently by different individuals. The authors and chairs have discussed the issue and we have a rough consens= us that we want the MIB module(s) to be read-only. We therefore are asking the working group if this is OK for the MIB module(s) in the current document. Please indicate Support or Oppose for th= is MIB (draft-ietf-mpls-tp-te-mib) to be read-only. Please send your comments to the working group mailing list before February= 18, 2014. Loa for the MPLS wg chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From kkoushik@cisco.com Tue Feb 4 08:23: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 EC9171A01E6 for ; Tue, 4 Feb 2014 08:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 jn4CA7pnOWtF for ; Tue, 4 Feb 2014 08:23:31 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 923301A01C1 for ; Tue, 4 Feb 2014 08:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7397; q=dns/txt; s=iport; t=1391531000; x=1392740600; h=from:message-id:mime-version:subject:date:references:cc: to; bh=u2UxGNyI2P1iNRgXEdfqVRssCiOc3+g/OJKDz80StTk=; b=HTUvYaA4SAqmBQ5uJ90h6ZC62HNaJbEAT0OOjYU2+XG5x7lNzACPmg8f lNEbylludaqJ4aeUWroSSTCak/suVTBQwFMWNHexoaTfAiH+1mEx//itj 8zC3JmdXWR83b2y7EOinWNjaSx32nPqT7Si3gTUEklDybmRf1yFhtUGdq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAHgT8VKtJV2Y/2dsb2JhbABZgww4vnCBDBZ0giUBAQEEAQEBGk4DCwwCAhwDAQEBKAcbDB8HAggGE4gFDc4UEwQEjg8RASQbDQQGB4MegRQEhVmDcI5ikiGDTB2BNQ X-IronPort-AV: E=Sophos;i="4.95,780,1384300800"; d="scan'208,217";a="301771462" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 04 Feb 2014 16:23:19 +0000 Received: from rcdn-kkoushik-8812.cisco.com (rcdn-kkoushik-8812.cisco.com [10.99.130.227]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s14GNJpk004507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Feb 2014 16:23:19 GMT From: Agrahara Kiran Koushik Content-Type: multipart/alternative; boundary="Apple-Mail=_AFE4F10B-C3C4-409A-84E8-F0F9A69AAE8B" Message-Id: <8D4AD29E-0FCF-4C36-9298-C04B4F687FC2@cisco.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Tue, 4 Feb 2014 10:23:19 -0600 References: To: "loa@pi.nu" X-Mailer: Apple Mail (2.1508) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-te-mib@tools.ietf.org Subject: [mpls] Fwd: seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 16:23:34 -0000 --Apple-Mail=_AFE4F10B-C3C4-409A-84E8-F0F9A69AAE8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Oppose. At present all the TP MIB implementations within Cisco are read-only. = But we need the MIBs to be read-write/create to handle future requirements. Thanks Kiran >> ---------- Forwarded message ---------- >> From: Muly Ilan >> Date: Tuesday, February 4, 2014 >> Subject: seeking consensus on making draft-ietf-mpls-tp-te-mib = read-only >> To: Loa Andersson , "mpls@ietf.org" >> Cc: "mpls-chairs@tools.ietf.org" , = "draft-ietf-mpls-tp-te-mib@tools.ietf.org" = >>=20 >>=20 >> Oppose. >>=20 >> In our implementation we need read-write/read-create access for the = TE and LSR extensions. >>=20 >> Specifically, the new functionality provided by mplsIdGlobalId, = mplsIdNodeId and mplsTunnelExtNodeConfigTable can only be realized by = read-write/read-create objects. >>=20 >> Regards, >>=20 >> Muly Ilan >>=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Tuesday, February 04, 2014 8:55 AM >> To: mpls@ietf.org >> Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-tp-te-mib@tools.ietf.org >> Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib = read-only >>=20 >> Working Group, >>=20 >> We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the = working group for more work. We have a series of comments that are = mostly for clarification. However the main reason for recalling the = document is that there is one point where we need to confirm working = group consensus. >>=20 >> The IETF, the working group and the MIB Doctors are today very = reluctant to produce read-write MIB modules. The current draft is = read-write for a few objects, this is based on a consensus call for an = earlier discussion, however the consensus call was not clear. It can be = taken to mean both that we want to go with read-write objects and that = we want to see read-only. Is it clear that it has been interpreted = differently by different individuals. >>=20 >> The authors and chairs have discussed the issue and we have a rough = consensus that we want the MIB module(s) to be read-only. >>=20 >> We therefore are asking the working group if this is OK for the MIB >> module(s) in the current document. Please indicate Support or Oppose = for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only. >>=20 >> Please send your comments to the working group mailing list before = February 18, 2014. >>=20 >> Loa >> for the MPLS wg chairs >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >>=20 >=20 --Apple-Mail=_AFE4F10B-C3C4-409A-84E8-F0F9A69AAE8B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi

Oppose.

At present all the TP MIB implementations within Cisco are read-only. But we need the MIBs to be read-write/create
to handle future requirements.

Thanks
Kiran


---------- Forwarded message ----------
From: Muly Ilan <muly_i@rad.com>
Date: Tuesday, February 4, 2014
Subject: seeking consensus on making draft-ietf-mpls-tp-te-mib read-only
To: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-tp-te-mib@tools.ietf.org" <draft-ietf-mpls-tp-te-mib@tools.ietf.org>


Oppose.

In our implementation we need read-write/read-create access for the TE and LSR extensions.

Specifically, the new functionality provided by mplsIdGlobalId, mplsIdNodeId and mplsTunnelExtNodeConfigTable can only be realized by read-write/read-create objects.

Regards,

Muly Ilan

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Tuesday, February 04, 2014 8:55 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-te-mib@tools.ietf.org
Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only

Working Group,

We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the working group for more work. We have a series of comments that are mostly for clarification. However the main reason for recalling the document is that there is one point where we need to confirm working group consensus.

The IETF, the working group and the MIB Doctors are today very reluctant to produce read-write MIB modules. The current draft is read-write for a few objects, this is based on a consensus call for an earlier discussion, however the consensus call was not clear. It can be taken to mean both that we want to go with read-write objects and that we want to see read-only. Is it clear that it has been interpreted differently by different individuals.

The authors and chairs have discussed the issue and we have a rough consensus that we want the MIB module(s) to be read-only.

We therefore are asking the working group if this is OK for the MIB
module(s) in the current document. Please indicate Support or Oppose for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only.

Please send your comments to the working group mailing list before February 18, 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
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls





--Apple-Mail=_AFE4F10B-C3C4-409A-84E8-F0F9A69AAE8B-- From loa@pi.nu Tue Feb 4 09:14: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 666EA1A00F9 for ; Tue, 4 Feb 2014 09:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23ct9nUZsEw2 for ; Tue, 4 Feb 2014 09:14:12 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 60D5D1A0035 for ; Tue, 4 Feb 2014 09:14:12 -0800 (PST) Received: from [192.168.1.3] (unknown [112.208.87.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9803A1802AAF; Tue, 4 Feb 2014 18:14:09 +0100 (CET) Message-ID: <52F11FD8.3000000@pi.nu> Date: Wed, 05 Feb 2014 01:14:00 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yakov Rekhter References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> <201312121651.rBCGpYL46117@magenta.juniper.net> In-Reply-To: <201312121651.rBCGpYL46117@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 17:14:15 -0000 On 2013-12-13 00:51, Yakov Rekhter wrote: > Loa, > >> Yacov, >> >> I can't see that this flies! In fact it is counter to the wg chair >> proposal. We intended to keep the overlap as small as possible, >> specify a function in the document that needs the function. We did >> not intend to increase the overlap, but keep it as small as possible. >> >> You have this already neatly specified in draft-rekhter- let it stay >> there. > > I am fine with keeping the encoding and the procedures for the two > new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared > Tree TLV in draft-rekhter-mpls-pim-sm-over-mldp. > > However, I have a question on the following: > > 2. Assuming that the drafts are adopted, complete > draft-wijnands-mpls-in-band-wildcard-encoding as the > normative protocol specification of the piece within the > overlap. > > What do you define as "the overlap" ? > > Yakov. Yakov and Ice, I'm sorry that I left the two draft hanging in a no mans land for such a long time, other than traveling, being busy with other working group issues, and having to do a couple of restarts there are no excuse. Yakov, It is my understanding that the overlap is summed up in the following text from draft-rekhter: "This document also identifies the deployment scenarios where BGP Source Active auto-discovery routes will not be used." More specifically, the overlap is the case where the service provider has provisioned the network in such a way that the RP for a particular group G is always between the receivers and the sources. If the network is provisioned that way, the ingress PE for (S,G) is always the same as the ingress PE for the RP, so the SA A-D routes are never needed. Draft-rekhter should be scoped to the case where the network is not known to be provisioned in this way. /Loa mpls wg co-chair > > >> >> /Loa >> >> >> >> On 2013-12-06 22:05, Yakov Rekhter wrote: >>> Loa, >>> >>>> Working Group, >>>> >>>> It has been pointed out that there is overlap between >>>> draft-wijnands-mpls-mldp-in-band-wildcard-encoding and >>>> draft-rekhter-mpls-pim-sm-over-mldp. Within the overlap >>>> there is a critical piece of the protocol specification. >>>> Having this specified in two places is likely to result >>>> in non-interoperable implementations. >>>> >>>> The working group chairs have discussed the overlap and >>>> propose the following as a means of moving forward. >>>> >>>> 1. Issue a single poll to adopt both documents together as >>>> working group documents >>>> >>>> 2. Assuming that the drafts are adopted, complete >>>> draft-wijnands-mpls-in-band-wildcard-encoding as the >>>> normative protocol specification of the piece within the >>>> overlap. >>>> >>>> 3. Where mechanisms in draft-wijnanads are needed in >>>> draft-rekhter-mpls-pim-sm-over-mldp have the latter document >>>> reference the necessary sections of the former document. >>> >>> This would be fine with me, *provided* that >>> draft-wijnands-mpls-in-band-wildcard-encoding will add the encoding >>> of two new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit >>> IPv6 Shared Tree TLV, as these two TLVs are required by the mechanisms >>> defined in draft-rekhter-mpls-pim-sm-over-mldp. >>> >>> Yakov. >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From agmalis@gmail.com Tue Feb 4 11:39: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 28DCA1A0167 for ; Tue, 4 Feb 2014 11:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-Vde5Y_Hjjy for ; Tue, 4 Feb 2014 11:39:48 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id E96C11A0127 for ; Tue, 4 Feb 2014 11:39:47 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id cm18so12809956qab.23 for ; Tue, 04 Feb 2014 11:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=g5KbojDEzm1V8oHZYx654AFYj/+MUDud9zOyoKi4X10=; b=mcG8+M+xcYg2pAIMecw1oz/Z3PoyDbCQ7lIilXqsMsWt1lK6m5OsUSDeNHEnt7rCzf lEEiHfdYsFtBTnVW7nZ9AkdR6v8vtTqJNgY42eIDFRB08DaFCioHZsLB3+7fSp2hWIjs QiyM7VP81hUKMbUpFw+ESpj3Ls02VY/m6OcfUfGZPtVs26O+FxUyG8Anje7xGe9IUZmp yBmiXZmcLMNFBtEtgTS5K1l/BF7I5JVM6jqzEEpj9kxiuu21NRd2s7RSmIS3msenOV5f zZxB8DFOGQGLP+fny7U7AYJYRw2ztnwY2z+g6ujW1yyRRrU++eNg1GTB4KJ25/oGn2Ip DBpg== X-Received: by 10.224.87.193 with SMTP id x1mr69850569qal.70.1391542783524; Tue, 04 Feb 2014 11:39:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.71.132 with HTTP; Tue, 4 Feb 2014 11:39:23 -0800 (PST) In-Reply-To: <52F08085.9000907@pi.nu> References: <52F08085.9000907@pi.nu> From: "Andrew G. Malis" Date: Tue, 4 Feb 2014 14:39:23 -0500 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-extended-admin-group@tools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 19:39:50 -0000 I was asked by the WG chairs for a WG LC review of this draft. In general, the draft is ready for publication, but I do have a few comments. [Editorial] Section 1: There are several unbracketed RFC references that are in the actual list of references, and thus should be in brackets in the text. [Technical] Section 2.2: The numbering of the EAG's first word of bits is discussed, but the numbering of the bits in subsequent words is not described. It can be implied that the bit numbering will continue at 32 with the LSB of the second word of the EAG, but that is not actually stated. [Technical] Section 2.3.1: It is easy to predict that routers or software loads that implement the EAG will be deployed in the same network as those that only implement the AG. It can be expected that routers that do not implement the EAG will simply ignore that particular sub-TLG. Thus, those routers, upon receipt of both the AG and EAG sub-TLVs, will ignore the EAG and use the AG. Thus, for improved backwards compatibility, if the AG and EAG co-exist and the AG is inconsistent with the first word of the EAG, it would seem that the AG should take precedence. This is the opposite of what is stated in the draft. Of course, once all of the routers in a network support the EAG, the AG will be unnecessary and only the EAG will be used. [Technical] Section 2.3.2: I'm personally hard-pressed to find usefulness in the flexibility in this section. For maximum interoperability and simplicity of implementations, I would prefer that the third paragraph be modified to say: To encourage maximum interoperability an implementation MUST treat desired but unadvertised EAG bits as if they are set to 0. Consider the case where a node wants to only use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, clearly the 127th EAG bit is not defined - that is, it is neither explicitly 0 nor 1. The node which wants the 127th EAG bit to be 1 MUST NOT use this link, as the assumption is than an unadvertised bit is set to 0. and also completely remove the following paragraph. [Technical] Section 3 contains a lot of unattributed hand-waving. I would prefer that is simply say: Signaling EAG in RVSP is not addressed in this document. Addressing this in the future is not precluded. [Technical] Section 4: While the existing text is strictly true, having available a virtually unlimited set of AGs does make it more important for network administrations that want their traffic engineering to operate correctly to be careful with their AG allocation and usage, to avoid unintended side-effects of unconstrained AG usage or router misconfiguration. What may have been a relatively easy task with 32 AGs may be more difficult with 128, or 1000, or 1,000,000 attributes. Previously manual processes may need to be automated to ensure correctness. Feel free to add text to this effect to this section, or not, as you prefer. Thanks, Andy On Tue, Feb 4, 2014 at 12:54 AM, Loa Andersson wrote: > Working Group, > > This is to initiate a working group last call on > draft-ietf-mpls-extended-admin-group-02. > > There are no IPR disclosures against this document. The author has > stated that he is unaware of any 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 Feb 18, 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@ipv6.occnc.com Tue Feb 4 11:47: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 5AA221A0127 for ; Tue, 4 Feb 2014 11:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 VYeE_fj-PP6D for ; Tue, 4 Feb 2014 11:47:01 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id CDB601A0035 for ; Tue, 4 Feb 2014 11:47:00 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s14JkwTK087481; Tue, 4 Feb 2014 14:46:58 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402041946.s14JkwTK087481@maildrop2.v6ds.occnc.com> To: Loa Andersson From: Curtis Villamizar In-reply-to: Your message of "Tue, 04 Feb 2014 13:23:52 +0800." <52F07968.4090309@pi.nu> Date: Tue, 04 Feb 2014 14:46:58 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "" Subject: Re: [mpls] Closed wglc - Re: working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:47:03 -0000 In message <52F07968.4090309@pi.nu> Loa Andersson writes: > Working Group, > > This working group last call has been closed. There have been comments > can the editors please update, confirm with reviewers that the comments > are satisfactorily addressed and re-post a new version. > > /Loa > for the mpls wg co-chairs Loa, A question possibly related to Eric's PSC Update draft rather than this one. Does Eric's draft, draft-ietf-mpls-psc-updates, update only RFC 6378, or does it update RFC 6378 and this draft, draft-ietf-mpls-tp-psc-itu? If draft-ietf-mpls-psc-updates updates both, then maybe only a change is needed in draft-ietf-mpls-psc-updates. Curtis > On 2014-01-20 10:28, Loa Andersson wrote: > > Working Group, > > > > This is to start a two week working group last call on > > draft-ietf-mpls-tp-psc-itu. > > > > Please find the document at: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > > > The document editors has also supplied a "diff-list" between > > version -00 and -01 at: > > http://www.ietf.org/mail-archive/web/mpls/current/msg11338.html > > > > ITU-T SG15 has advised us that this document is a necessary reference > > for documents that is planned to go into the ITU-T approval process > > from the SG15 meeting end of March / beginning of April. Editors, > > authors and chairs has put in quite an effort to make this document > > ready. The schedule is very tight. > > > > We are now doing several review steps in parallel > > > > - the normal working group last call, please send your comments to the > > mpls working group mailing list (mpls@ietf.org) > > - the working group chairs reviewed this document as part of the > > mpls-rt review, normally we do a wg chair review before starting the > > wglc, this review will now take place in parallel > > - after the wglc and publication request there is an AD evaluation, > > this will now also take place in parallel with the wglc > > > > The editors and authors are advised to try to resolve as many of the > > comments as possible (on the mailing list) as they come in, but not to > > post the new version of the draft until the wglc is closed and the > > comments are resolved. > > > > This working group last call ends February 3rd. > > > > /Loa > > for the MPLS WG co-chairs > > -- > > > Loa Andersson email: loa@mail01.huawei.com From curtis@ipv6.occnc.com Tue Feb 4 12:08:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C69E1A01A6 for ; Tue, 4 Feb 2014 12:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 JJb78S0ADGox for ; Tue, 4 Feb 2014 12:08:55 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 047D81A016C for ; Tue, 4 Feb 2014 12:08:54 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s14K8rlB087734; Tue, 4 Feb 2014 15:08:53 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402042008.s14K8rlB087734@maildrop2.v6ds.occnc.com> To: Muly Ilan From: Curtis Villamizar In-reply-to: Your message of "Tue, 04 Feb 2014 14:49:06 +0000." <60814a444d6343b5bc3eab5bbe181a3f@exrad6.ad.rad.co.il> Date: Tue, 04 Feb 2014 15:08:53 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 20:08:58 -0000 Support these as read-only. See inline for comments on prior post. In message <60814a444d6343b5bc3eab5bbe181a3f@exrad6.ad.rad.co.il> Muly Ilan writes: > > Oppose. > > In our implementation we need read-write/read-create access for the TE > and LSR extensions. > > Specifically, the new functionality provided by mplsIdGlobalId, > mplsIdNodeId and mplsTunnelExtNodeConfigTable can only be realized by > read-write/read-create objects. The reason that people in operations and equipment vendors both generally oppose read/write MIBs is that they are a bad way to configure equipment. Some reasons are: 1. MIB sets using UDP are unreliable and need to be confirmed. 2. MIB sets generally require small configuration change operations. Sparse bulk set operations are not supported. 3. Large configuration changes using MIB requires lots of small operations followed by confirmation in most cases after each small operation. Large atomic operations are not possible. 4. Large configuration changes are common for providers that batch changes and apply them during "maintenance windows" during very off-peak hours such that should something go wrong or small disruptions occur, the impact to most enterprises is minimal. 5. Configuration changes, both small and large are better accomplished through other means such as NETCONF. Note that some tools based on the Yang language can translate a MIB into an XML dialect suitable for use with NETCONF. This may be a good transition strategy if you had planned to use read/write MIB. > Regards, > > Muly Ilan Curtis > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, February 04, 2014 8:55 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-te-mib@tools.ietf.org > Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only > > Working Group, > > We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the > working group for more work. We have a series of comments that are > mostly for clarification. However the main reason for recalling the > document is that there is one point where we need to confirm working > group consensus. > > The IETF, the working group and the MIB Doctors are today very > reluctant to produce read-write MIB modules. The current draft is > read-write for a few objects, this is based on a consensus call for an > earlier discussion, however the consensus call was not clear. It can > be taken to mean both that we want to go with read-write objects and > that we want to see read-only. Is it clear that it has been > interpreted differently by different individuals. > > The authors and chairs have discussed the issue and we have a rough > consensus that we want the MIB module(s) to be read-only. > > We therefore are asking the working group if this is OK for the MIB > module(s) in the current document. Please indicate Support or Oppose > for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only. > > Please send your comments to the working group mailing list before > February 18, 2014. > > Loa > for the MPLS wg chairs From yakov@juniper.net Tue Feb 4 13:59: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 4EB831A015A for ; Tue, 4 Feb 2014 13:59:04 -0800 (PST) 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 2u0JhDev5QWq for ; Tue, 4 Feb 2014 13:59:01 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id E294D1A012C for ; Tue, 4 Feb 2014 13:59:00 -0800 (PST) Received: from mail78-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Feb 2014 21:59:00 +0000 Received: from mail78-co1 (localhost [127.0.0.1]) by mail78-co1-R.bigfish.com (Postfix) with ESMTP id 63CCAD400E4; Tue, 4 Feb 2014 21:59:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h1155h) Received-SPF: softfail (mail78-co1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail78-co1 (localhost.localdomain [127.0.0.1]) by mail78-co1 (MessageSwitch) id 1391551138189415_10358; Tue, 4 Feb 2014 21:58:58 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.250]) by mail78-co1.bigfish.com (Postfix) with ESMTP id 1F76C8C004A; Tue, 4 Feb 2014 21:58:58 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Feb 2014 21:58:57 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 4 Feb 2014 13:58:57 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s14LwnL93027; Tue, 4 Feb 2014 13:58:49 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201402042158.s14LwnL93027@magenta.juniper.net> To: Loa Andersson In-Reply-To: <52F11FD8.3000000@pi.nu> References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> <201312121651.rBCGpYL46117@magenta.juniper.net> <52F11FD8.3000000@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Wed, 05 Feb 2014 01:14:00 +0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88426.1391551128.1@juniper.net> Date: Tue, 4 Feb 2014 13:58:49 -0800 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 21:59:04 -0000 Loa, > >> Yacov, > >> > >> I can't see that this flies! In fact it is counter to the wg chair > >> proposal. We intended to keep the overlap as small as possible, > >> specify a function in the document that needs the function. We did > >> not intend to increase the overlap, but keep it as small as possible. > >> > >> You have this already neatly specified in draft-rekhter- let it stay > >> there. > > > > I am fine with keeping the encoding and the procedures for the two > > new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared > > Tree TLV in draft-rekhter-mpls-pim-sm-over-mldp. > > > > However, I have a question on the following: > > > > 2. Assuming that the drafts are adopted, complete > > draft-wijnands-mpls-in-band-wildcard-encoding as the > > normative protocol specification of the piece within the > > overlap. > > > > What do you define as "the overlap" ? > > > > Yakov. > > Yakov and Ice, > > I'm sorry that I left the two draft hanging in a no mans land for > such a long time, other than traveling, being busy with other working > group issues, and having to do a couple of restarts there are no excuse. > > Yakov, > > It is my understanding that the overlap is summed up in the following > text from draft-rekhter: > > "This document also identifies the deployment scenarios where BGP > Source Active auto-discovery routes will not be used." > > More specifically, the overlap is the case where the service provider > has provisioned the network in such a way that the RP for a particular > group G is always between the receivers and the sources. If the > network is provisioned that way, the ingress PE for (S,G) is always > the same as the ingress PE for the RP, so the SA A-D routes are never > needed. > > Draft-rekhter should be scoped to the case where the network is not > known to be provisioned in this way. Could you please propose the text that you'd like meto insert in draft-rekhter ? Yakov. From muly_i@rad.com Tue Feb 4 14:29: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 E62561A0167 for ; Tue, 4 Feb 2014 14:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2aPZetGlKHn for ; Tue, 4 Feb 2014 14:29:34 -0800 (PST) Received: from rad.co.il (mailrelay01-ib1.rad.com [94.188.133.165]) by ietfa.amsl.com (Postfix) with ESMTP id A0D881A0163 for ; Tue, 4 Feb 2014 14:29:33 -0800 (PST) Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with RC4-SHA encrypted SMTP; 5 Feb 2014 00:29:14 +0200 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Wed, 5 Feb 2014 00:29:18 +0200 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Wed, 5 Feb 2014 00:29:18 +0200 From: Muly Ilan To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only Thread-Index: AQHPIeTt24FW4ft2EUCWup+uSeelLJqlpr8A Date: Tue, 4 Feb 2014 22:29:17 +0000 Message-ID: <43eedf0d24b44989ad627359f470016f@exrad6.ad.rad.co.il> References: Your message of "Tue, 04 Feb 2014 14:49:06 +0000." <60814a444d6343b5bc3eab5bbe181a3f@exrad6.ad.rad.co.il> <201402042008.s14K8rlB087734@maildrop2.v6ds.occnc.com> In-Reply-To: <201402042008.s14K8rlB087734@maildrop2.v6ds.occnc.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.114.24.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090209.52F169C9.0053, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 (Unknown) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2014 22:29:37 -0000 Hi Curtis, I agree with some (most) of the points you listed below. It's not my intention to start a debate on the pros/cons of SNMP as a provi= sioning protocol. Currently, our products do not support NETCONF. I believe this is the case = for other vendors as well. In addition, we already support the MPLS-TE-STD-MIB and MPLS-LSR-STD-MIB fo= r MPLS-TE provisioning. So for us the shortest TTM is to add MIB extensions= for MPLS-TP provisioning. I believe this is the case for other vendors as = well. Since we need the functionality of mapping the MPLS-TP identifiers, Global_= ID::Node_ID, to the ingress/egress LSR identifier in existing mplsTunnelTab= le the mpls-tp-te-mib in its present contents, with read-write/read-create = objects, is good for us. Muly -----Original Message----- From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]=20 Sent: Tuesday, February 04, 2014 10:09 PM To: Muly Ilan Cc: Loa Andersson; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mp= ls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib r= ead-only Support these as read-only. See inline for comments on prior post. In message <60814a444d6343b5bc3eab5bbe181a3f@exrad6.ad.rad.co.il> Muly Ilan writes: >=20 > Oppose. > =20 > In our implementation we need read-write/read-create access for the TE=20 > and LSR extensions. > =20 > Specifically, the new functionality provided by mplsIdGlobalId,=20 > mplsIdNodeId and mplsTunnelExtNodeConfigTable can only be realized by=20 > read-write/read-create objects. The reason that people in operations and equipment vendors both generally o= ppose read/write MIBs is that they are a bad way to configure equipment. S= ome reasons are: 1. MIB sets using UDP are unreliable and need to be confirmed. 2. MIB sets generally require small configuration change operations. Sparse bulk set operations are not supported. 3. Large configuration changes using MIB requires lots of small operations followed by confirmation in most cases after each small operation. Large atomic operations are not possible. 4. Large configuration changes are common for providers that batch changes and apply them during "maintenance windows" during very off-peak hours such that should something go wrong or small disruptions occur, the impact to most enterprises is minimal. 5. Configuration changes, both small and large are better accomplished through other means such as NETCONF. Note that some tools based on the Yang language can translate a MIB into an= XML dialect suitable for use with NETCONF. This may be a good transition = strategy if you had planned to use read/write MIB. > Regards, > =20 > Muly Ilan Curtis > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, February 04, 2014 8:55 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org;=20 > draft-ietf-mpls-tp-te-mib@tools.ietf.org > Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib=20 > read-only > =20 > Working Group, > =20 > We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the=20 > working group for more work. We have a series of comments that are=20 > mostly for clarification. However the main reason for recalling the=20 > document is that there is one point where we need to confirm working=20 > group consensus. > =20 > The IETF, the working group and the MIB Doctors are today very=20 > reluctant to produce read-write MIB modules. The current draft is=20 > read-write for a few objects, this is based on a consensus call for an=20 > earlier discussion, however the consensus call was not clear. It can=20 > be taken to mean both that we want to go with read-write objects and=20 > that we want to see read-only. Is it clear that it has been=20 > interpreted differently by different individuals. > =20 > The authors and chairs have discussed the issue and we have a rough=20 > consensus that we want the MIB module(s) to be read-only. > =20 > We therefore are asking the working group if this is OK for the MIB > module(s) in the current document. Please indicate Support or Oppose=20 > for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only. > =20 > Please send your comments to the working group mailing list before=20 > February 18, 2014. > =20 > Loa > for the MPLS wg chairs From internet-drafts@ietf.org Tue Feb 4 18:14: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 5E4351A01C1; Tue, 4 Feb 2014 18:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G_0rb-3_vue; Tue, 4 Feb 2014 18:14:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA07D1A01BD; Tue, 4 Feb 2014 18:14:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140205021432.24695.98948.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 18:14:32 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-linear-protection-mib-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: Wed, 05 Feb 2014 02:14:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Transport Profile Linear Protection MIB Authors : Kingston Smiler Selvaraj Venkatesan Mahalingam Vishwas Manral Daniel King Sam Aldrin Filename : draft-ietf-mpls-tp-linear-protection-mib-02.txt Pages : 30 Date : 2014-02-04 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing MPLS Transport Profile (MPLS-TP) Linear Protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-linear-protection-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-linear-protection-mib-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 loa@pi.nu Tue Feb 4 21:30: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 517E51A0033 for ; Tue, 4 Feb 2014 21:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W6Hg57wjvIf for ; Tue, 4 Feb 2014 21:30:34 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A72B51A0031 for ; Tue, 4 Feb 2014 21:30:34 -0800 (PST) Received: from [192.168.1.3] (unknown [119.95.156.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BF6131802AAF; Wed, 5 Feb 2014 06:30:31 +0100 (CET) Message-ID: <52F1CC6F.1070906@pi.nu> Date: Wed, 05 Feb 2014 13:30:23 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yakov Rekhter References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> <201312121651.rBCGpYL46117@magenta.juniper.net> <52F11FD8.3000000@pi.nu> <201402042158.s14LwnL93027@magenta.juniper.net> In-Reply-To: <201402042158.s14LwnL93027@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Feb 2014 05:30:36 -0000 On 2014-02-05 05:58, Yakov Rekhter wrote: > Loa, > >>>> Yakov, >>>> >>>> I can't see that this flies! In fact it is counter to the wg chair >>>> proposal. We intended to keep the overlap as small as possible, >>>> specify a function in the document that needs the function. We did >>>> not intend to increase the overlap, but keep it as small as possible. >>>> >>>> You have this already neatly specified in draft-rekhter- let it stay >>>> there. >>> >>> I am fine with keeping the encoding and the procedures for the two >>> new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared >>> Tree TLV in draft-rekhter-mpls-pim-sm-over-mldp. >>> >>> However, I have a question on the following: >>> >>> 2. Assuming that the drafts are adopted, complete >>> draft-wijnands-mpls-in-band-wildcard-encoding as the >>> normative protocol specification of the piece within the >>> overlap. >>> >>> What do you define as "the overlap" ? >>> >>> Yakov. >> >> Yakov and Ice, >> >> I'm sorry that I left the two draft hanging in a no mans land for >> such a long time, other than traveling, being busy with other working >> group issues, and having to do a couple of restarts there are no excuse. >> >> Yakov, >> >> It is my understanding that the overlap is summed up in the following >> text from draft-rekhter: >> >> "This document also identifies the deployment scenarios where BGP >> Source Active auto-discovery routes will not be used." >> >> More specifically, the overlap is the case where the service provider >> has provisioned the network in such a way that the RP for a particular >> group G is always between the receivers and the sources. If the >> network is provisioned that way, the ingress PE for (S,G) is always >> the same as the ingress PE for the RP, so the SA A-D routes are never >> needed. >> >> Draft-rekhter should be scoped to the case where the network is not >> known to be provisioned in this way. > > Could you please propose the text that you'd like meto insert in > draft-rekhter ? > > Yakov. > Yakov, I will try to do so, as I understand it you agree to go ahead with the wg adoption poll for draft-wijnands-mpls-mldp-in-band-wildcard- encoding, while we sort out the text that needs to go into draft-rekhter-mpls-pim-sm-over-mldp. I will start this process as soon as I have a slot. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Tue Feb 4 22:29: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 771311A004C for ; Tue, 4 Feb 2014 22:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMahGl-WCmTP for ; Tue, 4 Feb 2014 22:29:11 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id CAEB11A004A for ; Tue, 4 Feb 2014 22:29:10 -0800 (PST) Received: from [192.168.1.3] (unknown [119.95.156.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9E22E1802AAF; Wed, 5 Feb 2014 07:29:08 +0100 (CET) Message-ID: <52F1DA2C.2070007@pi.nu> Date: Wed, 05 Feb 2014 14:29:00 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 06:29:12 -0000 Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. Please note that we have identified an overlap between this document and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp to cover this. There are no IPR claims against this document. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends February 19, 2014. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From Uwe.Joorde@telekom.de Wed Feb 5 00:28: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 160D01A00A3 for ; Wed, 5 Feb 2014 00:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjovRFsKoTAy for ; Wed, 5 Feb 2014 00:28:34 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id CF05E1A0063 for ; Wed, 5 Feb 2014 00:28:32 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 05 Feb 2014 09:28:29 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 5 Feb 2014 09:28:28 +0100 From: To: , , , , Date: Wed, 5 Feb 2014 09:28:27 +0100 Thread-Topic: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: Ac8iO57ybZUYlRlFSUC4BzZuBN068AAD4kzg Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DF92DAA669@HE113667.emea1.cds.t-internal.com> References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 08:28:37 -0000 Support. From operater's perspective there are several valid use cases. Cheers, Uwe Uwe Joorde, Deutsche Telekom IP-Backbone Engineering -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, February 05, 2014 7:29 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); = draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org Subject: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-enco= ding Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. Please note that we have identified an overlap between this document and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp to cover this. There are no IPR claims against this document. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends February 19, 2014. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From yakov@juniper.net Wed Feb 5 06:30:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA281A0180 for ; Wed, 5 Feb 2014 06:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HopiJuigUNxX for ; Wed, 5 Feb 2014 06:30:43 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 136F31A015B for ; Wed, 5 Feb 2014 06:30:42 -0800 (PST) Received: from mail180-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.22; Wed, 5 Feb 2014 14:30:42 +0000 Received: from mail180-co9 (localhost [127.0.0.1]) by mail180-co9-R.bigfish.com (Postfix) with ESMTP id 37FCFB000C8; Wed, 5 Feb 2014 14:30:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz98dI936eI1432Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h1155h) Received-SPF: softfail (mail180-co9: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail180-co9 (localhost.localdomain [127.0.0.1]) by mail180-co9 (MessageSwitch) id 1391610639576447_30726; Wed, 5 Feb 2014 14:30:39 +0000 (UTC) Received: from CO9EHSMHS015.bigfish.com (unknown [10.236.132.251]) by mail180-co9.bigfish.com (Postfix) with ESMTP id 87868B8004C; Wed, 5 Feb 2014 14:30:39 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by CO9EHSMHS015.bigfish.com (10.236.130.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 5 Feb 2014 14:30:39 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 5 Feb 2014 06:30:38 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s15EUML50526; Wed, 5 Feb 2014 06:30:33 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201402051430.s15EUML50526@magenta.juniper.net> To: Loa Andersson In-Reply-To: <52F1CC6F.1070906@pi.nu> References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> <201312121651.rBCGpYL46117@magenta.juniper.net> <52F11FD8.3000000@pi.nu> <201402042158.s14LwnL93027@magenta.juniper.net> <52F1CC6F.1070906@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Wed, 05 Feb 2014 13:30:23 +0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13938.1391610622.1@juniper.net> Date: Wed, 5 Feb 2014 06:30:22 -0800 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Feb 2014 14:30:45 -0000 Loa, > On 2014-02-05 05:58, Yakov Rekhter wrote: > > Loa, > > > >>>> Yakov, > >>>> > >>>> I can't see that this flies! In fact it is counter to the wg chair > >>>> proposal. We intended to keep the overlap as small as possible, > >>>> specify a function in the document that needs the function. We did > >>>> not intend to increase the overlap, but keep it as small as possible. > >>>> > >>>> You have this already neatly specified in draft-rekhter- let it stay > >>>> there. > >>> > >>> I am fine with keeping the encoding and the procedures for the two > >>> new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared > >>> Tree TLV in draft-rekhter-mpls-pim-sm-over-mldp. > >>> > >>> However, I have a question on the following: > >>> > >>> 2. Assuming that the drafts are adopted, complete > >>> draft-wijnands-mpls-in-band-wildcard-encoding as the > >>> normative protocol specification of the piece within the > >>> overlap. > >>> > >>> What do you define as "the overlap" ? > >>> > >>> Yakov. > >> > >> Yakov and Ice, > >> > >> I'm sorry that I left the two draft hanging in a no mans land for > >> such a long time, other than traveling, being busy with other working > >> group issues, and having to do a couple of restarts there are no excuse. > >> > >> Yakov, > >> > >> It is my understanding that the overlap is summed up in the following > >> text from draft-rekhter: > >> > >> "This document also identifies the deployment scenarios where BGP > >> Source Active auto-discovery routes will not be used." > >> > >> More specifically, the overlap is the case where the service provider > >> has provisioned the network in such a way that the RP for a particular > >> group G is always between the receivers and the sources. If the > >> network is provisioned that way, the ingress PE for (S,G) is always > >> the same as the ingress PE for the RP, so the SA A-D routes are never > >> needed. > >> > >> Draft-rekhter should be scoped to the case where the network is not > >> known to be provisioned in this way. > > > > Could you please propose the text that you'd like meto insert in > > draft-rekhter ? > > > > Yakov. > > > > Yakov, > > I will try to do so, as I understand it you agree to go ahead with > the wg adoption poll for draft-wijnands-mpls-mldp-in-band-wildcard- > encoding, while we sort out the text that needs to go into > draft-rekhter-mpls-pim-sm-over-mldp. I agreed to the plan you proposed in your e-mail on Dec 4, 2013. According to this plan 1. Issue a single poll to adopt both documents together as working group documents However, what you doing now is *not* what you proposed in the plan, as now you issued a two week poll on adopting just draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working group document. Yakov. From lizho.jin@gmail.com Wed Feb 5 07:02: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 3251A1A01BF for ; Wed, 5 Feb 2014 07:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNzInYKlEnXi for ; Wed, 5 Feb 2014 07:02:07 -0800 (PST) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6E1A01B7 for ; Wed, 5 Feb 2014 07:02:07 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id um1so471175pbc.19 for ; Wed, 05 Feb 2014 07:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:from:to:mime-version:content-type :content-transfer-encoding; bh=RZ84vqSIOmM1CwHWSah95VmgvODBAZun5QbGLstDgHo=; b=xRu6AFQKWZtqcZpqhEUm3Yo+C3GpV2kSjqZryKxX59PnzohsJXcXKN41j19CLNWW43 +ZoZgcwQwb/sev1Xnz8LUk8yzDXRdTebIV+TeikYW1JWdkf33rWZM3YiMKw3ixoEoMeH 4cP/V/y1JQejySyGQCmlQEASWs03DakHo7euSpDMeZLs4efaw+kIXu6X5GnOpo1AfRcI TlsvYHlA4XYAJcjAoEu39bQT238c0ntvCIHTie05djac8yUaa7KJgfn6i6nBdvBDjE1x jqh+Rh/lwvmE9976zjKtWDCIiz39psfwtUde/n5/cEEi8c8BCVDxJMcq8vDbaVOFDHFU rMbw== X-Received: by 10.68.249.100 with SMTP id yt4mr2147521pbc.165.1391612526240; Wed, 05 Feb 2014 07:02:06 -0800 (PST) Received: from [10.165.89.189] ([221.131.128.209]) by mx.google.com with ESMTPSA id os1sm197775367pac.20.2014.02.05.07.02.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 07:02:05 -0800 (PST) Date: Wed, 05 Feb 2014 22:51:15 +0800 Message-ID: From: Lizhong Jin To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: [mpls] Fwd: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Feb 2014 15:02:12 -0000 Rm9yd2FyZCBteSBjb21tZW50cyBvZiAtMTAgdmVyc2lvbiB0byBXRyBmb3IgZGlzY3Vzc2lvbi4K CkxpemhvbmcKCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0KU3ViamVjdDogUkU6 IE1QTFMtUlQgcmV2aWV3IG9mIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9u CkZyb206IExpemhvbmcgSmluIDxsaXpoby5qaW5AZ21haWwuY29tPgpUbzogJ1Jvc3MgQ2FsbG9u JyA8cmNhbGxvbkBqdW5pcGVyLm5ldD4sJ1JhdmVlbmRyYSBUb3J2aScgPHJ0b3J2aUBqdW5pcGVy Lm5ldD4sIidUYXJlayBTYWFkICh0c2FhZCknIiA8dHNhYWRAY2lzY28uY29tPiwnRXJpYyBHcmF5 JyA8ZXJpYy5ncmF5QGVyaWNzc29uLmNvbT4KQ0M6IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn LCdNYXJ0aW4gVmlnb3VyZXV4JyA8bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20+ CgpIaSBSb3NzIGFuZCBBdXRob3JzLApJIGhhdmUgc29tZSBhZGRpdGlvbmFsIGRpc2N1c3Npb25z IHdpdGggSHVhaW1vIHByaXZhdGVseSBhYm91dCB0aGlzIG5ldwp2ZXJzaW9uLiBUaGlzIHZlcnNp b24gaXMgdGVjaG5pY2FsbHkgZmVhc2libGUsIGJ1dCBJIGJlbGlldmUgYW4gdXBkYXRlZAp2ZXJz aW9uIGlzIHN0aWxsIG5lY2Vzc2FyeS4KVGhlIHRlY2huaWNhbCBjb21tZW50cyBhcmUgYnJpZWZs eSBhcyBmb2xsb3dzOgoxLiB0aGUgZmFjaWxpdHkgcHJvdGVjdGlvbiBpbiB0aGlzIGRyYWZ0IGlz IG5vdCB0aGUgc2FtZSBhcyBkZWZpbmVkIGluClJGQzQwOTAuIEZvciBmYWNpbGl0eSBwcm90ZWN0 aW9uIGluIFJGQzQwOTAsIGEgYmFja3VwIHR1bm5lbCBjb3VsZCBwcm90ZWN0CmFueSB0cmFmZmlj IHRoYXQgZGVzdGluZWQgdG8gdGhlIGJhY2t1cCBub2RlLiBCdXQgdGhlIHNvbHV0aW9uIGluIHRo aXMgZHJhZnQKcmVxdWlyZXMgZGlmZmVyZW50IGJhY2t1cCBMU1AgYWxsb2NhdGlvbiB0byBwcm90 ZWN0IGRpZmZlcmVudCBwcmltYXJ5IExFUi4gSQpzdWdnZXN0IGhhdmluZyBhbm90aGVyIG5hbWUg dG8gZGVzY3JpYmUgdGhpcyBtZWNoYW5pc20sIGxpa2UgdmlydHVhbCBub2RlCmJhc2VkIHByb3Rl Y3Rpb24uCjIuIHRoZSBzaWduYWxpbmcgYmV0d2VlbiBwcmltYXJ5IGVncmVzcyBhbmQgYmFja3Vw IGVncmVzcyBpbiBzZWN0aW9uIDQuMwpzaG91bGQgYmUgc3BlY2lmaWVkIGluIHRoaXMgc3RhbmRh cmQgdHJhY2sgZHJhZnQuCgpSZWdhcmRzCkxpemhvbmcKCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0KPiBGcm9tOiBSb3NzIENhbGxvbiBbbWFpbHRvOnJjYWxsb25AanVuaXBlci5uZXRdCj4g U2VudDogMjAxNOW5tDHmnIgxOOaXpSAwOjA4Cj4gVG86IFJhdmVlbmRyYSBUb3J2aTsgVGFyZWsg U2FhZCAodHNhYWQpOyBMaXpob25nIEppbjsgRXJpYyBHcmF5Cj4gQ2M6IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnOyBNYXJ0aW4gVmlnb3VyZXV4Cj4gU3ViamVjdDogRlc6IE1QTFMtUlQgcmV2 aWV3IG9mIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uCj4gCj4gVGhpcyBy ZXZpZXcgYW5kIHRoZSBhc3NvY2lhdGVkIGRpc2N1c3Npb24gaGFzIGdvbmUgb24gZm9yIHF1aXRl IGEgd2hpbGUuClRoZQo+IGRpc2N1c3Npb24gb24gdGhlIGVtYWlsIGxpc3QgYXBwZWFycyB0byBi ZSB3aW5kaW5nIGRvd24uCj4gCj4gQXJlIHlvdSBndXlzIG9rYXkgd2l0aCB0aGUgY3VycmVudCBz dGF0dXMgb2YgdGhlIGRyYWZ0PyBEbyB5b3UgdGhpbmsgdGhhdAphCj4gZnVydGhlciB1cGRhdGUg aXMgbmVlZGVkPwo+IAo+IFRoYW5rcywgUm9zcwo+IAo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tCj4gRnJvbTogUm9zcyBDYWxsb24KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDExLCAyMDEzIDEw OjE2IFBNCj4gVG86IFJhdmVlbmRyYSBUb3J2aTsgJ0VyaWMgR3JheSc7ICd0c2FhZEBjaXNjby5j b20nOyAnTGl6aG9uZyBKaW4nCj4gQ2M6IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyAnZHJh ZnQtY2hlbi1tcGxzLXAybXAtZWdyZXNzLQo+IHByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcnOyAn TWFydGluIFZpZ291cmV1eCcKPiBTdWJqZWN0OiBNUExTLVJUIHJldmlldyBvZiBkcmFmdC1jaGVu LW1wbHMtcDJtcC1lZ3Jlc3MtcHJvdGVjdGlvbgo+IAo+IFJhdmksIEVyaWMsIFRhcmVrLCBMaXpo b25nOwo+IAo+IFlvdSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgTVBMUyBSZXZpZXcgdGVhbSByZXZp ZXdlcnMgZm9yIGRyYWZ0LWNoZW4tCj4gbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uLTA5Lgo+ IAo+IE5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBDQydkIG9uIHRoaXMgZW1haWwgc28g dGhhdCB5b3UgY2FuIGtub3cKdGhhdAo+IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVy LCBwbGVhc2UgZG8gbm90IHJldmlldyB5b3VyIG93biBkb2N1bWVudC4KPiAKPiBSZXZpZXdzIHNo b3VsZCBjb21tZW50IG9uIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LCBpcyBpdCB1 c2VmdWwKPiAoaWUsIGlzIGl0IGxpa2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0 aW9uYWwgbmV0d29ya3MpLCBhbmQgaXMKdGhlCj4gZG9jdW1lbnQgdGVjaG5pY2FsbHkgc291bmQ/ ICBBbHNvLCBpcyB0aGUgdGV4dCBhbmQgZ3JhbW1hciB1bmRlcnN0YW5kYWJsZQo+IChpdCBkb2Vz bid0IG5lZWQgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlIHJlYXNv bmFibHkKY2xlYXIpLgo+IFdlIGFyZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgd2hldGhlciB0aGUg ZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUKPiBjb25zaWRlcmVkIGZvciBXRyBhZG9wdGlvbiAoaWUs IGl0IGRvZXNuJ3QgaGF2ZSB0byBiZSBwZXJmZWN0IGF0IHRoaXMKcG9pbnQsCj4gYnV0IHNob3Vs ZCBiZSBhIGdvb2Qgc3RhcnQpLgo+IAo+IFJldmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRv Y3VtZW50IGF1dGhvcnMsIFdHIGNvLWNoYWlycyBhbmQgV0cKPiBzZWNyZXRhcnksIGFuZCBDQydk IHRvIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QuIElmIG5lY2Vzc2FyeSwgQ29tbWVudHMgbWF5Cj4g YmUgc2VudCBwcml2YXRlbHkgdG8gb25seSB0aGUgV0cgY2hhaXJzLgo+IAo+IEFyZSB5b3UgYWJs ZSB0byByZXZpZXcgdGhpcyBkcmFmdCBieSBKdW5lIDI2LCAyMDEzPwo+IAo+IFRoYW5rcywgUm9z cwo+IChhcyBNUExTIFdHIGNoYWlyKQo+IAo+IAoKCg== From ryoo@etri.re.kr Wed Feb 5 07:50: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 DF0C71A01BB for ; Wed, 5 Feb 2014 07:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 kYopHykEzOoj for ; Wed, 5 Feb 2014 07:50:07 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 813211A01F6 for ; Wed, 5 Feb 2014 07:50:06 -0800 (PST) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 6 Feb 2014 00:50:07 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Thu, 6 Feb 2014 00:50:02 +0900 From: "Ryoo, Jeong-dong" To: "adrian@olddog.co.uk" , 'Loa Andersson' , "mpls@ietf.org" Thread-Topic: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01 Thread-Index: Ac8W6jHMZ8uZf2LMS56KIUdobofaHQDhoS5g//+n1QCAEIep9g== Date: Wed, 5 Feb 2014 15:50:01 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B619D@SMTP2.etri.info> References: <0bc301cf16ea$3981cd00$ac856700$@olddog.co.uk> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846@SMTP2.etri.info>, <009101cf1a90$132a5d30$397f1790$@olddog.co.uk> In-Reply-To: <009101cf1a90$132a5d30$397f1790$@olddog.co.uk> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.44] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B619DSMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:50:11 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B619DSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIGluZGljYXRlZCBpbiB0aGUgcHJldmlvdXMgZW1haWwsIEkgY29tbXVuaWNhdGVk IHdpdGggQWRyaWFuIHRvIHJlc29sdmUgaGlzIGNvbW1lbnRzIG9uIFNlY3Rpb24gOS4NClRoZSBu ZXcgdGV4dCBwcm9wb3NhbCBmb3IgU2VjdGlvbiA5IGlzIGJlbG93LCBhbmQgQWRyaWFuIGNvbmZp cm1lZCB0aGF0IHRoaXMgbmV3IHRleHQgd291bGQgYWRkcmVzcyBoaXMgY29uY2VybnMgb24gdGhh dCBzZWN0aW9uLg0KDQo9PT0gQkVHSU4gb2YgU2VjdGlvbiA5ID09PQ0KDQo5LiAgQ2FwYWJpbGl0 aWVzIGFuZCBtb2Rlcw0KDQoNCg0KOS4xLiAgQ2FwYWJpbGl0aWVzDQoNCg0KDQogICBBIENhcGFi aWxpdHkgaXMgYW4gaW5kaXZpZHVhbCBiZWhhdmlvciB3aG9zZSB1c2UgaXMgc2lnbmFsZWQgaW4g YQ0KDQogICBDYXBhYmlsaXRpZXMgVExWLCB3aGljaCBpcyBwbGFjZWQgaW4gT3B0aW9uYWwgVExW cyBmaWVsZCBpbnNpZGUgdGhlDQoNCiAgIFBTQyBtZXNzYWdlIHNob3duIGluIEZpZ3VyZSAyIG9m IFJGQyA2Mzc4IFtSRkM2Mzc4XS4gIFRoZSBmb3JtYXQgb2YNCg0KICAgdGhlIENhcGFiaWxpdGll cyBUTFYgaXM6DQoNCg0KDQogICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAg ICAgMiAgICAgICAgICAgICAgICAgICAzDQoNCiAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KDQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQog ICB8ICBUeXBlID0gQ2FwYWJpbGl0aWVzICAgICAgICAgIHwgICAgTGVuZ3RoICAgICAgICAgICAg ICAgICAgICAgfA0KDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAg VmFsdWUgPSBGbGFncyAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K DQoNCg0KICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBGb3JtYXQgb2YgQ2FwYWJpbGl0aWVz IFRMVg0KDQoNCg0KICAgVGhlIHZhbHVlIG9mIHRoZSBUeXBlIGZpZWxkIGlzIFRCRCBwZW5kaW5n IElBTkEgYWxsb2NhdGlvbi4NCg0KDQoNCiAgIFRoZSB2YWx1ZSBvZiB0aGUgTGVuZ3RoIGZpZWxk IGlzIHRoZSBsZW5ndGggb2YgdGhlIEZsYWdzIGZpZWxkIGluDQoNCiAgIG9jdGV0cy4gIFRoZSBs ZW5ndGggb2YgdGhlIEZsYWdzIGZpZWxkIE1VU1QgYmUgYSBtdWx0aXBsZSBvZiA0IG9jdGV0cw0K DQogICBhbmQgTVVTVCBiZSB0aGUgbWluaW11bSByZXF1aXJlZCB0byBzaWduYWwgYWxsIHRoZSBy ZXF1aXJlZA0KDQogICBjYXBhYmlsaXRpZXMuDQoNCg0KDQogICBTZWN0aW9uIDQgdG8gU2VjdGlv biA4IGRpc2N1c3MgZml2ZSBjYXBhYmlsaXRpZXMgdGhhdCBhcmUgc2lnbmFsZWQNCg0KICAgdXNp bmcgdGhlIGZpdmUgbW9zdCBzaWduaWZpY2FudCBiaXRzOyBpZiBhIG5vZGUgd2lzaGVzIHRvIHNp Z25hbA0KDQogICB0aGVzZSBmaXZlIGNhcGFiaWxpdGllcywgaXQgTVVTVCBzZW5kIGEgRmxhZ3Mg ZmllbGQgb2YgNCBvY3RldHMuICBBDQoNCiAgIG5vZGUgd291bGQgc2VuZCBhIEZsYWdzIGZpZWxk IGdyZWF0ZXIgdGhhbiA0IG9jdGV0cyBvbmx5IGlmIGl0IGhhZA0KDQogICBtb3JlIHRoYW4gMzIg Q2FwYWJpbGl0aWVzIHRvIGluZGljYXRlLiAgQWxsIHVudXNlZCBiaXRzIE1VU1QgYmUgc2V0DQoN CiAgIHRvIHplcm8uDQoNCg0KDQogICBJZiB0aGUgYml0IGFzc2lnbmVkIGZvciBhbiBpbmRpdmlk dWFsIGNhcGFiaWxpdHkgaXMgc2V0IHRvIDEsIGl0DQoNCiAgIGluZGljYXRlcyB0aGUgc2VuZGlu ZyBub2RlJ3MgaW50ZW50IHRvIHVzZSB0aGF0IGNhcGFiaWxpdHkgaW4gdGhlDQoNCiAgIHByb3Rl Y3RlZCBkb21haW4uICBJZiBhIGJpdCBpcyBzZXQgdG8gMCwgdGhlIHNlbmRpbmcgbm9kZSBkb2Vz IG5vdA0KDQogICBpbnRlbmQgdG8gdXNlIHRoZSBpbmRpY2F0ZWQgY2FwYWJpbGl0eSBpbiB0aGUg cHJvdGVjdGVkIGRvbWFpbi4gIE5vdGUNCg0KICAgdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8g ZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGUgaW50ZW50IG5vdCB0byB1c2UNCg0KICAgYSBjYXBhYmls aXR5IGFuZCBhIG5vZGUncyBjb21wbGV0ZSBub24tc3VwcG9ydCAoaS5lLiwgbGFjayBvZg0KDQog ICBpbXBsZW1lbnRhdGlvbikgb2YgYSBnaXZlbiBjYXBhYmlsaXR5Lg0KDQoNCg0KICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGZpdmUgc3BlY2lmaWMgY2FwYWJpbGl0aWVzIHRoYXQgYXJlIGRlc2Ny aWJlZA0KDQogICBmcm9tIFNlY3Rpb24gNCB0byBTZWN0aW9uIDguICBFYWNoIGNhcGFiaWxpdHkg aXMgYXNzaWduZWQgYml0IGFzDQoNCiAgIGZvbGxvd3M6DQoNCg0KDQogICAgICAweDgwMDAwMDAw OiBwcmlvcml0eSBtb2RpZmljYXRpb24NCg0KDQoNCiAgICAgIDB4NDAwMDAwMDA6IG5vbi1yZXZl cnRpdmUgYmVoYXZpb3IgbW9kaWZpY2F0aW9uDQoNCg0KDQogICAgICAweDIwMDAwMDAwOiBzdXBw b3J0IG9mIE1TLVcgY29tbWFuZA0KDQoNCg0KICAgICAgMHgxMDAwMDAwMDogc3VwcG9ydCBvZiBw cm90ZWN0aW9uIGFnYWluc3QgU0QNCg0KDQoNCiAgICAgIDB4MDgwMDAwMDA6IHN1cHBvcnQgb2Yg RVhFUiBjb21tYW5kDQoNCg0KDQogICBJZiBhbGwgdGhlIGZpdmUgY2FwYWJpbGl0aWVzIHNob3Vs ZCBiZSB1c2VkLCBhbiBMRVIgU0hBTEwgc2V0DQoNCiAgIDB4RjgwMDAwMDAgaW4gdGhlIEZsYWdz IGZpZWxkLg0KDQoNCg0KOS4xLjEuICBTZW5kaW5nIGFuZCByZWNlaXZpbmcgdGhlIENhcGFiaWxp dGllcyBUTFYNCg0KDQoNCiAgICBBIG5vZGUgTVVTVCBpbmNsdWRlIGl0cyBDYXBhYmlsaXRpZXMg VExWIGluIGV2ZXJ5IFBTQyBtZXNzYWdlIHRoYXQNCg0KaXQgc2VuZHMuIFRoZSB0cmFuc21pc3Np b24gYW5kIGFjY2VwdGFuY2Ugb2YgdGhlIFBTQyBtZXNzYWdlIGlzDQoNCmRlc2NyaWJlZCBpbiBT ZWN0aW9uIDQuMSBvZiBSRkMgNjM3OC4NCg0KDQoNCiAgIFdoZW4gYSBub2RlIHJlY2VpdmVzIGEg Q2FwYWJpbGl0aWVzIFRMViBpdCBNVVNUIGNvbXBhcmUgaXQgdG8gaXRzDQoNCiAgIG1vc3QgcmVj ZW50IHRyYW5zbWl0dGVkIENhcGFiaWxpdGllcyBUTFYuICBJZiB0aGUgdHdvIGFyZSBlcXVhbCwg dGhlDQoNCiAgIHByb3RlY3RlZCBkb21haW4gaXMgc2FpZCB0byBiZSBydW5uaW5nIGluIHRoZSBt b2RlIGluZGljYXRlZCBieSB0aGF0DQoNCiAgIHNldCBvZiBjYXBhYmlsaXRpZXMgKHNlZSBTZWN0 aW9uIDkuMikuICBJZiB0aGUgc2VudCBhbmQgcmVjZWl2ZWQNCg0KICAgQ2FwYWJpbGl0aWVzIFRM VnMgYXJlIG5vdCBlcXVhbCwgdGhpcyBpbmRpY2F0ZXMgYSBjYXBhYmlsaXRpZXMNCg0KICAgbWlz bWF0Y2guIFdoZW4gdGhpcyBoYXBwZW5zLCB0aGUgbm9kZSBNVVNUIGFsZXJ0IHRoZSBvcGVyYXRv ciBhbmQNCg0KICAgTVVTVCBOT1QgcGVyZm9ybSBhbnkgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdW50 aWwgdGhlIG9wZXJhdG9yIHJlc29sdmVzDQoNCnRoZSBtaXNtYXRjaCBpbiB0aGUgQ2FwYWJpbGl0 aWVzIFRMVi4NCg0KDQoNCjkuMi4gIE1vZGVzDQoNCg0KDQogICBBIE1vZGUgaXMgYSBnaXZlbiBz ZXQgb2YgQ2FwYWJpbGl0aWVzLiAgTW9kZXMgYXJlIHNob3J0aGFuZDsNCg0KICAgcmVmZXJyaW5n IHRvIGEgc2V0IG9mIGNhcGFiaWxpdGllcyBieSB0aGVpciBpbmRpdmlkdWFsIHZhbHVlcyBvciBi eQ0KDQogICB0aGUgbmFtZSBvZiB0aGVpciBtb2RlIGRvZXMgbm90IGNoYW5nZSB0aGUgcHJvdG9j b2wgYmVoYXZpb3IuICBUaGlzDQoNCiAgIGRvY3VtZW50IGRlZmluZXMgdHdvIG1vZGVzIC0gUFND IGFuZCBBUFMuDQoNCg0KDQo5LjIuMS4gIFBTQyBNb2RlDQoNCg0KDQogICBQU0MgTW9kZSBpcyBk ZWZpbmVkIGFzIHRoZSBsYWNrIG9mIGFueSBDYXBhYmlsaXRpZXMgLSB0aGF0IGlzLCBhDQoNCiAg IENhcGFiaWxpdGllcyBzZXQgb2YgMHgwLiAgSXQgaXMgdGhlIGJlaGF2aW9yIHNwZWNpZmllZCBp biBSRkMgNjM3OC4NCg0KDQoNClRoZXJlIGFyZSB0d28gd2F5cyB0byBkZWNsYXJlIFBTQyBNb2Rl LiAgQSBub2RlIGNhbiBzZW5kIGENCg0KICAgQ2FwYWJpbGl0aWVzIFRMViB3aXRoIEZsYWdzIHZh bHVlIHNldCB0byAweDAsIG9yIGl0IGNhbiBzZW5kIG5vDQoNCiAgIENhcGFiaWxpdGllcyBUTFYg YXQgYWxsLiBJbiBvcmRlciB0byBhbGxvdyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQoNCiBiZXR3 ZWVuIHR3byBub2RlcyAtIG9uZSB3aGljaCBjYW4gc2VuZCB0aGUgQ2FwYWJpbGl0aWVzIFRMViwg YW5kIG9uZQ0KDQogd2hpY2ggY2Fubm90LCBhIG5vZGUgd2hpY2ggaGFzIHRoZSBhYmlsaXR5IHRv IHNlbmQgYW5kIHJlY2VpdmUNCg0KICAgdGhlIFBTQyBNb2RlIENhcGFiaWxpdGllcyBUTFYgTVVT VCBiZSBhYmxlIHRvIGJvdGggc2VuZCB0aGUgUFNDIE1vZGUNCg0KICAgQ2FwYWJpbGl0aWVzIFRM ViBhbmQgc2VuZCBubyBDYXBhYmlsaXRpZXMgVExWIGF0IGFsbC4gIEFuDQoNCmltcGxlbWVudGF0 aW9uIE1VU1QgYmUgY29uZmlndXJhYmxlIGJldHdlZW4gdGhlc2UgdHdvIGNob2ljZXMuDQoNCg0K DQoNCg0KOS4yLjIuICBBUFMgTW9kZQ0KDQoNCg0KICAgQVBTIE1vZGUgaXMgZGVmaW5lZCBhcyB0 aGUgdXNlIG9mIGFsbCB0aGUgZml2ZSBzcGVjaWZpYyBjYXBhYmlsaXRpZXMsDQoNCiAgIHdoaWNo IGFyZSBkZXNjcmliZWQgZnJvbSBTZWN0aW9uIDQgdG8gU2VjdGlvbiA4IGluIHRoaXMgZG9jdW1l bnQuDQoNCiAgIEFQUyBNb2RlIGlzIGluZGljYXRlZCB3aXRoIHRoZSBGbGFncyB2YWx1ZSBvZiAw eEY4MDAwMDAwLg0KDQoNCg0KPT09IEVORCBvZiBTZWN0aW9uIDkgPT09DQpCZXN0IHJlZ2FyZHMs DQoNCkplb25nLWRvbmcNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tIDogIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KU2VudCA6IDIwMTQt MDEtMjYgMjE6MTM6NTkgKCArMDk6MDAgKQ0KVG8gOiBSeW9vLCBKZW9uZy1kb25nIDxyeW9vQGV0 cmkucmUua3I+LCAnTG9hIEFuZGVyc3NvbicgPGxvYUBwaS5udT4sIG1wbHNAaWV0Zi5vcmcgPG1w bHNAaWV0Zi5vcmc+DQpDYyA6IG1wbHMtYWRzQHRvb2xzLmlldGYub3JnIDxtcGxzLWFkc0B0b29s cy5pZXRmLm9yZz4sIG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIDxtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIDxk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZz4NClN1YmplY3QgOiBSRTog W21wbHNdIEFEIHJldmlldyA6IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGRyYWZ0LWlldGYtbXBs cy10cC1wc2MtaXR1LTAxDQoNCkhpIEplb25nLWRvbmcsDQoNCj4gSW4gbXkgb3BpbmlvbiwgYWxs IHRoZSB3b3JkaW5nIGZyb20gQUQgcmV2aWV3IHNob3VsZCBiZSB0YWtlbiBleGNlcHQgdGhlDQo+ IGZvbGxvd2luZ3MgdGhhdCBJIHdvdWxkIG5lZWQgZnVydGhlciBjbGFyaWZpY2F0aW9ucyBvciBj b25maXJtYXRpb25zIGZyb20gQUQ6DQo+IC0tLQ0KPiBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9u DQo+IER1ZSB0byB0aGUgbGltaXRhdGlvbiBpbiB0aGUgbGVuZ3RoIG9mIEFic3RyYWN0IGFuZCB0 aGUgbmF0dXJlIG9mIHRoZSBhYnN0cmFjdCwNCj4gd2hpY2ggZ2l2ZXMgdGhlIG1haW4gcG9pbnRz IG9mICp0aGlzKiBkb2N1bWVudCwgSSB3b3VsZCBsaWtlIHRvIHNlZSBpZiB3ZSBjYW4NCj4gYWRk IHRoZSBzZW50ZW5jZSBpbiB0aGUgSW50cm9kdWN0aW9uIHNlY3Rpb24gb25seS4NCg0KWWVzLiBH b29kIHBvaW50Lg0KDQo+IFNlY3Rpb24gNC4xDQo+IFRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIFNl Y3Rpb24gNC4xIGlzIHRvIGVtcGhhc2lzIHRoZSBpbXBvcnRhbmNlIG9mIHRoZQ0KPiBQU0MgY29t bXVuaWNhdGlvbiBjaGFubmVsIGluIGRlbGl2ZXJpbmcgdGhlIGV4dGVybmFsIHN3aXRjaCBjb21t YW5kLA0KPiBzbyB0aGF0IHRoZSBmYWlsdXJlIG9mIFBTQyBjb21tdW5pY2F0aW9uIGNoYW5uZWwg aGFzIGhpZ2hlciBwcmlvcml0eSB0aGFuIEZTLg0KPiBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0 byBjaGFuZ2UgdGhlIHBhcmFncmFwaCBhcyBmb2xsb3dzOg0KPiA9PT0gT0xEID09PQ0KPiBBY2Nv cmRpbmcgdG8gU2VjdGlvbiAyLjQgb2YgUkZDIDU2NTQgW1JGQzU2NTRdIGl0IE1VU1QgYmUgcG9z c2libGUgdG8NCj4gb3BlcmF0ZSBhbiBNUExTLVRQIG5ldHdvcmsgd2l0aG91dCB1c2luZyBhIGNv bnRyb2wgcGxhbmUuIFRoaXMgbWVhbnMNCj4gdGhhdCBleHRlcm5hbCBzd2l0Y2ggY29tbWFuZHMs IGUuZy4sIEZTLCBjYW4gYmUgdHJhbnNmZXJyZWQgdG8gdGhlDQo+IHJlbW90ZSBMYWJlbCBFZGdl IFJvdXRlciAoTEVSKSBvbmx5IGJ5IHVzaW5nIHRoZSBQU0MgY29tbXVuaWNhdGlvbg0KPiBjaGFu bmVsIGFuZCBzaG91bGQgbm90IHJlbHkgb24gdGhlIHByZXNlbmNlIG9mIGEgY29udHJvbCBwbGFu ZS4NCj4gPT09IE5FVyA9PT0NCj4gQWNjb3JkaW5nIHRvIFNlY3Rpb24gMi40IG9mIFJGQyA1NjU0 IFtSRkM1NjU0XSBpdCBNVVNUIGJlIHBvc3NpYmxlIHRvDQo+IG9wZXJhdGUgYW4gTVBMUy1UUCBu ZXR3b3JrIHdpdGhvdXQgdXNpbmcgYSBjb250cm9sIHBsYW5lLiBUaGlzIG1lYW5zDQo+IHRoYXQg dGhlIFBTQyBjb21tdW5pY2F0aW9uIGNoYW5uZWwgaXMgdmVyeSBpbXBvcnRhbnQgZm9yIHRoZSB0 cmFuc2Zlcg0KPiBvZiBleHRlcm5hbCBzd2l0Y2ggY29tbWFuZHMgKGUuZy4sIEZTKSwgYW5kIHRo ZXNlIGNvbW1hbmRzIHNob3VsZCBub3QNCj4gcmVseSBvbiB0aGUgcHJlc2VuY2Ugb2YgYSBjb250 cm9sIHBsYW5lLiBJbiBjb25zZXF1ZW5jZSwgdGhlIGZhaWx1cmUNCj4gb2YgdGhlIFBTQyBjb21t dW5pY2F0aW9uIGNoYW5uZWwgaGFzIGhpZ2hlciBwcmlvcml0eSB0aGFuIEZTLg0KDQpZZXMuIFRo YW5rcy4gSSBoYWQgY29tcGxldGVseSBtaXNzZWQgdGhpcyBwb2ludC4NCllvdXIgbmV3IHdvcmRp bmcgaXMgaGVscGZ1bC4NCg0KPiBTZWN0aW9uIDQuMw0KPiBZb3Ugc3VnZ2VzdGVkIOKAnHMvYnJv a2VuLCB0aGUgRnJlZXplIGNvbW1hbmQsL2Jyb2tlbi4NCj4gVGhlIEZyZWV6ZSBjb21tYW5kLC/i gJ0uDQo+IEJ1dCwgbXkgcmVhZGluZyBvZiB0d28gc2VwYXJhdGUgc2VudGVuY2VzIGlzIG5vdCBv ay4gVGhlDQo+IGZpcnN0IHNlbnRlbmNlIGRvZXNu4oCZdCBzZWVtIHRvIGJlIGNvbXBsZXRlLiBX b3VsZCB5b3UNCj4gcGxlYXNlIGNoZWNrIHRoaXMgYWdhaW4/DQoNCllvdSdyZSByaWdodC4gTXkg bWlzdGFrZS4NCkxlYXZlIGl0IGFzIGl0IGlzLg0KDQo+IFNlY3Rpb25zIDkuMS4xLCBTZWN0aW9u IDkuMS4yLCBTZWN0aW9uIDkuMS4zLjIgYW5kIFNlY3Rpb24gOS4xLjMuMw0KPiBGb3IgdGhvc2Ug Zm91ciBjb21tZW50cyBvbiBTZWN0aW9uIDksIEkgY2FuIHVuZGVyc3RhbmQgdGhlDQo+IGNvbmNl cm5zLiBJbiBteSBvcGluaW9uLCB0aGUgcXVlc3Rpb25zIGdpdmVuIGluIHRoZSBBRCByZXZpZXcN Cj4gY29tbWVudHMgYXJlIHZlcnkgdmFsaWQgYW5kIHNob3VsZCBiZSBhbnN3ZXJlZC4gSSB0aGlu ayB0aGUNCj4gdGV4dCBuZWVkcyB0byBiZSBjaGFuZ2VkIHJhdGhlciBzaWduaWZpY2FudGx5LiBJ IHdpbGwgcHJlcGFyZSBhDQo+IG5ldyB0ZXh0IHByb3Bvc2FsIGFuZCBmdXJ0aGVyIGNvbW11bmlj YXRlIHdpdGggQWRyaWFuLg0KDQpPSy4gSSdsbCBsb29rIGZvciB0aGF0Lg0KDQpNYW55IHRoYW5r cyBmb3IgdGhlIHF1aWNrIHR1cm4gYXJvdW5kIGFuZCB0aGUgY29uc3RydWN0aXZlIGFwcHJvYWNo Lg0KDQpSZWdhcmRzLA0KQWRyaWFuDQoNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B619DSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5IaSwgPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+QXMgaW5kaWNhdGVkIGluIHRoZSBwcmV2aW91cyBlbWFpbCwgSSBjb21tdW5pY2F0ZWQgd2l0 aCBBZHJpYW4gdG8gcmVzb2x2ZSBoaXMgY29tbWVudHMgb24gU2VjdGlvbiA5LjwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPlRoZSBuZXcgdGV4dCBwcm9wb3NhbCBmb3IgU2Vj dGlvbiA5IGlzIGJlbG93LCBhbmQgQWRyaWFuIGNvbmZpcm1lZCB0aGF0IHRoaXMgbmV3IHRleHQg d291bGQgYWRkcmVzcyBoaXMgY29uY2VybnMgb24gdGhhdCBzZWN0aW9uLiZuYnNwOzwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQiPj09PSBCRUdJTiBvZiBTZWN0aW9uIDkgPT09PC9kaXY+DQo8cCBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+OS48c3BhbiBz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOw0KPC9zcGFuPkNhcGFiaWxpdGllcyBhbmQg bW9kZXMNCjw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0gInVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz4NCjxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsg TUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9 IkVOLVVTIj48Zm9udCBzaXplPSIzIj45LjEuPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsNCjwvc3Bhbj5DYXBhYmlsaXRpZXM8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7 IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5n PSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsmbmJzcDsNCjwvc3Bhbj5BIENhcGFiaWxpdHkgaXMgYW4gaW5kaXZpZHVhbCBiZWhhdmlv ciB3aG9zZSB1c2UgaXMgc2lnbmFsZWQgaW4gYTxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3Jzsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj5DYXBhYmls aXRpZXMgVExWLCB3aGljaCBpcyBwbGFjZWQgaW4gT3B0aW9uYWwgVExWcyBmaWVsZCBpbnNpZGUg dGhlPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08i IGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPlBTQyBtZXNzYWdlIHNob3duIGluIEZpZ3VyZSAyIG9m IFJGQyA2Mzc4IFtSRkM2Mzc4XS48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw Ow0KPC9zcGFuPlRoZSBmb3JtYXQgb2Y8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+dGhlIENhcGFiaWxp dGllcyBUTFYgaXM6PG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20g MHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNp emU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+MDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzwvc3Bhbj4xPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4y PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjM8bzpwPjwvbzpwPjwvZm9udD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0 IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVy IE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9 IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86 cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsg TUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9 IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOyZuYnNwOw0KPC9zcGFuPnw8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L3NwYW4+VHlwZSA9IENhcGFiaWxpdGllczxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+fDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj5MZW5ndGg8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPnw8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDs8L3NwYW4+JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20g MHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNp emU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+fDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj5WYWx1ZSA9IEZsYWdzPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj58PG86cD48L286cD48 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAw Y20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48 Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNw Ow0KPC9zcGFuPiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBw dCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBL TyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+RmlndXJlIDE6IEZvcm1hdCBvZiBDYXBhYmlsaXRpZXMgVExWPG86cD48L286cD48 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAw Y20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+VGhlIHZhbHVlIG9mIHRoZSBUeXBl IGZpZWxkIGlzIFRCRCBwZW5kaW5nIElBTkEgYWxsb2NhdGlvbi48bzpwPjwvbzpwPjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20g MHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj5UaGUgdmFsdWUgb2YgdGhlIExlbmd0aCBmaWVs ZCBpcyB0aGUgbGVuZ3RoIG9mIHRoZSBGbGFncyBmaWVsZCBpbjxvOnA+PC9vOnA+PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6 ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bh bj5vY3RldHMuPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPlRo ZSBsZW5ndGggb2YgdGhlIEZsYWdzIGZpZWxkIE1VU1QgYmUgYSBtdWx0aXBsZSBvZiA0IG9jdGV0 czxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBs YW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj5hbmQgTVVTVCBiZSB0aGUgbWluaW11bSByZXF1aXJlZCB0 byBzaWduYWwgYWxsIHRoZSByZXF1aXJlZDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj5jYXBhYmlsaXRp ZXMuPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9w Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+U2VjdGlv biA0IHRvIFNlY3Rpb24gOCBkaXNjdXNzIGZpdmUgY2FwYWJpbGl0aWVzIHRoYXQgYXJlIHNpZ25h bGVkPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08i IGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPnVzaW5nIHRoZSBmaXZlIG1vc3Qgc2lnbmlmaWNhbnQg Yml0czsgaWYgYSBub2RlIHdpc2hlcyB0byBzaWduYWw8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMi PjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+dGhl c2UgZml2ZSBjYXBhYmlsaXRpZXMsIGl0IE1VU1Qgc2VuZCBhIEZsYWdzIGZpZWxkIG9mIDQgb2N0 ZXRzLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7DQo8L3NwYW4+QTxvOnA+ PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJF Ti1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsmbmJzcDsNCjwvc3Bhbj5ub2RlIHdvdWxkIHNlbmQgYSBGbGFncyBmaWVsZCBncmVhdGVyIHRo YW4gNCBvY3RldHMgb25seSBpZiBpdCBoYWQ8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFu IHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+bW9yZSB0aGFu IDMyIENhcGFiaWxpdGllcyB0byBpbmRpY2F0ZS48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyA8L3NwYW4+DQpBbGwgdW51c2VkIGJpdHMgTVVTVCBiZSBzZXQ8bzpwPjwvbzpw PjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46 IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMi Pjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+dG8gemVyby48bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjog MGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+ PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJz cDsNCjwvc3Bhbj5JZiB0aGUgYml0IGFzc2lnbmVkIGZvciBhbiBpbmRpdmlkdWFsIGNhcGFiaWxp dHkgaXMgc2V0IHRvIDEsIGl0PG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0i bXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPmluZGljYXRlcyB0aGUgc2Vu ZGluZyBub2RlJ3MgaW50ZW50IHRvIHVzZSB0aGF0IGNhcGFiaWxpdHkgaW4gdGhlPG86cD48L286 cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lO OiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVT Ij48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu YnNwOw0KPC9zcGFuPnByb3RlY3RlZCBkb21haW4uPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsgPC9zcGFuPklmIGEgYml0IGlzIHNldCB0byAwLCB0aGUgc2VuZGluZyBub2Rl IGRvZXMgbm90PG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFn ZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPmludGVuZCB0byB1c2UgdGhlIGluZGljYXRl ZCBjYXBhYmlsaXR5IGluIHRoZSBwcm90ZWN0ZWQgZG9tYWluLjxzcGFuIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7DQo8L3NwYW4+Tm90ZTxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+ PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj50aGF0 IGl0IGlzIG5vdCBwb3NzaWJsZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSBpbnRlbnQgbm90 IHRvIHVzZTxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj5hIGNhcGFiaWxpdHkgYW5kIGEgbm9kZSdzIGNv bXBsZXRlIG5vbi1zdXBwb3J0IChpLmUuLCBsYWNrIG9mPG86cD48L286cD48L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO ZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIz Ij48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPmlt cGxlbWVudGF0aW9uKSBvZiBhIGdpdmVuIGNhcGFiaWxpdHkuPG86cD48L286cD48L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBw dCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBL TyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+VGhpcyBkb2N1bWVudCBkZWZpbmVzIGZpdmUgc3Bl Y2lmaWMgY2FwYWJpbGl0aWVzIHRoYXQgYXJlIGRlc2NyaWJlZDxvOnA+PC9vOnA+PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6 ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bh bj5mcm9tIFNlY3Rpb24gNCB0byBTZWN0aW9uIDguPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsgPC9zcGFuPkVhY2ggY2FwYWJpbGl0eSBpcyBhc3NpZ25lZCBiaXQgYXM8bzpw PjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBN QVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0i RU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+Zm9sbG93czo8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJF Ti1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4weDgwMDAwMDAwOiBwcmlvcml0eSBt b2RpZmljYXRpb248bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6 ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj4weDQwMDAwMDAwOiBub24tcmV2ZXJ0aXZlIGJlaGF2aW9yIG1v ZGlmaWNhdGlvbjxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1I RUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBw dCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXpl PSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjB4MjAwMDAwMDA6IHN1cHBvcnQgb2YgTVMtVyBjb21tYW5kPG86 cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsg TUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+MHgxMDAwMDAwMDogc3VwcG9ydCBvZiBwcm90ZWN0aW9uIGFnYWluc3QgU0Q8bzpwPjwv bzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJH SU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj4weDA4MDAwMDAwOiBzdXBwb3J0IG9mIEVYRVIgY29tbWFuZDxvOnA+PC9vOnA+PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQiIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPklmIGFsbCB0aGUgZml2ZSBjYXBhYmlsaXRpZXMg c2hvdWxkIGJlIHVzZWQsIGFuIExFUiBTSEFMTCBzZXQ8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMi PjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+MHhG ODAwMDAwMCBpbiB0aGUgRmxhZ3MgZmllbGQuPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBN QVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0i RU4tVVMiPjxmb250IHNpemU9IjMiPjkuMS4xLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7DQo8L3NwYW4+U2VuZGluZyBhbmQgcmVjZWl2aW5nIHRoZSBDYXBhYmlsaXRpZXMg VExWPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9w Pg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L3NwYW4+QSBub2RlIE1VU1QgaW5jbHVk ZSBpdHMgQ2FwYWJpbGl0aWVzIFRMViBpbiBldmVyeSBQU0MgbWVzc2FnZSB0aGF0DQo8bzpwPjwv bzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBURVhU LUlOREVOVDogMjFwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLWNoYXItaW5kZW50LWNvdW50 OiAyLjAiIGNsYXNzPSJNc29QbGFpblRleHQiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn Q291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9u dCBzaXplPSIzIj5pdCBzZW5kcy4gVGhlIHRyYW5zbWlzc2lvbiBhbmQgYWNjZXB0YW5jZSBvZiB0 aGUgUFNDIG1lc3NhZ2UgaXM8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdDsgVEVYVC1JTkRFTlQ6IDIxcHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1jaGFy LWluZGVudC1jb3VudDogMi4wIiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4NCjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5n PSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+ZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xIG9mIFJGQyA2 Mzc4Lg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFy ZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPldoZW4gYSBub2RlIHJl Y2VpdmVzIGEgQ2FwYWJpbGl0aWVzIFRMViBpdCBNVVNUIGNvbXBhcmUgaXQgdG8gaXRzPG86cD48 L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFS R0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVO LVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyZuYnNwOw0KPC9zcGFuPm1vc3QgcmVjZW50IHRyYW5zbWl0dGVkIENhcGFiaWxpdGllcyBUTFYu PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsNCjwvc3Bhbj5JZiB0aGUgdHdv IGFyZSBlcXVhbCwgdGhlPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1s YW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPnByb3RlY3RlZCBkb21haW4gaXMg c2FpZCB0byBiZSBydW5uaW5nIGluIHRoZSBtb2RlIGluZGljYXRlZCBieSB0aGF0PG86cD48L286 cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lO OiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVT Ij48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu YnNwOw0KPC9zcGFuPnNldCBvZiBjYXBhYmlsaXRpZXMgKHNlZSBTZWN0aW9uIDkuMikuPHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPg0KSWYgdGhlIHNlbnQgYW5k IHJlY2VpdmVkPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFn ZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPkNhcGFiaWxpdGllcyBUTFZzIGFyZSBub3Qg ZXF1YWwsIHRoaXMgaW5kaWNhdGVzIGEgY2FwYWJpbGl0aWVzPG86cD48L286cD48L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBw dCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXpl PSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFu Pm1pc21hdGNoLiBXaGVuIHRoaXMgaGFwcGVucywgdGhlIG5vZGUgTVVTVCBhbGVydCB0aGUgb3Bl cmF0b3IgYW5kPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5ndWFn ZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOw0KPC9zcGFuPk1VU1QgTk9UIHBlcmZvcm0gYW55IHByb3RlY3Rpb24gc3dpdGNoaW5nIHVu dGlsIHRoZSBvcGVyYXRvciByZXNvbHZlcyA8bzpwPg0KPC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IFRFWFQtSU5ERU5UOiAxNS43NXB0OyBNQVJH SU46IDBjbSAwY20gMHB0OyBtc28tY2hhci1pbmRlbnQtY291bnQ6IDEuNSIgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPnRoZSBtaXNt YXRjaCBpbiB0aGUgQ2FwYWJpbGl0aWVzIFRMVi48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBj bSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxm b250IHNpemU9IjMiPjkuMi48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOw0K PC9zcGFuPk1vZGVzPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20g MHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNp emU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+QSBNb2RlIGlzIGEgZ2l2ZW4gc2V0IG9mIENhcGFiaWxpdGllcy48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+DQpNb2RlcyBhcmUgc2hvcnRoYW5kOzxvOnA+ PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJF Ti1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsmbmJzcDsNCjwvc3Bhbj5yZWZlcnJpbmcgdG8gYSBzZXQgb2YgY2FwYWJpbGl0aWVzIGJ5IHRo ZWlyIGluZGl2aWR1YWwgdmFsdWVzIG9yIGJ5PG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3Bh biBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPnRoZSBuYW1l IG9mIHRoZWlyIG1vZGUgZG9lcyBub3QgY2hhbmdlIHRoZSBwcm90b2NvbCBiZWhhdmlvci48c3Bh biBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOw0KPC9zcGFuPlRoaXM8bzpwPjwvbzpw PjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46 IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMi Pjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+ZG9jdW1lbnQgZGVmaW5lcyB0d28gbW9kZXMgLSBQU0MgYW5kIEFQUy48bzpw PjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBN QVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+OS4yLjEuPHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsNCjwvc3Bhbj5QU0MgTW9kZTxvOnA+ PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1B UkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFy ZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPlBTQyBNb2RlIGlzIGRl ZmluZWQgYXMgdGhlIGxhY2sgb2YgYW55IENhcGFiaWxpdGllcyAtIHRoYXQgaXMsIGE8bzpwPjwv bzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJH SU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4t VVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+Q2FwYWJpbGl0aWVzIHNldCBvZiAweDAuPHNwYW4gc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPkl0IGlzIHRoZSBiZWhhdmlvciBzcGVjaWZpZWQg aW4gUkZDIDYzNzguPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9mb250Pjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IFRFWFQtSU5ERU5UOiAyMXB0OyBN QVJHSU46IDBjbSAwY20gMHB0OyBtc28tY2hhci1pbmRlbnQtY291bnQ6IDIuMCIgY2xhc3M9Ik1z b1BsYWluVGV4dCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPlRoZXJl IGFyZSB0d28gd2F5cyB0byBkZWNsYXJlIFBTQyBNb2RlLjxzcGFuIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7DQo8L3NwYW4+QSBub2RlIGNhbiBzZW5kIGE8bzpwPjwvbzpwPjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAw Y20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250 IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+Q2FwYWJpbGl0aWVzIFRMViB3aXRoIEZsYWdzIHZhbHVlIHNldCB0byAweDAsIG9yIGl0 IGNhbiBzZW5kIG5vPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOw0KPC9zcGFuPkNhcGFiaWxpdGllcyBUTFYgYXQgYWxsLiBJbiBvcmRlciB0byBhbGxv dyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5PG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgVEVYVC1JTkRFTlQ6IDEwLjVwdDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgbXNvLWNoYXItaW5kZW50LWNvdW50OiAxLjAiIGNsYXNzPSJNc29QbGFpblRl eHQiPg0KPHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48c3BhbiBzdHlsZT0i bXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvc3Bhbj5iZXR3ZWVuIHR3byBub2RlcyAtIG9uZSB3 aGljaCBjYW4gc2VuZCB0aGUgQ2FwYWJpbGl0aWVzIFRMViwgYW5kIG9uZTxvOnA+PC9vOnA+PC9m b250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IFRFWFQtSU5ERU5U OiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1jaGFyLWluZGVudC1jb3VudDogMS4w IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4NCjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6 ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L3NwYW4+d2hpY2gg Y2Fubm90LCBhIG5vZGUgd2hpY2ggaGFzIHRoZSBhYmlsaXR5IHRvIHNlbmQgYW5kIHJlY2VpdmU8 bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyIgbGFu Zz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L3Nw YW4+dGhlIFBTQyBNb2RlIENhcGFiaWxpdGllcyBUTFYgTVVTVCBiZSBhYmxlIHRvIGJvdGggc2Vu ZCB0aGUgUFNDIE1vZGU8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+Q2FwYWJpbGl0aWVzIFRMViBhbmQg c2VuZCBubyBDYXBhYmlsaXRpZXMgVExWIGF0IGFsbC48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOw0KPC9zcGFuPkFuIDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IFRFWFQtSU5ERU5UOiAxNS43NXB0OyBNQVJHSU46 IDBjbSAwY20gMHB0OyBtc28tY2hhci1pbmRlbnQtY291bnQ6IDEuNSIgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBLTyIgbGFuZz0iRU4tVVMiPjxmb250IHNpemU9IjMiPmltcGxlbWVudGF0 aW9uIE1VU1QgYmUgY29uZmlndXJhYmxlIGJldHdlZW4gdGhlc2UgdHdvIGNob2ljZXMuPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBj bSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQg c2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwv c3Bhbj48bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+ OS4yLjIuPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsNCjwvc3Bhbj5BUFMg TW9kZTxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwv cD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcn OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPkFQUyBN b2RlIGlzIGRlZmluZWQgYXMgdGhlIHVzZSBvZiBhbGwgdGhlIGZpdmUgc3BlY2lmaWMgY2FwYWJp bGl0aWVzLDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj53aGljaCBhcmUgZGVzY3JpYmVkIGZyb20gU2Vj dGlvbiA0IHRvIFNlY3Rpb24gOCBpbiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIiBsYW5nPSJFTi1VUyI+PGZvbnQgc2l6 ZT0iMyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bh bj5BUFMgTW9kZSBpcyBpbmRpY2F0ZWQgd2l0aCB0aGUgRmxhZ3MgdmFsdWUgb2YgMHhGODAwMDAw MC48bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0OyBNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PT09IEVORCBvZiBTZWN0aW9uIDkgPT09 PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+QmVzdCByZWdhcmRz LDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij48YnI+DQombmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZxdW90O0FkcmlhbiBGYXJyZWwmcXVv dDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDE0LTAx LTI2IDIxOjEzOjU5ICggJiM0MzswOTowMCApPGJyPg0KPGI+VG8gOiA8L2I+UnlvbywgSmVvbmct ZG9uZyAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0OywgJ0xvYSBBbmRlcnNzb24nICZsdDtsb2FAcGku bnUmZ3Q7LCBtcGxzQGlldGYub3JnICZsdDttcGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjIDog PC9iPm1wbHMtYWRzQHRvb2xzLmlldGYub3JnICZsdDttcGxzLWFkc0B0b29scy5pZXRmLm9yZyZn dDssIG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnICZsdDttcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZyZndDssIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnICZsdDtk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0IDogPC9iPlJFOiBbbXBsc10gQUQgcmV2aWV3IDogd29ya2luZyBncm91cCBsYXN0IGNhbGwg ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDE8YnI+DQo8YnI+DQpIaSBKZW9uZy1kb25nLDxi cj4NCjxicj4NCiZndDsgSW4gbXkgb3BpbmlvbiwgYWxsIHRoZSB3b3JkaW5nIGZyb20gQUQgcmV2 aWV3IHNob3VsZCBiZSB0YWtlbiBleGNlcHQgdGhlPGJyPg0KJmd0OyBmb2xsb3dpbmdzIHRoYXQg SSB3b3VsZCBuZWVkIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbnMgb3IgY29uZmlybWF0aW9ucyBmcm9t IEFEOjxicj4NCiZndDsgLS0tPGJyPg0KJmd0OyBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uPGJy Pg0KJmd0OyBEdWUgdG8gdGhlIGxpbWl0YXRpb24gaW4gdGhlIGxlbmd0aCBvZiBBYnN0cmFjdCBh bmQgdGhlIG5hdHVyZSBvZiB0aGUgYWJzdHJhY3QsPGJyPg0KJmd0OyB3aGljaCBnaXZlcyB0aGUg bWFpbiBwb2ludHMgb2YgKnRoaXMqIGRvY3VtZW50LCBJIHdvdWxkIGxpa2UgdG8gc2VlIGlmIHdl IGNhbjxicj4NCiZndDsgYWRkIHRoZSBzZW50ZW5jZSBpbiB0aGUgSW50cm9kdWN0aW9uIHNlY3Rp b24gb25seS4gPGJyPg0KPGJyPg0KWWVzLiBHb29kIHBvaW50Ljxicj4NCjxicj4NCiZndDsgU2Vj dGlvbiA0LjE8YnI+DQomZ3Q7IFRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIFNlY3Rpb24gNC4xIGlz IHRvIGVtcGhhc2lzIHRoZSBpbXBvcnRhbmNlIG9mIHRoZTxicj4NCiZndDsgUFNDIGNvbW11bmlj YXRpb24gY2hhbm5lbCBpbiBkZWxpdmVyaW5nIHRoZSBleHRlcm5hbCBzd2l0Y2ggY29tbWFuZCwg PGJyPg0KJmd0OyBzbyB0aGF0IHRoZSBmYWlsdXJlIG9mIFBTQyBjb21tdW5pY2F0aW9uIGNoYW5u ZWwgaGFzIGhpZ2hlciBwcmlvcml0eSB0aGFuIEZTLiA8YnI+DQomZ3Q7IEkgd291bGQgbGlrZSB0 byBwcm9wb3NlIHRvIGNoYW5nZSB0aGUgcGFyYWdyYXBoIGFzIGZvbGxvd3M6PGJyPg0KJmd0OyA9 PT0gT0xEID09PTxicj4NCiZndDsgQWNjb3JkaW5nIHRvIFNlY3Rpb24gMi40IG9mIFJGQyA1NjU0 IFtSRkM1NjU0XSBpdCBNVVNUIGJlIHBvc3NpYmxlIHRvPGJyPg0KJmd0OyBvcGVyYXRlIGFuIE1Q TFMtVFAgbmV0d29yayB3aXRob3V0IHVzaW5nIGEgY29udHJvbCBwbGFuZS4gVGhpcyBtZWFucyA8 YnI+DQomZ3Q7IHRoYXQgZXh0ZXJuYWwgc3dpdGNoIGNvbW1hbmRzLCBlLmcuLCBGUywgY2FuIGJl IHRyYW5zZmVycmVkIHRvIHRoZTxicj4NCiZndDsgcmVtb3RlIExhYmVsIEVkZ2UgUm91dGVyIChM RVIpIG9ubHkgYnkgdXNpbmcgdGhlIFBTQyBjb21tdW5pY2F0aW9uPGJyPg0KJmd0OyBjaGFubmVs IGFuZCBzaG91bGQgbm90IHJlbHkgb24gdGhlIHByZXNlbmNlIG9mIGEgY29udHJvbCBwbGFuZS48 YnI+DQomZ3Q7ID09PSBORVcgPT09PGJyPg0KJmd0OyBBY2NvcmRpbmcgdG8gU2VjdGlvbiAyLjQg b2YgUkZDIDU2NTQgW1JGQzU2NTRdIGl0IE1VU1QgYmUgcG9zc2libGUgdG88YnI+DQomZ3Q7IG9w ZXJhdGUgYW4gTVBMUy1UUCBuZXR3b3JrIHdpdGhvdXQgdXNpbmcgYSBjb250cm9sIHBsYW5lLiBU aGlzIG1lYW5zPGJyPg0KJmd0OyB0aGF0IHRoZSBQU0MgY29tbXVuaWNhdGlvbiBjaGFubmVsIGlz IHZlcnkgaW1wb3J0YW50IGZvciB0aGUgdHJhbnNmZXI8YnI+DQomZ3Q7IG9mIGV4dGVybmFsIHN3 aXRjaCBjb21tYW5kcyAoZS5nLiwgRlMpLCBhbmQgdGhlc2UgY29tbWFuZHMgc2hvdWxkIG5vdDxi cj4NCiZndDsgcmVseSBvbiB0aGUgcHJlc2VuY2Ugb2YgYSBjb250cm9sIHBsYW5lLiBJbiBjb25z ZXF1ZW5jZSwgdGhlIGZhaWx1cmU8YnI+DQomZ3Q7IG9mIHRoZSBQU0MgY29tbXVuaWNhdGlvbiBj aGFubmVsIGhhcyBoaWdoZXIgcHJpb3JpdHkgdGhhbiBGUy48YnI+DQo8YnI+DQpZZXMuIFRoYW5r cy4gSSBoYWQgY29tcGxldGVseSBtaXNzZWQgdGhpcyBwb2ludC48YnI+DQpZb3VyIG5ldyB3b3Jk aW5nIGlzIGhlbHBmdWwuPGJyPg0KPGJyPg0KJmd0OyBTZWN0aW9uIDQuMzxicj4NCiZndDsgWW91 IHN1Z2dlc3RlZCDigJxzL2Jyb2tlbiwgdGhlIEZyZWV6ZSBjb21tYW5kLC9icm9rZW4uIDxicj4N CiZndDsgVGhlIEZyZWV6ZSBjb21tYW5kLC/igJ0uIDxicj4NCiZndDsgQnV0LCBteSByZWFkaW5n IG9mIHR3byBzZXBhcmF0ZSBzZW50ZW5jZXMgaXMgbm90IG9rLiBUaGU8YnI+DQomZ3Q7IGZpcnN0 IHNlbnRlbmNlIGRvZXNu4oCZdCBzZWVtIHRvIGJlIGNvbXBsZXRlLiBXb3VsZCB5b3UgPGJyPg0K Jmd0OyBwbGVhc2UgY2hlY2sgdGhpcyBhZ2Fpbj8gPGJyPg0KPGJyPg0KWW91J3JlIHJpZ2h0LiBN eSBtaXN0YWtlLjxicj4NCkxlYXZlIGl0IGFzIGl0IGlzLjxicj4NCjxicj4NCiZndDsgU2VjdGlv bnMgOS4xLjEsIFNlY3Rpb24gOS4xLjIsIFNlY3Rpb24gOS4xLjMuMiBhbmQgU2VjdGlvbiA5LjEu My4zPGJyPg0KJmd0OyBGb3IgdGhvc2UgZm91ciBjb21tZW50cyBvbiBTZWN0aW9uIDksIEkgY2Fu IHVuZGVyc3RhbmQgdGhlIDxicj4NCiZndDsgY29uY2VybnMuIEluIG15IG9waW5pb24sIHRoZSBx dWVzdGlvbnMgZ2l2ZW4gaW4gdGhlIEFEIHJldmlldzxicj4NCiZndDsgY29tbWVudHMgYXJlIHZl cnkgdmFsaWQgYW5kIHNob3VsZCBiZSBhbnN3ZXJlZC4gSSB0aGluayB0aGU8YnI+DQomZ3Q7IHRl eHQgbmVlZHMgdG8gYmUgY2hhbmdlZCByYXRoZXIgc2lnbmlmaWNhbnRseS4gSSB3aWxsIHByZXBh cmUgYSA8YnI+DQomZ3Q7IG5ldyB0ZXh0IHByb3Bvc2FsIGFuZCBmdXJ0aGVyIGNvbW11bmljYXRl IHdpdGggQWRyaWFuLiA8YnI+DQo8YnI+DQpPSy4gSSdsbCBsb29rIGZvciB0aGF0Ljxicj4NCjxi cj4NCk1hbnkgdGhhbmtzIGZvciB0aGUgcXVpY2sgdHVybiBhcm91bmQgYW5kIHRoZSBjb25zdHJ1 Y3RpdmUgYXBwcm9hY2guPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpBZHJpYW48YnI+DQo8YnI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B619DSMTP2etriinfo_-- From andy.da.green@bt.com Wed Feb 5 09:36: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 5F5191A01CC for ; Wed, 5 Feb 2014 09:36:38 -0800 (PST) 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 AHdIUsiXaKIb for ; Wed, 5 Feb 2014 09:36:36 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id CBF9A1A010D for ; Wed, 5 Feb 2014 09:36:35 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 5 Feb 2014 17:36:43 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.37]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 5 Feb 2014 17:36:33 +0000 From: To: , , , , Date: Wed, 5 Feb 2014 17:36:32 +0000 Thread-Topic: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQHPIjut270tDLb2ukyCu7UnvpR9bpqm7OSQ Message-ID: <464C9090B4F1624C9174D50D456B13EF5DEE5BF546@EMV65-UKRD.domain1.systemhost.net> References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Feb 2014 09:38:33 -0800 Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 17:36:38 -0000 I support this draft. Please adopt. Regards Andy -----Original Message----- From: loa@pi.nu [mailto:loa@pi.nu]=20 Sent: 05 February 2014 06:29 To: mpls@ietf.org; mpls-chairs@tools.ietf.org; martin.vigoureux@alcatel-luc= ent.com; draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org Subject: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-enco= ding Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-in-ba= nd-wildcard-encoding as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. Please note that we have identified an overlap between this document and dr= aft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this document = unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp to cover this. There are no IPR claims against this document. The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends February 19, 2014. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From kkoushik@cisco.com Wed Feb 5 10:39:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5924B1A01CF for ; Wed, 5 Feb 2014 10:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 sFM1Mme0-FLe for ; Wed, 5 Feb 2014 10:39:53 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BC5E91A0192 for ; Wed, 5 Feb 2014 10:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8500; q=dns/txt; s=iport; t=1391625592; x=1392835192; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=29vgbD2Zs0m/QvPAA77VZosZlKK5Kae+wXSZp/o1Vik=; b=QlHU52+tQiDeJdAi8AqTPF70p+A79oEderIlhSY02GF2YNNxrZvDVDrZ eP4P6PL9taDtYBz+Y5YAHhPk7J+7HqNiFfcjWAuKurMQMB4lEELbzcYkm I0l0eyZLLH89wc4zMCZXtSnaq0wJTUtfUsHDDiWCozt2L1Ongi2C09LoT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAFKE8lKtJXG9/2dsb2JhbABZgww4vyOBEBZ0giUBAQEDAQEBARpOAwsFBwICCxEDAQEBKAcbDB8JCAYTh30IDc54EwQEjg8RASQbDQQGAQaDHoEUBIVZg3COYpIhg0wdgTU X-IronPort-AV: E=Sophos;i="4.95,788,1384300800"; d="scan'208,217";a="302171760" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 05 Feb 2014 18:39:51 +0000 Received: from rcdn-kkoushik-8812.cisco.com (rcdn-kkoushik-8812.cisco.com [10.99.130.227]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s15IdpQY028407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 18:39:51 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_631191C0-07DA-4AFD-9F21-85E5CE756B27" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Agrahara Kiran Koushik In-Reply-To: <8D4AD29E-0FCF-4C36-9298-C04B4F687FC2@cisco.com> Date: Wed, 5 Feb 2014 12:39:51 -0600 Message-Id: References: <8D4AD29E-0FCF-4C36-9298-C04B4F687FC2@cisco.com> To: "loa@pi.nu" X-Mailer: Apple Mail (2.1508) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Feb 2014 18:39:55 -0000 --Apple-Mail=_631191C0-07DA-4AFD-9F21-85E5CE756B27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I'd like to change my decision to "Support" based on Cisco-wide = consensus to=20 support read-only MIBs in the future. Thanks Kiran On Feb 4, 2014, at 10:23 AM, Agrahara Kiran Koushik = wrote: > Hi >=20 > Oppose. >=20 > At present all the TP MIB implementations within Cisco are read-only. = But we need the MIBs to be read-write/create > to handle future requirements. >=20 > Thanks > Kiran >=20 >=20 >>> ---------- Forwarded message ---------- >>> From: Muly Ilan >>> Date: Tuesday, February 4, 2014 >>> Subject: seeking consensus on making draft-ietf-mpls-tp-te-mib = read-only >>> To: Loa Andersson , "mpls@ietf.org" >>> Cc: "mpls-chairs@tools.ietf.org" , = "draft-ietf-mpls-tp-te-mib@tools.ietf.org" = >>>=20 >>>=20 >>> Oppose. >>>=20 >>> In our implementation we need read-write/read-create access for the = TE and LSR extensions. >>>=20 >>> Specifically, the new functionality provided by mplsIdGlobalId, = mplsIdNodeId and mplsTunnelExtNodeConfigTable can only be realized by = read-write/read-create objects. >>>=20 >>> Regards, >>>=20 >>> Muly Ilan >>>=20 >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >>> Sent: Tuesday, February 04, 2014 8:55 AM >>> To: mpls@ietf.org >>> Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-tp-te-mib@tools.ietf.org >>> Subject: [mpls] seeking consensus on making = draft-ietf-mpls-tp-te-mib read-only >>>=20 >>> Working Group, >>>=20 >>> We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the = working group for more work. We have a series of comments that are = mostly for clarification. However the main reason for recalling the = document is that there is one point where we need to confirm working = group consensus. >>>=20 >>> The IETF, the working group and the MIB Doctors are today very = reluctant to produce read-write MIB modules. The current draft is = read-write for a few objects, this is based on a consensus call for an = earlier discussion, however the consensus call was not clear. It can be = taken to mean both that we want to go with read-write objects and that = we want to see read-only. Is it clear that it has been interpreted = differently by different individuals. >>>=20 >>> The authors and chairs have discussed the issue and we have a rough = consensus that we want the MIB module(s) to be read-only. >>>=20 >>> We therefore are asking the working group if this is OK for the MIB >>> module(s) in the current document. Please indicate Support or Oppose = for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only. >>>=20 >>> Please send your comments to the working group mailing list before = February 18, 2014. >>>=20 >>> Loa >>> for the MPLS wg chairs >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_631191C0-07DA-4AFD-9F21-85E5CE756B27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I'd = like to change my decision to "Support" based on Cisco-wide consensus = to 
support read-only MIBs in the = future.

Thanks
Kiran

On Feb 4, 2014, at 10:23 AM, Agrahara Kiran Koushik <kkoushik@cisco.com> = wrote:

---------- Forwarded message ----------
From: Muly Ilan <muly_i@rad.com>
Date: Tuesday, February 4, 2014
Subject: seeking consensus on making = draft-ietf-mpls-tp-te-mib read-only
To: Loa Andersson = <loa@pi.nu>, "mpls@ietf.org" = <mpls@ietf.org>
Cc: "mpls-chairs@tools.ietf.org" = <mpls-chairs@tools.ietf.org>, = "draft-ietf-mpls-tp-te-mib@tools.ietf.org" = <draft-ietf-mpls-tp-te-mib@tools.ietf.org>


Oppose.

In our implementation we need read-write/read-create access for the TE = and LSR extensions.

Specifically, the new functionality provided by mplsIdGlobalId, = mplsIdNodeId and mplsTunnelExtNodeConfigTable can only be realized by = read-write/read-create objects.

Regards,

Muly Ilan

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa = Andersson
Sent: Tuesday, February 04, 2014 8:55 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-tp-te-mib@tools.ietf.org
Subject: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib = read-only

Working Group,

We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the = working group for more work. We have a series of comments that are = mostly for clarification. However the main reason for recalling the = document is that there is one point where we need to confirm working = group consensus.

The IETF, the working group and the MIB Doctors are today very reluctant = to produce read-write MIB modules. The current draft is read-write for a = few objects, this is based on a consensus call for an earlier = discussion, however the consensus call was not clear. It can be taken to = mean both that we want to go with read-write objects and that we want to = see read-only. Is it clear that it has been interpreted differently by = different individuals.

The authors and chairs have discussed the issue and we have a rough = consensus that we want the MIB module(s) to be read-only.

We therefore are asking the working group if this is OK for the MIB
module(s) in the current document. Please indicate Support or Oppose for = this MIB (draft-ietf-mpls-tp-te-mib) to be read-only.

Please send your comments to the working group mailing list before = February 18, 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
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls




=


= --Apple-Mail=_631191C0-07DA-4AFD-9F21-85E5CE756B27-- From arkadiy.gulko@thomsonreuters.com Wed Feb 5 12:39: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 9C4EC1A01D1 for ; Wed, 5 Feb 2014 12:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.435 X-Spam-Level: X-Spam-Status: No, score=-7.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puyIRmdz002d for ; Wed, 5 Feb 2014 12:39:42 -0800 (PST) Received: from mailout1-trm.thomsonreuters.com (mailout1-trm.thomsonreuters.com [159.220.28.56]) by ietfa.amsl.com (Postfix) with ESMTP id D9DEF1A01CC for ; Wed, 5 Feb 2014 12:39:40 -0800 (PST) Received: from ocdp-erfsmlr01.erf.thomson.com ([10.31.3.8]) by mailout1-trm.thomsonreuters.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s15KdWc2024731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 20:39:32 GMT Received: from EAGH-ERFPHUB05.ERF.thomson.com ([163.231.29.164]) by ocdp-erfsmlr01.erf.thomson.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s15KdTEd021918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 20:39:31 GMT Received: from C597JHEEHUB03.ERF.thomson.com (163.231.29.203) by EAGH-ERFPHUB05.ERF.thomson.com (163.231.29.164) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 14:39:29 -0600 Received: from C111NTDEMBX52.ERF.thomson.com ([fe80::258d:aef3:9aa7:4f92]) by C597JHEEHUB03.ERF.thomson.com ([fe80::21ac:e4a1:cd8a:978d%15]) with mapi id 14.03.0158.001; Wed, 5 Feb 2014 14:39:29 -0600 From: To: , , , , Thread-Topic: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQHPIjut270tDLb2ukyCu7UnvpR9bpqnHgDA Date: Wed, 5 Feb 2014 20:39:28 +0000 Message-ID: <4A496052E7B7E84A9324854763C616FA07308820@C111NTDEMBX52.ERF.thomson.com> References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.30.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:39:43 -0000 I support (as co-author).=20 Regards, Arkadiy -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Wednesday, February 05, 2014 1:29 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); = draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org Subject: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-enco= ding Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-in-ba= nd-wildcard-encoding as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. Please note that we have identified an overlap between this document and dr= aft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this document = unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp to cover this. There are no IPR claims against this document. The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends February 19, 2014. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From gregory.mirsky@ericsson.com Wed Feb 5 13:46: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 56EFE1A0101 for ; Wed, 5 Feb 2014 13:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vinsZe_yzHGL for ; Wed, 5 Feb 2014 13:46:17 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 44E7A1A0100 for ; Wed, 5 Feb 2014 13:46:17 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-cf-52f2b1286ceb Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 01.FF.11484.821B2F25; Wed, 5 Feb 2014 22:46:16 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 16:46:14 -0500 From: Gregory Mirsky To: "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: Comments to draft-chen-mpls-p2mp-egress-protection-10 Thread-Index: Ac8it3gag8BDTdsTQrCmaY8m+AociA== Date: Wed, 5 Feb 2014 21:46:14 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B75EC6Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyuXRPuK7Gxk9BBpeeyFv0zt7OaHFr6UpW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStj4vNGtoJPshU7OqYyNTD+keli5OSQEDCR 6N73mwXCFpO4cG89WxcjF4eQwBFGievnp7JCOMsYJZ4s/scMUsUmYCTxYmMPO0hCRGAGo8SX +fPBEsICdhIPdl1kBLFFBJwlJp8+wAZh60ksW/AOKM7BwSKgIvH7vSKIySvgK3H8OdhiRqDF 30+tYQKxmQXEJW49mc8EcZCAxJI955khbFGJl4//sULYShKTlp5jhajPl2i+tBFsDq+AoMTJ mU9YJjAKzUIyahaSsllIymYBXcEsoCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzFylBan luWmGxluYgTGwjEJNscdjAs+WR5ilOZgURLn/fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QD42bOuX1CH39venp28rdz9ovSJCf1yx6yuKFsKWDH1L2H4Zrefp8Z15aaybinxAc/Pnr/ X5Mew7R9jcxH2desDGFcJq963HvLkVurDf5PCtnYKn7OeAmfcW3h9P27Ja9zhRQvX5KnO7Up e27JzCvulqrvOr+pWJ7Nem000f9wZNwFtrIHTMb7W5VYijMSDbWYi4oTAVhuZHxTAgAA Subject: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Feb 2014 21:46:19 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B75EC6Feusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBdXRob3JzLCBldC4gYWwsDQpwbGVhc2UgZmluZCBteSBjb21tZW50cyB0byB0aGUgbGF0 ZXN0IHZlcnNpb24gYmVsb3c6DQrigKIgICAgICAgSW50cm9kdWN0aW9uLiAiIFRoZSBtYWluIGRp c2FkdmFudGFnZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgbW9yZSBuZXR3b3JrIHJlc291cmNl cyBzdWNoIGFzIGRvdWJsZSBiYW5kd2lkdGhzIG1heSBiZSB1c2VkLiIgSSBiZWxpZXZlIHRoYXQg Y2FuIGJlIGVhc2lseSBhdm9pZGVkIGlmIFNoYXJlZCBleHBsaWNpdCBmaWx0ZXJzcGVjIHVzZWQg c2lnbmFsaW5nIHdvcmtpbmcgYW5kIHByb3RlY3RpbmcgTFNQcyBzbyB0aGF0IGJvdGggY291bGQg c2hhcmUgQlcgcmVzb3VyY2VzIG9mIGNvbW1vbiBsaW5rcy4gSWYgdGhhdCBpcyB0aGUgbWFpbiBt b3RpdmF0aW9uIGZvciB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9ucywgSSBkb24ndCBzZWUgaXQgYXMg c3VmZmljaWVudGx5IHN0cm9uZyBjYXNlLg0K4oCiICAgICAgIFNlY3Rpb24gMS4xIOKAnFRoZSBm YWlsdXJlIG9mIGEgcHJpbWFyeSBlZ3Jlc3MgKGUuZy4sIEwxIGluIHRoZSBmaWd1cmUpIE1BWSBi ZSBkZXRlY3RlZCBieSBpdHMgdXBzdHJlYW0gbm9kZSAoZS5nLiwgUjMgaW4gdGhlIGZpZ3VyZSkg dGhyb3VnaCBhIEJGRCBzZXNzaW9uIGJldHdlZW4gdGhlIHVwc3RyZWFtIG5vZGUgYW5kIHRoZSBl Z3Jlc3MgaW4gTVBMUyBuZXR3b3Jrcy7igJ0gSWYgbW9uaXRvcmVkIHBhdGggaXMgbGltaXRlZCB0 byBzZWdtZW50IGJldHdlZW4gUjMgYW5kIEwxLCB0aGVuIGZhaWx1cmUgb2YgTDEgdG8gZm9yd2Fy ZCB0cmFmZmljIHRvIENFMSBvciBDRTEgdG8gcmVjZWl2ZSBmcm9tIEwxIHdvdWxkIG5vdCBiZSBk ZXRlY3RlZC4gSXMgc3VjaCBsaW1pdGVkIHNjb3BlIHJlYWxseSB1c2VmdWw/DQoNCiAgIFJlZ2Fy ZHMsDQogICAgICAgIEdyZWcNCg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B75EC6Feusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+RGVhciBBdXRob3JzLCBldC4gYWwsPC9kaXY+DQo8 ZGl2PnBsZWFzZSBmaW5kIG15IGNvbW1lbnRzIHRvIHRoZSBsYXRlc3QgdmVyc2lvbiBiZWxvdzo8 L2Rpdj4NCjx1bCBzdHlsZT0ibWFyZ2luOjA7cGFkZGluZy1sZWZ0OjU0cHQ7Ij4NCjxsaT5JbnRy b2R1Y3Rpb24uICZxdW90OyBUaGUgbWFpbiBkaXNhZHZhbnRhZ2Ugb2YgdGhpcyBhcHByb2FjaCBp cyB0aGF0IG1vcmUgbmV0d29yayByZXNvdXJjZXMgc3VjaCBhcyBkb3VibGUgYmFuZHdpZHRocyBt YXkgYmUgdXNlZC4mcXVvdDsgSSBiZWxpZXZlIHRoYXQgY2FuIGJlIGVhc2lseSBhdm9pZGVkIGlm IFNoYXJlZCBleHBsaWNpdCBmaWx0ZXJzcGVjIHVzZWQgc2lnbmFsaW5nIHdvcmtpbmcgYW5kIHBy b3RlY3RpbmcgTFNQcyBzbyB0aGF0IGJvdGggY291bGQNCnNoYXJlIEJXIHJlc291cmNlcyBvZiBj b21tb24gbGlua3MuIElmIHRoYXQgaXMgdGhlIG1haW4gbW90aXZhdGlvbiBmb3IgdGhlIHByb3Bv c2VkIGV4dGVuc2lvbnMsIEkgZG9uJ3Qgc2VlIGl0IGFzIHN1ZmZpY2llbnRseSBzdHJvbmcgY2Fz ZS48L2xpPjxsaT5TZWN0aW9uIDEuMSDigJxUaGUgZmFpbHVyZSBvZiBhIHByaW1hcnkgZWdyZXNz IChlLmcuLCBMMSBpbiB0aGUgZmlndXJlKSBNQVkgYmUgZGV0ZWN0ZWQgYnkgaXRzIHVwc3RyZWFt IG5vZGUgKGUuZy4sIFIzIGluIHRoZSBmaWd1cmUpIHRocm91Z2ggYSBCRkQgc2Vzc2lvbiBiZXR3 ZWVuIHRoZSB1cHN0cmVhbSBub2RlIGFuZCB0aGUgZWdyZXNzIGluIE1QTFMgbmV0d29ya3Mu4oCd IElmIG1vbml0b3JlZCBwYXRoIGlzIGxpbWl0ZWQgdG8gc2VnbWVudA0KYmV0d2VlbiBSMyBhbmQg TDEsIHRoZW4gZmFpbHVyZSBvZiBMMSB0byBmb3J3YXJkIHRyYWZmaWMgdG8gQ0UxIG9yIENFMSB0 byByZWNlaXZlIGZyb20gTDEgd291bGQgbm90IGJlIGRldGVjdGVkLiBJcyBzdWNoIGxpbWl0ZWQg c2NvcGUgcmVhbGx5IHVzZWZ1bD88L2xpPjwvdWw+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6 MThwdDsiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjE4cHQ7Ij5SZWdh cmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjE4cHQ7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF1121B75EC6Feusaamb103erics_-- From gregory.mirsky@ericsson.com Wed Feb 5 14:21:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408021A012F for ; Wed, 5 Feb 2014 14:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mbGCM17U1YH3 for ; Wed, 5 Feb 2014 14:20:56 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 37FE61A0224 for ; Wed, 5 Feb 2014 14:20:56 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-de-52f2b946c962 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F9.81.11484.649B2F25; Wed, 5 Feb 2014 23:20:55 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 17:20:53 -0500 From: Gregory Mirsky To: "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: Comments to draft-chen-mpls-p2mp-egress-protection-10 Thread-Index: Ac8it3gag8BDTdsTQrCmaY8m+AociAABwxoA Date: Wed, 5 Feb 2014 22:20:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B75ED12@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B75ED12eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPrK77zk9BBp0fBSx6Z29ntLi1dCWr A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVxe84/loKm+orZZw+zNzCeqe5i5OCQEDCR 2HHJuouRE8gUk7hwbz1bFyMXh5DAEUaJj93rmSGcZYwS13tmMoNUsQkYSbzY2MMOkhARmMEo 8WX+fLCEsICTRO+EuewgtoiAs8Tk0wfYIGwjiW/fvzGB2CwCKhJL9n1lA9nMK+ArcfVCBEhY CMic+2w9K4jNKeAn8ex3G9gYRqCLvp9aA9bKLCAucevJfCaISwUkluw5zwxhi0q8fPyPFcJW kpi09BwrRH2+xKeJc1hAbF4BQYmTM5+wTGAUmYVk1CwkZbOQlM0Cuo5ZQFNi/S59iBJFiSnd D9khbA2J1jlz2ZHFFzCyr2LkKC1OLctNNzLcxAiMnWMSbI47GBd8sjzEKM3BoiTO++Wtc5CQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGxqb7hrznOXbarXx87Y1eyYMll/v7ZzFsDPh8kfvg dZdoT9HEMJETrz4w7bvzqFzf+Ezbs+R45dAThj+5fz4VudMn8HXi6m/d7jr27A/uRD86e2hi gscRfyF3d623JS6ik1dPUKjP6k+fv/VWzeUJO/Z/236r+9OF7ksxC5dwPNuWxuMopD/JjkWJ pTgj0VCLuag4EQDB4VaOawIAAA== Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Feb 2014 22:21:00 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B75ED12eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQpJ4oCZZCBsaWtlIHRvIGFkZCB0byBteSBjb21tZW50IG9uIHVzZSBjYXNlIHBy ZXNlbnRlZCBpbiB0aGUgZG9jdW1lbnQuDQpQcm9wb3NhbCBpcyBiYXNlZCBvbiBhc3N1bXB0aW9u IHRoYXQgZGV0ZWN0ZWQgbG9zcyBvZiBjb250aW51aXR5IChMb0MpIGJldHdlZW4gUjMgYW5kIEwx IGlzIGJlY2F1c2Ugb2YgTDEgZmFpbHVyZS4gIEJ1dCB0aGF0IG1heSBiZSBub3QgdGhlIGNhc2Ug YW5kIExvQyBmYXVsdCBtYXkgYmUgYmVjYXVzZSBSMyBvciBwYXRoIHByb2JsZW0sIG9yIHByb2Js ZW0gb2YgcGFydGljdWxhciBwb3J0IG9uIEwxLiBBbGwgdGhhdCBjYW4gY2F1c2UgTG9DIGZhdWx0 IHdoaWxlIEwxIGlzIGZ1bmN0aW9uYWxseSBzb3VuZC4gQW5kIFJGQyA0MDkwIGJhc2VkIEZSUiB3 b3VsZCBoYW5kbGUgdGhlc2UgZmFpbHVyZSBzY2VuYXJpb3MgdGh1cyBtYWtpbmcgbmV3IGV4dGVu c2lvbnMgYW5kIGFkZGl0aW9uYWwgY29tcGxleGl0eSB1bm5lY2Vzc2FyeS4gSSB0aGluayB0aGF0 IGlmIHRoZSBnb2FsIGlzIHByb3RlY3Rpb24gb2YgYW4gZWdyZXNzIG5vZGUsIHRoZW4gdGhlcmUg bXVzdCBiZSBtb3JlIGRldGVybWluaXNtIGluIGRldGVjdGluZyBpdHMgZmFpbHVyZSB0byBzdXBw b3J0IHRoZSB1c2UgY2FzZS4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWdvcnkgTWlyc2t5DQpTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDE6NDYgUE0NClRvOiBkcmFmdC1jaGVuLW1wbHMtcDJtcC1l Z3Jlc3MtcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDog W21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9u LTEwDQoNCkRlYXIgQXV0aG9ycywgZXQuIGFsLA0KcGxlYXNlIGZpbmQgbXkgY29tbWVudHMgdG8g dGhlIGxhdGVzdCB2ZXJzaW9uIGJlbG93Og0KwrcgICAgICAgICBJbnRyb2R1Y3Rpb24uICIgVGhl IG1haW4gZGlzYWR2YW50YWdlIG9mIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCBtb3JlIG5ldHdvcmsg cmVzb3VyY2VzIHN1Y2ggYXMgZG91YmxlIGJhbmR3aWR0aHMgbWF5IGJlIHVzZWQuIiBJIGJlbGll dmUgdGhhdCBjYW4gYmUgZWFzaWx5IGF2b2lkZWQgaWYgU2hhcmVkIGV4cGxpY2l0IGZpbHRlcnNw ZWMgdXNlZCBzaWduYWxpbmcgd29ya2luZyBhbmQgcHJvdGVjdGluZyBMU1BzIHNvIHRoYXQgYm90 aCBjb3VsZCBzaGFyZSBCVyByZXNvdXJjZXMgb2YgY29tbW9uIGxpbmtzLiBJZiB0aGF0IGlzIHRo ZSBtYWluIG1vdGl2YXRpb24gZm9yIHRoZSBwcm9wb3NlZCBleHRlbnNpb25zLCBJIGRvbid0IHNl ZSBpdCBhcyBzdWZmaWNpZW50bHkgc3Ryb25nIGNhc2UuDQrCtyAgICAgICAgIFNlY3Rpb24gMS4x IOKAnFRoZSBmYWlsdXJlIG9mIGEgcHJpbWFyeSBlZ3Jlc3MgKGUuZy4sIEwxIGluIHRoZSBmaWd1 cmUpIE1BWSBiZSBkZXRlY3RlZCBieSBpdHMgdXBzdHJlYW0gbm9kZSAoZS5nLiwgUjMgaW4gdGhl IGZpZ3VyZSkgdGhyb3VnaCBhIEJGRCBzZXNzaW9uIGJldHdlZW4gdGhlIHVwc3RyZWFtIG5vZGUg YW5kIHRoZSBlZ3Jlc3MgaW4gTVBMUyBuZXR3b3Jrcy7igJ0gSWYgbW9uaXRvcmVkIHBhdGggaXMg bGltaXRlZCB0byBzZWdtZW50IGJldHdlZW4gUjMgYW5kIEwxLCB0aGVuIGZhaWx1cmUgb2YgTDEg dG8gZm9yd2FyZCB0cmFmZmljIHRvIENFMSBvciBDRTEgdG8gcmVjZWl2ZSBmcm9tIEwxIHdvdWxk IG5vdCBiZSBkZXRlY3RlZC4gSXMgc3VjaCBsaW1pdGVkIHNjb3BlIHJlYWxseSB1c2VmdWw/DQoN ClJlZ2FyZHMsDQogICAgICAgIEdyZWcNCg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B75ED12eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuZW1haWxxdW90ZSwgbGkuZW1haWxxdW90ZSwgZGl2LmVtYWlscXVvdGUNCgl7bXNvLXN0 eWxlLW5hbWU6ZW1haWxxdW90ZTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjEu MHB0Ow0KCWJvcmRlcjpub25lOw0KCXBhZGRpbmc6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTMxOTU4MDYzMDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwODYxNDMwMzQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBBbGwsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPknigJlkIGxpa2UgdG8gYWRkIHRvIG15IGNvbW1lbnQgb24gdXNlIGNh c2UgcHJlc2VudGVkIGluIHRoZSBkb2N1bWVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5Qcm9wb3NhbCBpcyBiYXNlZCBvbiBhc3N1bXB0aW9uIHRoYXQgZGV0ZWN0ZWQgbG9zcyBv ZiBjb250aW51aXR5IChMb0MpIGJldHdlZW4gUjMgYW5kIEwxIGlzIGJlY2F1c2Ugb2YgTDEgZmFp bHVyZS4mbmJzcDsgQnV0IHRoYXQgbWF5IGJlIG5vdCB0aGUgY2FzZSBhbmQgTG9DIGZhdWx0DQog bWF5IGJlIGJlY2F1c2UgUjMgb3IgcGF0aCBwcm9ibGVtLCBvciBwcm9ibGVtIG9mIHBhcnRpY3Vs YXIgcG9ydCBvbiBMMS4gQWxsIHRoYXQgY2FuIGNhdXNlIExvQyBmYXVsdCB3aGlsZSBMMSBpcyBm dW5jdGlvbmFsbHkgc291bmQuIEFuZCBSRkMgNDA5MCBiYXNlZCBGUlIgd291bGQgaGFuZGxlIHRo ZXNlIGZhaWx1cmUgc2NlbmFyaW9zIHRodXMgbWFraW5nIG5ldyBleHRlbnNpb25zIGFuZCBhZGRp dGlvbmFsIGNvbXBsZXhpdHkgdW5uZWNlc3NhcnkuDQogSSB0aGluayB0aGF0IGlmIHRoZSBnb2Fs IGlzIHByb3RlY3Rpb24gb2YgYW4gZWdyZXNzIG5vZGUsIHRoZW4gdGhlcmUgbXVzdCBiZSBtb3Jl IGRldGVybWluaXNtIGluIGRldGVjdGluZyBpdHMgZmFpbHVyZSB0byBzdXBwb3J0IHRoZSB1c2Ug Y2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgRmVicnVhcnkgMDUsIDIwMTQgMTo0NiBQTTxicj4NCjxiPlRvOjwvYj4gZHJhZnQtY2hlbi1t cGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LWNoZW4tbXBscy1w Mm1wLWVncmVzcy1wcm90ZWN0aW9uLTEwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGVhciBB dXRob3JzLCBldC4gYWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5wbGVhc2UgZmlu ZCBteSBjb21tZW50cyB0byB0aGUgbGF0ZXN0IHZlcnNpb24gYmVsb3c6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkludHJvZHVjdGlvbi4gJnF1b3Q7IFRoZSBtYWluIGRp c2FkdmFudGFnZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgbW9yZSBuZXR3b3JrIHJlc291cmNl cyBzdWNoIGFzIGRvdWJsZSBiYW5kd2lkdGhzIG1heSBiZSB1c2VkLiZxdW90OyBJIGJlbGlldmUg dGhhdCBjYW4gYmUgZWFzaWx5IGF2b2lkZWQNCiBpZiBTaGFyZWQgZXhwbGljaXQgZmlsdGVyc3Bl YyB1c2VkIHNpZ25hbGluZyB3b3JraW5nIGFuZCBwcm90ZWN0aW5nIExTUHMgc28gdGhhdCBib3Ro IGNvdWxkIHNoYXJlIEJXIHJlc291cmNlcyBvZiBjb21tb24gbGlua3MuIElmIHRoYXQgaXMgdGhl IG1haW4gbW90aXZhdGlvbiBmb3IgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbnMsIEkgZG9uJ3Qgc2Vl IGl0IGFzIHN1ZmZpY2llbnRseSBzdHJvbmcgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlNlY3Rpb24gMS4xIOKAnFRoZSBmYWlsdXJlIG9mIGEgcHJpbWFyeSBlZ3Jlc3MgKGUu Zy4sIEwxIGluIHRoZSBmaWd1cmUpIE1BWSBiZSBkZXRlY3RlZCBieSBpdHMgdXBzdHJlYW0gbm9k ZSAoZS5nLiwgUjMgaW4gdGhlIGZpZ3VyZSkgdGhyb3VnaCBhIEJGRCBzZXNzaW9uIGJldHdlZW4N CiB0aGUgdXBzdHJlYW0gbm9kZSBhbmQgdGhlIGVncmVzcyBpbiBNUExTIG5ldHdvcmtzLuKAnSBJ ZiBtb25pdG9yZWQgcGF0aCBpcyBsaW1pdGVkIHRvIHNlZ21lbnQgYmV0d2VlbiBSMyBhbmQgTDEs IHRoZW4gZmFpbHVyZSBvZiBMMSB0byBmb3J3YXJkIHRyYWZmaWMgdG8gQ0UxIG9yIENFMSB0byBy ZWNlaXZlIGZyb20gTDEgd291bGQgbm90IGJlIGRldGVjdGVkLiBJcyBzdWNoIGxpbWl0ZWQgc2Nv cGUgcmVhbGx5IHVzZWZ1bD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF1121B75ED12eusaamb103erics_-- From adrian@olddog.co.uk Wed Feb 5 14:33: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 AD9E41A021F for ; Wed, 5 Feb 2014 14:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ5L-Cp3rZdK for ; Wed, 5 Feb 2014 14:33:29 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 226FD1A01FC for ; Wed, 5 Feb 2014 14:33:27 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s15MXCFQ007252; Wed, 5 Feb 2014 22:33:16 GMT Received: from 950129200 (p5798E386.dip0.t-ipconnect.de [87.152.227.134]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s15MX9Om007221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 22:33:09 GMT From: "Adrian Farrel" To: "'Ryoo, Jeong-dong'" , "'Loa Andersson'" , References: <0bc301cf16ea$3981cd00$ac856700$@olddog.co.uk> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846@SMTP2.etri.info>, <009101cf1a90$132a5d30$397f1790$@olddog.co.uk> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B619D@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B619D@SMTP2.etri.info> Date: Wed, 5 Feb 2014 22:33:05 -0000 Message-ID: <09f901cf22c2$3ee10d90$bca328b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09FA_01CF22C2.3EE79D40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDDGELNpZkSuNS/NSgW0Szz71cHAI+7oqoAqXxpGsBbBFWVpoM463Q Content-Language: en-gb Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: Re: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:33:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09FA_01CF22C2.3EE79D40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And, formally, a public Ack from me. =20 Adrian =20 From: Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr]=20 Sent: 05 February 2014 15:50 To: adrian@olddog.co.uk; 'Loa Andersson'; mpls@ietf.org Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; = draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: RE: [mpls] AD review : working group last call = draft-ietf-mpls-tp-psc-itu-01 =20 Hi,=20 =20 As indicated in the previous email, I communicated with Adrian to = resolve his comments on Section 9. The new text proposal for Section 9 is below, and Adrian confirmed that = this new text would address his concerns on that section.=20 =20 =3D=3D=3D BEGIN of Section 9 =3D=3D=3D 9. Capabilities and modes=20 =20 9.1. Capabilities =20 A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of RFC 6378 [RFC6378]. The format of the Capabilities TLV is: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D Capabilities | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value =3D Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 1: Format of Capabilities TLV =20 The value of the Type field is TBD pending IANA allocation. =20 The value of the Length field is the length of the Flags field in octets. The length of the Flags field MUST be a multiple of 4 octets and MUST be the minimum required to signal all the required capabilities. =20 Section 4 to Section 8 discuss five capabilities that are signaled using the five most significant bits; if a node wishes to signal these five capabilities, it MUST send a Flags field of 4 octets. A node would send a Flags field greater than 4 octets only if it had more than 32 Capabilities to indicate. All unused bits MUST be set to zero. =20 If the bit assigned for an individual capability is set to 1, it indicates the sending node's intent to use that capability in the protected domain. If a bit is set to 0, the sending node does not intend to use the indicated capability in the protected domain. Note that it is not possible to distinguish between the intent not to use a capability and a node's complete non-support (i.e., lack of implementation) of a given capability. =20 This document defines five specific capabilities that are described from Section 4 to Section 8. Each capability is assigned bit as follows: =20 0x80000000: priority modification =20 0x40000000: non-revertive behavior modification =20 0x20000000: support of MS-W command =20 0x10000000: support of protection against SD =20 0x08000000: support of EXER command =20 If all the five capabilities should be used, an LER SHALL set 0xF8000000 in the Flags field. =20 9.1.1. Sending and receiving the Capabilities TLV =20 A node MUST include its Capabilities TLV in every PSC message that=20 it sends. The transmission and acceptance of the PSC message is described in Section 4.1 of RFC 6378.=20 =20 When a node receives a Capabilities TLV it MUST compare it to its most recent transmitted Capabilities TLV. If the two are equal, the protected domain is said to be running in the mode indicated by that set of capabilities (see Section 9.2). If the sent and received Capabilities TLVs are not equal, this indicates a capabilities mismatch. When this happens, the node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves = the mismatch in the Capabilities TLV. =20 9.2. Modes =20 A Mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. =20 9.2.1. PSC Mode =20 PSC Mode is defined as the lack of any Capabilities - that is, a Capabilities set of 0x0. It is the behavior specified in RFC 6378. =20 There are two ways to declare PSC Mode. A node can send a Capabilities TLV with Flags value set to 0x0, or it can send no Capabilities TLV at all. In order to allow backward compatibility between two nodes - one which can send the Capabilities TLV, and one which cannot, a node which has the ability to send and receive the PSC Mode Capabilities TLV MUST be able to both send the PSC Mode Capabilities TLV and send no Capabilities TLV at all. An=20 implementation MUST be configurable between these two choices. =20 =20 9.2.2. APS Mode =20 APS Mode is defined as the use of all the five specific capabilities, which are described from Section 4 to Section 8 in this document. APS Mode is indicated with the Flags value of 0xF8000000. =20 =3D=3D=3D END of Section 9 =3D=3D=3D Best regards, =20 Jeong-dong =20 =20 _____ =20 >From : "Adrian Farrel" Sent : 2014-01-26 21:13:59 ( +09:00 ) To : Ryoo, Jeong-dong , 'Loa Andersson' , = mpls@ietf.org Cc : mpls-ads@tools.ietf.org , = mpls-chairs@tools.ietf.org , = draft-ietf-mpls-tp-psc-itu@tools.ietf.org = Subject : RE: [mpls] AD review : working group last call = draft-ietf-mpls-tp-psc-itu-01 Hi Jeong-dong, > In my opinion, all the wording from AD review should be taken except = the > followings that I would need further clarifications or confirmations = from AD: > --- > Abstract and Introduction > Due to the limitation in the length of Abstract and the nature of the = abstract, > which gives the main points of *this* document, I would like to see if = we can > add the sentence in the Introduction section only.=20 Yes. Good point. > Section 4.1 > The second paragraph in Section 4.1 is to emphasis the importance of = the > PSC communication channel in delivering the external switch command,=20 > so that the failure of PSC communication channel has higher priority = than FS.=20 > I would like to propose to change the paragraph as follows: > =3D=3D=3D OLD =3D=3D=3D > According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to > operate an MPLS-TP network without using a control plane. This means=20 > that external switch commands, e.g., FS, can be transferred to the > remote Label Edge Router (LER) only by using the PSC communication > channel and should not rely on the presence of a control plane. > =3D=3D=3D NEW =3D=3D=3D > According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to > operate an MPLS-TP network without using a control plane. This means > that the PSC communication channel is very important for the transfer > of external switch commands (e.g., FS), and these commands should not > rely on the presence of a control plane. In consequence, the failure > of the PSC communication channel has higher priority than FS. Yes. Thanks. I had completely missed this point. Your new wording is helpful. > Section 4.3 > You suggested =E2=80=9Cs/broken, the Freeze command,/broken.=20 > The Freeze command,/=E2=80=9D.=20 > But, my reading of two separate sentences is not ok. The > first sentence doesn=E2=80=99t seem to be complete. Would you=20 > please check this again?=20 You're right. My mistake. Leave it as it is. > Sections 9.1.1, Section 9.1.2, Section 9.1.3.2 and Section 9.1.3.3 > For those four comments on Section 9, I can understand the=20 > concerns. In my opinion, the questions given in the AD review > comments are very valid and should be answered. I think the > text needs to be changed rather significantly. I will prepare a=20 > new text proposal and further communicate with Adrian.=20 OK. I'll look for that. Many thanks for the quick turn around and the constructive approach. Regards, Adrian ------=_NextPart_000_09FA_01CF22C2.3EE79D40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

And, formally, a public Ack = from me.

 

Adrian

 

From: Ryoo, Jeong-dong = [mailto:ryoo@etri.re.kr]
Sent: 05 February 2014 = 15:50
To: adrian@olddog.co.uk; 'Loa Andersson'; = mpls@ietf.org
Cc: mpls-ads@tools.ietf.org; = mpls-chairs@tools.ietf.org; = draft-ietf-mpls-tp-psc-itu@tools.ietf.org
Subject: RE: [mpls] = AD review : working group last call = draft-ietf-mpls-tp-psc-itu-01

 

Hi,

 

As indicated in the previous email, I = communicated with Adrian to resolve his comments on Section = 9.

The new text proposal for Section 9 is = below, and Adrian confirmed that this new text would address his = concerns on that section. 

 

=3D=3D=3D BEGIN of Section 9 = =3D=3D=3D

9.=C2=A0 Capabilities and modes =

 

9.1.=C2=A0 = Capabilities

 

=C2=A0=C2=A0 A Capability is an = individual behavior whose use is signaled in a

=C2=A0=C2=A0 Capabilities TLV, which = is placed in Optional TLVs field inside the

=C2=A0=C2=A0 PSC message shown in = Figure 2 of RFC 6378 [RFC6378].=C2=A0 = The format of

=C2=A0=C2=A0 the Capabilities TLV = is:

 

=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 3

=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

=C2=A0=C2=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

=C2=A0=C2=A0 |=C2=A0 Type =3D Capabilities=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0 = Length=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 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

=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 Value =3D Flags=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 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

=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 = Figure 1: Format of Capabilities TLV

 

=C2=A0=C2=A0 The value of the Type = field is TBD pending IANA allocation.

 

=C2=A0=C2=A0 The value of the Length = field is the length of the Flags field in

=C2=A0=C2=A0 octets.=C2=A0 The length of the Flags field = MUST be a multiple of 4 octets

=C2=A0=C2=A0 and MUST be the minimum = required to signal all the required

=C2=A0=C2=A0 = capabilities.

 

=C2=A0=C2=A0 Section 4 to Section 8 = discuss five capabilities that are signaled

=C2=A0=C2=A0 using the five most = significant bits; if a node wishes to signal

=C2=A0=C2=A0 these five capabilities, = it MUST send a Flags field of 4 octets.=C2=A0 A

=C2=A0=C2=A0 node would send a Flags = field greater than 4 octets only if it had

=C2=A0=C2=A0 more than 32 Capabilities = to indicate.=C2=A0 All unused = bits MUST be set

=C2=A0=C2=A0 to = zero.

 

=C2=A0=C2=A0 If the bit assigned for = an individual capability is set to 1, it

=C2=A0=C2=A0 indicates the sending = node's intent to use that capability in the

=C2=A0=C2=A0 protected domain. =C2=A0If a bit is set to 0, the = sending node does not

=C2=A0=C2=A0 intend to use the = indicated capability in the protected domain.=C2=A0 Note

=C2=A0=C2=A0 that it is not possible = to distinguish between the intent not to use

=C2=A0=C2=A0 a capability and a node's = complete non-support (i.e., lack of

=C2=A0=C2=A0 implementation) of a = given capability.

 

=C2=A0=C2=A0 This document defines = five specific capabilities that are described

=C2=A0=C2=A0 from Section 4 to Section = 8.=C2=A0 Each capability is = assigned bit as

=C2=A0=C2=A0 = follows:

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 0x80000000: priority modification

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 0x40000000: non-revertive behavior = modification

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 0x20000000: support of MS-W command

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 0x10000000: support of protection against = SD

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 0x08000000: support of EXER command

 

=C2=A0=C2=A0 If all the five = capabilities should be used, an LER SHALL set

=C2=A0=C2=A0 0xF8000000 in the Flags = field.

 

9.1.1.=C2=A0 Sending and receiving the = Capabilities TLV

 

=C2=A0=C2=A0=C2=A0 A node MUST include = its Capabilities TLV in every PSC message that

it sends. = The transmission and acceptance of the PSC message is

described = in Section 4.1 of RFC 6378.

 

=C2=A0=C2=A0 When a node receives a = Capabilities TLV it MUST compare it to its

=C2=A0=C2=A0 most recent transmitted = Capabilities TLV.=C2=A0 If the = two are equal, the

=C2=A0=C2=A0 protected domain is said = to be running in the mode indicated by that

=C2=A0=C2=A0 set of capabilities (see = Section 9.2).=C2=A0 If the sent = and received

=C2=A0=C2=A0 Capabilities TLVs are not = equal, this indicates a capabilities

=C2=A0=C2=A0 mismatch. When this = happens, the node MUST alert the operator and

=C2=A0=C2=A0 MUST NOT perform any = protection switching until the operator resolves =

the = mismatch in the Capabilities TLV.

 

9.2.=C2=A0 Modes

 

=C2=A0=C2=A0 A Mode is a given set of = Capabilities.=C2=A0 Modes are = shorthand;

=C2=A0=C2=A0 referring to a set of = capabilities by their individual values or by

=C2=A0=C2=A0 the name of their mode = does not change the protocol behavior.=C2=A0 This

=C2=A0=C2=A0 document defines two = modes - PSC and APS.

 

9.2.1.=C2=A0 PSC = Mode

 

=C2=A0=C2=A0 PSC Mode is defined as = the lack of any Capabilities - that is, a

=C2=A0=C2=A0 Capabilities set of 0x0. = =C2=A0It is the behavior = specified in RFC 6378.

=C2=A0=C2=A0

There are = two ways to declare PSC Mode.=C2=A0 = A node can send a

=C2=A0=C2=A0 Capabilities TLV with = Flags value set to 0x0, or it can send no

=C2=A0=C2=A0 Capabilities TLV at all. = In order to allow backward compatibility

between = two nodes - one which can send the Capabilities TLV, and = one

which = cannot, a node which has the ability to send and = receive

=C2=A0=C2=A0 the PSC Mode Capabilities = TLV MUST be able to both send the PSC Mode

=C2=A0=C2=A0 Capabilities TLV and send = no Capabilities TLV at all.=C2=A0 = An

implementat= ion MUST be configurable between these two choices.

=C2=A0=C2=A0

 

9.2.2.=C2=A0 APS = Mode

 

=C2=A0=C2=A0 APS Mode is defined as = the use of all the five specific capabilities,

=C2=A0=C2=A0 which are described from = Section 4 to Section 8 in this document.

=C2=A0=C2=A0 APS Mode is indicated = with the Flags value of 0xF8000000.

 

=3D=3D=3D END of Section 9 = =3D=3D=3D

Best = regards,

 

Jeong-dong


 

 

From : "Adrian Farrel" = <adrian@olddog.co.uk>
Sent : 2014-01-26 21:13:59 ( = +09:00 )
To : Ryoo, Jeong-dong <ryoo@etri.re.kr>, 'Loa = Andersson' <loa@pi.nu>, mpls@ietf.org = <mpls@ietf.org>
Cc : mpls-ads@tools.ietf.org = <mpls-ads@tools.ietf.org>, mpls-chairs@tools.ietf.org = <mpls-chairs@tools.ietf.org>, = draft-ietf-mpls-tp-psc-itu@tools.ietf.org = <draft-ietf-mpls-tp-psc-itu@tools.ietf.org>
Subject : = RE: [mpls] AD review : working group last call = draft-ietf-mpls-tp-psc-itu-01

Hi Jeong-dong,

> In my = opinion, all the wording from AD review should be taken except = the
> followings that I would need further clarifications or = confirmations from AD:
> ---
> Abstract and = Introduction
> Due to the limitation in the length of Abstract and = the nature of the abstract,
> which gives the main points of = *this* document, I would like to see if we can
> add the sentence = in the Introduction section only.

Yes. Good point.

> = Section 4.1
> The second paragraph in Section 4.1 is to emphasis = the importance of the
> PSC communication channel in delivering = the external switch command,
> so that the failure of PSC = communication channel has higher priority than FS.
> I would like = to propose to change the paragraph as follows:
> =3D=3D=3D OLD = =3D=3D=3D
> According to Section 2.4 of RFC 5654 [RFC5654] it MUST = be possible to
> operate an MPLS-TP network without using a = control plane. This means
> that external switch commands, e.g., = FS, can be transferred to the
> remote Label Edge Router (LER) = only by using the PSC communication
> channel and should not rely = on the presence of a control plane.
> =3D=3D=3D NEW = =3D=3D=3D
> According to Section 2.4 of RFC 5654 [RFC5654] it MUST = be possible to
> operate an MPLS-TP network without using a = control plane. This means
> that the PSC communication channel is = very important for the transfer
> of external switch commands = (e.g., FS), and these commands should not
> rely on the presence = of a control plane. In consequence, the failure
> of the PSC = communication channel has higher priority than FS.

Yes. Thanks. I = had completely missed this point.
Your new wording is = helpful.

> Section 4.3
> You suggested = =E2=80=9Cs/broken, the Freeze command,/broken.
> The Freeze = command,/=E2=80=9D.
> But, my reading of two separate sentences = is not ok. The
> first sentence doesn=E2=80=99t seem to be = complete. Would you
> please check this again?

You're = right. My mistake.
Leave it as it is.

> Sections 9.1.1, = Section 9.1.2, Section 9.1.3.2 and Section 9.1.3.3
> For those = four comments on Section 9, I can understand the
> concerns. In = my opinion, the questions given in the AD review
> comments are = very valid and should be answered. I think the
> text needs to be = changed rather significantly. I will prepare a
> new text = proposal and further communicate with Adrian.

OK. I'll look for = that.

Many thanks for the quick turn around and the constructive = approach.

Regards,
Adrian

------=_NextPart_000_09FA_01CF22C2.3EE79D40-- From internet-drafts@ietf.org Wed Feb 5 14:56:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBA81A021A; Wed, 5 Feb 2014 14:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFMBlBm5w3ko; Wed, 5 Feb 2014 14:56:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C491A016B; Wed, 5 Feb 2014 14:56:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140205225626.29660.79485.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2014 14:56:26 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-12.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, 05 Feb 2014 22:56:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Updates to LDP for IPv6 Authors : Rajiv Asati Vishwas Manral Rajiv Papneja Carlos Pignataro Filename : draft-ietf-mpls-ldp-ipv6-12.txt Pages : 19 Date : 2014-02-05 Abstract: The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-ipv6-12 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 rajiva@cisco.com Wed Feb 5 15:04: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 978A31A0276; Wed, 5 Feb 2014 15:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 VUpWoMMk6wdj; Wed, 5 Feb 2014 15:04:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 95D9F1A0292; Wed, 5 Feb 2014 15:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2395; q=dns/txt; s=iport; t=1391641488; x=1392851088; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kl7Noqr0NxoqcZu1nE8+JHuxVhHGDxlxqIZyjmzgE/U=; b=CFhEJWAhwU640G5K1Av23ekgPfjNDbuZR9jiHNE4dAkqVN/bsMQToeej RJuQFzu9DicYr6fDVWkDJRld7l131DWPdHI2cFrqYJ7DrCJnwBQsAHZBR FnY6IJj1WKEAr63vchdNgzaKjJ8QKcWw+s387aNbOktbUuy2Se8vEXgHQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucFAGnD8lKtJV2a/2dsb2JhbABZgww4UQa+XYEKFnSCJQEBAQQBAQE3NAsMBgEIEQMBAh83Cx0IAgQBDQUJh3wIBc5pF451BwaEMgSYK4EykG+DLYIq X-IronPort-AV: E=Sophos;i="4.95,789,1384300800"; d="scan'208";a="301977746" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 05 Feb 2014 23:04:29 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s15N4T5j016889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 23:04:29 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.70]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 17:04:29 -0600 From: "Rajiv Asati (rajiva)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-12.txt Thread-Index: AQHPIsWKiCE97FuwyUaucpD8kf8Hr5qnWG2A Date: Wed, 5 Feb 2014 23:04:28 +0000 Message-ID: In-Reply-To: <20140205225626.29660.79485.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.61.160.157] Content-Type: text/plain; charset="us-ascii" Content-ID: <12B3EFA9EE6660488E8449D6FE77D84D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-12.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, 05 Feb 2014 23:04:53 -0000 We have posted a new version incorporating the feedback by the AD, chairs and others, and committing a lot of editorial changes. To highlight the key changes in this version: - Added specifics on tLDP discovery & peering throughout the document - Moved the text from section 6.2 to section 5.1.1 with some paraphrasing - Moved quite a bit of text from section 4 into the Appendix - updated section 7 to remove bullet#2 and rephrased bullet#1 =20 --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: "internet-drafts@ietf.org" Date: Wednesday, February 5, 2014 5:56 PM To: "i-d-announce@ietf.org" Cc: "mpls@ietf.org" Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-12.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Multiprotocol Label Switching Working >Group of the IETF. > > Title : Updates to LDP for IPv6 > Authors : Rajiv Asati > Vishwas Manral > Rajiv Papneja > Carlos Pignataro > Filename : draft-ietf-mpls-ldp-ipv6-12.txt > Pages : 19 > Date : 2014-02-05 > >Abstract: > The Label Distribution Protocol (LDP) specification defines > procedures to exchange label bindings over either IPv4, or IPv6 or > both networks. This document corrects and clarifies the LDP behavior > when IPv6 network is used (with or without IPv4). This document > updates RFC 5036. > > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ipv6-12 > > >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 jeff.tantsura@ericsson.com Wed Feb 5 15:06: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 502F51A029A for ; Wed, 5 Feb 2014 15:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NohDXIPqlVs8 for ; Wed, 5 Feb 2014 15:06:36 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id DACDA1A016B for ; Wed, 5 Feb 2014 15:06:35 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-fe-52f2c3f6287f Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AD.F2.12743.6F3C2F25; Thu, 6 Feb 2014 00:06:31 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 18:06:33 -0500 From: Jeff Tantsura To: Loa Andersson Thread-Topic: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQHPIjuaiwmakNvbTUGS96ZWGdyTNZqnSVoV Date: Wed, 5 Feb 2014 23:06:32 +0000 Message-ID: References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXSPt+73w5+CDJ4u47aYuvgrq8W/uXOY Le7s+sJq8f3SEhaLW0tXsjqwerQ+28vqsWTJTyaPWdPb2Dy+XP7MFsASxWWTkpqTWZZapG+X wJWx7Plr5oINPBW9Ty6yNzDe5+xi5OSQEDCROLr3NyOELSZx4d56ti5GLg4hgSOMEr93vmCE cJYxSuz6d4cFpIpNwEDi/7fjYLaIgKzEtW0/mUCKmAU2M0k03lrIDpIQFoiR+LngOCNEUazE 5ZunmCBsI4nGc9/AmlkEVCSebNrNCmLzCthLXDq8iQ3EFgKKH7vdAWRzcHAKqEp0NQWDhBmB rvt+ag3YGGYBcYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQNToSC3Z/YoOwtSWWLXzNDLFKUOLk zCcsExhFZyEZNQtJyywkLbOQtCxgZFnFyFFanFqWm25ksIkRGEHHJNh0dzDueWl5iFGag0VJ nPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw+N67nBcjOt3/5O8Pmgr/mm8s2YsXZ qfyhUp9jeWZoxp19blLe9OL7hMornGpz2s7s/y+peCUi9E6dQMgktg3eh7Miqk7XTLwlr1oz 09D2vcbM+cXsT7sTDV6yrv9i3tTYlxq/bP2ro4fnbTPgcw6p17sdY7BOIf6V5bvXT/1n9pVu avvhxq7EUpyRaKjFXFScCAA9iuQEbgIAAA== Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:06:38 -0000 Yes/support as coauthor=20 Regards, Jeff > On Feb 4, 2014, at 10:29 PM, "Loa Andersson" wrote: >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working > group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > Please note that we have identified an overlap between this document > and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this > document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp > to cover this. >=20 > There are no IPR claims against this document. >=20 > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. >=20 > This poll ends February 19, 2014. >=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 huaimo.chen@huawei.com Wed Feb 5 20:39: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 8B6B31A029D for ; Wed, 5 Feb 2014 20:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 xoUyoXG6oblT for ; Wed, 5 Feb 2014 20:39:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4DF11A0277 for ; Wed, 5 Feb 2014 20:39:07 -0800 (PST) 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 BDH43882; Thu, 06 Feb 2014 04:39:05 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 04:38:23 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 04:39:04 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Wed, 5 Feb 2014 20:38:53 -0800 From: Huaimo Chen To: Gregory Mirsky , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: Comments to draft-chen-mpls-p2mp-egress-protection-10 Thread-Index: Ac8it3gag8BDTdsTQrCmaY8m+AociAAOW52A Date: Thu, 6 Feb 2014 04:38:53 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C35557@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.97] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C35557SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 04:39:10 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C35557SJCEML701CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBHcmVnLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMhDQpNeSBhbnN3ZXJzL2V4cGxh bmF0aW9ucyBhcmUgaW5saW5lIGJlbG93Lg0KDQpCZXN0IFJlZ2FyZHMsDQpIdWFpbW8NCkZyb206 IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnb3J5 IE1pcnNreQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNSwgMjAxNCA0OjQ2IFBNDQpUbzog ZHJhZnQtY2hlbi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc7IG1w bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1jaGVuLW1wbHMt cDJtcC1lZ3Jlc3MtcHJvdGVjdGlvbi0xMA0KDQpEZWFyIEF1dGhvcnMsIGV0LiBhbCwNCnBsZWFz ZSBmaW5kIG15IGNvbW1lbnRzIHRvIHRoZSBsYXRlc3QgdmVyc2lvbiBiZWxvdzoNCsK3ICAgICAg ICAgSW50cm9kdWN0aW9uLiAiIFRoZSBtYWluIGRpc2FkdmFudGFnZSBvZiB0aGlzIGFwcHJvYWNo IGlzIHRoYXQgbW9yZSBuZXR3b3JrIHJlc291cmNlcyBzdWNoIGFzIGRvdWJsZSBiYW5kd2lkdGhz IG1heSBiZSB1c2VkLiIgSSBiZWxpZXZlIHRoYXQgY2FuIGJlIGVhc2lseSBhdm9pZGVkIGlmIFNo YXJlZCBleHBsaWNpdCBmaWx0ZXJzcGVjIHVzZWQgc2lnbmFsaW5nIHdvcmtpbmcgYW5kIHByb3Rl Y3RpbmcgTFNQcyBzbyB0aGF0IGJvdGggY291bGQgc2hhcmUgQlcgcmVzb3VyY2VzIG9mIGNvbW1v biBsaW5rcy4gSWYgdGhhdCBpcyB0aGUgbWFpbiBtb3RpdmF0aW9uIGZvciB0aGUgcHJvcG9zZWQg ZXh0ZW5zaW9ucywgSSBkb24ndCBzZWUgaXQgYXMgc3VmZmljaWVudGx5IHN0cm9uZyBjYXNlLg0K SHVhaW1vOiBJbiB0aGUgY2FzZSB0aGF0IHRoZSBwcmltYXJ5IExTUCBpcyBmcm9tIGFuIGluZ3Jl c3Mgbm9kZSBBIHRvIGEgbnVtYmVyIG9mIGVncmVzcyBub2RlcyBhbmQgdGhlIHN0YW5kYnkgTFNQ IGlzIGZyb20gYSBiYWNrdXAgaW5ncmVzcyBub2RlIEIgKG5vdGUgdGhhdCBBIGlzIGRpZmZlcmVu dCBmcm9tIEIpLCBpdCBzZWVtcyB0aGF0IHRoZSBzaGFyZWQgZXhwbGljaXQgUlNWUCByZXNlcnZh dGlvbiBzdHlsZSBkb2VzIG5vdCB3b3JrIGluIHRoaXMgY2FzZS4gIFRoZSBwcmltYXJ5IExTUCBj YW4gbm90IHNoYXJlIGl0cyBiYW5kd2lkdGggd2l0aCB0aGUgc3RhbmRieSBMU1Agc2luY2UgdGhl eSBhcmUgdHdvIGRpZmZlcmVudCBMU1AgdHVubmVscyBzdGFydGluZyBmcm9tIHR3byBkaWZmZXJl bnQgaW5ncmVzcyBub2Rlcy4NCsK3ICAgICAgICAgU2VjdGlvbiAxLjEg4oCcVGhlIGZhaWx1cmUg b2YgYSBwcmltYXJ5IGVncmVzcyAoZS5nLiwgTDEgaW4gdGhlIGZpZ3VyZSkgTUFZIGJlIGRldGVj dGVkIGJ5IGl0cyB1cHN0cmVhbSBub2RlIChlLmcuLCBSMyBpbiB0aGUgZmlndXJlKSB0aHJvdWdo IGEgQkZEIHNlc3Npb24gYmV0d2VlbiB0aGUgdXBzdHJlYW0gbm9kZSBhbmQgdGhlIGVncmVzcyBp biBNUExTIG5ldHdvcmtzLuKAnSBJZiBtb25pdG9yZWQgcGF0aCBpcyBsaW1pdGVkIHRvIHNlZ21l bnQgYmV0d2VlbiBSMyBhbmQgTDEsIHRoZW4gZmFpbHVyZSBvZiBMMSB0byBmb3J3YXJkIHRyYWZm aWMgdG8gQ0UxIG9yIENFMSB0byByZWNlaXZlIGZyb20gTDEgd291bGQgbm90IGJlIGRldGVjdGVk LiBJcyBzdWNoIGxpbWl0ZWQgc2NvcGUgcmVhbGx5IHVzZWZ1bD8NCkh1YWltbzogSW4gYWRkaXRp b24gdG8gZGV0ZWN0aW5nIHRoZSBmYWlsdXJlIG9mIGEgcHJpbWFyeSBlZ3Jlc3Mgc3VjaCBhcyBM MSBpbiB0aGUgZmlndXJlLCB3ZSB0YWxrZWQgYWJvdXQgZGV0ZWN0aW5nL21vbml0b3JpbmcgdGhl IG90aGVyIHBhcnRzIHN1Y2ggYXMgdGhvc2UgeW91IG1lbnRpb25lZCBhYm92ZSBpbiBJRVRGIE1Q TFMgd29ya2luZyBncm91cCBtZWV0aW5ncy4gRGV0ZWN0aW5nL21vbml0b3JpbmcgdGhlc2UgcGFy dHMgY2FuIGJlIGRlY2lkZWQgbG9jYWxseSBieSBvcGVyYXRvcnMuIEl0IHNlZW1zIHRoYXQgdGhl cmUgaXMgbm8gaW1wYWN0IG9uIHRoZSBNUExTIHByb3RvY29scy4NCg0KUmVnYXJkcywNCiAgICAg ICAgR3JlZw0KDQoNCg== --_000_5316A0AB3C851246A7CA5758973207D445C35557SJCEML701CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLmVtYWlscXVvdGUsIGxpLmVtYWls cXVvdGUsIGRpdi5lbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmVtYWlscXVvdGU7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDoxLjBwdDsNCglib3JkZXI6bm9uZTsNCglwYWRk aW5nOjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjE1NjI5MDUyNTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjUxMTcz MDgzMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBHcmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjkuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgYW5zd2Vycy9leHBsYW5h dGlvbnMgYXJlIGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IdWFpbW88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1wbHMgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyZWdvcnkgTWlyc2t5PGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDo0NiBQTTxicj4NCjxi PlRvOjwvYj4gZHJhZnQtY2hlbi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb25AdG9vbHMuaWV0 Zi5vcmc7IG1wbHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21wbHNdIENvbW1lbnRz IHRvIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uLTEwPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RGVhciBBdXRob3JzLCBldC4gYWwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5wbGVhc2UgZmluZCBteSBjb21tZW50cyB0byB0aGUgbGF0ZXN0IHZlcnNpb24g YmVsb3c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkludHJvZHVjdGlv bi4gJnF1b3Q7IFRoZSBtYWluIGRpc2FkdmFudGFnZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQg bW9yZSBuZXR3b3JrIHJlc291cmNlcyBzdWNoIGFzIGRvdWJsZSBiYW5kd2lkdGhzIG1heSBiZSB1 c2VkLiZxdW90OyBJIGJlbGlldmUgdGhhdCBjYW4gYmUgZWFzaWx5IGF2b2lkZWQNCiBpZiBTaGFy ZWQgZXhwbGljaXQgZmlsdGVyc3BlYyB1c2VkIHNpZ25hbGluZyB3b3JraW5nIGFuZCBwcm90ZWN0 aW5nIExTUHMgc28gdGhhdCBib3RoIGNvdWxkIHNoYXJlIEJXIHJlc291cmNlcyBvZiBjb21tb24g bGlua3MuIElmIHRoYXQgaXMgdGhlIG1haW4gbW90aXZhdGlvbiBmb3IgdGhlIHByb3Bvc2VkIGV4 dGVuc2lvbnMsIEkgZG9uJ3Qgc2VlIGl0IGFzIHN1ZmZpY2llbnRseSBzdHJvbmcgY2FzZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IdWFpbW86IEluIHRoZSBjYXNlIHRoYXQgdGhl IHByaW1hcnkgTFNQIGlzIGZyb20gYW4gaW5ncmVzcyBub2RlIEEgdG8gYSBudW1iZXIgb2YgZWdy ZXNzIG5vZGVzIGFuZA0KIHRoZSBzdGFuZGJ5IExTUCBpcyBmcm9tIGEgYmFja3VwIGluZ3Jlc3Mg bm9kZSBCIChub3RlIHRoYXQgQSBpcyBkaWZmZXJlbnQgZnJvbSBCKSwgaXQgc2VlbXMgdGhhdCB0 aGUgc2hhcmVkIGV4cGxpY2l0IFJTVlAgcmVzZXJ2YXRpb24gc3R5bGUgZG9lcyBub3Qgd29yayBp biB0aGlzIGNhc2UuICZuYnNwO1RoZSBwcmltYXJ5IExTUCBjYW4gbm90IHNoYXJlIGl0cyBiYW5k d2lkdGggd2l0aCB0aGUgc3RhbmRieSBMU1Agc2luY2UgdGhleSBhcmUgdHdvIGRpZmZlcmVudA0K IExTUCB0dW5uZWxzIHN0YXJ0aW5nIGZyb20gdHdvIGRpZmZlcmVudCBpbmdyZXNzIG5vZGVzLiAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlY3Rpb24gMS4xIOKAnFRoZSBm YWlsdXJlIG9mIGEgcHJpbWFyeSBlZ3Jlc3MgKGUuZy4sIEwxIGluIHRoZSBmaWd1cmUpIE1BWSBi ZSBkZXRlY3RlZCBieSBpdHMgdXBzdHJlYW0gbm9kZSAoZS5nLiwgUjMgaW4gdGhlIGZpZ3VyZSkg dGhyb3VnaCBhIEJGRCBzZXNzaW9uIGJldHdlZW4NCiB0aGUgdXBzdHJlYW0gbm9kZSBhbmQgdGhl IGVncmVzcyBpbiBNUExTIG5ldHdvcmtzLuKAnSBJZiBtb25pdG9yZWQgcGF0aCBpcyBsaW1pdGVk IHRvIHNlZ21lbnQgYmV0d2VlbiBSMyBhbmQgTDEsIHRoZW4gZmFpbHVyZSBvZiBMMSB0byBmb3J3 YXJkIHRyYWZmaWMgdG8gQ0UxIG9yIENFMSB0byByZWNlaXZlIGZyb20gTDEgd291bGQgbm90IGJl IGRldGVjdGVkLiBJcyBzdWNoIGxpbWl0ZWQgc2NvcGUgcmVhbGx5IHVzZWZ1bD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IdWFpbW86IEluIGFkZGl0aW9uIHRvIGRldGVjdGluZyB0 aGUgZmFpbHVyZSBvZiBhIHByaW1hcnkgZWdyZXNzIHN1Y2ggYXMgTDEgaW4gdGhlIGZpZ3VyZSwg d2UgdGFsa2VkDQogYWJvdXQgZGV0ZWN0aW5nL21vbml0b3JpbmcgdGhlIG90aGVyIHBhcnRzIHN1 Y2ggYXMgdGhvc2UgeW91IG1lbnRpb25lZCBhYm92ZSBpbiBJRVRGIE1QTFMgd29ya2luZyBncm91 cCBtZWV0aW5ncy4gRGV0ZWN0aW5nL21vbml0b3JpbmcgdGhlc2UgcGFydHMgY2FuIGJlIGRlY2lk ZWQgbG9jYWxseSBieSBvcGVyYXRvcnMuIEl0IHNlZW1zIHRoYXQgdGhlcmUgaXMgbm8gaW1wYWN0 IG9uIHRoZSBNUExTIHByb3RvY29scy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3Jl ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5316A0AB3C851246A7CA5758973207D445C35557SJCEML701CHMchi_-- From y-iizawa@cd.jp.nec.com Wed Feb 5 22:01:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839461A0034 for ; Wed, 5 Feb 2014 22:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZBrCPlaHAX6 for ; Wed, 5 Feb 2014 22:01:44 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEC91A0030 for ; Wed, 5 Feb 2014 22:01:44 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id s1661hCr026648 for ; Thu, 6 Feb 2014 15:01:43 +0900 (JST) Received: from mailsv.nec.co.jp (imss61.nec.co.jp [10.7.69.156]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id s1661gZ07423 for ; Thu, 6 Feb 2014 15:01:42 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id s1661RHY020347 for ; Thu, 6 Feb 2014 15:01:42 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.132] [10.38.151.132]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-803492; Thu, 6 Feb 2014 15:01:00 +0900 Received: from BPXM02GP.gisp.nec.co.jp ([169.254.1.234]) by BPXC04GP.gisp.nec.co.jp ([10.38.151.132]) with mapi id 14.02.0328.011; Thu, 6 Feb 2014 15:00:59 +0900 From: Yohei Iizawa To: "mpls@ietf.org" Thread-Topic: iPOP2014 Paper Submission Deadline Extended Thread-Index: Ac8jAMlpv8C1M86jT6iClQnHv4+oYg== Date: Thu, 6 Feb 2014 06:00:59 +0000 Message-ID: <6D8CC8EB7FE4C444B73DF64E761A0DCC1D54F717@BPXM02GP.gisp.nec.co.jp> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.56.47.179] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] iPOP2014 Paper Submission Deadline Extended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 06:01:45 -0000 (Apologies if you received multiple copies of this message.) Dear MPLS subscribers, The paper submission deadline of iPOP2014 has been extended to February 20t= h, 2014. Best Regards, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Oh behalf of Kohei Shiomoto, Eiji Oki, iPOP2014 TPC Co-chairs http://www.pilab.jp/ipop2014/ Yohei Iizawa, iPOP2014 TPC Secretary --------------------------------------------------------------------- Call for Presentation 10th International Conference on IP + Optical Network (iPOP 2014) May 22-23, 2014 NTT R&D center Musashino, Tokyo, Japan http://www.pilab.jp/ipop2014/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 20, 2014=20 Notification of acceptance: March 24, 2014 Submission deadline of final presentation slides: April 11, 2014 The Technical Program Committee for iPOP 2014 is soliciting presentation=20 proposals for this conference. Protocol design, experiment, theory,=20 implementation, and operational experiences are solicited. The topics of the conference will include but not be limited to the followi= ng: - Photonic network for NxGN and NwGN - Multi-Layer Network (MLN)/Multi-Region Network (MRN) - Inter-area/inter-AS network - Software Defined Networking (SDN) - Software Defined Optics (SDO) and its network application - SDN network services and monetization=20 - Open Source Software (OSS) activities for SDN - Network virtualization=20 - Data center and WAN orchestration - Path Computation Element (PCE) and traffic engineering - GMPLS/ASON technologies - Application with high-bandwidth demand - L0-L3 Virtual Private Network (VPN) - MPLS and Ethernet networking for inter-data center connectivity for cloud computing - Carrier Ethernet and MPLS-TP for backhauling - Optical networking/switching for cloud services - Testbed, field trial If you wish to submit a topic for consideration, please send an Extended=20 Abstracts of 400 words and a maximum of 1 page, including figures and=20 diagrams, speaker's name, affiliation, and contact information=20 to the Technical Program Committee at ipop2014-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2014/ for more details. ---------------------------------------------------------------------------= ---- From kingstonsmiler@gmail.com Wed Feb 5 23:14:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E261A004C for ; Wed, 5 Feb 2014 23:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9xrEAKZZOUe for ; Wed, 5 Feb 2014 23:13:58 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4871A037A for ; Wed, 5 Feb 2014 23:13:58 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id b8so1152678lan.33 for ; Wed, 05 Feb 2014 23:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QJamFoLHdwWD3pDSl5OZGVoMvQk4+xtPxnfw2UK3bB0=; b=aBTTO+in/qCVPVrxVCGu0D5+A3dnUb8qRRF8tgxAS4tP8jWH5W5irX/tSExVHQRsRy fVCmMrt35qBn0k9yzl+c5ytSj9Vvwyu3iUeU3uTcsn2ip/TNMLaPIYytASBkfk++71Ks HhcmB41Vx5tokzmHh6bGEIk8vEzPEgDUhyNMvQGwHurEl2vY/TcVvRQz6HCKjfIoeASi iMWqKbUXpaXVmQ/BG7no9q4EOCtaBTCf1KqvRKcjrBaasQhZ/YURN3Ap9SMPSkp8TYhd egLThFCGn/J9i4Ao6BBKDuVyGAnDfH0FxAW5YtyLc1P3+/IPOWlu4/vprdMSOSPuUSk9 dsFQ== MIME-Version: 1.0 X-Received: by 10.152.21.4 with SMTP id r4mr28377lae.51.1391670836539; Wed, 05 Feb 2014 23:13:56 -0800 (PST) Received: by 10.114.200.203 with HTTP; Wed, 5 Feb 2014 23:13:56 -0800 (PST) In-Reply-To: <52F08ED9.5050509@pi.nu> References: <52F08ED9.5050509@pi.nu> Date: Thu, 6 Feb 2014 12:43:56 +0530 Message-ID: From: Kingston Smiler To: Loa Andersson Content-Type: multipart/alternative; boundary=089e0141a4a8db367504f1b79d50 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: Re: [mpls] seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 07:14:00 -0000 --089e0141a4a8db367504f1b79d50 Content-Type: text/plain; charset=ISO-8859-1 Hi All, Oppose as Read-only. We prefer to have read-write variant of this MIB for our product because of the reasons already mentioned by different folks in this thread. Regards, S. Kingston Smiler. On Tue, Feb 4, 2014 at 12:25 PM, Loa Andersson wrote: > Working Group, > > We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the > working group for more work. We have a series of comments that are > mostly for clarification. However the main reason for recalling the > document is that there is one point where we need to confirm working > group consensus. > > The IETF, the working group and the MIB Doctors are today very reluctant > to produce read-write MIB modules. The current draft is read-write for a > few objects, this is based on a consensus call for an earlier > discussion, however the consensus call was not clear. It can be taken > to mean both that we want to go with read-write objects and that we > want to see read-only. Is it clear that it has been interpreted > differently by different individuals. > > The authors and chairs have discussed the issue and we have a rough > consensus that we want the MIB module(s) to be read-only. > > We therefore are asking the working group if this is OK for the MIB > module(s) in the current document. Please indicate Support or Oppose > for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only. > > Please send your comments to the working group mailing list before > February 18, 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --089e0141a4a8db367504f1b79d50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

Oppose as Read-only. We pre= fer to have read-write variant of this MIB for our product because of the r= easons already mentioned by different folks in this thread.

Regards,
S. Kingston Smiler.

On Tue, Feb 4, 2014 at 12:25 PM, Loa Andersson = <loa@pi= .nu> wrote:
Working Group,

We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the
working group for more work. We have a series of comments that are
mostly for clarification. However the main reason for recalling the
document is that there is one point where we need to confirm working
group consensus.

The IETF, the working group and the MIB Doctors are today very reluctant to produce read-write MIB modules. The current draft is read-write for a fe= w objects, this is based on a consensus call for an earlier
discussion, however the consensus call was not clear. It can be taken
to mean both that we want to go with read-write objects and that we
want to see read-only. Is it clear that it has been interpreted
differently by different individuals.

The authors and chairs have discussed the issue and we have a rough
consensus that we want the MIB module(s) to be read-only.

We therefore are asking the working group if this is OK for the MIB
module(s) in the current document. Please indicate Support or Oppose
for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only.

Please send your comments to the working group mailing list before
February 18, 2014.

Loa
for the MPLS wg chairs
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--089e0141a4a8db367504f1b79d50-- From ldeghein@cisco.com Wed Feb 5 23:38: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 332BE1A0389 for ; Wed, 5 Feb 2014 23:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 nhCunXT6Ytsf for ; Wed, 5 Feb 2014 23:38:19 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id A77621A0380 for ; Wed, 5 Feb 2014 23:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1133; q=dns/txt; s=iport; t=1391672298; x=1392881898; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=q4PRDtnhcptck8Bw/6bCLz49SbAF2gzgExV0RnKDDH8=; b=maSdpR1V9YGGhPPOQ3CKo9CR995XhkuA+yEeQmTZDpzfFsMCKEIlptp5 S44NR6QqIRoL1sjUAf47P4ogFhuvpw86iwzjgvtkiimKxN4or+6bLToKn pLwsXAVpvrI5AMWbcaxpzGwAv/+SfmUSm1en0ErBOZfKFkDrMJMGuEeDl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFADg781KQ/khN/2dsb2JhbABZgwy/fYEGFnSCJQEBAQMBODYKBgsLIRYPCQMCAQIBRRMGAgEBh3kIzkkXjwEWhCIBA5grhkiLWYFvgT8 X-IronPort-AV: E=Sophos;i="4.95,792,1384300800"; d="scan'208";a="4059483" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 06 Feb 2014 07:38:17 +0000 Received: from [144.254.7.68] (dhcp-peg3-vl30-144-254-7-68.cisco.com [144.254.7.68]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s167cCm3022075 for ; Thu, 6 Feb 2014 07:38:12 GMT Message-ID: <52F33BE4.7070002@cisco.com> Date: Thu, 06 Feb 2014 08:38:12 +0100 From: Luc De Ghein Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mpls@ietf.org References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ldeghein@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 07:38:20 -0000 Support. Best regards, Luc > Working Group, > > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > Please note that we have identified an overlap between this document > and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this > document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp > to cover this. > > There are no IPR claims against this document. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends February 19, 2014. > > /Loa > (mpls wg co-chair) From francesco.fondelli@gmail.com Thu Feb 6 03:03: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 401561A0274 for ; Thu, 6 Feb 2014 03:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjZIn638hUKV for ; Thu, 6 Feb 2014 03:03:01 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C873E1A00C4 for ; Thu, 6 Feb 2014 03:03:00 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so2767505qcz.17 for ; Thu, 06 Feb 2014 03:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/YwXOYTk+wt6/d9FX6VZ0CH/7vigZGx2RjhaGXiepXs=; b=vSbEHkjjGH9qi3F6fbuAcMqAj9JD6eS5a7wFFEEErTxHF/ONtwCqk4+orT4+jvFnx3 fGDW4qUqqUeIa3oIqrQlDhwZkvRbovHzqRX3/rjII1u2LWH4CIBmwp6UcmxDnIEs4yfF JbURJQ2TgqDdrfxrr0HtmJUQ/JoZNEZ4C5NIV6L9LAtmrjLahOS7stNA7J2BDfg/Sozf cOUddf8xlzuslPvUIH/ppEJY6qOnKlPBa60CJGZ3whXUuiDJqVemTo1ARkGrZgMYCdWE 2TpRmNPpAfDsJaCyEoFrjtTsvSGZ7O/wMGKqKQBdS7qAy6edreN3WKGS5+Hyhs4nLfHu nWUg== MIME-Version: 1.0 X-Received: by 10.229.127.72 with SMTP id f8mr8641885qcs.12.1391684579500; Thu, 06 Feb 2014 03:02:59 -0800 (PST) Received: by 10.224.35.70 with HTTP; Thu, 6 Feb 2014 03:02:59 -0800 (PST) In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C35557@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C35557@SJCEML701-CHM.china.huawei.com> Date: Thu, 6 Feb 2014 12:02:59 +0100 Message-ID: From: Francesco Fondelli To: Huaimo Chen Content-Type: text/plain; charset=UTF-8 Cc: "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 11:03:02 -0000 Hi, On Thu, Feb 6, 2014 at 5:38 AM, Huaimo Chen wrote: > Dear Greg, [cut] > Huaimo: In the case that the primary LSP is from an ingress node A to a > number of egress nodes and the standby LSP is from a backup ingress node B > (note that A is different from B), it seems that the shared explicit RSVP > reservation style does not work in this case. The primary LSP can not share > its bandwidth with the standby LSP since they are two different LSP tunnels > starting from two different ingress nodes. Oh, this is in my still-have-to-be-understood-queue since a while... SE-style reservation creates a single reservation shared by selected upstream sender*s* (I do not think they have to be be on the same node) within a given session [RFC2205]. In a p2mp scenario a session is identified by the tuple (P2MP ID, Tunnel ID, Extended Tunnel ID) [RFC4875]. If ingress nodes A and B use the same P2MP ID *and* the same Tunnel ID *and* 0 as Extended Tunnel ID (it is normally set to a value != 0 by ingress nodes that wish to *narrow* the scope of a session to the ingress-egress pair [RFC3209], though in this case we want the opposite) primary and standby LSPs will share the same resources along common links/nodes. How nodes A and B shares P2MP ID and Tunnel ID is outside the scope of this email :-), I guess manual configuration might be a possibility. This is my understanding. ACK/NACK would be much appreciated (not sure all I said is 100% correct or I missed something). thank you ciao fra PS this possibility for the p2p case is mentioned in RFC3209 section 2.4.3 "SE style reservations can be provided using multipoint-to-point label-switched-path or LSP per sender..." From maho@lab.dtag.de Thu Feb 6 00:56:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7789B1A00AB for ; Thu, 6 Feb 2014 00:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 vaa327PTyRTF for ; Thu, 6 Feb 2014 00:56:04 -0800 (PST) Received: from owl.lab.dtag.de (Owl.lab.DTAG.DE [194.25.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id 807021A006A for ; Thu, 6 Feb 2014 00:56:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by owl.lab.dtag.de (Postfix) with ESMTP id 981905972CD for ; Thu, 6 Feb 2014 09:56:01 +0100 (CET) Received: from tsunami-neu.39.lab.dtag.de (o.Boggart.lab.dtag.de [62.153.176.78]) by owl.lab.dtag.de (Postfix) with ESMTPSA id 7604B5968BB for ; Thu, 6 Feb 2014 09:56:01 +0100 (CET) Message-ID: <52F34E21.9040906@lab.dtag.de> Date: Thu, 06 Feb 2014 09:56:01 +0100 From: Martin Horneffer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mpls@ietf.org References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Feb 2014 05:49:34 -0800 Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 08:56:06 -0000 Support. Best regards, Martin Am 05.02.14 07:29, schrieb Loa Andersson: > Working Group, > > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > Please note that we have identified an overlap between this document > and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this > document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp > to cover this. > > There are no IPR claims against this document. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends February 19, 2014. > > /Loa > (mpls wg co-chair) ############################################## # Mail Account for technical purposes only ############################################## From cpignata@cisco.com Thu Feb 6 06:20: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 A77361A03CC for ; Thu, 6 Feb 2014 06:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 Td1Tyt-l2k_w for ; Thu, 6 Feb 2014 06:20:13 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 22FA31A0143 for ; Thu, 6 Feb 2014 06:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2332; q=dns/txt; s=iport; t=1391696412; x=1392906012; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XFzYes0j3UX/8ACghFfZWrE49MtMIZiq2ZU+Q/PlP1E=; b=HinI5A9LaIqzK9KGeYzOnrVPDO5bO+z89cRKFP1k9ggasdyht6OoK0n3 C0c88a8leK6OuE2WdITowTMPRlQrHC2cM0gMWOuu0HEecQoMfS4tbVhlO ojP3qW5zvYF+1323MwESAaLZNElwrbqVCQUlxBieQslJ72qgUZVPsxGf4 0=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAC+Z81KtJXHB/2dsb2JhbABZgww4V75xgQkWdIIlAQEBAwEBAQEaTgMLBQkCAgEIRhsMCyUCBA4FDodvCA3ONRMEBI4UEQFQB4MkgRQEkD+BMoY6kiGDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="asc'?scan'208";a="302379104" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 06 Feb 2014 14:20:12 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s16EKBFM008908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 14:20:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 08:20:11 -0600 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] working group last call for draft-ietf-mpls-extended-admin-group Thread-Index: AQHPI0aLkLy7o3Lm40K1SbmbvdojgA== Date: Thu, 6 Feb 2014 14:20:10 +0000 Message-ID: <07634523-CB29-44C0-B5CB-A695F77D623E@cisco.com> References: <52F08085.9000907@pi.nu> In-Reply-To: <52F08085.9000907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/signed; boundary="Apple-Mail=_C1B63C21-DD9C-42C4-B357-A8E10916695E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 14:20:20 -0000 --Apple-Mail=_C1B63C21-DD9C-42C4-B357-A8E10916695E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Loa, I think that this document is almost ready for publication moving = forward. It addresses a focused problem in a direct way. I only have one technical comment: Section 2.3.1 addresses "coexistence" giving preference to the EAG over = the AG. That is fine, however it does not address "backwards = compatibility" in the case in which both are advertised in an IGP, but a = node understands only AG and not EAG. In that case, if the first 32 bits = differ, then the node that advertises and the node that receives it (and = does not understand EAG) have different views of the decision. This = should be anomalous and an error condition. Also some nits regarding citations in the Abstract and a downref = Normative that should be noted. Thanks! Carlos. On Feb 4, 2014, at 12:54 AM, Loa Andersson wrote: > Working Group, >=20 > This is to initiate a working group last call on > draft-ietf-mpls-extended-admin-group-02. >=20 > There are no IPR disclosures against this document. The author has > stated that he is unaware of any IPRs that relate to this document. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > This working group last call ends Feb 18, 2014. >=20 > /Loa > for the MPLS wg chairs > --=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 --Apple-Mail=_C1B63C21-DD9C-42C4-B357-A8E10916695E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLzmhoACgkQtfDPGTp3USxkuQCfaG3v+ExW2hpB2Q3wTBUbtTpZ nfoAn1T0tnx7cgthgj09+0P0uS/rdh7h =BBqM -----END PGP SIGNATURE----- --Apple-Mail=_C1B63C21-DD9C-42C4-B357-A8E10916695E-- From agmalis@gmail.com Thu Feb 6 07:31: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 A78CA1A01B6 for ; Thu, 6 Feb 2014 07:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VotadHkiZimM for ; Thu, 6 Feb 2014 07:31:11 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A2E8F1A0186 for ; Thu, 6 Feb 2014 07:31:11 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id n7so3404281qcx.30 for ; Thu, 06 Feb 2014 07:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=DYLr4QHxyMOWPqhXINFVEqeomPXxs9vmPzKEujrmiFU=; b=iBWvvIMEtwnYK9UncM1zY3Cr+6zVgMIzV3nzq8RMBikm1pkEx2uaJyjfFlDv3RMMps Kwhdvf+Arpvs4vAAYq73rqpHbrXetihyv4nWJyYfCwYPM8zUF4x7VP64V/ftGg8ELodJ 5PPcj6BNEoCBNK+faLJC2P+qowo1mhftgrGSiyI+a0aj2855kKhR85bqKGoQWD5fZWWG B8voWB+vYyZFUq/EuH0m64AIuomESpdefSX9xzOzft2SrGP9l6rE+3N+LyLTRs6Z1Iah k7AlrRVYQWWBKWFNmwcDwh18dBTBducKH/+VLizHvb21N9XbLNQf+T2r472/yYbtCuJf Ii3Q== X-Received: by 10.229.46.70 with SMTP id i6mr411797qcf.10.1391700670369; Thu, 06 Feb 2014 07:31:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Thu, 6 Feb 2014 07:28:52 -0800 (PST) In-Reply-To: <07634523-CB29-44C0-B5CB-A695F77D623E@cisco.com> References: <52F08085.9000907@pi.nu> <07634523-CB29-44C0-B5CB-A695F77D623E@cisco.com> From: "Andrew G. Malis" Date: Thu, 6 Feb 2014 10:28:52 -0500 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 15:31:13 -0000 Carlos, Regarding your technical comment, if a receiver only understands the AG and not the EAG, then it should silently ignore the EAG, and there is no way for it to detect the case where they are in disagreement. Thus there is no way to report this as an error condition. Also see my comment on section 2.3.1 backwards compatibility in my previous email. Cheers, Andy On Thu, Feb 6, 2014 at 9:20 AM, Carlos Pignataro (cpignata) wrote: > Hi, Loa, > > I think that this document is almost ready for publication moving forward= . It addresses a focused problem in a direct way. > > I only have one technical comment: > > Section 2.3.1 addresses "coexistence" giving preference to the EAG over t= he AG. That is fine, however it does not address "backwards compatibility" = in the case in which both are advertised in an IGP, but a node understands = only AG and not EAG. In that case, if the first 32 bits differ, then the no= de that advertises and the node that receives it (and does not understand E= AG) have different views of the decision. This should be anomalous and an e= rror condition. > > Also some nits regarding citations in the Abstract and a downref Normativ= e that should be noted. > > Thanks! > > Carlos. > > On Feb 4, 2014, at 12:54 AM, Loa Andersson wrote: > >> Working Group, >> >> This is to initiate a working group last call on >> draft-ietf-mpls-extended-admin-group-02. >> >> There are no IPR disclosures against this document. The author has >> stated that he is unaware of any 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 Feb 18, 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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From cpignata@cisco.com Thu Feb 6 07:44: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 6187D1A018E for ; Thu, 6 Feb 2014 07:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 M9IwG-OOFVnh for ; Thu, 6 Feb 2014 07:44:22 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 620A31A0143 for ; Thu, 6 Feb 2014 07:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3526; q=dns/txt; s=iport; t=1391701461; x=1392911061; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PMqBkvdc4GgGzcTOvwmsOQXyELRffICr4GdKiqxb+IE=; b=LOLw2SvYApRwDvV8soYqdY6dLNBivRjWxPcfUrI1wvu0te1MOZ7y8Di9 O2w6+lTaN4q5WhM5sk2wc3T8Yrq0u0Y1jCvW6aOHMt94SHuak7llsiM1N RzOVa5/c2/igFgzIGuKdRdTsuQtbVqKsRgmmGirg+BqMM5UO9HhuEPprH 0=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJCt81KtJV2c/2dsb2JhbABZgww4V75xgQsWdIIlAQEBAwEBAQEaTgMLBQkCAgEIGC4bBgYLJQIEDgUOh2MDCQgNxQQNiQ0TBASMYIE0EQFQB4MkgRQEkD+BMoROgWyMXoVDgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="asc'?scan'208";a="18479970" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 06 Feb 2014 15:44:21 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s16FiKsF029111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:44:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 09:44:20 -0600 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-extended-admin-group Thread-Index: AQHPI1B4rxIRlT8h4kqFmAE5ZtsRpZqowosA Date: Thu, 6 Feb 2014 15:44:19 +0000 Message-ID: <1B2BDE4C-F739-44DB-BA1B-5A6A3AEB48CB@cisco.com> References: <52F08085.9000907@pi.nu> <07634523-CB29-44C0-B5CB-A695F77D623E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/signed; boundary="Apple-Mail=_7DC51ACA-9987-405C-8850-C3B995B1DB6B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 15:44:24 -0000 --Apple-Mail=_7DC51ACA-9987-405C-8850-C3B995B1DB6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Andy, On Feb 6, 2014, at 10:28 AM, Andrew G. Malis wrote: > Carlos, >=20 > Regarding your technical comment, if a receiver only understands the > AG and not the EAG, then it should silently ignore the EAG, and there > is no way for it to detect the case where they are in disagreement. > Thus there is no way to report this as an error condition. >=20 Yes, exactly. My call out was only that two routers will have a separate = view of the coloring, and cannot be detected by the router that does not = understand EAG. Just something that needs perhaps to he spelled out in = the doc. > Also see my comment on section 2.3.1 backwards compatibility in my > previous email. >=20 I fully agree with that comment. That would cover it. Thanks! Carlos. > Cheers, > Andy >=20 > On Thu, Feb 6, 2014 at 9:20 AM, Carlos Pignataro (cpignata) > wrote: >> Hi, Loa, >>=20 >> I think that this document is almost ready for publication moving = forward. It addresses a focused problem in a direct way. >>=20 >> I only have one technical comment: >>=20 >> Section 2.3.1 addresses "coexistence" giving preference to the EAG = over the AG. That is fine, however it does not address "backwards = compatibility" in the case in which both are advertised in an IGP, but a = node understands only AG and not EAG. In that case, if the first 32 bits = differ, then the node that advertises and the node that receives it (and = does not understand EAG) have different views of the decision. This = should be anomalous and an error condition. >>=20 >> Also some nits regarding citations in the Abstract and a downref = Normative that should be noted. >>=20 >> Thanks! >>=20 >> Carlos. >>=20 >> On Feb 4, 2014, at 12:54 AM, Loa Andersson wrote: >>=20 >>> Working Group, >>>=20 >>> This is to initiate a working group last call on >>> draft-ietf-mpls-extended-admin-group-02. >>>=20 >>> There are no IPR disclosures against this document. The author has >>> stated that he is unaware of any IPRs that relate to this document. >>>=20 >>> Please send your comments to the mpls wg mailing list = (mpls@ietf.org). >>>=20 >>> This working group last call ends Feb 18, 2014. >>>=20 >>> /Loa >>> for the MPLS wg chairs >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 --Apple-Mail=_7DC51ACA-9987-405C-8850-C3B995B1DB6B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLzrdIACgkQtfDPGTp3USwTuQCeIS0oveCsG6b9YlT7SOQRJwaZ WiMAoMhaJFRF91TBmlMViO3ZPQa8KkmA =ZdSl -----END PGP SIGNATURE----- --Apple-Mail=_7DC51ACA-9987-405C-8850-C3B995B1DB6B-- From tsaad@cisco.com Thu Feb 6 08:35: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 1F3521A03F9 for ; Thu, 6 Feb 2014 08:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 5nR7-eV-Xeuo for ; Thu, 6 Feb 2014 08:35:27 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6577F1A01E7 for ; Thu, 6 Feb 2014 08:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1391704526; x=1392914126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AKvtgN4viwP0ywshyIS0XsdDrlejnwjJ57TrltYOdL8=; b=TkCwhKgCeK5lUvQKRm9KUYovcj27XLJjdHg1mnMzIOf6fIRwPiHpNX/O V4tre2QID7eV1TPe5zR6piDL2qua9KPnSeyKNtpRQ/mYh4IaO4WjECmLZ f4muzSoOgH7K+uBhw22bm9EkSuQ5b4gWWN3MJb6OfrHAotEOePrp0itZS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEu581KtJXG8/2dsb2JhbABZgww4V75xgQsWdIImAQEEAQEBGgoTMQMLDgICAQg2EBsMCyUCBAENBYgFDc4FEwQEjhQRAVAHhDgEmCuSIYMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="302353365" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 06 Feb 2014 16:35:26 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s16GZQtV016398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 16:35:26 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 10:35:25 -0600 From: "Tarek Saad (tsaad)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-extended-admin-group Thread-Index: AQHPI1lvKVihJZqYOkiIWLXvq52Q3Q== Date: Thu, 6 Feb 2014 16:35:25 +0000 Message-ID: References: <52F08085.9000907@pi.nu> In-Reply-To: <52F08085.9000907@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.86.242.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <50DBB10DAF19754D8B8425860DACE53D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 16:35:29 -0000 Hi, This document looks good, and addresses a real limitation with existing AGs. I think it is ready for publication. Few comments: - section 2.3.1: prefer rewording to explicitly spell the behaviour on a receiving node that supports EAG.. example, "... EAG MUST take priority on a receiving node that supports it." minor edit comments: - section 1, might want to define LSA, MTU before use - section 2.3.2 equally applicable to AG too; maybe re-title as "Desire for unadvertised bits for AG/EAG"? - typo in Section 2.3.2, "... assumption is than" -> "assumption is that" Regards, Tarek On 2014-02-04 12:54 AM, "Loa Andersson" wrote: >Working Group, > >This is to initiate a working group last call on >draft-ietf-mpls-extended-admin-group-02. > >There are no IPR disclosures against this document. The author has >stated that he is unaware of any 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 Feb 18, 2014. > >/Loa >for the MPLS wg chairs >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Thu Feb 6 09:24:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E8B1A0025 for ; Thu, 6 Feb 2014 09:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy-ZA474PCHq for ; Thu, 6 Feb 2014 09:24:20 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC51A0172 for ; Thu, 6 Feb 2014 09:24:20 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so3715809qcz.3 for ; Thu, 06 Feb 2014 09:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ir+k0/t4I1hQOFulrd696+zOXGjy9G7k7HeOBfam4g0=; b=JuO14sTMD84LUT6f+zgpgDcG6+Py6vT9EUNzaYiU6azERPw90wWtd5uEu/r7Yph/3d 0elyuR7uZehrjCeSDfhpwac9vKg/u5O+yABop8PtSwC7CzzbXlHO217l7xyF+7BG4o/f 9Asz2wFKjRhZI6dQ4UJd3SUU2Uxmd4pC+bxF/5c3Tyl1GxfuJxX2HLJKrJdc8v6YAnWc N+FwfG/+ZguYyUbu0tVoo4LHeAbZ3tAue+w1oHNUkJmd4oOkYqOh9KZfgasr4gfA3dwL yV8neZgECo1GBqUA/C2wVOJgm3gYgAck7DFCcV4V0UsC4jSu0MfqBRb0H6G8wausvl+V HyKw== X-Received: by 10.224.4.130 with SMTP id 2mr14248707qar.83.1391707116685; Thu, 06 Feb 2014 09:18:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Thu, 6 Feb 2014 09:18:16 -0800 (PST) In-Reply-To: References: <52F08085.9000907@pi.nu> From: "Andrew G. Malis" Date: Thu, 6 Feb 2014 12:18:16 -0500 Message-ID: To: "Tarek Saad (tsaad)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 17:24:22 -0000 Tarek, In my earlier review, I argued the opposite for section 2.3.1, that AG MUST take priority over EAG for backwards compatibility. See my email for my reasoning. Cheers, Andy On Thu, Feb 6, 2014 at 11:35 AM, Tarek Saad (tsaad) wrote: > Hi, > > This document looks good, and addresses a real limitation with existing > AGs. I think it is ready for publication. Few comments: > - section 2.3.1: prefer rewording to explicitly spell the behaviour on a > receiving node that supports EAG.. example, "... EAG MUST take priority on > a receiving node that supports it." > > > minor edit comments: > - section 1, might want to define LSA, MTU before use > - section 2.3.2 equally applicable to AG too; maybe re-title as "Desire > for unadvertised bits for AG/EAG"? > - typo in Section 2.3.2, "... assumption is than" -> "assumption is that" > > Regards, > > Tarek > > On 2014-02-04 12:54 AM, "Loa Andersson" wrote: > >>Working Group, >> >>This is to initiate a working group last call on >>draft-ietf-mpls-extended-admin-group-02. >> >>There are no IPR disclosures against this document. The author has >>stated that he is unaware of any 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 Feb 18, 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 >>_______________________________________________ >>mpls mailing list >>mpls@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Thu Feb 6 09:34: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 40AB01A03FB for ; Thu, 6 Feb 2014 09:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bENZFNbG5wfA for ; Thu, 6 Feb 2014 09:34:35 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAA31A03F2 for ; Thu, 6 Feb 2014 09:34:34 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-74-52f3c7aa2dc4 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8D.3E.11484.AA7C3F25; Thu, 6 Feb 2014 18:34:34 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 12:34:32 -0500 From: Gregory Mirsky To: Huaimo Chen , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: Comments to draft-chen-mpls-p2mp-egress-protection-10 Thread-Index: Ac8it3gag8BDTdsTQrCmaY8m+AociAAOW52AABuskfA= Date: Thu, 6 Feb 2014 17:34:33 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B75F307@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C35557@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C35557@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B75F307eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXRPrO6q45+DDNruqlv0zt7OaLH16RVG i1tLV7I6MHu0HHnL6rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZcyZfoq54NokpoqpM48w NjDu6WbqYuTkkBAwkXh6+SkzhC0mceHeerYuRi4OIYEjjBL/r/UzQjjLGCVa550Aq2ITMJJ4 sbGHHSQhInCAUeLQ33WMIAlhASeJ3glz2UFsEQFnicmnD7BB2FYSE583gtWwCKhITFr4GWw1 r4CvxKsVfVAbZjJKPO7aBLaBUyBM4sa8LWANjEA3fT+1BqyBWUBc4taT+VB3C0gs2XMe6m5R iZeP/7FC2EoSk5aeY4Woz5fYdnYaC8QyQYmTM5+wTGAUmYVk1CwkZbOQlM1i5ACKa0qs36UP UaIoMaX7ITuErSHROmcuO7L4Akb2VYwcpcWpZbnpRoabGIGRdUyCzXEH44JPlocYpTlYlMR5 v7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6HBqU/BHK8Z1Hkte/H7sqHR+0uwv3PsT 9n+Q+9nXrLgj7eIMraer9jAf/3xiwavINdrxp+4JT6t/8vHGN9kd3zVbknTNkqcvUauZsdJh /+wN1SvnNb/lf7RzTkrqh40nJs/7Jr5FobdewLxwYt/67w4J/JJnRZb8nrX9xAJp5sjYLPv4 /ZftiyKVWIozEg21mIuKEwHh9LugegIAAA== Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 17:34:40 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B75F307eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSHVhaW1vLA0KbWFueSB0aGFua3MgZm9yIHRoZSBtb3N0IGV4cGVkaWVudCByZXNwb25zZSBh bmQgdGhvcm91Z2ggY29uc2lkZXJhdGlvbiBvZiBteSBjb21tZW50cy4gUGxlYXNlIGZpbmQgY291 cGxlIG5vdGVzIGluLWxpbmVkIGFuZCB0YWdnZWQgYnkgR0lNPj4uDQoNCiAgICAgICAgICAgICAg ICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206 IEh1YWltbyBDaGVuIFttYWlsdG86aHVhaW1vLmNoZW5AaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODozOSBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5OyBkcmFm dC1jaGVuLW1wbHMtcDJtcC1lZ3Jlc3MtcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzsgbXBsc0Bp ZXRmLm9yZw0KU3ViamVjdDogUkU6IENvbW1lbnRzIHRvIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVn cmVzcy1wcm90ZWN0aW9uLTEwDQoNCkRlYXIgR3JlZywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzIQ0KTXkgYW5zd2Vycy9leHBsYW5hdGlvbnMgYXJlIGlubGluZSBiZWxvdy4NCg0KQmVzdCBS ZWdhcmRzLA0KSHVhaW1vDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgR3JlZ29yeSBNaXJza3kNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkg MDUsIDIwMTQgNDo0NiBQTQ0KVG86IGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0 aW9uQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1jaGVuLW1wbHMtcDJtcC1lZ3Jlc3MtcHJv dGVjdGlvbkB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtY2hlbi1tcGxzLXAybXAtZWdy ZXNzLXByb3RlY3Rpb24tMTANCg0KRGVhciBBdXRob3JzLCBldC4gYWwsDQpwbGVhc2UgZmluZCBt eSBjb21tZW50cyB0byB0aGUgbGF0ZXN0IHZlcnNpb24gYmVsb3c6DQrCtyAgICAgICAgIEludHJv ZHVjdGlvbi4gIiBUaGUgbWFpbiBkaXNhZHZhbnRhZ2Ugb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0 IG1vcmUgbmV0d29yayByZXNvdXJjZXMgc3VjaCBhcyBkb3VibGUgYmFuZHdpZHRocyBtYXkgYmUg dXNlZC4iIEkgYmVsaWV2ZSB0aGF0IGNhbiBiZSBlYXNpbHkgYXZvaWRlZCBpZiBTaGFyZWQgZXhw bGljaXQgZmlsdGVyc3BlYyB1c2VkIHNpZ25hbGluZyB3b3JraW5nIGFuZCBwcm90ZWN0aW5nIExT UHMgc28gdGhhdCBib3RoIGNvdWxkIHNoYXJlIEJXIHJlc291cmNlcyBvZiBjb21tb24gbGlua3Mu IElmIHRoYXQgaXMgdGhlIG1haW4gbW90aXZhdGlvbiBmb3IgdGhlIHByb3Bvc2VkIGV4dGVuc2lv bnMsIEkgZG9uJ3Qgc2VlIGl0IGFzIHN1ZmZpY2llbnRseSBzdHJvbmcgY2FzZS4NCkh1YWltbzog SW4gdGhlIGNhc2UgdGhhdCB0aGUgcHJpbWFyeSBMU1AgaXMgZnJvbSBhbiBpbmdyZXNzIG5vZGUg QSB0byBhIG51bWJlciBvZiBlZ3Jlc3Mgbm9kZXMgYW5kIHRoZSBzdGFuZGJ5IExTUCBpcyBmcm9t IGEgYmFja3VwIGluZ3Jlc3Mgbm9kZSBCIChub3RlIHRoYXQgQSBpcyBkaWZmZXJlbnQgZnJvbSBC KSwgaXQgc2VlbXMgdGhhdCB0aGUgc2hhcmVkIGV4cGxpY2l0IFJTVlAgcmVzZXJ2YXRpb24gc3R5 bGUgZG9lcyBub3Qgd29yayBpbiB0aGlzIGNhc2UuICBUaGUgcHJpbWFyeSBMU1AgY2FuIG5vdCBz aGFyZSBpdHMgYmFuZHdpZHRoIHdpdGggdGhlIHN0YW5kYnkgTFNQIHNpbmNlIHRoZXkgYXJlIHR3 byBkaWZmZXJlbnQgTFNQIHR1bm5lbHMgc3RhcnRpbmcgZnJvbSB0d28gZGlmZmVyZW50IGluZ3Jl c3Mgbm9kZXMuDQpHSU0+PiBUaGF0IG1heSBiZSB2YWxpZCBjYXNlIGJ1dCBJIGRvbuKAmXQgc2Vl IHdoYXQgdHlwZSBvZiBjb29yZGluYXRpb24gaXMgcmVxdWlyZWQgdGhlbi4gQW5kIG1vcmUgcXVl c3Rpb25zIHRvIHRoaXMgdXNlIGNhc2U6DQoNCsK3ICAgICAgICAgd2hlcmUgaXMgUExSIHRoYXQg bW9uaXRvcnMgZWdyZXNz4oCZIHdlbGwtYmVpbmcNCg0KwrcgICAgICAgICBpZiBuZXR3b3JrIGlz IHRpZ2h0bHkgY29udHJvbGxlZCwgd2lsZGNhcmQgcmVzZXJ2YXRpb24gbWF5IGJlIEJXIGNvbnNl cnZhdGlvbiBtZWFzdXJlDQrCtyAgICAgICAgIFNlY3Rpb24gMS4xIOKAnFRoZSBmYWlsdXJlIG9m IGEgcHJpbWFyeSBlZ3Jlc3MgKGUuZy4sIEwxIGluIHRoZSBmaWd1cmUpIE1BWSBiZSBkZXRlY3Rl ZCBieSBpdHMgdXBzdHJlYW0gbm9kZSAoZS5nLiwgUjMgaW4gdGhlIGZpZ3VyZSkgdGhyb3VnaCBh IEJGRCBzZXNzaW9uIGJldHdlZW4gdGhlIHVwc3RyZWFtIG5vZGUgYW5kIHRoZSBlZ3Jlc3MgaW4g TVBMUyBuZXR3b3Jrcy7igJ0gSWYgbW9uaXRvcmVkIHBhdGggaXMgbGltaXRlZCB0byBzZWdtZW50 IGJldHdlZW4gUjMgYW5kIEwxLCB0aGVuIGZhaWx1cmUgb2YgTDEgdG8gZm9yd2FyZCB0cmFmZmlj IHRvIENFMSBvciBDRTEgdG8gcmVjZWl2ZSBmcm9tIEwxIHdvdWxkIG5vdCBiZSBkZXRlY3RlZC4g SXMgc3VjaCBsaW1pdGVkIHNjb3BlIHJlYWxseSB1c2VmdWw/DQpIdWFpbW86IEluIGFkZGl0aW9u IHRvIGRldGVjdGluZyB0aGUgZmFpbHVyZSBvZiBhIHByaW1hcnkgZWdyZXNzIHN1Y2ggYXMgTDEg aW4gdGhlIGZpZ3VyZSwgd2UgdGFsa2VkIGFib3V0IGRldGVjdGluZy9tb25pdG9yaW5nIHRoZSBv dGhlciBwYXJ0cyBzdWNoIGFzIHRob3NlIHlvdSBtZW50aW9uZWQgYWJvdmUgaW4gSUVURiBNUExT IHdvcmtpbmcgZ3JvdXAgbWVldGluZ3MuIERldGVjdGluZy9tb25pdG9yaW5nIHRoZXNlIHBhcnRz IGNhbiBiZSBkZWNpZGVkIGxvY2FsbHkgYnkgb3BlcmF0b3JzLiBJdCBzZWVtcyB0aGF0IHRoZXJl IGlzIG5vIGltcGFjdCBvbiB0aGUgTVBMUyBwcm90b2NvbHMuDQpHSU0+PiBXZeKAmXZlIGRpc2N1 c3NlZCBpc3N1ZXMgcmVsYXRlZCB0byBtb25pdG9yaW5nIGNvbnRpbnVpdHkgYmV0d2VlbiBSMSBh bmQgQ0UxIG92ZXIgTDEuIFRydWUsIGl0IHdvdWxkIGFkZHJlc3MgbW9yZSBmYWlsdXJlIHNjZW5h cmlvcyBidXQsIElNTywgd291bGQgaW50cm9kdWNlIHNldmVyYWwgcHJvYmxlbXMgb2YgaXRzIG93 bjoNCg0KwrcgICAgICAgICBzZWN1cml0eSDigJMgQ1BFIGRldmljZSBtdXN0IGhhdmUgY29ubmVj dGl2aXR5IHdlbGwgaW50byBwcm92aWRlcuKAmXMgZG9tYWluOw0KDQrCtyAgICAgICAgIGVuc3Vy aW5nIHRoYXQgT0FNIGZvbGxvd3MgQ0UxLUwxLVIxIHBhdGggaW4gYm90aCBkaXJlY3Rpb25zLg0K QmVjYXVzZSBvZiB0aGVzZSBpc3N1ZXMsIEkgc3RpbGwgYmVsaWV2ZSB0aGF0IGl0IGlzIGJldHRl ciB0byBzcGxpdCBwcm90ZWN0aW9uIHRhc2sgaW4gdHdvIGRvbWFpbnM6DQoNCsK3ICAgICAgICAg TFNQIHByb3RlY3Rpb24g4oCTIGUyZSBvciBsb2NhbA0KDQrCtyAgICAgICAgIGFjY2VzcyBsaW5r IHByb3RlY3Rpb24g4oCTIG11bHRpLWhvbWluZywgTUMtTEFHDQoNClJlZ2FyZHMsDQogICAgICAg IEdyZWcNCg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B75F307eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLmVtYWlscXVvdGUsIGxpLmVtYWlscXVvdGUsIGRpdi5lbWFpbHF1b3RlDQoJe21z by1zdHlsZS1uYW1lOmVtYWlscXVvdGU7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDoxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTkzOTAwMjU5 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODQyMTMz Nzg0IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjg4NDM2NjU1NTsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI5Mzk3Njg1 NiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo5NTkyNTg4MTQ7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTc4NDE0MDU0 IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE1NjI5MDUyNTM7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjUxMTczMDgzMjt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDM6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBIdWFpbW8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPm1hbnkgdGhhbmtzIGZvciB0aGUgbW9zdCBleHBlZGllbnQgcmVzcG9uc2UgYW5kIHRob3Jv dWdoIGNvbnNpZGVyYXRpb24gb2YgbXkgY29tbWVudHMuIFBsZWFzZSBmaW5kIGNvdXBsZSBub3Rl cyBpbi1saW5lZCBhbmQgdGFnZ2VkIGJ5IEdJTSZndDsmZ3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSHVhaW1vIENo ZW4gW21haWx0bzpodWFpbW8uY2hlbkBodWF3ZWkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgODozOSBQTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29y eSBNaXJza3k7IGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uQHRvb2xzLmll dGYub3JnOyBtcGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBDb21tZW50cyB0 byBkcmFmdC1jaGVuLW1wbHMtcDJtcC1lZ3Jlc3MtcHJvdGVjdGlvbi0xMDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5EZWFyIEdyZWcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBhbnN3ZXJzL2V4cGxhbmF0aW9u cyBhcmUgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C ZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkh1YWltbzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbXBscyBbPGEgaHJlZj0ibWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNDo0NiBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnIj4NCmRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPg0KbXBsc0BpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LWNoZW4tbXBs cy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uLTEwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGVh ciBBdXRob3JzLCBldC4gYWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5wbGVhc2Ug ZmluZCBteSBjb21tZW50cyB0byB0aGUgbGF0ZXN0IHZlcnNpb24gYmVsb3c6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1i b2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkludHJvZHVjdGlvbi4gJnF1b3Q7IFRoZSBtYWlu IGRpc2FkdmFudGFnZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgbW9yZSBuZXR3b3JrIHJlc291 cmNlcyBzdWNoIGFzIGRvdWJsZSBiYW5kd2lkdGhzIG1heSBiZSB1c2VkLiZxdW90OyBJIGJlbGll dmUgdGhhdCBjYW4gYmUgZWFzaWx5IGF2b2lkZWQNCiBpZiBTaGFyZWQgZXhwbGljaXQgZmlsdGVy c3BlYyB1c2VkIHNpZ25hbGluZyB3b3JraW5nIGFuZCBwcm90ZWN0aW5nIExTUHMgc28gdGhhdCBi b3RoIGNvdWxkIHNoYXJlIEJXIHJlc291cmNlcyBvZiBjb21tb24gbGlua3MuIElmIHRoYXQgaXMg dGhlIG1haW4gbW90aXZhdGlvbiBmb3IgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbnMsIEkgZG9uJ3Qg c2VlIGl0IGFzIHN1ZmZpY2llbnRseSBzdHJvbmcgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5IdWFpbW86IEluIHRoZSBjYXNlIHRoYXQgdGhlIHByaW1hcnkgTFNQIGlzIGZy b20gYW4gaW5ncmVzcyBub2RlIEEgdG8gYSBudW1iZXIgb2YgZWdyZXNzIG5vZGVzIGFuZA0KIHRo ZSBzdGFuZGJ5IExTUCBpcyBmcm9tIGEgYmFja3VwIGluZ3Jlc3Mgbm9kZSBCIChub3RlIHRoYXQg QSBpcyBkaWZmZXJlbnQgZnJvbSBCKSwgaXQgc2VlbXMgdGhhdCB0aGUgc2hhcmVkIGV4cGxpY2l0 IFJTVlAgcmVzZXJ2YXRpb24gc3R5bGUgZG9lcyBub3Qgd29yayBpbiB0aGlzIGNhc2UuICZuYnNw O1RoZSBwcmltYXJ5IExTUCBjYW4gbm90IHNoYXJlIGl0cyBiYW5kd2lkdGggd2l0aCB0aGUgc3Rh bmRieSBMU1Agc2luY2UgdGhleSBhcmUgdHdvIGRpZmZlcmVudA0KIExTUCB0dW5uZWxzIHN0YXJ0 aW5nIGZyb20gdHdvIGRpZmZlcmVudCBpbmdyZXNzIG5vZGVzLiAmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5HSU0mZ3Q7Jmd0OyBUaGF0IG1heSBiZSB2YWxpZCBjYXNlIGJ1 dCBJIGRvbuKAmXQgc2VlIHdoYXQgdHlwZSBvZiBjb29yZGluYXRpb24gaXMgcmVxdWlyZWQgdGhl bi4gQW5kIG1vcmUNCiBxdWVzdGlvbnMgdG8gdGhpcyB1c2UgY2FzZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj53aGVyZSBpcyBQTFIgdGhhdCBtb25p dG9ycyBlZ3Jlc3PigJkgd2VsbC1iZWluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs MSBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmlmIG5ldHdvcmsgaXMgdGlnaHRseSBjb250cm9sbGVkLCB3aWxk Y2FyZCByZXNlcnZhdGlvbiBtYXkgYmUgQlcgY29uc2VydmF0aW9uIG1lYXN1cmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlY3Rpb24gMS4xIOKAnFRoZSBmYWlsdXJlIG9mIGEgcHJp bWFyeSBlZ3Jlc3MgKGUuZy4sIEwxIGluIHRoZSBmaWd1cmUpIE1BWSBiZSBkZXRlY3RlZCBieSBp dHMgdXBzdHJlYW0gbm9kZSAoZS5nLiwgUjMgaW4gdGhlIGZpZ3VyZSkgdGhyb3VnaCBhIEJGRCBz ZXNzaW9uIGJldHdlZW4NCiB0aGUgdXBzdHJlYW0gbm9kZSBhbmQgdGhlIGVncmVzcyBpbiBNUExT IG5ldHdvcmtzLuKAnSBJZiBtb25pdG9yZWQgcGF0aCBpcyBsaW1pdGVkIHRvIHNlZ21lbnQgYmV0 d2VlbiBSMyBhbmQgTDEsIHRoZW4gZmFpbHVyZSBvZiBMMSB0byBmb3J3YXJkIHRyYWZmaWMgdG8g Q0UxIG9yIENFMSB0byByZWNlaXZlIGZyb20gTDEgd291bGQgbm90IGJlIGRldGVjdGVkLiBJcyBz dWNoIGxpbWl0ZWQgc2NvcGUgcmVhbGx5IHVzZWZ1bD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IdWFpbW86IEluIGFkZGl0aW9uIHRvIGRldGVjdGluZyB0aGUgZmFpbHVyZSBvZiBh IHByaW1hcnkgZWdyZXNzIHN1Y2ggYXMgTDEgaW4gdGhlIGZpZ3VyZSwgd2UgdGFsa2VkDQogYWJv dXQgZGV0ZWN0aW5nL21vbml0b3JpbmcgdGhlIG90aGVyIHBhcnRzIHN1Y2ggYXMgdGhvc2UgeW91 IG1lbnRpb25lZCBhYm92ZSBpbiBJRVRGIE1QTFMgd29ya2luZyBncm91cCBtZWV0aW5ncy4gRGV0 ZWN0aW5nL21vbml0b3JpbmcgdGhlc2UgcGFydHMgY2FuIGJlIGRlY2lkZWQgbG9jYWxseSBieSBv cGVyYXRvcnMuIEl0IHNlZW1zIHRoYXQgdGhlcmUgaXMgbm8gaW1wYWN0IG9uIHRoZSBNUExTIHBy b3RvY29scy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HSU0mZ3Q7Jmd0OyBXZeKA mXZlIGRpc2N1c3NlZCBpc3N1ZXMgcmVsYXRlZCB0byBtb25pdG9yaW5nIGNvbnRpbnVpdHkgYmV0 d2VlbiBSMSBhbmQgQ0UxIG92ZXIgTDEuIFRydWUsIGl0DQogd291bGQgYWRkcmVzcyBtb3JlIGZh aWx1cmUgc2NlbmFyaW9zIGJ1dCwgSU1PLCB3b3VsZCBpbnRyb2R1Y2Ugc2V2ZXJhbCBwcm9ibGVt cyBvZiBpdHMgb3duOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7C tzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPnNlY3VyaXR5IOKAkyBDUEUgZGV2aWNlIG11c3QgaGF2ZSBjb25uZWN0aXZpdHkgd2Vs bCBpbnRvIHByb3ZpZGVy4oCZcyBkb21haW47PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+ZW5zdXJpbmcgdGhhdCBPQU0gZm9sbG93cyBDRTEtTDEtUjEg cGF0aCBpbiBib3RoIGRpcmVjdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QmVjYXVzZSBvZiB0aGVzZSBpc3N1ZXMsIEkgc3RpbGwgYmVsaWV2ZSB0aGF0IGl0IGlzIGJldHRl ciB0byBzcGxpdCBwcm90ZWN0aW9uIHRhc2sgaW4gdHdvIGRvbWFpbnM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TFNQIHByb3RlY3Rpb24g4oCTIGUy ZSBvciBsb2NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm81Ij4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7Ctzxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPmFjY2VzcyBsaW5rIHByb3RlY3Rpb24g4oCTIG11bHRpLWhvbWluZywgTUMtTEFHPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B75F307eusaamb103erics_-- From tsaad@cisco.com Thu Feb 6 09:49: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 477AF1A03E1 for ; Thu, 6 Feb 2014 09:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 PjHqJvtY61HR for ; Thu, 6 Feb 2014 09:49:44 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 441841A00EA for ; Thu, 6 Feb 2014 09:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2577; q=dns/txt; s=iport; t=1391708983; x=1392918583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Raf3KDxDuD088alff9MnaI9/MAULL1sZOdq7xrmDl0Y=; b=bSWTlJyTI6R4GNMYSwnZSc82UyX1oN87hp54CDc6v3mr5K6vVK68jD60 ggBa5lq4fVzr4AyEj5yOGZox2BQkWTxKlC6pH1/m8aBpILVjkwo3ndRa7 kDi35SoP5Eqjmfl8WbcffckFcKzvLS6Qf6qUGk6566VoOyKXFs9vN3ASZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFABvK81KtJV2c/2dsb2JhbABZgww4V75xgQwWdIIlAQEBBAEBARoKEzEDCw4CAgEIGB4QGwYGCyUCBA4Fh3EDEQ3ERA2IahMEBIxggTQRAVAHhDgElj+BbIxehUODLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="302340840" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 06 Feb 2014 17:49:43 +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 s16HngXi008857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 17:49:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 11:49:42 -0600 From: "Tarek Saad (tsaad)" To: "Andrew G. Malis" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-extended-admin-group Thread-Index: AQHPI1lvKVihJZqYOkiIWLXvq52Q3Zqo3LoA//+09oA= Date: Thu, 6 Feb 2014 17:49:42 +0000 Message-ID: References: <52F08085.9000907@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.86.242.246] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 17:49:46 -0000 In case of inconsistency, see 3 options: 1. use AG and discard EAG, i.e. ignore subsequent bits in (EAG) 2. use AG for first word and subsequent bits from EAG bits 3. use EAG and discard AG The way the draft puts it is EAG is a "superset" of AG. I'm in favour of 3) when router speaks/understands EAG. Just as it is true that for routers that speak/understand only AG, they'd use AG. Note, my understanding is AG at sometime will become obsolete and eventually most (if not all) routers will be speaking EAG. Regards, Tarek=20 On 2014-02-06 12:18 PM, "Andrew G. Malis" wrote: >Tarek, > >In my earlier review, I argued the opposite for section 2.3.1, that AG >MUST take priority over EAG for backwards compatibility. See my email >for my reasoning. > >Cheers, >Andy > >On Thu, Feb 6, 2014 at 11:35 AM, Tarek Saad (tsaad) >wrote: >> Hi, >> >> This document looks good, and addresses a real limitation with existing >> AGs. I think it is ready for publication. Few comments: >> - section 2.3.1: prefer rewording to explicitly spell the behaviour on a >> receiving node that supports EAG.. example, "... EAG MUST take priority >>on >> a receiving node that supports it." >> >> >> minor edit comments: >> - section 1, might want to define LSA, MTU before use >> - section 2.3.2 equally applicable to AG too; maybe re-title as "Desire >> for unadvertised bits for AG/EAG"? >> - typo in Section 2.3.2, "... assumption is than" -> "assumption is >>that" >> >> Regards, >> >> Tarek >> >> On 2014-02-04 12:54 AM, "Loa Andersson" wrote: >> >>>Working Group, >>> >>>This is to initiate a working group last call on >>>draft-ietf-mpls-extended-admin-group-02. >>> >>>There are no IPR disclosures against this document. The author has >>>stated that he is unaware of any 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 Feb 18, 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 >>>_______________________________________________ >>>mpls mailing list >>>mpls@ietf.org >>>https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Thu Feb 6 10:07: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 E147D1A01E3 for ; Thu, 6 Feb 2014 10:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw8qPlaPBZBx for ; Thu, 6 Feb 2014 10:07:33 -0800 (PST) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD6E1A018C for ; Thu, 6 Feb 2014 10:07:32 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id ii20so3303789qab.5 for ; Thu, 06 Feb 2014 10:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fFrKOe7zAG+RWy59bRZStrMObfl/YrWcwY1rvVz1PFE=; b=js25TgHL8qdXXNLl27pIZCfHVjCVXnoyJyk03JeIQU4tNGgeLb+piJkLxECJh0hKuW c0oi4KnepL2HPVM/HSG70RO4SyiXWAehkr1FdiV1npX+A6TmUjoecA8Qo6iR9Q9runDQ d1Jh9ogDDU/VZ5ppZqt6lahA8gMukra7IIY5Xvn3nHsNr6XH6YIwiPwbsd47mZAZ4uG6 SwfNTX3BqVBpgcigNYIe5ot5EXX2HbKoy0QJyh32uYPWRKnE0IDBSegOATzcy3arYAnn saxDRa4nXEF5BuXoOat7ZE49YcaYyVmGifVNNSQdWc7BmxoLFqzV1N9RA/qqTD2AjkLf +bbQ== X-Received: by 10.224.87.193 with SMTP id x1mr14793004qal.70.1391710051737; Thu, 06 Feb 2014 10:07:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Thu, 6 Feb 2014 10:06:13 -0800 (PST) In-Reply-To: References: <52F08085.9000907@pi.nu> From: "Andrew G. Malis" Date: Thu, 6 Feb 2014 13:06:13 -0500 Message-ID: To: "Tarek Saad (tsaad)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 18:07:35 -0000 Tarek, Imagine that you have a network that has been using AG and is transitioning to EAG. Since not all routers can be updated simultaneously, there will be a period where some will support both AG and EAG and others will only support AG. As long as AG and the first word of EAG are consistent, everything works well. But if a provisioning or software bug leads to the case where the two are inconsistent, option (2) will operate better than option (3), since with option (2), both old and new routers will be using a consistent set of bits 0-31. Cheers, Andy On Thu, Feb 6, 2014 at 12:49 PM, Tarek Saad (tsaad) wrote: > In case of inconsistency, see 3 options: > 1. use AG and discard EAG, i.e. ignore subsequent bits in (EAG) > 2. use AG for first word and subsequent bits from EAG bits > 3. use EAG and discard AG > > The way the draft puts it is EAG is a "superset" of AG. > > I'm in favour of 3) when router speaks/understands EAG. Just as it is true > that for routers that speak/understand only AG, they'd use AG. > Note, my understanding is AG at sometime will become obsolete and > eventually most (if not all) routers will be speaking EAG. > > > Regards, > Tarek > > On 2014-02-06 12:18 PM, "Andrew G. Malis" wrote: > >>Tarek, >> >>In my earlier review, I argued the opposite for section 2.3.1, that AG >>MUST take priority over EAG for backwards compatibility. See my email >>for my reasoning. >> >>Cheers, >>Andy >> >>On Thu, Feb 6, 2014 at 11:35 AM, Tarek Saad (tsaad) >>wrote: >>> Hi, >>> >>> This document looks good, and addresses a real limitation with existing >>> AGs. I think it is ready for publication. Few comments: >>> - section 2.3.1: prefer rewording to explicitly spell the behaviour on a >>> receiving node that supports EAG.. example, "... EAG MUST take priority >>>on >>> a receiving node that supports it." >>> >>> >>> minor edit comments: >>> - section 1, might want to define LSA, MTU before use >>> - section 2.3.2 equally applicable to AG too; maybe re-title as "Desire >>> for unadvertised bits for AG/EAG"? >>> - typo in Section 2.3.2, "... assumption is than" -> "assumption is >>>that" >>> >>> Regards, >>> >>> Tarek >>> >>> On 2014-02-04 12:54 AM, "Loa Andersson" wrote: >>> >>>>Working Group, >>>> >>>>This is to initiate a working group last call on >>>>draft-ietf-mpls-extended-admin-group-02. >>>> >>>>There are no IPR disclosures against this document. The author has >>>>stated that he is unaware of any 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 Feb 18, 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 >>>>_______________________________________________ >>>>mpls mailing list >>>>mpls@ietf.org >>>>https://www.ietf.org/mailman/listinfo/mpls >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > From eric.osborne@notcom.com Thu Feb 6 11:06:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02631A00EA for ; Thu, 6 Feb 2014 11:06:55 -0800 (PST) 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 ewlYBa9PhpTs for ; Thu, 6 Feb 2014 11:06:53 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id 90AD51A00C9 for ; Thu, 6 Feb 2014 11:06:53 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wo20so2737112obc.38 for ; Thu, 06 Feb 2014 11:06:52 -0800 (PST) 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=a0sVQULLM6N8b7hpdkzZYtnbtpXJ37VpbwWsutzIqR4=; b=EifsjgP1955E13Z1rxdgHPFoq4dS2roV6h2maw09C0Gkk1ALQzuBWpqrvetksMtT0X ToS8sIx/QQq3Q25hlwuRdzIwpKi7JllESr1/7irl+nIBycdFjh+ejAuqvhF8QeNUqclw HALt+U7Jq0+syDTHCdFYx0XpD7LZ6QhLOjt9DuWT0B55cm5ZFjSqtifMhnCVi88v4K+m 9uo1d5PyZZbOOelS/cDLeRBO9HJDhRCOeU9NDoezbelNh9foSD4D1p1RcD4Q0CQK5FM9 TDwVXD8NiAoTGwB1ukA31eGK7kx7duysCE0ZyFFkNJkgmVHMOlAKkluk81Cz00YBoW37 klSw== X-Gm-Message-State: ALoCoQlHwDJNoxjPF4bANHy778aatzoRsbSkn/o6WoVCZuUblg7Vn+y8+B0ozWlbvmG6KWaUb0xO MIME-Version: 1.0 X-Received: by 10.60.228.135 with SMTP id si7mr8619676oec.4.1391713612287; Thu, 06 Feb 2014 11:06:52 -0800 (PST) Received: by 10.182.135.229 with HTTP; Thu, 6 Feb 2014 11:06:52 -0800 (PST) In-Reply-To: References: <52F08085.9000907@pi.nu> Date: Thu, 6 Feb 2014 14:06:52 -0500 Message-ID: From: Eric Osborne To: "Andrew G. Malis" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 19:06:56 -0000 Hi Andy- So the concern is around how to handle the case where AG doesn't match the first 32 bits of EAG. The current text in 2.3.1 says: "If a node advertises both AG and EAG then the first 32 bits of the EAG MUST be identical to the advertised AG. If the AG and EAG advertised for a link differ, the EAG MUST take priority." I think I can fix this by changing the second sentence to: "If a node advertises both AG and EAG then the first 32 bits of the EAG MUST be identical to the advertised AG. If a receiving node notices that the AG differs from the first 32 bits of the EAG, it SHOULD use the AG as the first 32 bits of the EAG, and MUST indicate this mismatch to the operator." I very deliberately used 'SHOULD' because there is at least one implementation already in production with the current logic and I don't want to obsolete it to cover a corner case that's already illegal and clearly a bug. Does that work? Tarek, does that break anything in what's shipping? eric On Thu, Feb 6, 2014 at 1:06 PM, Andrew G. Malis wrote: > Tarek, > > Imagine that you have a network that has been using AG and is > transitioning to EAG. Since not all routers can be updated > simultaneously, there will be a period where some will support both AG > and EAG and others will only support AG. As long as AG and the first > word of EAG are consistent, everything works well. But if a > provisioning or software bug leads to the case where the two are > inconsistent, option (2) will operate better than option (3), since > with option (2), both old and new routers will be using a consistent > set of bits 0-31. > > Cheers, > Andy > > > On Thu, Feb 6, 2014 at 12:49 PM, Tarek Saad (tsaad) wrote: >> In case of inconsistency, see 3 options: >> 1. use AG and discard EAG, i.e. ignore subsequent bits in (EAG) >> 2. use AG for first word and subsequent bits from EAG bits >> 3. use EAG and discard AG >> >> The way the draft puts it is EAG is a "superset" of AG. >> >> I'm in favour of 3) when router speaks/understands EAG. Just as it is true >> that for routers that speak/understand only AG, they'd use AG. >> Note, my understanding is AG at sometime will become obsolete and >> eventually most (if not all) routers will be speaking EAG. >> >> >> Regards, >> Tarek >> >> On 2014-02-06 12:18 PM, "Andrew G. Malis" wrote: >> >>>Tarek, >>> >>>In my earlier review, I argued the opposite for section 2.3.1, that AG >>>MUST take priority over EAG for backwards compatibility. See my email >>>for my reasoning. >>> >>>Cheers, >>>Andy >>> >>>On Thu, Feb 6, 2014 at 11:35 AM, Tarek Saad (tsaad) >>>wrote: >>>> Hi, >>>> >>>> This document looks good, and addresses a real limitation with existing >>>> AGs. I think it is ready for publication. Few comments: >>>> - section 2.3.1: prefer rewording to explicitly spell the behaviour on a >>>> receiving node that supports EAG.. example, "... EAG MUST take priority >>>>on >>>> a receiving node that supports it." >>>> >>>> >>>> minor edit comments: >>>> - section 1, might want to define LSA, MTU before use >>>> - section 2.3.2 equally applicable to AG too; maybe re-title as "Desire >>>> for unadvertised bits for AG/EAG"? >>>> - typo in Section 2.3.2, "... assumption is than" -> "assumption is >>>>that" >>>> >>>> Regards, >>>> >>>> Tarek >>>> >>>> On 2014-02-04 12:54 AM, "Loa Andersson" wrote: >>>> >>>>>Working Group, >>>>> >>>>>This is to initiate a working group last call on >>>>>draft-ietf-mpls-extended-admin-group-02. >>>>> >>>>>There are no IPR disclosures against this document. The author has >>>>>stated that he is unaware of any 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 Feb 18, 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 >>>>>_______________________________________________ >>>>>mpls mailing list >>>>>mpls@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Thu Feb 6 11:10: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 4AB911A041C for ; Thu, 6 Feb 2014 11:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 Fr8_MFDw62Dg for ; Thu, 6 Feb 2014 11:10:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D056D1A03ED for ; Thu, 6 Feb 2014 11:10:32 -0800 (PST) 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 BDI11872; Thu, 06 Feb 2014 19:10:29 +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; Thu, 6 Feb 2014 19:09:45 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 19:10:28 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 11:10:25 -0800 From: Huaimo Chen To: Francesco Fondelli Thread-Topic: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 Thread-Index: Ac8it3gag8BDTdsTQrCmaY8m+AociAAOW52AAB9JooAABraZ4A== Date: Thu, 6 Feb 2014 19:10:24 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C3575B@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C35557@SJCEML701-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.246.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 19:10:36 -0000 VGhlcmUgYXJlIGEgbnVtYmVyIG9mIGNvbmRpdGlvbnMgZm9yIHR3byBvciBtb3JlIExTUHMgdG8g c2hhcmUgc29tZSBiYW5kd2lkdGhzIG9mIGEgbGluay4gVGhlIGNvbmRpdGlvbnMgaW5jbHVkZToN CjEpIFRoZXkgKHRoZXNlIExTUHMpIGJlbG9uZyB0byBhIHNhbWUgdHVubmVsLCBhbmQNCjIpIFRo ZXkgc2hhcmUgdGhlIHNhbWUgbGluaywgYW5kDQozKSBPbmx5IG9uZSBvZiB0aGVtIHNlbmRzIGRh dGEgdHJhZmZpYyB0byB0aGF0IGxpbmsgYXQgYW55IHRpbWUuDQoNCkZvciB0d28gTFNQcyBzdGFy dGluZyBmcm9tIGRpZmZlcmVudCBpbmdyZXNzIG5vZGVzIHN1Y2ggYXMgbm9kZSBBIGFuZCBub2Rl IEIsIGl0IGlzIHZlcnkgaGFyZCB0byBtYWtlIHRoZW0gYmVsb25nIHRvIGEgc2FtZSB0dW5uZWwu IA0KQSB0dW5uZWwgaXMgaWRlbnRpZmllZCBieSA8UDJNUCBJRC9EZXN0aW5hdGlvbiwgVHVubmVs IElELCBFeHRlbmRlZCBUdW5uZWwgSUQ+LiBTZXR0aW5nIEV4dGVuZGVkIFR1bm5lbCBJRCB0byAw IGluIHRoZSBzZXNzaW9uIG9iamVjdCBvbiBub2RlIEEgYW5kIG5vZGUgQiBmb3IgdHdvIExTUHMg cmVzcGVjdGl2ZWx5IHRvIG1ha2UgdGhlbSBiZWxvbmcgdG8gdGhlIHNhbWUgdHVubmVsIHNlZW1z IG5vdCB3b3JrLiBTZWUgdGhlIHRvcCBwYXJ0IG9mIHBhZ2UgMTMgaW4gUkZDIDMyMDkuIA0KDQpC YXNpY2FsbHksIGEgbm9kZSBpbiB0aGUgbmV0d29yayBuZWVkcyB0byBpZGVudGlmeSBhIHR1bm5l bCB1bmlxdWVseSBmb3IgdHdvIG9yIG1vcmUgTFNQcyB1bmRlciB0aGUgc2FtZSB0dW5uZWwgdG8g c2hhcmUgdGhlIGJhbmR3aWR0aCBvZiBhIGxpbmsuIElmIEV4dGVuZGVkIFR1bm5lbCBJRCBpcyBz ZXQgdG8gMCwgPFAyTVAgSUQvRGVzdGluYXRpb24sIFR1bm5lbCBJRCwgMCBmb3IgRXh0ZW5kZWQg VHVubmVsIElEPiBzZWVtcyBub3QgZW5vdWdoIHRvIGlkZW50aWZ5IGEgdHVubmVsIHVuaXF1ZWx5 IHVubGVzcyBzb21lIGl0ZW1zIHN1Y2ggYXMgMTYtYml0IHR1bm5lbCBJRCBhcmUgbWFkZSBnbG9i YWxseSB1bmlxdWUuICANCg0KQmVzdCBSZWdhcmRzLA0KSHVhaW1vDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRnJhbmNlc2NvIEZvbmRlbGxpIFttYWlsdG86ZnJhbmNlc2NvLmZv bmRlbGxpQGdtYWlsLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgNjow MyBBTQ0KVG86IEh1YWltbyBDaGVuDQpDYzogR3JlZ29yeSBNaXJza3k7IGRyYWZ0LWNoZW4tbXBs cy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVz cy1wcm90ZWN0aW9uLTEwDQoNCkhpLA0KDQpPbiBUaHUsIEZlYiA2LCAyMDE0IGF0IDU6MzggQU0s IEh1YWltbyBDaGVuIDxodWFpbW8uY2hlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4gRGVhciBHcmVn LA0KDQpbY3V0XQ0KDQo+IEh1YWltbzogSW4gdGhlIGNhc2UgdGhhdCB0aGUgcHJpbWFyeSBMU1Ag aXMgZnJvbSBhbiBpbmdyZXNzIG5vZGUgQSB0byANCj4gYSBudW1iZXIgb2YgZWdyZXNzIG5vZGVz IGFuZCB0aGUgc3RhbmRieSBMU1AgaXMgZnJvbSBhIGJhY2t1cCBpbmdyZXNzIA0KPiBub2RlIEIg KG5vdGUgdGhhdCBBIGlzIGRpZmZlcmVudCBmcm9tIEIpLCBpdCBzZWVtcyB0aGF0IHRoZSBzaGFy ZWQgDQo+IGV4cGxpY2l0IFJTVlAgcmVzZXJ2YXRpb24gc3R5bGUgZG9lcyBub3Qgd29yayBpbiB0 aGlzIGNhc2UuICBUaGUgDQo+IHByaW1hcnkgTFNQIGNhbiBub3Qgc2hhcmUgaXRzIGJhbmR3aWR0 aCB3aXRoIHRoZSBzdGFuZGJ5IExTUCBzaW5jZSANCj4gdGhleSBhcmUgdHdvIGRpZmZlcmVudCBM U1AgdHVubmVscyBzdGFydGluZyBmcm9tIHR3byBkaWZmZXJlbnQgaW5ncmVzcyBub2Rlcy4NCg0K T2gsIHRoaXMgaXMgaW4gbXkgc3RpbGwtaGF2ZS10by1iZS11bmRlcnN0b29kLXF1ZXVlIHNpbmNl IGEgd2hpbGUuLi4NCg0KU0Utc3R5bGUgcmVzZXJ2YXRpb24gY3JlYXRlcyBhIHNpbmdsZSByZXNl cnZhdGlvbiBzaGFyZWQgYnkgc2VsZWN0ZWQgdXBzdHJlYW0gc2VuZGVyKnMqIChJIGRvIG5vdCB0 aGluayB0aGV5IGhhdmUgdG8gYmUgYmUgb24gdGhlIHNhbWUNCm5vZGUpIHdpdGhpbiBhIGdpdmVu IHNlc3Npb24gW1JGQzIyMDVdLiAgSW4gYSBwMm1wIHNjZW5hcmlvIGEgc2Vzc2lvbiBpcyBpZGVu dGlmaWVkIGJ5IHRoZSB0dXBsZSAoUDJNUCBJRCwgVHVubmVsIElELCBFeHRlbmRlZCBUdW5uZWwg SUQpIFtSRkM0ODc1XS4gIElmIGluZ3Jlc3Mgbm9kZXMgQSBhbmQgQiB1c2UgdGhlIHNhbWUgUDJN UCBJRCAqYW5kKiB0aGUgc2FtZSBUdW5uZWwgSUQgKmFuZCogMCBhcyBFeHRlbmRlZCBUdW5uZWwg SUQgKGl0IGlzIG5vcm1hbGx5IHNldCB0byBhIHZhbHVlICE9IDAgYnkgaW5ncmVzcyBub2RlcyB0 aGF0IHdpc2ggdG8gKm5hcnJvdyogdGhlIHNjb3BlIG9mIGEgc2Vzc2lvbiB0byB0aGUgaW5ncmVz cy1lZ3Jlc3MgcGFpciBbUkZDMzIwOV0sIHRob3VnaCBpbiB0aGlzIGNhc2Ugd2Ugd2FudCB0aGUg b3Bwb3NpdGUpIHByaW1hcnkgYW5kIHN0YW5kYnkgTFNQcyB3aWxsIHNoYXJlIHRoZSBzYW1lIHJl c291cmNlcyBhbG9uZyBjb21tb24gbGlua3Mvbm9kZXMuICBIb3cgbm9kZXMgQSBhbmQgQiBzaGFy ZXMgUDJNUCBJRCBhbmQgVHVubmVsIElEIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZW1h aWwgOi0pLCBJIGd1ZXNzIG1hbnVhbCBjb25maWd1cmF0aW9uIG1pZ2h0IGJlIGEgcG9zc2liaWxp dHkuDQoNClRoaXMgaXMgbXkgdW5kZXJzdGFuZGluZy4gIEFDSy9OQUNLIHdvdWxkIGJlIG11Y2gg YXBwcmVjaWF0ZWQgKG5vdCBzdXJlIGFsbCBJIHNhaWQgaXMgMTAwJSBjb3JyZWN0IG9yIEkgbWlz c2VkIHNvbWV0aGluZykuDQoNCnRoYW5rIHlvdQ0KY2lhbw0KZnJhDQoNClBTDQp0aGlzIHBvc3Np YmlsaXR5IGZvciB0aGUgcDJwIGNhc2UgaXMgbWVudGlvbmVkIGluIFJGQzMyMDkgc2VjdGlvbg0K Mi40LjMgIlNFIHN0eWxlIHJlc2VydmF0aW9ucyBjYW4gYmUgcHJvdmlkZWQgdXNpbmcgbXVsdGlw b2ludC10by1wb2ludCBsYWJlbC1zd2l0Y2hlZC1wYXRoIG9yIExTUCBwZXIgc2VuZGVyLi4uIg0K From eric.osborne@notcom.com Thu Feb 6 11:14: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 E4F811A044C for ; Thu, 6 Feb 2014 11:14:10 -0800 (PST) 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 Yhd4VZXeyFUF for ; Thu, 6 Feb 2014 11:14:07 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 523381A03E4 for ; Thu, 6 Feb 2014 11:14:07 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id vb8so2752082obc.17 for ; Thu, 06 Feb 2014 11:14:06 -0800 (PST) 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=znOnjHx6YA/rJyKDCc8COzmzV2vomY1k3FT+Cf5tYbI=; b=h4ZcarvoqBF44flI4PmWeFdtbH62GDUNO9VCVCIJO76a6eDwbYrb10vTEU1E8vnsPi o4r/EMy9WXqOe4RKhliNzpjsc6xUQsTVrhgA2nXaZ9HGdYV4Jfxm2Q83+fH2EcYLWVZq Ig3unjdxD6m3TC8RdeAUZAbJ+lRfqdsMmz1fDisaFjmssZfzoMV6Gl9+yocRNYQOSFKO Xu0yie6a/YJ2PeGAPWRhuxz4szrGZyOOaOALBBtveyysEbcZ8I6MDOytersY+rB9VMHC XK/pTtU40xfTPPKwh2a8Mot0IaErvAP3txTK1yX226qLo/i/JjsQqaAQwqzP++7oJ0u0 kvNg== X-Gm-Message-State: ALoCoQlsBDkmHd6MD5v7+2AAO1OeFs9XvBeyjigK/7j4biaMFDa4omiWNPy9d0bxu4PvJkFDcD19 MIME-Version: 1.0 X-Received: by 10.182.142.229 with SMTP id rz5mr8793779obb.12.1391714046091; Thu, 06 Feb 2014 11:14:06 -0800 (PST) Received: by 10.182.135.229 with HTTP; Thu, 6 Feb 2014 11:14:05 -0800 (PST) In-Reply-To: References: <52F08085.9000907@pi.nu> Date: Thu, 6 Feb 2014 14:14:05 -0500 Message-ID: From: Eric Osborne To: "Andrew G. Malis" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-extended-admin-group@tools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 19:14:11 -0000 Hi Andy- Inline with EO# On Tue, Feb 4, 2014 at 2:39 PM, Andrew G. Malis wrote: > I was asked by the WG chairs for a WG LC review of this draft. In > general, the draft is ready for publication, but I do have a few > comments. > > [Editorial] Section 1: There are several unbracketed RFC references > that are in the actual list of references, and thus should be in > brackets in the text. > EO# ACK, will fix. > [Technical] Section 2.2: The numbering of the EAG's first word of bits > is discussed, but the numbering of the bits in subsequent words is not > described. It can be implied that the bit numbering will continue at > 32 with the LSB of the second word of the EAG, but that is not > actually stated. > EO# ACK, will fix. > [Technical] Section 2.3.1: It is easy to predict that routers or > software loads that implement the EAG will be deployed in the same > network as those that only implement the AG. It can be expected that > routers that do not implement the EAG will simply ignore that > particular sub-TLG. Thus, those routers, upon receipt of both the AG > and EAG sub-TLVs, will ignore the EAG and use the AG. Thus, for > improved backwards compatibility, if the AG and EAG co-exist and the > AG is inconsistent with the first word of the EAG, it would seem that > the AG should take precedence. This is the opposite of what is stated > in the draft. > > Of course, once all of the routers in a network support the EAG, the > AG will be unnecessary and only the EAG will be used. > EO# I sent a separate email on this. > [Technical] Section 2.3.2: I'm personally hard-pressed to find > usefulness in the flexibility in this section. For maximum > interoperability and simplicity of implementations, I would prefer > that the third paragraph be modified to say: > > To encourage maximum interoperability an > implementation MUST treat desired but unadvertised EAG bits as if > they are set to 0. Consider the case where a node wants to only use > links where the 127th bit of an EAG is set to 1. If a link is only > advertising 64 EAG bits, clearly the 127th EAG bit is not defined - > that is, it is neither explicitly 0 nor 1. The node which wants the > 127th EAG bit to be 1 MUST NOT use this link, as the assumption is > than an unadvertised bit is set to 0. > EO# That works for me; you're basically doing s/SHOULD/MUST/. Tarek? Thoughts? > and also completely remove the following paragraph. > > [Technical] Section 3 contains a lot of unattributed hand-waving. I > would prefer that is simply say: > > Signaling EAG in RVSP is not addressed in this document. Addressing > this in the future is not precluded. > EO# Yeah, there's a lot of history there. I used to get blasted for not having enough justification for doing certain things in this draft and now it looks like I'm in trouble for having too much. :) I don't much care what that section says - if nobody else cares to take a position opposite yours then I'll change it. > [Technical] Section 4: While the existing text is strictly true, > having available a virtually unlimited set of AGs does make it more > important for network administrations that want their traffic > engineering to operate correctly to be careful with their AG > allocation and usage, to avoid unintended side-effects of > unconstrained AG usage or router misconfiguration. What may have been > a relatively easy task with 32 AGs may be more difficult with 128, or > 1000, or 1,000,000 attributes. Previously manual processes may need to > be automated to ensure correctness. Feel free to add text to this > effect to this section, or not, as you prefer. > EO# IMO it doesn't belong. Reminding operators that they may need to manage things carefully as they scale seems awfully nanny-state-ish and not unique to EAG. thanks! eric > Thanks, > Andy > > > > On Tue, Feb 4, 2014 at 12:54 AM, Loa Andersson wrote: >> Working Group, >> >> This is to initiate a working group last call on >> draft-ietf-mpls-extended-admin-group-02. >> >> There are no IPR disclosures against this document. The author has >> stated that he is unaware of any 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 Feb 18, 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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Thu Feb 6 11:24:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53EA1A041C for ; Thu, 6 Feb 2014 11:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmGARCjUhF4x for ; Thu, 6 Feb 2014 11:24:24 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id A1BC81A03EE for ; Thu, 6 Feb 2014 11:24:24 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so2085350pde.41 for ; Thu, 06 Feb 2014 11:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=v6MAY9BYCDLAzHk6UQGCkd+WeeqET70XmaKhT1NNuX4=; b=GodkFQJGDmaAJ0YwqM7EDapcvYur2+qaoMVNTIIkS/Bfen8TSOvoWACTvmmGkDk7gE P53YwOa8E2aldrKtASU1PeYeWYe3fgzAr1pLsWn3DM7xlLYqHPeM3/aOmWy+D+nUubgC D5qBysrXdm8kvIzdAZko6/hazmmRHUOXrmPt1+i6hK4yrKdQ+XRQLSg2ZTg2hSMhQyps VoqE9GiLvIOvvaRco/7n1bi2hY5ILRuIkdD/nwwNn997CY5bo5ZAvEVse/W4B2uAyNKA sgMEmb8qfjfdWcyl3AD6egHlt2SkhMe531YCz4x8eDd4GQ2mBi8s/QDV1rzMfx5XGNtW 7o9Q== X-Received: by 10.68.228.138 with SMTP id si10mr14527929pbc.13.1391714663429; Thu, 06 Feb 2014 11:24:23 -0800 (PST) Received: from [192.168.1.6] (c-107-3-154-8.hsd1.ca.comcast.net. [107.3.154.8]) by mx.google.com with ESMTPSA id qh2sm13685962pab.13.2014.02.06.11.24.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 11:24:22 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_71E1647F-6F3D-4239-A62C-853A76ACEF59" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sam Aldrin In-Reply-To: Date: Thu, 6 Feb 2014 11:24:20 -0800 Message-Id: References: <52F08085.9000907@pi.nu> To: "eosborne (eosborne)" X-Mailer: Apple Mail (2.1827) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-extended-admin-group@tools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 19:24:28 -0000 --Apple-Mail=_71E1647F-6F3D-4239-A62C-853A76ACEF59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Was asked by WG chairs to review the document as part of LC. The document is concise and clear. Would like the comments below = addressed prior to publication. Some/all of the comments might be a repeat of what others might have = already raised (I didn=92t read any of those). So, bear with me. -Please add Terminology section and identify terms there. - Not all RFC=92s referenced are not bracketed.=20 - In section 2.3.1, it says, for eventual migration away from AG. Does = that mean, at some point a node will stop advertising AG? If so, when = and how? i.e. how does a one know the network has fully migrated to EAG, = so nodes could stop advertising AG. A little more clarity to section = should help. - When this new sub-TLV is received on a node and it doesn=92t = understand, what does it do? safely ignore or report its = incompatibility? - Typo "as the assumption is than an unadvertised bit is set to 0=94 - In sec 3. concludes that this work may happen in future if necessary. = Hence, I would like the following sentence to be removed/reworded, "It = is thus likely that signaling EAG in a SESSION_ATTRIBUTE would see virtually no deployment.=94 cheers -sam On Feb 4, 2014, at 11:39 AM, Andrew G. Malis wrote: > I was asked by the WG chairs for a WG LC review of this draft. In > general, the draft is ready for publication, but I do have a few > comments. >=20 > [Editorial] Section 1: There are several unbracketed RFC references > that are in the actual list of references, and thus should be in > brackets in the text. >=20 > [Technical] Section 2.2: The numbering of the EAG's first word of bits > is discussed, but the numbering of the bits in subsequent words is not > described. It can be implied that the bit numbering will continue at > 32 with the LSB of the second word of the EAG, but that is not > actually stated. >=20 > [Technical] Section 2.3.1: It is easy to predict that routers or > software loads that implement the EAG will be deployed in the same > network as those that only implement the AG. It can be expected that > routers that do not implement the EAG will simply ignore that > particular sub-TLG. Thus, those routers, upon receipt of both the AG > and EAG sub-TLVs, will ignore the EAG and use the AG. Thus, for > improved backwards compatibility, if the AG and EAG co-exist and the > AG is inconsistent with the first word of the EAG, it would seem that > the AG should take precedence. This is the opposite of what is stated > in the draft. >=20 > Of course, once all of the routers in a network support the EAG, the > AG will be unnecessary and only the EAG will be used. >=20 > [Technical] Section 2.3.2: I'm personally hard-pressed to find > usefulness in the flexibility in this section. For maximum > interoperability and simplicity of implementations, I would prefer > that the third paragraph be modified to say: >=20 > To encourage maximum interoperability an > implementation MUST treat desired but unadvertised EAG bits as if > they are set to 0. Consider the case where a node wants to only use > links where the 127th bit of an EAG is set to 1. If a link is only > advertising 64 EAG bits, clearly the 127th EAG bit is not defined - > that is, it is neither explicitly 0 nor 1. The node which wants the > 127th EAG bit to be 1 MUST NOT use this link, as the assumption is > than an unadvertised bit is set to 0. >=20 > and also completely remove the following paragraph. >=20 > [Technical] Section 3 contains a lot of unattributed hand-waving. I > would prefer that is simply say: >=20 > Signaling EAG in RVSP is not addressed in this document. Addressing > this in the future is not precluded. >=20 > [Technical] Section 4: While the existing text is strictly true, > having available a virtually unlimited set of AGs does make it more > important for network administrations that want their traffic > engineering to operate correctly to be careful with their AG > allocation and usage, to avoid unintended side-effects of > unconstrained AG usage or router misconfiguration. What may have been > a relatively easy task with 32 AGs may be more difficult with 128, or > 1000, or 1,000,000 attributes. Previously manual processes may need to > be automated to ensure correctness. Feel free to add text to this > effect to this section, or not, as you prefer. >=20 > Thanks, > Andy >=20 >=20 >=20 > On Tue, Feb 4, 2014 at 12:54 AM, Loa Andersson wrote: >> Working Group, >>=20 >> This is to initiate a working group last call on >> draft-ietf-mpls-extended-admin-group-02. >>=20 >> There are no IPR disclosures against this document. The author has >> stated that he is unaware of any IPRs that relate to this document. >>=20 >> Please send your comments to the mpls wg mailing list = (mpls@ietf.org). >>=20 >> This working group last call ends Feb 18, 2014. >>=20 >> /Loa >> for the MPLS wg chairs >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_71E1647F-6F3D-4239-A62C-853A76ACEF59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Was = asked by WG chairs to review the document as part of LC.
The = document is concise and clear. Would like the comments below addressed = prior to publication.
Some/all of the comments might be a = repeat of what others might have already raised (I didn=92t read any of = those). So, bear with me.

 -Please add = Terminology section and identify terms there.
- Not all RFC=92s = referenced are not bracketed. 
- In section 2.3.1, it = says, for eventual migration away from AG. Does that mean, at some point = a node will stop advertising AG? If so, when and how? i.e. how does a = one know the network has fully migrated to EAG, so nodes could stop = advertising AG. A little more clarity to section should = help.
- When this new sub-TLV is received on a node and it = doesn=92t understand, what does it do? safely ignore or report its = incompatibility?
- Typo "as the assumption is
   than =
an unadvertised bit is set to 0=94
- In sec 3. concludes that this work may happen in future if =
necessary. Hence, I would like the following =
sentence to be removed/reworded, "It is thus likely that signaling EAG in =
a
   SESSION_ATTRIBUTE would see =
virtually no deployment.=94

cheers
-sam
On Feb 4, 2014, at 11:39 AM, Andrew G. Malis = <agmalis@gmail.com> = wrote:

I was asked by the WG chairs for a WG LC review of this = draft. In
general, the draft is ready for publication, but I do have = a few
comments.

[Editorial] Section 1: There are several = unbracketed RFC references
that are in the actual list of references, = and thus should be in
brackets in the text.

[Technical] = Section 2.2: The numbering of the EAG's first word of bits
is = discussed, but the numbering of the bits in subsequent words is = not
described. It can be implied that the bit numbering will continue = at
32 with the LSB of the second word of the EAG, but that is = not
actually stated.

[Technical] Section 2.3.1: It is easy to = predict that routers or
software loads that implement the EAG will be = deployed in the same
network as those that only implement the AG. It = can be expected that
routers that do not implement the EAG will = simply ignore that
particular sub-TLG. Thus, those routers, upon = receipt of both the AG
and EAG sub-TLVs, will ignore the EAG and use = the AG. Thus, for
improved backwards compatibility, if the AG and EAG = co-exist and the
AG is inconsistent with the first word of the EAG, = it would seem that
the AG should take precedence. This is the = opposite of what is stated
in the draft.

Of course, once all = of the routers in a network support the EAG, the
AG will be = unnecessary and only the EAG will be used.

[Technical] Section = 2.3.2: I'm personally hard-pressed to find
usefulness in the = flexibility in this section. For maximum
interoperability and = simplicity of implementations, I would prefer
that the third = paragraph be modified to say:

  To encourage maximum = interoperability an
  implementation MUST treat desired = but unadvertised EAG bits as if
  they are set to 0. =  Consider the case where a node wants to only use
=   links where the 127th bit of an EAG is set to 1.  If a = link is only
  advertising 64 EAG bits, clearly the 127th = EAG bit is not defined -
  that is, it is neither = explicitly 0 nor 1.  The node which wants the
  127th = EAG bit to be 1 MUST NOT use this link, as the assumption is
=   than an unadvertised bit is set to 0.

and also = completely remove the following paragraph.

[Technical] Section 3 = contains a lot of unattributed hand-waving. I
would prefer that is = simply say:

  Signaling EAG in RVSP is not addressed = in this document. Addressing
this in the future is not = precluded.

[Technical] Section 4: While the existing text is = strictly true,
having available a virtually unlimited set of AGs does = make it more
important for network administrations that want their = traffic
engineering to operate correctly to be careful with their = AG
allocation and usage, to avoid unintended side-effects = of
unconstrained AG usage or router misconfiguration. What may have = been
a relatively easy task with 32 AGs may be more difficult with = 128, or
1000, or 1,000,000 attributes. Previously manual processes = may need to
be automated to ensure correctness. Feel free to add text = to this
effect to this section, or not, as you = prefer.

Thanks,
Andy



On Tue, Feb 4, 2014 at = 12:54 AM, Loa Andersson <loa@pi.nu>= wrote:
Working Group,

This is to = initiate a working group last call = on
draft-ietf-mpls-extended-admin-group-02.

There are no IPR = disclosures against this document. The author has
stated that he is = unaware of any 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 Feb 18, 2014.

/Loa
for the MPLS wg = chairs
--


Loa Andersson =             &n= bsp;          email: = loa@mail01.huawei.com
Senior = MPLS Expert =             &n= bsp;           &nbs= p;loa@pi.nu
Huawei Technologies = (consultant)     phone: +46 739 81 21 = 64
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls
______________________________________= _________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls

= --Apple-Mail=_71E1647F-6F3D-4239-A62C-853A76ACEF59-- From agmalis@gmail.com Thu Feb 6 11:57: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 A66811A03ED for ; Thu, 6 Feb 2014 11:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug4vcRg2m0i0 for ; Thu, 6 Feb 2014 11:57:35 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 531AE1A0122 for ; Thu, 6 Feb 2014 11:57:35 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so3638130qae.13 for ; Thu, 06 Feb 2014 11:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4mRGqwoM5AFxR8nrGq8hp6l9vfqQErYETxAzLaQsm5w=; b=qcNp2U9rFNFcnOo/MKWG464tIiWX8/I9VStqgmqOzVKDopCN971qBoP8KnY3cDiJre CDg0zfJGpmxCByuB8Y63oBlv+ySbxxfWGD7FBiwU+jcW7O5QI3fxRfxdMqNnQJJhMC5H AFL/v3+IN4o/adZykUWMVXmNABWU7hx21E7eUbhHFxQzXKQxL59cU4O/w/ybAt7WL4Ic QiLqcwR2S1YJyEpfkAlbeqYx+v/clbYJaCVMkSFFj0RlvlqdWTiRQ60RSAXgt4OceYgR XSnko3eABPw1JFBfBMAUHIQKnIllg9JPIlmlNvlcx41cic9M0YNV8dvRB8CB9QbgChJM tU8A== X-Received: by 10.224.167.84 with SMTP id p20mr15502804qay.24.1391716633596; Thu, 06 Feb 2014 11:57:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Thu, 6 Feb 2014 11:56:53 -0800 (PST) In-Reply-To: References: <52F08085.9000907@pi.nu> From: "Andrew G. Malis" Date: Thu, 6 Feb 2014 14:56:53 -0500 Message-ID: To: Eric Osborne Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 19:57:37 -0000 Eric, I'm fine with your responses, thanks! Cheers, Andy On Thu, Feb 6, 2014 at 2:14 PM, Eric Osborne wrote: > Hi Andy- > > Inline with EO# > > On Tue, Feb 4, 2014 at 2:39 PM, Andrew G. Malis wrote: >> I was asked by the WG chairs for a WG LC review of this draft. In >> general, the draft is ready for publication, but I do have a few >> comments. >> >> [Editorial] Section 1: There are several unbracketed RFC references >> that are in the actual list of references, and thus should be in >> brackets in the text. >> > > EO# ACK, will fix. > >> [Technical] Section 2.2: The numbering of the EAG's first word of bits >> is discussed, but the numbering of the bits in subsequent words is not >> described. It can be implied that the bit numbering will continue at >> 32 with the LSB of the second word of the EAG, but that is not >> actually stated. >> > > EO# ACK, will fix. > > >> [Technical] Section 2.3.1: It is easy to predict that routers or >> software loads that implement the EAG will be deployed in the same >> network as those that only implement the AG. It can be expected that >> routers that do not implement the EAG will simply ignore that >> particular sub-TLG. Thus, those routers, upon receipt of both the AG >> and EAG sub-TLVs, will ignore the EAG and use the AG. Thus, for >> improved backwards compatibility, if the AG and EAG co-exist and the >> AG is inconsistent with the first word of the EAG, it would seem that >> the AG should take precedence. This is the opposite of what is stated >> in the draft. >> >> Of course, once all of the routers in a network support the EAG, the >> AG will be unnecessary and only the EAG will be used. >> > > EO# I sent a separate email on this. > >> [Technical] Section 2.3.2: I'm personally hard-pressed to find >> usefulness in the flexibility in this section. For maximum >> interoperability and simplicity of implementations, I would prefer >> that the third paragraph be modified to say: >> >> To encourage maximum interoperability an >> implementation MUST treat desired but unadvertised EAG bits as if >> they are set to 0. Consider the case where a node wants to only use >> links where the 127th bit of an EAG is set to 1. If a link is only >> advertising 64 EAG bits, clearly the 127th EAG bit is not defined - >> that is, it is neither explicitly 0 nor 1. The node which wants the >> 127th EAG bit to be 1 MUST NOT use this link, as the assumption is >> than an unadvertised bit is set to 0. >> > > EO# That works for me; you're basically doing s/SHOULD/MUST/. > Tarek? Thoughts? > >> and also completely remove the following paragraph. >> >> [Technical] Section 3 contains a lot of unattributed hand-waving. I >> would prefer that is simply say: >> >> Signaling EAG in RVSP is not addressed in this document. Addressing >> this in the future is not precluded. >> > > EO# Yeah, there's a lot of history there. I used to get blasted for > not having enough justification for doing certain things in this draft > and now it looks like I'm in trouble for having too much. :) I don't > much care what that section says - if nobody else cares to take a > position opposite yours then I'll change it. > >> [Technical] Section 4: While the existing text is strictly true, >> having available a virtually unlimited set of AGs does make it more >> important for network administrations that want their traffic >> engineering to operate correctly to be careful with their AG >> allocation and usage, to avoid unintended side-effects of >> unconstrained AG usage or router misconfiguration. What may have been >> a relatively easy task with 32 AGs may be more difficult with 128, or >> 1000, or 1,000,000 attributes. Previously manual processes may need to >> be automated to ensure correctness. Feel free to add text to this >> effect to this section, or not, as you prefer. >> > > EO# IMO it doesn't belong. Reminding operators that they may need to > manage things carefully as they scale seems awfully nanny-state-ish > and not unique to EAG. > > thanks! > > > > > eric > >> Thanks, >> Andy >> >> >> >> On Tue, Feb 4, 2014 at 12:54 AM, Loa Andersson wrote: >>> Working Group, >>> >>> This is to initiate a working group last call on >>> draft-ietf-mpls-extended-admin-group-02. >>> >>> There are no IPR disclosures against this document. The author has >>> stated that he is unaware of any 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 Feb 18, 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 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Thu Feb 6 12:04: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 B061A1A0458 for ; Thu, 6 Feb 2014 12:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63D4xzFsw8J7 for ; Thu, 6 Feb 2014 12:04:05 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 304CA1A0434 for ; Thu, 6 Feb 2014 12:04:05 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id x13so4048438qcv.6 for ; Thu, 06 Feb 2014 12:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fSArHh9dTSxBFpwcqPnL7K4JmpILGooCFABmX5SNbHY=; b=la4ISZI6BBWd4C6guxjVLqboOHxtCP71+x34Tcu6yp+W7IvD0DFTVSG3xf/UzrpjfO OaNwyy5BgYL2p1zIVjyqfJHm4V0nUkih/hdBSYdCWivfN4GcIOgkrsfBRrENxBsX5B8O kl6qi9AptCpzEl71925Gs7KzVOk3rp+oq9l8y3EOJX3YQ20VvNJ7aSLNZ4kkv0oRKdVT 4fOGIKcOrnOScnxgdQO8kY4q9bEhPsB9nh4UdmmpfmEORhfFx9hpFNglcbyzwEBipOe5 QJPAlak0wUWeviXYAcozsDqV0L8kCiPskcfKyMtjez64Gl5Hnifmeg+xbU8y0p/8UwsN PA9w== X-Received: by 10.140.32.98 with SMTP id g89mr14423486qgg.37.1391716630604; Thu, 06 Feb 2014 11:57:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Thu, 6 Feb 2014 11:55:22 -0800 (PST) In-Reply-To: References: <52F08085.9000907@pi.nu> From: "Andrew G. Malis" Date: Thu, 6 Feb 2014 14:55:22 -0500 Message-ID: To: Eric Osborne Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 20:04:07 -0000 Eric, Yes, that will work for me. Thanks, Andy On Thu, Feb 6, 2014 at 2:06 PM, Eric Osborne wrote: > Hi Andy- > > So the concern is around how to handle the case where AG doesn't > match the first 32 bits of EAG. The current text in 2.3.1 says: > > > "If a node > advertises both AG and EAG then the first 32 bits of the EAG MUST be > identical to the advertised AG. If the AG and EAG advertised for a > link differ, the EAG MUST take priority." > > I think I can fix this by changing the second sentence to: > > "If a node > advertises both AG and EAG then the first 32 bits of the EAG MUST be > identical to the advertised AG. If a receiving node notices that > the AG differs from the first 32 bits of the EAG, it SHOULD use the AG > as the first 32 bits of the EAG, and MUST indicate this mismatch to > the operator." > > I very deliberately used 'SHOULD' because there is at least one > implementation already in production with the current logic and I > don't want to obsolete it to cover a corner case that's already > illegal and clearly a bug. > > Does that work? > Tarek, does that break anything in what's shipping? > > > > > eric > > On Thu, Feb 6, 2014 at 1:06 PM, Andrew G. Malis wrote: >> Tarek, >> >> Imagine that you have a network that has been using AG and is >> transitioning to EAG. Since not all routers can be updated >> simultaneously, there will be a period where some will support both AG >> and EAG and others will only support AG. As long as AG and the first >> word of EAG are consistent, everything works well. But if a >> provisioning or software bug leads to the case where the two are >> inconsistent, option (2) will operate better than option (3), since >> with option (2), both old and new routers will be using a consistent >> set of bits 0-31. >> >> Cheers, >> Andy >> >> >> On Thu, Feb 6, 2014 at 12:49 PM, Tarek Saad (tsaad) wrote: >>> In case of inconsistency, see 3 options: >>> 1. use AG and discard EAG, i.e. ignore subsequent bits in (EAG) >>> 2. use AG for first word and subsequent bits from EAG bits >>> 3. use EAG and discard AG >>> >>> The way the draft puts it is EAG is a "superset" of AG. >>> >>> I'm in favour of 3) when router speaks/understands EAG. Just as it is true >>> that for routers that speak/understand only AG, they'd use AG. >>> Note, my understanding is AG at sometime will become obsolete and >>> eventually most (if not all) routers will be speaking EAG. >>> >>> >>> Regards, >>> Tarek >>> >>> On 2014-02-06 12:18 PM, "Andrew G. Malis" wrote: >>> >>>>Tarek, >>>> >>>>In my earlier review, I argued the opposite for section 2.3.1, that AG >>>>MUST take priority over EAG for backwards compatibility. See my email >>>>for my reasoning. >>>> >>>>Cheers, >>>>Andy >>>> >>>>On Thu, Feb 6, 2014 at 11:35 AM, Tarek Saad (tsaad) >>>>wrote: >>>>> Hi, >>>>> >>>>> This document looks good, and addresses a real limitation with existing >>>>> AGs. I think it is ready for publication. Few comments: >>>>> - section 2.3.1: prefer rewording to explicitly spell the behaviour on a >>>>> receiving node that supports EAG.. example, "... EAG MUST take priority >>>>>on >>>>> a receiving node that supports it." >>>>> >>>>> >>>>> minor edit comments: >>>>> - section 1, might want to define LSA, MTU before use >>>>> - section 2.3.2 equally applicable to AG too; maybe re-title as "Desire >>>>> for unadvertised bits for AG/EAG"? >>>>> - typo in Section 2.3.2, "... assumption is than" -> "assumption is >>>>>that" >>>>> >>>>> Regards, >>>>> >>>>> Tarek >>>>> >>>>> On 2014-02-04 12:54 AM, "Loa Andersson" wrote: >>>>> >>>>>>Working Group, >>>>>> >>>>>>This is to initiate a working group last call on >>>>>>draft-ietf-mpls-extended-admin-group-02. >>>>>> >>>>>>There are no IPR disclosures against this document. The author has >>>>>>stated that he is unaware of any 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 Feb 18, 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 >>>>>>_______________________________________________ >>>>>>mpls mailing list >>>>>>mpls@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Thu Feb 6 12:23:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E611A04C6 for ; Thu, 6 Feb 2014 12:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqCr25etYVJo for ; Thu, 6 Feb 2014 12:23:49 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0D1A04C1 for ; Thu, 6 Feb 2014 12:23:49 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kq14so2168425pab.31 for ; Thu, 06 Feb 2014 12:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=clMmXb0TcoosGE4i2TJKiuHNxxRAM4FrQwhQa6ckgQI=; b=aO7d2BTvvnzB2hCl3VqOVjAJ7GcVwki3mbAq+wgDU56cIDDw9nG+O8vGIcoNdlt0sW YJYe3LFbvxMbWC9vGZC+23iDqFDTqOmBjfiVi7K+uRH8kYp0ie3umvB02ai/w9fwHXJt WiS9D1iilj27hKzQRfuTfkTgIZHrlxmZB5bghkmep7MOTB9T6NvwFGLjSdtwXjpxDgUB MaZltDMygiMit8DxY2M2D2Hkf6CxQi0iUYMYxs2qLH4KeGuddwXATU6pBim8PcEfsWem /EGHsNbgAe/lt1p/BsBjd5cRgZ0Jv7j68Y/czHDPZ2BpEE+WY4xrOyApBxHgwfLw0B46 VNug== X-Received: by 10.68.189.198 with SMTP id gk6mr14790198pbc.146.1391718228670; Thu, 06 Feb 2014 12:23:48 -0800 (PST) Received: from [192.168.1.6] (c-107-3-154-8.hsd1.ca.comcast.net. [107.3.154.8]) by mx.google.com with ESMTPSA id ja8sm6429839pbd.3.2014.02.06.12.23.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 12:23:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A5ADAC41-6F28-49A4-9753-C8A47197DA8A" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sam Aldrin In-Reply-To: Date: Thu, 6 Feb 2014 12:23:45 -0800 Message-Id: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1827) Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Curtis Villamizar Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 20:23:53 -0000 --Apple-Mail=_A5ADAC41-6F28-49A4-9753-C8A47197DA8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Nobo et al, Please find my initial comments of the draft v01. - non-corouted -> associated - In sec 2 Some return path(s) are more preferred than others, but preferred cannot be used in all cases. Thus implementations are required to compute when preferred return path encoding can and cannot be used, and that computation is becoming more and more difficult. As response code is initiated by the initiator, user in this case, the = preferred return path is for UI implementation and not the actual LSP = ping functionality. Which/what part of implementation are you referring = to? - Sec 2 This document adds one Reply Mode to describe reverse LSP, and one optional TLV to describe ordered list of reply modes. Based on operational needs, the TLV can describe multiple Reply Mode values in preferred order to allow responder to use first available Reply Mode from the list. This eliminates the need for initiator to compute, or sometimes "guess", the "default" return path encoding. And that will result in simplified implementations across vendors, and result in improved usability to fit operational needs. I do not subscribe to the text above as is. Even with the new proposal, = the compute/guess/default still remain, irrespective of presence/absence = of this new TLV. All you might be adding is an option for sender to = group different return codes, instead of initiator to send request = individually (of course little more than I summarized, but hope you got = my point) - Sec 3.1, how is this different from RFC 7110? If same, please call it = out here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for = the same. If different to the RFC, I would like to see those details = here. - Missing details on how it will work within proxy LSP ping. General comments: - I believe this new enhancement will only provide a degree of variance = to RFC4379, where the response could be received back at initiator. Here = is why 1. If the response is not received back at source, even with the new = TLV, one cannot conclude that LSP is broken.=20 2. Bidirectional LSP=92s exist only for few FEC types. Hence this will = be limited to those FEC types.=20 3. To solve one thing, we might be loosing other aspects. For example, = when I chose return codes in this order, a. Return LSP(5); b. IP(2). So, = if return LSP is broken, with RFC4379 & RFC7110, response will not be = received. But with this, if IP path exists, response will be received = and you do not know how the response is received and initiator will not = know the response is sent over IP. Breakage of return LSP will not be = know at the initiator. 4. As least common denominator is still RFC4379, to support backward = capability, it is impossible to safely assume the network is fully = supportive of the new capability. Do we need controller for that? . = At the end of the day, this is optimization for the sender to reduce = number of requests.=20 cheers -sam On Dec 16, 2013, at 6:28 PM, Nobo Akiya (nobo) wrote: > Hi Sam, Curtis, Greg, >=20 > Thank you for your comments at IETF88, in particular about: >=20 > - Transition plan > - Deviating operational preference in Reply Mode order > - Error cases for "Reply Mode Order TLV" >=20 > These points have been updated in -01. >=20 > In summary, we have decided to remove " Reply via pre-defined = preference" Reply Mode, and to allow the "Reply Mode Order TLV" to be = used with any Reply Mode value in echo request. >=20 > URL: = http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-ping-reply-mode-s= imple-01.txt > Status: = http://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-reply-mode-simpl= e > Htmlized: = http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-lsp-ping-reply-mode-si= mple-01 >=20 > -Nobo --Apple-Mail=_A5ADAC41-6F28-49A4-9753-C8A47197DA8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Nobo et al,

Please find my initial comments of the = draft v01.

- non-corouted -> = associated
- In sec 2
Some return =
path(s) are more preferred than others, but preferred
   cannot be used in all cases.  Thus implementations are required to
   compute when preferred return path encoding can and cannot be used,
   and that computation is becoming more and more =
difficult.

As response code is initiated = by the initiator, user in this case, the preferred return path is for UI = implementation and not the actual LSP ping functionality. Which/what = part of implementation are you referring to?
- Sec = 2
This document adds one Reply Mode =
to describe reverse LSP, and one
   optional TLV to describe ordered list of reply modes.  Based on
   operational needs, the TLV can describe multiple Reply Mode values in
   preferred order to allow responder to use first available Reply Mode
   from the list.  This eliminates the need for initiator to compute, or
   sometimes "guess", the "default" return path encoding.  And that will
   result in simplified implementations across vendors, and result in
   improved usability to fit operational needs.

I do not subscribe to the text above as = is. Even with the new proposal, the compute/guess/default still remain, = irrespective of presence/absence of this new TLV. All you might be = adding is an option for sender to group different return codes, instead = of initiator to send request individually (of course little more than I = summarized, but hope you got my point)

- Sec = 3.1, how is this different from RFC 7110? If same, please call it out = here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for the = same. If different to the RFC, I would like to see those details = here.

- Missing details on how it will work = within proxy LSP ping.

General = comments:

- I believe this new enhancement will = only provide a degree of variance to RFC4379, where the response could = be received back at initiator. Here is why
  1. If the = response is not received back at source, even with the new TLV, one = cannot conclude that LSP is broken. 
  2. = Bidirectional LSP=92s exist only for few FEC types. Hence this will be = limited to those FEC types. 
  3. To solve one = thing, we might be loosing other aspects. For example, when I chose = return codes in this order, a. Return LSP(5); b. IP(2). So, if return = LSP is broken, with RFC4379 & RFC7110, response will not be = received. But with this, if IP path exists, response will be received = and you do not know how the response is received and initiator will not = know the response is sent over IP. Breakage of return LSP will not be = know at the initiator.
  4. As least common denominator = is still RFC4379, to support backward capability, it is impossible to = safely assume the network is fully supportive of the new capability. Do = we need controller for that? </jk>. At the end of the day, this is = optimization for the sender to reduce number of = requests. 

cheers
-sam
=

On Dec 16, 2013, at 6:28 PM, Nobo Akiya (nobo) = <nobo@cisco.com> = wrote:

Hi Sam, Curtis, Greg,

Thank you for your comments = at IETF88, in particular about:

- Transition plan
- Deviating = operational preference in Reply Mode order
- Error cases for "Reply = Mode Order TLV"

These points have been updated in -01.

In = summary, we have decided to remove " Reply via pre-defined preference" = Reply Mode, and to allow the "Reply Mode Order TLV" to be used with any = Reply Mode value in echo request.

URL: =             http://www.ietf.org/internet-drafts/draft-akiya-mpls= -lsp-ping-reply-mode-simple-01.txt
Status: =          http://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-reply= -mode-simple
Htmlized: =        http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-s= imple-01
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-lsp-p= ing-reply-mode-simple-01

-Nobo

=
= --Apple-Mail=_A5ADAC41-6F28-49A4-9753-C8A47197DA8A-- From sriganeshkini@gmail.com Thu Feb 6 14:04: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 930411A0101 for ; Thu, 6 Feb 2014 14:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0UNcfky8Bba for ; Thu, 6 Feb 2014 14:04:24 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id F39131A03C4 for ; Thu, 6 Feb 2014 14:04:23 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id w10so2270631pde.7 for ; Thu, 06 Feb 2014 14:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/4VbISy7may3TF1XwCUaanu4Z3jwpmAkDrhBJywLw9g=; b=RTGpKJEx7yXTqXc0/7n/dDgZYRAWThlXiBE7mDkJKwXVtVYYiFmi0X0dsQe+2K+EaT LND4DJSXIxZiiaWNABe3l1smKzsjzB7kkHj25hxp1s9TbWn3c6v+DIqse8Lwz2sxvLH5 Eelb/HcB6Q+8+GGOwcaSPlyGsUwfOiT9ihRy5tr4nuAn5yui8uihBwUWU+XyJJHHq7zJ NdDZAkZ7WwXml2qoPxbl8DJ8hOZN40J3NmPaC3bPQt40FY+IoJbgixZ2m0wkjEpxk1NG AXxSX9ZCRFO0ecNZhcvRoU8rgVX5yaO3MVD1TN/Yr19kFzrMJWZtlOOIWXLaVZIHC2oO /T5w== X-Received: by 10.68.134.8 with SMTP id pg8mr15421577pbb.84.1391724262839; Thu, 06 Feb 2014 14:04:22 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.84.165 with HTTP; Thu, 6 Feb 2014 14:03:52 -0800 (PST) In-Reply-To: <11094_1391177507_52EBAF23_11094_2718_1_EEE55384044474429A926C625D0FCC8109A301097D@PUEXCB2F.nanterre.francetelecom.fr> References: <11094_1391177507_52EBAF23_11094_2718_1_EEE55384044474429A926C625D0FCC8109A301097D@PUEXCB2F.nanterre.francetelecom.fr> From: Sriganesh Kini Date: Thu, 6 Feb 2014 14:03:52 -0800 X-Google-Sender-Auth: _M8WWWXtk02tDNiIixI86ahsDP0 Message-ID: To: stephane.litkowski@orange.com Content-Type: multipart/alternative; boundary=047d7b10cb594feeb304f1c40e72 Cc: "mpls@ietf.org" , "draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org" Subject: Re: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2014 22:04:26 -0000 --047d7b10cb594feeb304f1c40e72 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephane, On Fri, Jan 31, 2014 at 6:11 AM, wrote: > Hi Authors, > > > > > > I would like to know if you are progressing on this draft ? > > Entropy label support for stacked tunnels would be mandatory for us, so I > would like to support the work on this topic to have a working solution a= s > soon as possible. > Yes, we are progressing on this draft. Thanks for supporting this work. > > > > > Regarding the solutions you are proposing in the current version, there i= s > none perfect one, and unfortunately all have drawbacks. > Precisely why we wanted to put all the options on the table. > The compatibility (on LSR) with current generation of hardwares may be > =E2=80=9Cgood=E2=80=9D (mandatory ?) for the target solution. > > > > In your document , solution =C2=A73.3 =E2=80=9Cre-usable EL for a stack o= f tunnels=E2=80=9D > sounds for me to be the best base idea. I=E2=80=99m just wondering what w= ould be > the hardware impact of doing the reinsertion of ELI at tunnel end . Could > this be done in one pass ? (IMHO, this may be possible, as today we are > able to pop or swap + push FRR headers) As you are three different vendor= s > as co-author, did you already evaluate such impact on your hardwares ? (I= =E2=80=99m > not expecting details on the mailing list, but I would be interested by > details unicast to me and just yes/no on the the list) > This is vendor+platform specific question. IMO it is best if the details are unicast. > > > To be exhaustive in listing solutions, did you think about leaving the > EL/ELI at top of the stack ? I think there is already a case where a > special label may > Yes, we had considered this. Since it was not inline with RFC6790 and it is almost exactly the same as the re-usable EL option, we did not include it. > be kept at top of the stack (MPLS Router alert). > > What would be needed : > > - each hop need to advertise is ability to process EL, if > nexthop cannot process EL, it should be removed when forwarded to nexthop > (there should be the same requirement for re-usable EL) > EL capability advertisement via IGP is defined in draft-xu-{isis|ospf}-mpls-elc. Re-inserting EL it at the next place in the stack where the next EL capability LSR along the path is there is a better option than just removing EL when nexthop is not EL capable. But this unnecessary burden on transit LSR. A better alternative could be the ingress since it can determine more easily as to which LSRs along the path are not EL capable and then insert multiple ELs such that even if an EL is dropped when nexthop is not EL capable, then another EL is available in the stack when the packet reaches LSRs that are EL capable. The tradeoff is increased stack size, but size increases only by the number of non EL capable LSR segments along the path. > I don=E2=80=99t think this is really different from re-usable EL in the c= oncept : > Yes. But the differences are subtle. > - reusable EL : process top level forwarding label, if popped > and next label is EL, pop ELI/EL and next label L, push pack ELI/EL and > then L (we need to swap positions between ELI/EL and L) if nexthop is abl= e > to process EL. > Mostly correct. But note that when a tunnel-segment is terminated at a LSR, the label-operation for next tunnel-segment is swap. In your example the operation for the incoming label L would be swap, hence the outgoing label may be L'. So the received ELI/EL needs to be pushed during this operation. Advertising this capability is simple since this is the tunnel termination point. When the operation is swap without terminating the tunnel-segment, then ELI/EL is not at the top of stack so the transit LSR of the tunnel-segment does not need any additional capability. So the "no transit LSR change" property of RFC6790 is preserved. Only the LSRs that are terminating tunnel-segments need the new capability. > - top level EL : process top level ELI, ELI is recognized, > ELI/EL is removed, forwarding is done on forwarding label, ELI/EL is push= ed > back in nexthop is able to process EL. > The biggest drawback is that every LSR along every tunnel-segment should now have the new behavior of pushing the received ELI/EL after the forwarding label swap. > > > In term of operations, I think that top level EL may be simpler , but as > I=E2=80=99m not hardware coder, may be I=E2=80=99m wrong =E2=80=A6 moreov= er it may be similar to > MPLS Router alert processing. > It is different from Router-alert processing. Here everything is in the fast-path and processing has to be at line-rate. In case of Router-alert it was handoff to a software module for slower-path processing. > > > > > Your thoughts ? > I think top-level EL is harder to deploy and less in-line with RFC6790. Sri > > > > Stephane > > > > > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --047d7b10cb594feeb304f1c40e72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephane,


On Fri, Jan 31, 2014 at 6:11 AM, <stephane.l= itkowski@orange.com> wrote:

Hi Authors,

=C2=A0

=C2=A0

I would like to know if you are progressing on this draft= =C2=A0?

Entropy label support for stack= ed tunnels would be mandatory for us, so I would like to support the work o= n this topic to have a working solution as soon as possible.


Yes, we are progressing on this draf= t. Thanks for supporting this work.
=C2=A0

=C2=A0

=C2=A0

Regarding the solutions you are= proposing in the current version, there is none perfect one, and unfortuna= tely all have drawbacks.


Precisely why we wanted to put all the options on the table.
=C2=A0

The compatibility (on LSR) with current generation of hardw= ares may be =E2=80=9Cgood=E2=80=9D (mandatory ?) for the target solution.

=C2=A0

=

In your document , solution =C2= =A73.3 =E2=80=9Cre-usable EL for a stack of tunnels=E2=80=9D sounds for me = to be the best base idea. I=E2=80=99m just wondering what would be the hard= ware impact of doing the reinsertion of ELI at tunnel end . Could this be d= one in one pass ? (IMHO, this may be possible, as today we are able to pop = or swap + push FRR headers) As you are three different vendors as co-author= , did you already evaluate such impact on your hardwares ? (I=E2=80=99m not= expecting details on the mailing list, but I would be interested by detail= s unicast to me and just yes/no on the the list)


This is vendor+platform specif= ic question. IMO it is best if the details are unicast.
=C2=A0

=C2=A0

To be exhaustive in listing solutions, did you think about = leaving the EL/ELI at top of the stack ? I think there is already a case wh= ere a special label may


Yes, we had considered this. S= ince it was not inline with RFC6790 and it is almost exactly the same as th= e re-usable EL option, we did not include it.
=C2=A0

be kept at top of the stack (MPLS Router alert).<= /u>

What would= be needed :

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 each hop need= to advertise is ability to process EL, if nexthop cannot process EL, it sh= ould be removed when forwarded to nexthop (there should be the same require= ment for re-usable EL)


EL capability advertisement vi= a IGP is defined in=C2=A0draft-xu-{isis|ospf}-mpls-elc. Re-inserting EL it = at the next place in the stack where the next EL capability LSR along the p= ath is there is a better option than just removing EL when nexthop is not E= L capable. But this unnecessary burden on transit LSR. A better alternative= could be the ingress since it can determine more easily as to which LSRs a= long the path are not EL capable and then insert multiple ELs such that eve= n if an EL is dropped when nexthop is not EL capable, then another EL is av= ailable in the stack when the packet reaches LSRs that are EL capable. The = tradeoff is increased stack size, but size increases only by the number of = non EL capable LSR segments along the path.
=C2=A0

I don=E2=80=99t think this is really different from re-us= able EL in the concept :


=
Yes. But the differences are subtle.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reusable EL : process top level forwarding = label, if popped and next label is EL, pop ELI/EL and next label L, push pa= ck ELI/EL and then L (we need to swap positions between ELI/EL and L) if ne= xthop is able to process EL.

Mostly correct. But note that when a tunnel-s= egment is terminated at a LSR, the label-operation for next tunnel-segment = is swap. In your example the operation for the incoming label L would be sw= ap, hence the outgoing label may be L'. So the received ELI/EL needs to= be pushed during this operation. Advertising this capability is simple sin= ce this is the tunnel termination point. When the operation is swap without= terminating the tunnel-segment, then ELI/EL is not at the top of stack so = the transit LSR of the tunnel-segment does not need any additional capabili= ty. So the "no transit LSR change" property of RFC6790 is preserv= ed. Only the LSRs that are terminating tunnel-segments need the new capabil= ity.
=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = top level EL : process top level ELI, EL= I is recognized, ELI/EL is removed, forwarding is done on forwarding label,= ELI/EL is pushed back in nexthop is able to process EL.

The biggest drawback is that every LSR along = every tunnel-segment should now have the new behavior of pushing the receiv= ed ELI/EL after the forwarding label swap.
=C2=A0

<= /u>=C2=A0

In t= erm of operations, I think that top level EL may be simpler , but as I=E2= =80=99m not hardware coder, may be I=E2=80=99m wrong =E2=80=A6 moreover it = may be similar to MPLS Router alert processing.


It is different from Router-al= ert processing. Here everything is in the fast-path and processing has to b= e at line-rate. In case of Router-alert it was handoff to a software module= for slower-path processing.
=C2=A0

=C2=A0

=C2=A0

Your thoughts ?



I think top-lev= el EL is harder to deploy and less in-line with RFC6790.=C2=A0

Sri

=C2=A0

=C2=A0

Stephane

=C2=A0

=C2=A0

=C2=A0

________________________________________________________________=
_________________________________________________________

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

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

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


--047d7b10cb594feeb304f1c40e72-- From loa@pi.nu Thu Feb 6 21:47: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 D7E2B1A05AA for ; Thu, 6 Feb 2014 21:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5tbp-QhKD-T for ; Thu, 6 Feb 2014 21:47:41 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 97ED61A0375 for ; Thu, 6 Feb 2014 21:47:41 -0800 (PST) Received: from [192.168.1.5] (unknown [119.95.153.237]) (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 4869B180150F; Fri, 7 Feb 2014 06:47:36 +0100 (CET) Message-ID: <52F47370.2020202@pi.nu> Date: Fri, 07 Feb 2014 13:47:28 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , draft-ietf-mpls-psc-updates@tools.ietf.org References: <52E63702.20102@pi.nu> In-Reply-To: <52E63702.20102@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 05:47:44 -0000 Folks, Martin "Eagle Eye" has spotted a typo in this wglc, the date should be Feb 10, 2014. /Loa On 2014-01-27 18:37, Loa Andersson wrote: > Working Group, > > This is to initiate a working group last call on > draft-ietf-mpls-psc-updates. > > One reason for the timing, other than that the author thinks is ready > for wglc, is that this document is normatively referenced in > draft-ietf-mpls-tp-psc-itu which also is in wglc. > > There are no IPR disclosures against this document. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > This working group last call ends Feb 190, 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 loa@pi.nu Thu Feb 6 22:09: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 446771A05AB for ; Thu, 6 Feb 2014 22:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzJXeRY_cLig for ; Thu, 6 Feb 2014 22:09:57 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9C16E1A029D for ; Thu, 6 Feb 2014 22:09:57 -0800 (PST) Received: from [192.168.1.5] (unknown [119.95.153.237]) (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 46F32180150F; Fri, 7 Feb 2014 07:09:53 +0100 (CET) Message-ID: <52F478A8.1000101@pi.nu> Date: Fri, 07 Feb 2014 14:09:44 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yakov Rekhter References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> <201312121651.rBCGpYL46117@magenta.juniper.net> <52F11FD8.3000000@pi.nu> <201402042158.s14LwnL93027@magenta.juniper.net> <52F1CC6F.1070906@pi.nu> <201402051430.s15EUML50526@magenta.juniper.net> In-Reply-To: <201402051430.s15EUML50526@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2014 06:09:59 -0000 Yakov, On 2014-02-05 22:30, Yakov Rekhter wrote: > I agreed to the plan you proposed in your e-mail on Dec 4, 2013. > According to this plan > > 1. Issue a single poll to adopt both documents together as > working group documents > > However, what you doing now is*not* what you proposed in the plan, > as now you issued a two week poll on adopting just > draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working > group document. > > Yakov. I found no way to hold the draft-wijnands-mpls-mldp-in-band-wildcard- encoding further, it is almost 5 months since that document were ready to move. However, I'm prepared to go to wg adoption poll on draft-rekhter- mpls-pim-sm-over-mldp very quickly if the following update is made. OLD This document uses BGP Source Active auto-discovery routes, as defined in [MVPN-BGP]. This document also identifies the deployment scenarios where BGP Source Active auto-discovery routes will not be used. NEW This document uses BGP Source Active auto-discovery routes, as defined in [MVPN-BGP]. In a deployment scenario where the service provider has provisioned the network in such a way that the RP for a particular ASM group G is always between the receivers and the sources. If the network is provisioned in this manner, the ingress PE for (S,G) is always the same as the ingress PE for the RP, and thus the Source Active A-D routes are never needed. If it is known a priori that the network is provisioned in this manner, mLDP in-band signaling can be supported using a simplified set of procedures. Specification of the simplified procedures supporting this scenario is outside the scope of the present document. See [draft-wijnands- mpls-mldp-in-band-wildcard-encoding]. A service provider will provision the PE routers either to use [draft-wijnands] procedures or to use the procedures of this document. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From francesco.fondelli@gmail.com Fri Feb 7 00:42:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C5B1A05C7 for ; Fri, 7 Feb 2014 00:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXrSFL7QyiR7 for ; Fri, 7 Feb 2014 00:42:53 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFCD1A039F for ; Fri, 7 Feb 2014 00:42:53 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id m15so2056858wgh.14 for ; Fri, 07 Feb 2014 00:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nqued3WX2yi7cgk2VJsty8rpmuo36+KzDr55bQ76wM0=; b=t0HuCtjonfH/5RhdRIkgE2LthR0uIiwHSlPZD74beEcwbs2gQFuOux0w1PNknPdDtE ZviIoqE/yGt1UxUCc5o1pKRTR4aZT+Uri9WtxWg9MSiCwWByZR2+WWyGzmD6NMepoubx 3iFTxXN8LK5v7K5zhFvMSCSPM/wMx8Y48RU5wI7/OWNLksIX731BaabWeKXCm+XLXoP6 +/2LTnzmVckXYmhayIy3tIvslQJYU6Tz22d5I2HE2oJIZrlJgFHyPwARlr9j+f4wz4D5 0efmf+IC59WPrco62hEUbKev1qkW+W1pbSg3oZuf+dLTDD4tvGF8MQUeobzwarqIU/eg Xa7Q== MIME-Version: 1.0 X-Received: by 10.194.63.228 with SMTP id j4mr9689680wjs.34.1391762571201; Fri, 07 Feb 2014 00:42:51 -0800 (PST) Received: by 10.194.239.40 with HTTP; Fri, 7 Feb 2014 00:42:51 -0800 (PST) In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C3575B@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B75EC6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C35557@SJCEML701-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C3575B@SJCEML701-CHM.china.huawei.com> Date: Fri, 7 Feb 2014 09:42:51 +0100 Message-ID: From: Francesco Fondelli To: Huaimo Chen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2014 08:42:55 -0000 Hi Huaimo, On Thu, Feb 6, 2014 at 8:10 PM, Huaimo Chen wrote: [cut] > A tunnel is identified by . Setting Extended Tunnel ID to 0 in the session object on node A and = node B for two LSPs respectively to make them belong to the same tunnel see= ms not work. I agree, I said "If ingress nodes A and B use the same P2MP ID *and* the same Tunnel ID *and* 0 as Extended Tunnel ID...". I highlighted 'and' to emphasize the fact that all conditions must be met. > Basically, a node in the network needs to identify a tunnel uniquely for = two or more LSPs under the same tunnel to share the bandwidth of a link. If= Extended Tunnel ID is set to 0, seems not enough to identify a tunnel uniquely unless some= items such as 16-bit tunnel ID are made globally unique. Some implementations let the user specify the Tunnel ID, I guess is possible to do the same for the P2MP ID and the Extended Tunnel ID. Operator would have explicit network-wise control of this mp2mp construct. So basically, we agree. thanks ciao fra > Best Regards, > Huaimo > -----Original Message----- > From: Francesco Fondelli [mailto:francesco.fondelli@gmail.com] > Sent: Thursday, February 06, 2014 6:03 AM > To: Huaimo Chen > Cc: Gregory Mirsky; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org= ; mpls@ietf.org > Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10 > > Hi, > > On Thu, Feb 6, 2014 at 5:38 AM, Huaimo Chen wrot= e: >> Dear Greg, > > [cut] > >> Huaimo: In the case that the primary LSP is from an ingress node A to >> a number of egress nodes and the standby LSP is from a backup ingress >> node B (note that A is different from B), it seems that the shared >> explicit RSVP reservation style does not work in this case. The >> primary LSP can not share its bandwidth with the standby LSP since >> they are two different LSP tunnels starting from two different ingress n= odes. > > Oh, this is in my still-have-to-be-understood-queue since a while... > > SE-style reservation creates a single reservation shared by selected upst= ream sender*s* (I do not think they have to be be on the same > node) within a given session [RFC2205]. In a p2mp scenario a session is = identified by the tuple (P2MP ID, Tunnel ID, Extended Tunnel ID) [RFC4875].= If ingress nodes A and B use the same P2MP ID *and* the same Tunnel ID *a= nd* 0 as Extended Tunnel ID (it is normally set to a value !=3D 0 by ingres= s nodes that wish to *narrow* the scope of a session to the ingress-egress = pair [RFC3209], though in this case we want the opposite) primary and stand= by LSPs will share the same resources along common links/nodes. How nodes = A and B shares P2MP ID and Tunnel ID is outside the scope of this email :-)= , I guess manual configuration might be a possibility. > > This is my understanding. ACK/NACK would be much appreciated (not sure a= ll I said is 100% correct or I missed something). > > thank you > ciao > fra > > PS > this possibility for the p2p case is mentioned in RFC3209 section > 2.4.3 "SE style reservations can be provided using multipoint-to-point la= bel-switched-path or LSP per sender..." From chris75roberts@gmail.com Fri Feb 7 01:24: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 B12F41A01E5 for ; Fri, 7 Feb 2014 01:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MISSING_HEADERS=1.021, 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 lVX5KmLcROIi for ; Fri, 7 Feb 2014 01:24:18 -0800 (PST) Received: from mail-vc0-x244.google.com (mail-vc0-x244.google.com [IPv6:2607:f8b0:400c:c03::244]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1E1A00AB for ; Fri, 7 Feb 2014 01:24:18 -0800 (PST) Received: by mail-vc0-f196.google.com with SMTP id lf12so580863vcb.3 for ; Fri, 07 Feb 2014 01:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=O96fQESu//bb4KqgsM+++MlWwe45D0qnJaj69/kR7vk=; b=ILIMYaiG8vvS/MDUvYr1txt/bkeowg/8JHIATmDSOtMoymppoCG0hRH2wjOswnrp+w DCm1Pho9p/lhjFqlv2J+S19k0FtCfXAp3qA9CJOIxaZfw7lQgMJCOgKlKPYTKyvEw99Q DnnJrrHAOyxRTtp6HsTyI22sLD2hwCfy+olJRss9LJ/iWGHiVDxdV1cnTK/7/D8ntE9O eVRHSw+4ysZ0jScLQ7TmXsgAmkxrJ8c9PMJxJZFK9rqJb8Pc1ad2X7kFdejMYIqQJaZ/ YCbpCM4jMJ3Da/eOjZrcIRdxXdxhCAp/KAZw6PoAhraZEYmL1Zp0YlUKywrcU4RyC8NT WdMQ== MIME-Version: 1.0 X-Received: by 10.58.255.233 with SMTP id at9mr9734465ved.20.1391765056629; Fri, 07 Feb 2014 01:24:16 -0800 (PST) Received: by 10.220.196.208 with HTTP; Fri, 7 Feb 2014 01:24:16 -0800 (PST) In-Reply-To: <52F34E21.9040906@lab.dtag.de> References: <52F1DA2C.2070007@pi.nu> <52F34E21.9040906@lab.dtag.de> Date: Fri, 7 Feb 2014 09:24:16 +0000 Message-ID: From: Chris Roberts Cc: mpls@ietf.org Content-Type: multipart/alternative; boundary=047d7bf15fc8cfb2c204f1cd8d06 Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 09:24:19 -0000 --047d7bf15fc8cfb2c204f1cd8d06 Content-Type: text/plain; charset=ISO-8859-1 Support. Thanks, Chris On Thu, Feb 6, 2014 at 8:56 AM, Martin Horneffer wrote: > Support. > > Best regards, Martin > > Am 05.02.14 07:29, schrieb Loa Andersson: > > Working Group, >> >> This is to start a two week poll on adopting >> draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working >> group document. >> >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls@ietf.org). Please give a technical >> motivation for your support/not support, especially if you think that >> the document should not be adopted as a working group document. >> >> Please note that we have identified an overlap between this document >> and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this >> document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp >> to cover this. >> >> There are no IPR claims against this document. >> >> The authors has stated on the working group mailing list >> that they are not aware of any other IPR claims against this draft. >> >> However if you are on the the mpls working group mailing list and >> aware of IPR that relates to this draft, the time to disclose >> this is now. >> >> This poll ends February 19, 2014. >> >> /Loa >> (mpls wg co-chair) >> > > ############################################## > # Mail Account for technical purposes only > ############################################## > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7bf15fc8cfb2c204f1cd8d06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.

Thanks,

Chris


On Thu, Feb 6, 2014 at 8:56 AM, Martin Horneffer <maho@lab.dtag.de>= wrote:
Support.

Best regards, Martin

Am 05.02.14 07:29, schrieb Loa Andersson:

Working Group,

This is to start a two week poll on adopting
draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS workin= g
group document.

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

Please note that we have identified an overlap between this document
and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave t= his
document unchanged and add text to draft-rekhter-mpls-pim-sm-over-ml= dp
to cover this.

There are no IPR claims against this document.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.

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

This poll ends February 19, 2014.

/Loa
(mpls wg co-chair)

##############################################
# Mail Account for technical purposes only
##############################################

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

--047d7bf15fc8cfb2c204f1cd8d06-- From mach.chen@huawei.com Fri Feb 7 01:54: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 1F0671A05E2 for ; Fri, 7 Feb 2014 01:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 3iRnzLNvRnJd for ; Fri, 7 Feb 2014 01:54:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A3CE21A05DF for ; Fri, 7 Feb 2014 01:54:21 -0800 (PST) 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 BDI62743; Fri, 07 Feb 2014 09:54:19 +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, 7 Feb 2014 09:53:18 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 09:54:17 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 17:54:14 +0800 From: Mach Chen To: Sam Aldrin , "Nobo Akiya (nobo)" Thread-Topic: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: AQHPI3lg31b+vJ48O0W0RVxPH/dGa5qpjW4w Date: Fri, 7 Feb 2014 09:54:13 +0000 Message-ID: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D95C809SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Curtis Villamizar Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 09:54:27 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D95C809SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, Thanks for your comments, the authors (some still on their vacation) will d= iscuss and address your comments later. Best regards, Mach From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Friday, February 07, 2014 4:24 AM To: Nobo Akiya (nobo) Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.o= rg; Curtis Villamizar Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-= mode-simple Hi Nobo et al, Please find my initial comments of the draft v01. - non-corouted -> associated - In sec 2 Some return path(s) are more preferred than others, but preferred cannot be used in all cases. Thus implementations are required to compute when preferred return path encoding can and cannot be used, and that computation is becoming more and more difficult. As response code is initiated by the initiator, user in this case, the pref= erred return path is for UI implementation and not the actual LSP ping func= tionality. Which/what part of implementation are you referring to? - Sec 2 This document adds one Reply Mode to describe reverse LSP, and one optional TLV to describe ordered list of reply modes. Based on operational needs, the TLV can describe multiple Reply Mode values in preferred order to allow responder to use first available Reply Mode from the list. This eliminates the need for initiator to compute, or sometimes "guess", the "default" return path encoding. And that will result in simplified implementations across vendors, and result in improved usability to fit operational needs. I do not subscribe to the text above as is. Even with the new proposal, the= compute/guess/default still remain, irrespective of presence/absence of th= is new TLV. All you might be adding is an option for sender to group differ= ent return codes, instead of initiator to send request individually (of cou= rse little more than I summarized, but hope you got my point) - Sec 3.1, how is this different from RFC 7110? If same, please call it out= here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for the same= . If different to the RFC, I would like to see those details here. - Missing details on how it will work within proxy LSP ping. General comments: - I believe this new enhancement will only provide a degree of variance to = RFC4379, where the response could be received back at initiator. Here is wh= y 1. If the response is not received back at source, even with the new TLV,= one cannot conclude that LSP is broken. 2. Bidirectional LSP's exist only for few FEC types. Hence this will be l= imited to those FEC types. 3. To solve one thing, we might be loosing other aspects. For example, wh= en I chose return codes in this order, a. Return LSP(5); b. IP(2). So, if r= eturn LSP is broken, with RFC4379 & RFC7110, response will not be received.= But with this, if IP path exists, response will be received and you do not= know how the response is received and initiator will not know the response= is sent over IP. Breakage of return LSP will not be know at the initiator. 4. As least common denominator is still RFC4379, to support backward capa= bility, it is impossible to safely assume the network is fully supportive o= f the new capability. Do we need controller for that? . At the end of = the day, this is optimization for the sender to reduce number of requests. cheers -sam On Dec 16, 2013, at 6:28 PM, Nobo Akiya (nobo) > wrote: Hi Sam, Curtis, Greg, Thank you for your comments at IETF88, in particular about: - Transition plan - Deviating operational preference in Reply Mode order - Error cases for "Reply Mode Order TLV" These points have been updated in -01. In summary, we have decided to remove " Reply via pre-defined preference" R= eply Mode, and to allow the "Reply Mode Order TLV" to be used with any Repl= y Mode value in echo request. URL: http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-p= ing-reply-mode-simple-01.txt Status: http://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-= reply-mode-simple Htmlized: http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply= -mode-simple-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-lsp-pi= ng-reply-mode-simple-01 -Nobo --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D95C809SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Sam,<= /p>

=  

= Thanks for your comments, the aut= hors (some still on their vacation) will discuss and address your comments late= r.

=  

= Best regards,

= Mach

=  

From: mpls [mailto:mpls-bounces@ietf.org] On= Behalf Of Sam Aldrin
Sent: Friday, February 07, 2= 014 4:24 AM
To: Nobo Akiya (nobo)
Cc: mpls@ietf.org; draft-aki= ya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; Curtis Villamizar
Subject: Re: [mpls] Thanks f= or comments on draft-akiya-mpls-lsp-ping-reply-mode-simple

 

Hi Nobo et al,

 

Please find my initial comments of the draft v01.=

 

- non-corouted -> associated

- In sec 2

Some return path(s) are more p=
referred than others, but preferred
   cannot be used in all cases.  Thus implementations are required to
   compute when preferred return path encoding can and =
cannot be used,
   and that computation is becoming more and more diffi=
cult.

 

As response code is initiated by the initiator, user in this= case, the preferred return path is for UI implementation and not the actual LSP ping functionality. Which/what part of implementati= on are you referring to?

- Sec 2

This document adds one Reply M=
ode to describe reverse LSP, and one
   optional TLV to describe ordered list of reply modes=
.  Based on<=
/font>
   operational needs, the TLV can describe multiple Rep=
ly Mode values in
   preferred order to allow responder to use first avai=
lable Reply Mode
   from the list. =
; This eliminates the need for initiator to compute, or
   sometimes "guess", the "default"=
 return path encoding.  And th=
at will
   result in simplified implementations across vendors,=
 and result in
   improved usability to fit operational needs.

 

I do not subscribe to the text above as is. Even with the ne= w proposal, the compute/guess/default still remain, irrespective of presence/absence of this new TLV. All you might be adding = is an option for sender to group different return codes, instead of initiat= or to send request individually (of course little more than I summarized, b= ut hope you got my point)

 

- Sec 3.1, how is this different from RFC 7110? If same, ple= ase call it out here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for the same. If different to the RFC, I would like to = see those details here.

 

- Missing details on how it will work within proxy LSP ping.=

 

General comments:

 

- I believe this new enhancement will only provide a degree = of variance to RFC4379, where the response could be received back at initiator. Here is why

  1. If the response is not received back at source, ev= en with the new TLV, one cannot conclude that LSP is broken. 

  2. Bidirectional LSP’s exist only for few FEC t= ypes. Hence this will be limited to those FEC types. 

  3. To solve one thing, we might be loosing other aspe= cts. For example, when I chose return codes in this order, a. Return LSP(5); b. IP(2). So, if return LSP is broken, with RFC4379 &= ; RFC7110, response will not be received. But with this, if IP path exists,= response will be received and you do not know how the response is received= and initiator will not know the response is sent over IP. Breakage of return LSP will not be know at the initiator.=

  4. As least common denominator is still RFC4379, to s= upport backward capability, it is impossible to safely assume the network is fully supportive of the new capability. Do we need controll= er for that? </jk>. At the end of the day, this is optimization for t= he sender to reduce number of requests. 

 

cheers

-sam

 

On Dec 16, 2013, at 6:28 PM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:<= /font>



Hi Sam, Curtis, Greg,

Thank you for your comments at IETF88, in particular about:

- Transition plan
- Deviating operational preference in Reply Mode order
- Error cases for "Reply Mode Order TLV"

These points have been updated in -01.

In summary, we have decided to remove " Reply via pre-defined preferen= ce" Reply Mode, and to allow the "Reply Mode Order TLV" to b= e used with any Reply Mode value in echo request.

URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-akiya-m= pls-lsp-ping-reply-mode-simple-01.txt
Status:          = http://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-reply-mode-simple=
Htmlized:        http://tools= .ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-lsp-pin= g-reply-mode-simple-01

-Nobo

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D95C809SZXEMA510MBXchi_-- From lizho.jin@gmail.com Fri Feb 7 07:41: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 A7D231A8035 for ; Fri, 7 Feb 2014 07:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARimC69pwu9m for ; Fri, 7 Feb 2014 07:41:45 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1549F1A03CC for ; Fri, 7 Feb 2014 07:41:44 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id jt11so3397583pbb.39 for ; Fri, 07 Feb 2014 07:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=oeXMoYBkjofYhNWH2rHHGlVACzPtPGgLM3SlDxnPAVc=; b=dGM9JEFGy7PMFr91KV3k4Nvxi4fWOEH9IoQzB85QoyvyaDTAfgo43g0uA/I1I+CBH8 EM7Ys33bqeVqHJc9ApsdEifcOoREro1i2ClTl6dx7bYn+3KultjEczYilkNPyHh9DSqs yWmMFLZJ6kT1JCy4OyuF4TLvajAbXCwURoYwxfhft10kOvvmVWVIM0YeKxm8H+IwpE7L wKFtVK0SMuuwDCd+se9TcgKIkJ2pT0c+Bpph03bP3L0Y16WshUewhCsrFXwSZAuS5LkF +ArT/wEseggel9Pmmz8vk4BV2nDm31IVRXz42cPSW4rORSWFEvwqELXd7o4qHMJWGexk ERQA== X-Received: by 10.66.142.107 with SMTP id rv11mr8731580pab.17.1391787704295; Fri, 07 Feb 2014 07:41:44 -0800 (PST) Received: from LIZHONGJ ([221.131.128.205]) by mx.google.com with ESMTPSA id pe3sm14757207pbc.23.2014.02.07.07.41.37 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Feb 2014 07:41:43 -0800 (PST) From: "Lizhong Jin" To: "'Ross Callon'" , "'Eric Gray'" , "'Tarek Saad \(tsaad\)'" References: <1684242330fd4f2e98ae1a792d1639c1@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <1684242330fd4f2e98ae1a792d1639c1@CO2PR05MB636.namprd05.prod.outlook.com> Date: Fri, 7 Feb 2014 23:41:04 +0800 Message-ID: <000001cf241b$15a9a4f0$40fceed0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGaNIxzciPExEO4uTznjbYOEPYdYJsTxZyQ Content-Language: zh-cn Cc: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2014 15:41:46 -0000 Hi authors, I review this draft, and I think the problem the draft tries to solve is = a real problem in operational networks.=20 But from the technical point of view, whether RSVP-TE is the right = signaling protocol between primary and backup ingress node needs to be discussed = in the WG list. This document uses RSVP-TE as a pure signaling protocol between primary ingress and backup ingress node, to exchange necessary protection information. Then the behavior of RSVP-TE signaling on backup ingress = node will only exchange control information, but will not create any = forwarding status (for off-path case). Such kind of behavior is different with traditional RSVP-TE protocol.=20 1. This new behavior changes RSVP-TE fundamentally, and RSVP-TE becomes = a pure signaling protocol, not a path setup protocol between primary and backup node. 2. RSVP is a hop-by-hop protocol, and requires logical direct connection between primary ingress and backup ingress node, which is an additional burden for network operation.=20 Then I don't think RSVP-TE is a good candidate for the mechanism = described in this draft. Some TCP based signaling protocol maybe more suitable, = e.g, ICCP. The above personal concern is the technical direction of this draft, and = I think the WG should get consensus before adoption. Regards Lizhong > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: 2014=C4=EA1=D4=C223=C8=D5 0:19 > To: Eric Gray; Tarek Saad (tsaad); Lizhong Jin > Cc: mpls-chairs@tools.ietf.org; draft-chen-mpls-p2mp-ingress- > protection@tools.ietf.org; Martin Vigoureux > Subject: MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 >=20 > Eric, Tarek, Lizhong; >=20 > You have been selected as MPLS Review team reviewers for draft-chen- > mpls-p2mp-ingress-protection-10. >=20 > Note to authors: You have been CC'd on this email so that you can know that > this review is going on. However, please do not review your own = document. >=20 > Reviews should comment on whether the document is coherent, is it = 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). >=20 > 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. >=20 > Are you able to review this draft by February 6, 2014? >=20 > Thanks, Ross > (as MPLS WG chair) >=20 >=20 From internet-drafts@ietf.org Fri Feb 7 09:01:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564101A0421; Fri, 7 Feb 2014 09:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vcy88b-g6jgD; Fri, 7 Feb 2014 09:01:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 020C41AC4C5; Fri, 7 Feb 2014 09:01:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207170153.3588.50180.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 09:01:53 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-rekhter-mpls-pim-sm-over-mldp-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: Fri, 07 Feb 2014 17:01:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Authors : Yakov Rekhter Rahul Aggarwal Nicolai Leymann Wim Henderickx Quintin Zhao Richard Li Filename : draft-rekhter-mpls-pim-sm-over-mldp-08.txt Pages : 12 Date : 2014-02-07 Abstract: When IP multicast trees created by PIM-SM in Any Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switched Paths are established using mLDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rekhter-mpls-pim-sm-over-mldp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-rekhter-mpls-pim-sm-over-mldp-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-rekhter-mpls-pim-sm-over-mldp-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 yakov@juniper.net Fri Feb 7 09:07: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 608191ACCD8 for ; Fri, 7 Feb 2014 09:07:34 -0800 (PST) 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 Hc3WYsth0dXx for ; Fri, 7 Feb 2014 09:07:31 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3761E1ACC89 for ; Fri, 7 Feb 2014 09:07:31 -0800 (PST) Received: from mail95-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE016.bigfish.com (10.3.207.138) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Feb 2014 17:07:30 +0000 Received: from mail95-am1 (localhost [127.0.0.1]) by mail95-am1-R.bigfish.com (Postfix) with ESMTP id 731AD1403DF; Fri, 7 Feb 2014 17:07:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI936eI1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h1155h) Received-SPF: softfail (mail95-am1: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail95-am1 (localhost.localdomain [127.0.0.1]) by mail95-am1 (MessageSwitch) id 1391792848909095_27386; Fri, 7 Feb 2014 17:07:28 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.232]) by mail95-am1.bigfish.com (Postfix) with ESMTP id CF826120066; Fri, 7 Feb 2014 17:07:28 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Feb 2014 17:07:28 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 7 Feb 2014 09:07:24 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s17H7NL76696; Fri, 7 Feb 2014 09:07:23 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201402071707.s17H7NL76696@magenta.juniper.net> To: Loa Andersson In-Reply-To: <52F478A8.1000101@pi.nu> References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> <201312121651.rBCGpYL46117@magenta.juniper.net> <52F11FD8.3000000@pi.nu> <201402042158.s14LwnL93027@magenta.juniper.net> <52F1CC6F.1070906@pi.nu> <201402051430.s15EUML50526@magenta.juniper.net> <52F478A8.1000101@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Fri, 07 Feb 2014 14:09:44 +0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95450.1391792839.1@juniper.net> Date: Fri, 7 Feb 2014 09:07:19 -0800 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2014 17:07:34 -0000 Loa, > Yakov, > > > On 2014-02-05 22:30, Yakov Rekhter wrote: > > I agreed to the plan you proposed in your e-mail on Dec 4, 2013. > > According to this plan > > > > 1. Issue a single poll to adopt both documents together as > > working group documents > > > > However, what you doing now is*not* what you proposed in the plan, > > as now you issued a two week poll on adopting just > > draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working > > group document. > > > > Yakov. > > I found no way to hold the draft-wijnands-mpls-mldp-in-band-wildcard- > encoding further, it is almost 5 months since that document were ready > to move. > > However, I'm prepared to go to wg adoption poll on draft-rekhter- > mpls-pim-sm-over-mldp very quickly if the following update is made. > > OLD > > This document uses BGP Source Active auto-discovery routes, as > defined in [MVPN-BGP]. This document also identifies the deployment > scenarios where BGP Source Active auto-discovery routes will not be > used. > > NEW > > This document uses BGP Source Active auto-discovery routes, as > defined in [MVPN-BGP]. > > In a deployment scenario where the service provider has > provisioned the network in such a way that the RP for a particular > ASM group G is always between the receivers and the sources. If the > network is provisioned in this manner, the ingress PE for (S,G) > is always the same as the ingress PE for the RP, and thus the > Source Active A-D routes are never needed. If it is known a priori > that the network is provisioned in this manner, mLDP in-band > signaling can be supported using a simplified set of procedures. > Specification of the simplified procedures supporting this scenario > is outside the scope of the present document. See [draft-wijnands- > mpls-mldp-in-band-wildcard-encoding]. A service provider will > provision the PE routers either to use [draft-wijnands] procedures > or to use the procedures of this document. The revised draft (see below) contains the change you suggested above (with some minor edits). Given that, please do as you proposed in your plan on Dec 4, 2013 - issue a *single* poll to adopt *both* documents *together* as working group documents. Yakov. ----------------------------------------------------------------------------- Date: Fri, 07 Feb 2014 09:01:53 PST To: cc: From: Subject: I-D Action: draft-rekhter-mpls-pim-sm-over-mldp-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Authors : Yakov Rekhter Rahul Aggarwal Nicolai Leymann Wim Henderickx Quintin Zhao Richard Li Filename : draft-rekhter-mpls-pim-sm-over-mldp-08.txt Pages : 12 Date : 2014-02-07 Abstract: When IP multicast trees created by PIM-SM in Any Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switched Paths are established using mLDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rekhter-mpls-pim-sm-over-mldp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-rekhter-mpls-pim-sm-over-mldp-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-rekhter-mpls-pim-sm-over-mldp-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From tsaad@cisco.com Fri Feb 7 09:39: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 54CE91A0203 for ; Fri, 7 Feb 2014 09:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 Rg98zAILyFP6 for ; Fri, 7 Feb 2014 09:39:55 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C44AA1A0128 for ; Fri, 7 Feb 2014 09:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5096; q=dns/txt; s=iport; t=1391794795; x=1393004395; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JrcIr+zzBgktNHzzLEULqnfgYIK+u+vMWD7w75KBTBw=; b=bakROt0Cxne4CCHGpdBNnKYhnjz+qpz5vduuX6yKQoTURMJOLOZEzosG YzKCTtM94YUtyJ5UF+/IYhHjmT9K3Eesi6A3WdjbfyFlhgegJI7f2PeCY bc37d4nWrw0fdpgw3nd3zJkZuq2MagBYG0R0st1UnBhbi84Urb90ydap6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJQZ9VKtJXG+/2dsb2JhbABZgww4V75ogQ4WdIIlAQEBBAEBARoKEzEDCw4CAgEIGB4QGwYGCyUCBAENBYdxAxENw0gNiEQTBASMYoE1EQFQB4Q4BJY/gWyMXoVDgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,802,1384300800"; d="scan'208";a="302555130" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 07 Feb 2014 17:39:54 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s17HdsLO017193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 17:39:54 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 11:39:54 -0600 From: "Tarek Saad (tsaad)" To: Eric Osborne , "Andrew G. Malis" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-extended-admin-group Thread-Index: AQHPI1lvKVihJZqYOkiIWLXvq52Q3Zqo3LoA//+09oCAAFhwgIAAEPIAgAEmM4A= Date: Fri, 7 Feb 2014 17:39:53 +0000 Message-ID: References: <52F08085.9000907@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [161.44.212.58] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2014 17:39:57 -0000 Hi Eric, On 2014-02-06 2:06 PM, "Eric Osborne" wrote: >Hi Andy- > > So the concern is around how to handle the case where AG doesn't >match the first 32 bits of EAG. The current text in 2.3.1 says: > > >"If a node > advertises both AG and EAG then the first 32 bits of the EAG MUST be > identical to the advertised AG. If the AG and EAG advertised for a > link differ, the EAG MUST take priority." > >I think I can fix this by changing the second sentence to: > >"If a node > advertises both AG and EAG then the first 32 bits of the EAG MUST be > identical to the advertised AG. If a receiving node notices that >the AG differs from the first 32 bits of the EAG, it SHOULD use the AG >as the first 32 bits of the EAG, and MUST indicate this mismatch to >the operator." > >I very deliberately used 'SHOULD' because there is at least one >implementation already in production with the current logic and I >don't want to obsolete it to cover a corner case that's already >illegal and clearly a bug. > >Does that work? >Tarek, does that break anything in what's shipping? [TS]: yes, that would be a change of the current implementation-- which is as per the current version of the draft. Regards, Tarek > > > > >eric > >On Thu, Feb 6, 2014 at 1:06 PM, Andrew G. Malis wrote: >> Tarek, >> >> Imagine that you have a network that has been using AG and is >> transitioning to EAG. Since not all routers can be updated >> simultaneously, there will be a period where some will support both AG >> and EAG and others will only support AG. As long as AG and the first >> word of EAG are consistent, everything works well. But if a >> provisioning or software bug leads to the case where the two are >> inconsistent, option (2) will operate better than option (3), since >> with option (2), both old and new routers will be using a consistent >> set of bits 0-31. >> >> Cheers, >> Andy >> >> >> On Thu, Feb 6, 2014 at 12:49 PM, Tarek Saad (tsaad) >>wrote: >>> In case of inconsistency, see 3 options: >>> 1. use AG and discard EAG, i.e. ignore subsequent bits in (EAG) >>> 2. use AG for first word and subsequent bits from EAG bits >>> 3. use EAG and discard AG >>> >>> The way the draft puts it is EAG is a "superset" of AG. >>> >>> I'm in favour of 3) when router speaks/understands EAG. Just as it is >>>true >>> that for routers that speak/understand only AG, they'd use AG. >>> Note, my understanding is AG at sometime will become obsolete and >>> eventually most (if not all) routers will be speaking EAG. >>> >>> >>> Regards, >>> Tarek >>> >>> On 2014-02-06 12:18 PM, "Andrew G. Malis" wrote: >>> >>>>Tarek, >>>> >>>>In my earlier review, I argued the opposite for section 2.3.1, that AG >>>>MUST take priority over EAG for backwards compatibility. See my email >>>>for my reasoning. >>>> >>>>Cheers, >>>>Andy >>>> >>>>On Thu, Feb 6, 2014 at 11:35 AM, Tarek Saad (tsaad) >>>>wrote: >>>>> Hi, >>>>> >>>>> This document looks good, and addresses a real limitation with >>>>>existing >>>>> AGs. I think it is ready for publication. Few comments: >>>>> - section 2.3.1: prefer rewording to explicitly spell the behaviour >>>>>on a >>>>> receiving node that supports EAG.. example, "... EAG MUST take >>>>>priority >>>>>on >>>>> a receiving node that supports it." >>>>> >>>>> >>>>> minor edit comments: >>>>> - section 1, might want to define LSA, MTU before use >>>>> - section 2.3.2 equally applicable to AG too; maybe re-title as >>>>>"Desire >>>>> for unadvertised bits for AG/EAG"? >>>>> - typo in Section 2.3.2, "... assumption is than" -> "assumption is >>>>>that" >>>>> >>>>> Regards, >>>>> >>>>> Tarek >>>>> >>>>> On 2014-02-04 12:54 AM, "Loa Andersson" wrote: >>>>> >>>>>>Working Group, >>>>>> >>>>>>This is to initiate a working group last call on >>>>>>draft-ietf-mpls-extended-admin-group-02. >>>>>> >>>>>>There are no IPR disclosures against this document. The author has >>>>>>stated that he is unaware of any 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 Feb 18, 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 >>>>>>_______________________________________________ >>>>>>mpls mailing list >>>>>>mpls@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From tsaad@cisco.com Fri Feb 7 09:43: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 38B871AC7F3 for ; Fri, 7 Feb 2014 09:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 Co5QrkRcjFtr for ; Fri, 7 Feb 2014 09:43:31 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C8FA91AC7F1 for ; Fri, 7 Feb 2014 09:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1087; q=dns/txt; s=iport; t=1391795012; x=1393004612; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q5XyNdhV1QYF7ZsQqfa6fD34HG7fp2rfAHFnhjS8q60=; b=Y7z6U4PFrHnsTnsVxuhVkXyqxe8vm1cFbJt+5jAkg3HetDQIKLJ4lLF4 zUsYLbsUowkWFLf5b9en6Vcnd49prYmLMBPMUnTe0IWMrDqGON59/wRbU PstC9n+Dx4sMP7et8dhNz7xspAMTg7lxPGOBjMM7QzKGcVoKKpS9GgzJT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALka9VKtJXG9/2dsb2JhbABZgwyBD75ogQ4WdIImAQEEHR0/EAIBCDYQMiUCBAENBYgFzCkXjn0HhDgBA5grkiGDLYIq X-IronPort-AV: E=Sophos;i="4.95,802,1384300800"; d="scan'208";a="302579370" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 07 Feb 2014 17:43:31 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s17HhVBC030504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 17:43:31 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 11:43:30 -0600 From: "Tarek Saad (tsaad)" To: Eric Osborne , "Andrew G. Malis" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-extended-admin-group Thread-Index: AQHPJCwdHHwUi9ZymE+R4tMHMsvNgw== Date: Fri, 7 Feb 2014 17:43:30 +0000 Message-ID: References: <52F08085.9000907@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [161.44.212.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <1964A901B932FB4BA22336394EA8D9A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2014 17:43:33 -0000 Inline.. On 2014-02-06 2:14 PM, "Eric Osborne" wrote: >> >>[Technical] Section 2.3.2: I'm personally hard-pressed to find >>usefulness in the flexibility in this section. For maximum >>interoperability and simplicity of implementations, I would prefer >>that the third paragraph be modified to say: >> >> To encourage maximum interoperability an >> implementation MUST treat desired but unadvertised EAG bits as if >> they are set to 0. Consider the case where a node wants to only use >> links where the 127th bit of an EAG is set to 1. If a link is only >> advertising 64 EAG bits, clearly the 127th EAG bit is not defined - >> that is, it is neither explicitly 0 nor 1. The node which wants the >> 127th EAG bit to be 1 MUST NOT use this link, as the assumption is >> than an unadvertised bit is set to 0. >> > >EO# That works for me; you're basically doing s/SHOULD/MUST/. >Tarek? Thoughts? [TS]: yes, this is acceptable. BTW, I'd s/encourage/allow/ if MUST is what we'll have. Regards, Tarek > From huaimo.chen@huawei.com Fri Feb 7 14:49: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 225771AD669 for ; Fri, 7 Feb 2014 14:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 AJZi7uaKAr62 for ; Fri, 7 Feb 2014 14:49:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C2E891AD66B for ; Fri, 7 Feb 2014 14:49:00 -0800 (PST) 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 BDJ11196; Fri, 07 Feb 2014 22:48:58 +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; Fri, 7 Feb 2014 22:47:56 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 22:48:57 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 14:48:44 -0800 From: Huaimo Chen To: Lizhong Jin , "'Ross Callon'" , "'Eric Gray'" , "'Tarek Saad (tsaad)'" Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 Thread-Index: AQHPJBsjPH7KcPWk+ES1APWCB/RlLpqqAlCA Date: Fri, 7 Feb 2014 22:48:44 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C35C06@SJCEML701-CHM.china.huawei.com> References: <1684242330fd4f2e98ae1a792d1639c1@CO2PR05MB636.namprd05.prod.outlook.com> <000001cf241b$15a9a4f0$40fceed0$@gmail.com> In-Reply-To: <000001cf241b$15a9a4f0$40fceed0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.176] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C35C06SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2014 22:49:04 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C35C06SJCEML701CHMchi_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Thanks much for your comments! My explanations/answers are inline below. Best Regards, Huaimo -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, February 07, 2014 10:41 AM To: 'Ross Callon'; 'Eric Gray'; 'Tarek Saad (tsaad)' Cc: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org; mpls@ietf.org; = mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protecti= on-10 Hi authors, I review this draft, and I think the problem the draft tries to solve is a = real problem in operational networks. But from the technical point of view, whether RSVP-TE is the right signalin= g protocol between primary and backup ingress node needs to be discussed in= the WG list. This document uses RSVP-TE as a pure signaling protocol between primary ing= ress and backup ingress node, to exchange necessary protection information.= Then the behavior of RSVP-TE signaling on backup ingress node will only ex= change control information, but will not create any forwarding status (for = off-path case). Such kind of behavior is different with traditional RSVP-T= E protocol. 1. This new behavior changes RSVP-TE fundamentally, and RSVP-TE becomes a p= ure signaling protocol, not a path setup protocol between primary and backu= p node. 2. RSVP is a hop-by-hop protocol, and requires logical direct connection be= tween primary ingress and backup ingress node, which is an additional burde= n for network operation. Then I don't think RSVP-TE is a good candidate for the mechanism described = in this draft. Some TCP based signaling protocol maybe more suitable, e.g, = ICCP. [Huaimo (start)]: We considered to use other protocols such as OSPF as a signaling protocol b= etween a primary and a backup ingress node. In some early versions of the d= raft, there is a section about this. It seems that it is more complicated f= or us to use another protocol (e.g., OSPF/ICCP/BGP) as the signaling protoc= ol. If another protocol (e.g., OSPF/ICCP/BGP) is used, then two protocols need = to be changed and changed more. At first, the other protocol (e.g., OSPF/IC= CP/BGP) needs to be extended for transporting/exchanging the necessary prot= ection information between the primary ingress and backup ingress node. Secondly, this protocol component (e.g., OSPF/ICCP/BGP process/thread) has = to dynamically obtain the necessary protection information from protocol RS= VP-TE component on the primary ingress, and give the information to protoco= l RSVP-TE on the backup ingress node, and vise versa. Thirdly, RSVP-TE component (process/thread) is required to be extended for = receiving the protection information from another protocol component (e.g.,= OSPF/ICCP/BGP process/thread) and also providing the protection informatio= n to another protocol component. Moreover, RSVP-TE protocol needs to be extended for creating a backup LSP a= nd its corresponding states according to the protection information receive= d from another protocol. And so on. Using just one protocol RSVP-TE is simpler. A couple of new objects need to= be added to the existing RSVP-TE messages and used for transporting/exchan= ging the necessary protection information between the primary and backup in= gress. On the backup ingress, RSVP-TE creates a backup LSP and its correspo= nding states according to the protection information in the RSVP-TE message= s received from the primary ingress. [Huaimo (end)] The above personal concern is the technical direction of this draft, and I = think the WG should get consensus before adoption. Regards Lizhong > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: 2014=1B$BG/=1B(B1=1B$B7n=1B(B23=1B$BF|=1B(B 0:19 > To: Eric Gray; Tarek Saad (tsaad); Lizhong Jin > Cc: mpls-chairs@tools.ietf.org; draft-= chen-mpls-p2mp-ingress- > protection@tools.ietf.org; Martin Vigou= reux > Subject: MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 > > Eric, Tarek, Lizhong; > > You have been selected as MPLS Review team reviewers for draft-chen- > mpls-p2mp-ingress-protection-10. > > 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 February 6, 2014? > > Thanks, Ross > (as MPLS WG chair) > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_5316A0AB3C851246A7CA5758973207D445C35C06SJCEML701CHMchi_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi Lizhong,
 
    Thanks much for your comments!
    My explanations/answers are inline below.
 
Best Regards,
Huaimo
-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Lizhong Jin
Sent: Friday, February 07, 2014 10:41 AM
To: 'Ross Callon'; 'Eric Gray'; 'Tarek Saad (tsaad)'
Cc: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org; mpls@ietf.org; = mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protecti= on-10
 
Hi authors,
I review this draft, and I think the problem the draft tries to solve = is a real problem in operational networks.
But from the technical point of view, whether RSVP-TE is the right sig= naling protocol between primary and backup ingress node needs to be discuss= ed in the WG list.
This document uses RSVP-TE as a pure signaling protocol between primar= y ingress and backup ingress node, to exchange necessary protection informa= tion. Then the behavior of RSVP-TE signaling on backup ingress node will on= ly exchange control information, but will not create any forwarding status (for off-path case).  Such k= ind of behavior is different with traditional RSVP-TE protocol.
1. This new behavior changes RSVP-TE fundamentally, and RSVP-TE become= s a pure signaling protocol, not a path setup protocol between primary and = backup node.
2. RSVP is a hop-by-hop protocol, and requires logical direct connecti= on between primary ingress and backup ingress node, which is an additional = burden for network operation.
Then I don't think RSVP-TE is a good candidate for the mechanism descr= ibed in this draft. Some TCP based signaling protocol maybe more suitable, = e.g, ICCP.
 
[Huaimo (start)]:
We considered to use other protocols such as OSPF= as a signaling protocol between a primary and a backup ingress node. In so= me early versions of the draft, there is a section about this. It seems tha= t it is more complicated for us to use another protocol (e.g., OSPF/ICCP/BGP) as the signaling protocol.
If another protocol (e.g., OSPF/ICCP/BGP) is used= , then two protocols need to be changed and changed more. At first, the oth= er protocol (e.g., OSPF/ICCP/BGP) needs to be extended for transporting/exc= hanging the necessary protection information between the primary ingress and backup ingress node.
Secondly, this protocol component (e.g., OSPF/ICC= P/BGP process/thread) has to dynamically obtain the necessary protection in= formation from protocol RSVP-TE component on the primary ingress, and give = the information to protocol RSVP-TE on the backup ingress node, and vise versa.
Thirdly, RSVP-TE component (process/thread) is re= quired to be extended for receiving the protection information from another= protocol component (e.g., OSPF/ICCP/BGP process/thread) and also providing= the protection information to another protocol component.
Moreover, RSVP-TE protocol needs to be extended f= or creating a backup LSP and its corresponding states according to the prot= ection information received from another protocol. And so on.
 
Using just one protocol RSVP-TE is simpler. A cou= ple of new objects need to be added to the existing RSVP-TE messages and us= ed for transporting/exchanging the necessary protection information between= the primary and backup ingress. On the backup ingress, RSVP-TE creates a backup LSP and its corresponding stat= es according to the protection information in the RSVP-TE messages received= from the primary ingress.
[Huaimo (end)]
 
The above personal concern is the technical direction of this draft, a= nd I think the WG should get consensus before adoption.
 
Regards
Lizhong
 
 
> -----Original Message-----
> From: Ross Callon [mailto:= rcallon@juniper.net]
> Sent: 2014=1B$BG/=1B(B1=1B$B7n=1B(B23=1B$BF|=1B(B 0:19
> To: Eric Gray; Tarek Saad (tsaad); Lizhong Jin
> Cc: mpls-chairs@too= ls.ietf.org; draft-chen-mpls-p2mp-ingress-
> protection@tools.iet= f.org; Martin Vigoureux
> Subject: MPLS-RT review of draft-chen-mpls-p2mp-ingress-protectio= n-10
>
> Eric, Tarek, Lizhong;
>
> You have been selected as MPLS Review team reviewers for draft-ch= en-
> mpls-p2mp-ingress-protection-10.
>
> 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.
>
> 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 <= /div>
> 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, Comm= ents
> may be sent privately to only the WG chairs.
>
> Are you able to review this draft by February 6, 2014?
>
> Thanks, Ross
> (as MPLS WG chair)
>
>
 
 
_______________________________________________
mpls mailing list
 
 --_000_5316A0AB3C851246A7CA5758973207D445C35C06SJCEML701CHMchi_-- From loa@pi.nu Fri Feb 7 21:05: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 866481A0294 for ; Fri, 7 Feb 2014 21:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ua7YwYx-2Ex for ; Fri, 7 Feb 2014 21:05:34 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 19A6F1ADDBD for ; Fri, 7 Feb 2014 21:05:34 -0800 (PST) Received: from [192.168.1.5] (unknown [119.95.153.237]) (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 643F6180158F; Sat, 8 Feb 2014 06:05:32 +0100 (CET) Message-ID: <52F5BB13.9060001@pi.nu> Date: Sat, 08 Feb 2014 13:05:23 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] mpls i London X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 08 Feb 2014 05:05:36 -0000 Working Group, We have the final agenda for the London IETF: https://datatracker.ietf.org/meeting/89/agenda.html We will have two slots for the mpls wg in London Tuesday 13.00-14.00 Sovereign RTG mpls Multiprotocol Label Switching Thursday 15.20-18.30 Sovereign RTG mpls Multiprotocol Label Switching The schedule is "unusual" in that it start with the short slot. Also note that the is a 10 minute break in second slot, but we are not going to bother about that and use all 190min if we need to, otherwise finish early. The "Bits-n-Bites" session will take place after the mpls meeting. The wg chairs has just started to look at the agenda, please look up Martin's mail and send us your slot requests according to the format Martin gave. See you in London! /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 jrjahangir@gmail.com Sat Feb 8 00:18: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 A90131A05C5 for ; Sat, 8 Feb 2014 00:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTyXwlUFIe5a for ; Sat, 8 Feb 2014 00:18:32 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B410B1A0502 for ; Sat, 8 Feb 2014 00:18:32 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id e9so7759578qcy.1 for ; Sat, 08 Feb 2014 00:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8DhzzEYi08HMZnUNfAcp85ETasqjc/mYlFc/1r4cjqw=; b=xkuSHoMVPhAcK5mEyuu4I2pa1P8ipeyZhcAUFWmRKOKa3/Lv4v3MtrOwfVXLf+HeL+ kp2mi+nFkeBjLbvfLrLbqHoW8Gjzmj0E1Qi8IkeOuG8hEuOGYh7iH6PC7kJ/cg+CRyXZ z0qIi0VMGNkqZFTDe1Bp3PvsAp0ko2Oo16PuLGBnM6NINNgyCYmYctznp+pkrae3WuhZ OG5bxHNFUnYDsE/KNtlIW1eZnDWmGJdhsoahbCgbeKv45VxmzesJIUiPvjg0C93Btxnp Srq75IadSrwegUjr68F1zVNCykOS4TOnhWiJlPFIEjAi0tKBdi7oicK8iRr/3Q3FCbhV S9tQ== MIME-Version: 1.0 X-Received: by 10.229.179.69 with SMTP id bp5mr12143248qcb.17.1391847512199; Sat, 08 Feb 2014 00:18:32 -0800 (PST) Received: by 10.140.41.180 with HTTP; Sat, 8 Feb 2014 00:18:32 -0800 (PST) In-Reply-To: <52F5BB13.9060001@pi.nu> References: <52F5BB13.9060001@pi.nu> Date: Sat, 8 Feb 2014 14:18:32 +0600 Message-ID: From: Jahangir Hossain To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c2bf4e8bd80704f1e0c052 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] mpls i London X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 08 Feb 2014 08:18:34 -0000 --001a11c2bf4e8bd80704f1e0c052 Content-Type: text/plain; charset=ISO-8859-1 Thanks Loa for sharing this information. Regards // Jahangir On Sat, Feb 8, 2014 at 11:05 AM, Loa Andersson wrote: > Working Group, > > We have the final agenda for the London IETF: > https://datatracker.ietf.org/meeting/89/agenda.html > > We will have two slots for the mpls wg in London > > Tuesday 13.00-14.00 Sovereign RTG mpls Multiprotocol Label Switching > Thursday 15.20-18.30 Sovereign RTG mpls Multiprotocol Label Switching > > The schedule is "unusual" in that it start with the short slot. Also > note that the is a 10 minute break in second slot, but we are not > going to bother about that and use all 190min if we need to, otherwise > finish early. The "Bits-n-Bites" session will take place after the mpls > meeting. > > The wg chairs has just started to look at the agenda, please look up > Martin's mail and send us your slot requests according to the format > Martin gave. > > See you in London! > > /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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- --001a11c2bf4e8bd80704f1e0c052 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Loa for sharing this information.




Regards // =A0= Jahangir

On Sat, Feb 8, 201= 4 at 11:05 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

We have the final agenda for the London IETF:
https://datatracker.ietf.org/meeting/89/agenda.html

We will have two slots for the mpls wg in London

Tuesday =A0 13.00-14.00 Sovereign RTG mpls Multiprotocol Label Switching Thursday =A015.20-18.30 Sovereign RTG mpls Multiprotocol Label Switching
The schedule is "unusual" in that it start with the short slot. A= lso
note that the is a 10 minute break in second slot, but we are not
going to bother about that and use all 190min if we need to, otherwise
finish early. The "Bits-n-Bites" session will take place after th= e mpls
meeting.

The wg chairs has just started to look at the agenda, please look up
Martin's mail and send us your slot requests according to the format Martin gave.

See you in London!

/Loa
for the mpls wg chairs
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
<= br>
=A0

=A0 =A0 =A0

--001a11c2bf4e8bd80704f1e0c052-- From loa@pi.nu Sat Feb 8 01:13: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 6164C1ADF4B for ; Sat, 8 Feb 2014 01:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcilXKOknL4m for ; Sat, 8 Feb 2014 01:13:42 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1AC1AD7C2 for ; Sat, 8 Feb 2014 01:13:42 -0800 (PST) Received: from [192.168.1.5] (unknown [119.95.153.237]) (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 4E98A180158F; Sat, 8 Feb 2014 10:13:40 +0100 (CET) Message-ID: <52F5F53A.9010107@pi.nu> Date: Sat, 08 Feb 2014 17:13:30 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 09:13:47 -0000 Working Group, This is to start a two week poll on adopting draft-rekhter-mpls-pim-sm-over-mld as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. Please note that we have identified an overlap between this document and draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document includes text to cover this. There are 1 IPR claim against this document. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends February 22, 2014. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From wim.henderickx@alcatel-lucent.com Sat Feb 8 02:13: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 6A0D01A0456 for ; Sat, 8 Feb 2014 02:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 em7j7w7v_ITM for ; Sat, 8 Feb 2014 02:13:18 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id A28951A020E for ; Sat, 8 Feb 2014 02:13:18 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s18ADFqd017927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 8 Feb 2014 04:13:17 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s18ADDSC010347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Feb 2014 11:13:13 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.30]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sat, 8 Feb 2014 11:13:13 +0100 From: "Henderickx, Wim (Wim)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4bLIktP/Nhs0iDM1GeH9Z+IpqrI10A Date: Sat, 8 Feb 2014 10:13:13 +0000 Message-ID: References: <52F5F53A.9010107@pi.nu> In-Reply-To: <52F5F53A.9010107@pi.nu> Accept-Language: nl-BE, 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: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <11229638E20E404FA4138C5C4392D3FB@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 10:13:20 -0000 Support as co-author On 08/02/14 10:13, "Loa Andersson" wrote: > >Working Group, > >This is to start a two week poll on adopting >draft-rekhter-mpls-pim-sm-over-mld as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >Please note that we have identified an overlap between this document >and draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document >includes text to cover this. > >There are 1 IPR claim against this document. > >The authors has stated on the working group mailing list >that they are not aware of any other IPR claims against this draft. > >However if you are on the the mpls working group mailing list and >aware of IPR that relates to this draft, the time to disclose >this is now. > >This poll ends February 22, 2014. > >/Loa >(mpls wg co-chair) >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Sat Feb 8 02:20: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 60FB71A0292 for ; Sat, 8 Feb 2014 02:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHkoluwKDlhb for ; Sat, 8 Feb 2014 02:20:34 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEFD1A020E for ; Sat, 8 Feb 2014 02:20:33 -0800 (PST) Received: from [192.168.1.4] (unknown [112.208.36.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F07CF180158F; Sat, 8 Feb 2014 11:20:30 +0100 (CET) Message-ID: <52F604E5.4090701@pi.nu> Date: Sat, 08 Feb 2014 18:20:21 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yakov Rekhter References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> <201312121651.rBCGpYL46117@magenta.juniper.net> <52F11FD8.3000000@pi.nu> <201402042158.s14LwnL93027@magenta.juniper.net> <52F1CC6F.1070906@pi.nu> <201402051430.s15EUML50526@magenta.juniper.net> <52F478A8.1000101@pi.nu> <201402071707.s17H7NL76696@magenta.juniper.net> In-Reply-To: <201402071707.s17H7NL76696@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 08 Feb 2014 10:20:35 -0000 Yakov, On 2014-02-08 01:07, Yakov Rekhter wrote: > Given that, please do as you proposed in your plan on Dec 4, 2013 - > issue a*single* poll to adopt*both* documents*together* as working > group documents. > > Yakov. If you mean that it will send one single mail to the working group for the adoption poll I will not do that. I've done that mistake and it is very hard to sort the comments in such a way that I have them available when I need the for a particular document. Also, the mail you quote is not a promise to adopt *both* documents, that it up to how the shepherd/chairs evaluate the responses we get on the poll. The *togetherness* you get here is that the polls for the documents are started reasonable close together. And - the feedback will be evaluated for each document independently. Sorry if that was not clear from the December mail, but it hs been a very longstanding IETF practice. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From agmalis@gmail.com Sat Feb 8 07:54: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 9A7C51A03A5 for ; Sat, 8 Feb 2014 07:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 KUtqdjxaRfLM for ; Sat, 8 Feb 2014 07:54:32 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C10071A033A for ; Sat, 8 Feb 2014 07:54:32 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id o15so7078608qap.2 for ; Sat, 08 Feb 2014 07:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f5OeqWtt9a4HXO1LQVbaNLpu8MCeHI/b0ENEddNfqu8=; b=w6bMhbs1oSANMGj67BGlXlxLHDHlrgB6rp4Bk5+oCrJJfiMJSbFmDdjiRLxkVAVyKF i9eVKFVT0R7892+Hn56mIk4WckJV9EQxdh2oxwsXTzjZjgtHMd7rx7puV8QhjIBe0xK/ aF+0hKWpd8Kfb/Mg8laz89Xj4gK1EeuBAMKC+XgCQTdW96xVg20ADA1vz+V0NwsP1yGA 3h8vZAWwzuMKPUIVqZAG8OmgZbTiZsn3Ii/9c7mcmAGou/nur3jkeqa7JHU19p4IbeLq cg4NA6E7oZCxM6u/3We49pEgDIdcqMRZt2gjziKGN6iXkYHrG8PznN5UeeXT3Vf7vbV1 5Ovg== X-Received: by 10.224.172.133 with SMTP id l5mr32577240qaz.25.1391874873229; Sat, 08 Feb 2014 07:54:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Sat, 8 Feb 2014 07:54:13 -0800 (PST) In-Reply-To: References: <52F08085.9000907@pi.nu> From: "Andrew G. Malis" Date: Sat, 8 Feb 2014 10:54:13 -0500 Message-ID: To: "Tarek Saad (tsaad)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 08 Feb 2014 15:54:34 -0000 s/encourage/allow/ looks good to me as well. Cheers, Andy On Fri, Feb 7, 2014 at 12:43 PM, Tarek Saad (tsaad) wrote: > Inline.. > > On 2014-02-06 2:14 PM, "Eric Osborne" wrote: > >>> >>>[Technical] Section 2.3.2: I'm personally hard-pressed to find >>>usefulness in the flexibility in this section. For maximum >>>interoperability and simplicity of implementations, I would prefer >>>that the third paragraph be modified to say: >>> >>> To encourage maximum interoperability an >>> implementation MUST treat desired but unadvertised EAG bits as if >>> they are set to 0. Consider the case where a node wants to only use >>> links where the 127th bit of an EAG is set to 1. If a link is only >>> advertising 64 EAG bits, clearly the 127th EAG bit is not defined - >>> that is, it is neither explicitly 0 nor 1. The node which wants the >>> 127th EAG bit to be 1 MUST NOT use this link, as the assumption is >>> than an unadvertised bit is set to 0. >>> >> >>EO# That works for me; you're basically doing s/SHOULD/MUST/. >>Tarek? Thoughts? > [TS]: yes, this is acceptable. BTW, I'd s/encourage/allow/ if MUST is what > we'll have. > > Regards, > Tarek > >> > From agmalis@gmail.com Sat Feb 8 07:56: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 16E821A0339 for ; Sat, 8 Feb 2014 07:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 eQYH4bCzX0Y9 for ; Sat, 8 Feb 2014 07:56:47 -0800 (PST) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6D1A0144 for ; Sat, 8 Feb 2014 07:56:47 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id w8so7189255qac.28 for ; Sat, 08 Feb 2014 07:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eBofXTnh8H0n664RymX488umDQ8e7y+PzkiQfEjMU1g=; b=IDyt06U/Mek3chynUduFWmMeuV3kyHx0OUQMH5bffKGCsC1NpgjlTk8K6zA4KzpZYx 4/kRU07pYskvFg4t/FU90QALXj0RJxq+IydWP0DJtuPiXNjmLbmzch82EETHLZ4SV/GM UaCKFkl7B5GCA7mvCJlluWRFgLMk4E8/ecFRCJ2SmgH2s+NyCfkmpqYHEDfNGYA+pJe3 DFuKkrp6Lma7KI0/ZHXbf+uir6NWXN6M7tFHqQIrdgBXqDolk64/OUffOUfmczLaqPOW 00FfnlXNEgj72b7xsuonl/IpTrREndtjLuT31f1v1ScaCNATskm65E5YL8c6m8Dx/iff 38dQ== X-Received: by 10.140.31.75 with SMTP id e69mr30548350qge.76.1391875007509; Sat, 08 Feb 2014 07:56:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Sat, 8 Feb 2014 07:56:27 -0800 (PST) In-Reply-To: References: <52F08085.9000907@pi.nu> From: "Andrew G. Malis" Date: Sat, 8 Feb 2014 10:56:27 -0500 Message-ID: To: "Tarek Saad (tsaad)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 08 Feb 2014 15:56:50 -0000 Tarek, SHOULD will still allow the current implementation (while encouraging you to update it to the final text). Cheers, Andy On Fri, Feb 7, 2014 at 12:39 PM, Tarek Saad (tsaad) wrote: > Hi Eric, > > On 2014-02-06 2:06 PM, "Eric Osborne" wrote: > >>Hi Andy- >> >> So the concern is around how to handle the case where AG doesn't >>match the first 32 bits of EAG. The current text in 2.3.1 says: >> >> >>"If a node >> advertises both AG and EAG then the first 32 bits of the EAG MUST be >> identical to the advertised AG. If the AG and EAG advertised for a >> link differ, the EAG MUST take priority." >> >>I think I can fix this by changing the second sentence to: >> >>"If a node >> advertises both AG and EAG then the first 32 bits of the EAG MUST be >> identical to the advertised AG. If a receiving node notices that >>the AG differs from the first 32 bits of the EAG, it SHOULD use the AG >>as the first 32 bits of the EAG, and MUST indicate this mismatch to >>the operator." >> >>I very deliberately used 'SHOULD' because there is at least one >>implementation already in production with the current logic and I >>don't want to obsolete it to cover a corner case that's already >>illegal and clearly a bug. >> >>Does that work? >>Tarek, does that break anything in what's shipping? > [TS]: yes, that would be a change of the current implementation-- which is > as per the current version of the draft. > > Regards, > Tarek > >> >> >> >> >>eric >> >>On Thu, Feb 6, 2014 at 1:06 PM, Andrew G. Malis wrote: >>> Tarek, >>> >>> Imagine that you have a network that has been using AG and is >>> transitioning to EAG. Since not all routers can be updated >>> simultaneously, there will be a period where some will support both AG >>> and EAG and others will only support AG. As long as AG and the first >>> word of EAG are consistent, everything works well. But if a >>> provisioning or software bug leads to the case where the two are >>> inconsistent, option (2) will operate better than option (3), since >>> with option (2), both old and new routers will be using a consistent >>> set of bits 0-31. >>> >>> Cheers, >>> Andy >>> >>> >>> On Thu, Feb 6, 2014 at 12:49 PM, Tarek Saad (tsaad) >>>wrote: >>>> In case of inconsistency, see 3 options: >>>> 1. use AG and discard EAG, i.e. ignore subsequent bits in (EAG) >>>> 2. use AG for first word and subsequent bits from EAG bits >>>> 3. use EAG and discard AG >>>> >>>> The way the draft puts it is EAG is a "superset" of AG. >>>> >>>> I'm in favour of 3) when router speaks/understands EAG. Just as it is >>>>true >>>> that for routers that speak/understand only AG, they'd use AG. >>>> Note, my understanding is AG at sometime will become obsolete and >>>> eventually most (if not all) routers will be speaking EAG. >>>> >>>> >>>> Regards, >>>> Tarek >>>> >>>> On 2014-02-06 12:18 PM, "Andrew G. Malis" wrote: >>>> >>>>>Tarek, >>>>> >>>>>In my earlier review, I argued the opposite for section 2.3.1, that AG >>>>>MUST take priority over EAG for backwards compatibility. See my email >>>>>for my reasoning. >>>>> >>>>>Cheers, >>>>>Andy >>>>> >>>>>On Thu, Feb 6, 2014 at 11:35 AM, Tarek Saad (tsaad) >>>>>wrote: >>>>>> Hi, >>>>>> >>>>>> This document looks good, and addresses a real limitation with >>>>>>existing >>>>>> AGs. I think it is ready for publication. Few comments: >>>>>> - section 2.3.1: prefer rewording to explicitly spell the behaviour >>>>>>on a >>>>>> receiving node that supports EAG.. example, "... EAG MUST take >>>>>>priority >>>>>>on >>>>>> a receiving node that supports it." >>>>>> >>>>>> >>>>>> minor edit comments: >>>>>> - section 1, might want to define LSA, MTU before use >>>>>> - section 2.3.2 equally applicable to AG too; maybe re-title as >>>>>>"Desire >>>>>> for unadvertised bits for AG/EAG"? >>>>>> - typo in Section 2.3.2, "... assumption is than" -> "assumption is >>>>>>that" >>>>>> >>>>>> Regards, >>>>>> >>>>>> Tarek >>>>>> >>>>>> On 2014-02-04 12:54 AM, "Loa Andersson" wrote: >>>>>> >>>>>>>Working Group, >>>>>>> >>>>>>>This is to initiate a working group last call on >>>>>>>draft-ietf-mpls-extended-admin-group-02. >>>>>>> >>>>>>>There are no IPR disclosures against this document. The author has >>>>>>>stated that he is unaware of any 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 Feb 18, 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 >>>>>>>_______________________________________________ >>>>>>>mpls mailing list >>>>>>>mpls@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/mpls >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > From yakov@juniper.net Sat Feb 8 16:01:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BA81A064B for ; Sat, 8 Feb 2014 16:01:06 -0800 (PST) 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 irD7uQelfhib for ; Sat, 8 Feb 2014 16:01:04 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 10A2E1A064A for ; Sat, 8 Feb 2014 16:01:03 -0800 (PST) Received: from mail109-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.22; Sun, 9 Feb 2014 00:01:03 +0000 Received: from mail109-am1 (localhost [127.0.0.1]) by mail109-am1-R.bigfish.com (Postfix) with ESMTP id 7FFEF3A0D45; Sun, 9 Feb 2014 00:01:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz62a3I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh1de097hz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h1155h) Received-SPF: softfail (mail109-am1: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail109-am1 (localhost.localdomain [127.0.0.1]) by mail109-am1 (MessageSwitch) id 1391904061664837_15008; Sun, 9 Feb 2014 00:01:01 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.250]) by mail109-am1.bigfish.com (Postfix) with ESMTP id 9E0D5240066; Sun, 9 Feb 2014 00:01:01 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 9 Feb 2014 00:01:01 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 8 Feb 2014 16:00:57 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s1900nL97658; Sat, 8 Feb 2014 16:00:55 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201402090000.s1900nL97658@magenta.juniper.net> To: Loa Andersson In-Reply-To: <52F5F53A.9010107@pi.nu> References: <52F5F53A.9010107@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Sat, 08 Feb 2014 17:13:30 +0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24939.1391904049.1@juniper.net> Date: Sat, 8 Feb 2014 16:00:49 -0800 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 00:01:06 -0000 Loa, > > Working Group, > > This is to start a two week poll on adopting > draft-rekhter-mpls-pim-sm-over-mld as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > Please note that we have identified an overlap between this document > and draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document > includes text to cover this. > > There are 1 IPR claim against this document. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends February 22, 2014. support as co-author Yakov. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > From internet-drafts@ietf.org Sat Feb 8 20:50: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 2E5451A0353; Sat, 8 Feb 2014 20:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe4KtU4rhF0A; Sat, 8 Feb 2014 20:50:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF281A0008; Sat, 8 Feb 2014 20:50:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140209045019.7359.77582.idtracker@ietfa.amsl.com> Date: Sat, 08 Feb 2014 20:50:19 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-psc-itu-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: Sun, 09 Feb 2014 04:50: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 : MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators Authors : Jeong-dong Ryoo Eric Gray Huub van Helvoort Alessandro D'Alessandro Taesik Cheung Eric Osborne Filename : draft-ietf-mpls-tp-psc-itu-02.txt Pages : 38 Date : 2014-02-08 Abstract: This document describes alternate mechanisms to perform some of the sub-functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-psc-itu-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-psc-itu-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 ryoo@etri.re.kr Sat Feb 8 21:01: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 128F81A0353 for ; Sat, 8 Feb 2014 21:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 2cbQ6IuK3m66 for ; Sat, 8 Feb 2014 21:01:35 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 07CB61A0347 for ; Sat, 8 Feb 2014 21:01:34 -0800 (PST) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 9 Feb 2014 14:01:31 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP3.etri.info ([169.254.157.203]) with mapi id 14.01.0355.002; Sun, 9 Feb 2014 14:01:33 +0900 From: "Ryoo, Jeong-dong" To: "mpls@ietf.org" Thread-Topic: New (02) version of draft-ietf-mpls-tp-psc-itu Thread-Index: AQHPJVQA61zfQQGGJkCW1HPlV9+E9A== Date: Sun, 9 Feb 2014 05:01:32 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18@SMTP2.etri.info> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18SMTP2etriinfo_" MIME-Version: 1.0 Subject: [mpls] New (02) version of draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Feb 2014 05:01:38 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoZSAwMiB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1 IGhhcyBiZWVuIHVwbG9hZGVkLg0KSW4gdGhpcyB2ZXJzaW9uLCB0aGUgQXV0aG9ycyBvZiB0aGlz IGRvY3VtZW50IGhhdmUgYmVlbiBhYmxlIHRvIGFjY29tbW9kYXRlIGFsbCB0aGUgY29tbWVudHMg cmFpc2VkIGR1cmluZyB0aGUgTVBMUyBXRyBMQw0KZXhjZXB0IHRoZSBvbmUgb24gdGhlIHZlcnNp b24gbnVtYmVyIGNoYW5nZSBmcm9tIFlhYWNvdi4NClRoYW5rcyBmb3IgdGhvc2Ugd2hvIHNlbnQg dGhlaXIgY29tbWVudHMgdG8gdGhlIFdHIGxpc3Qgb3IgdG8gdGhlIGF1dGhvcnMgb2ZmIHRoZSBs aXN0Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU2VudCA6IDIwMTQtMDItMDkgMTM6NTE6MDggKCAr MDk6MDAgKQ0KVG8gOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcgPGktZC1hbm5vdW5jZUBpZXRmLm9y Zz4NCkNjIDogbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4NClN1YmplY3QgOiBbbXBsc10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDIudHh0DQoNCg0KQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlw cm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KVGl0 bGUgOiBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBMaW5lYXIgUHJvdGVjdGlvbiB0 byBNYXRjaCB0aGUgT3BlcmF0aW9uYWwgRXhwZWN0YXRpb25zIG9mIFNESCwgT1ROIGFuZCBFdGhl cm5ldCBUcmFuc3BvcnQgTmV0d29yayBPcGVyYXRvcnMNCkF1dGhvcnMgOiBKZW9uZy1kb25nIFJ5 b28NCkVyaWMgR3JheQ0KSHV1YiB2YW4gSGVsdm9vcnQNCkFsZXNzYW5kcm8gRCdBbGVzc2FuZHJv DQpUYWVzaWsgQ2hldW5nDQpFcmljIE9zYm9ybmUNCkZpbGVuYW1lIDogZHJhZnQtaWV0Zi1tcGxz LXRwLXBzYy1pdHUtMDIudHh0DQpQYWdlcyA6IDM4DQpEYXRlIDogMjAxNC0wMi0wOA0KDQpBYnN0 cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFsdGVybmF0ZSBtZWNoYW5pc21zIHRvIHBl cmZvcm0gc29tZSBvZiB0aGUNCnN1Yi1mdW5jdGlvbnMgb2YgTVBMUyBUcmFuc3BvcnQgUHJvZmls ZSAoTVBMUy1UUCkgbGluZWFyIHByb3RlY3Rpb24NCmRlZmluZWQgaW4gUkZDIDYzNzgsIGFuZCBh bHNvIGRlZmluZXMgYWRkaXRpb25hbCBtZWNoYW5pc21zLiBUaGUNCnB1cnBvc2Ugb2YgdGhlc2Ug YWx0ZXJuYXRlIGFuZCBhZGRpdGlvbmFsIG1lY2hhbmlzbXMgaXMgdG8gcHJvdmlkZQ0Kb3BlcmF0 b3IgY29udHJvbCBhbmQgZXhwZXJpZW5jZSB0aGF0IG1vcmUgY2xvc2VseSBtb2RlbHMgdGhlIGJl aGF2aW9yDQpvZiBsaW5lYXIgcHJvdGVjdGlvbiBzZWVuIGluIG90aGVyIHRyYW5zcG9ydCBuZXR3 b3Jrcy4NCg0KVGhpcyBkb2N1bWVudCBhbHNvIGludHJvZHVjZXMgY2FwYWJpbGl0aWVzIGFuZCBt b2RlcyBmb3IgbGluZWFyDQpwcm90ZWN0aW9uLiBBIGNhcGFiaWxpdHkgaXMgYW4gaW5kaXZpZHVh bCBiZWhhdmlvciwgYW5kIGEgbW9kZSBpcyBhDQpwYXJ0aWN1bGFyIGNvbWJpbmF0aW9uIG9mIGNh cGFiaWxpdGllcy4gVHdvIG1vZGVzIGFyZSBkZWZpbmVkIGluDQp0aGlzIGRvY3VtZW50OiBQcm90 ZWN0aW9uIFN0YXRlIENvb3JkaW5hdGlvbiAoUFNDKSBtb2RlIGFuZCBBdXRvbWF0aWMNClByb3Rl Y3Rpb24gU3dpdGNoaW5nIChBUFMpIG1vZGUuDQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRo ZSBiZWhhdmlvciBvZiB0aGUgUFNDIHByb3RvY29sIGluY2x1ZGluZw0KcHJpb3JpdHkgbG9naWMg YW5kIHN0YXRlIG1hY2hpbmUgd2hlbiBhbGwgdGhlIGNhcGFiaWxpdGllcyBhc3NvY2lhdGVkDQp3 aXRoIHRoZSBBUFMgbW9kZSBhcmUgZW5hYmxlZC4NCg0KVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJG QyA2Mzc4IGluIHRoYXQgdGhlIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudA0KbWV0aG9kIGRlZmlu ZWQgaGVyZSBpcyBhbiBhZGRpdGlvbiB0byB0aGF0IGRvY3VtZW50Lg0KDQoNClRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUvDQoNClRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDINCg0KQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDINCg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5EZWFyIGFsbCw8L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij5UaGUgMDImbmJzcDt2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1 Jm5ic3A7aGFzIGJlZW4mbmJzcDt1cGxvYWRlZC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij5JbiB0aGlzIHZlcnNpb24sIHRoZSBBdXRob3JzIG9mIHRoaXMgZG9jdW1lbnQg aGF2ZSBiZWVuIGFibGUgdG8gYWNjb21tb2RhdGUgYWxsIHRoZSBjb21tZW50cyByYWlzZWQgZHVy aW5nIHRoZSBNUExTIFdHIExDDQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 Ij5leGNlcHQgdGhlIG9uZSBvbiB0aGUgdmVyc2lvbiBudW1iZXIgY2hhbmdlJm5ic3A7ZnJvbSBZ YWFjb3YuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+VGhhbmtzIGZvciB0 aG9zZSB3aG8gc2VudCB0aGVpciBjb21tZW50cyB0byB0aGUgV0cgbGlzdCBvciB0byB0aGUmbmJz cDthdXRob3JzJm5ic3A7b2ZmIHRoZSBsaXN0LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkJl c3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8 L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KPGJyPg0KJm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxTaWduIj48YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmcXVvdDsgJmx0O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTQtMDItMDkgMTM6NTE6MDggKCAmIzQzOzA5OjAw ICk8YnI+DQo8Yj5UbyA6IDwvYj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmcgJmx0O2ktZC1hbm5vdW5j ZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYyA6IDwvYj5tcGxzQGlldGYub3JnICZsdDttcGxzQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+W21wbHNdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtbXBscy10cC1wc2MtaXR1LTAyLnR4dDxicj4NCjxicj4NCjxicj4NCkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNdWx0aXBy b3RvY29sIExhYmVsIFN3aXRjaGluZyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCjxi cj4NClRpdGxlIDogTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgTGluZWFyIFByb3Rl Y3Rpb24gdG8gTWF0Y2ggdGhlIE9wZXJhdGlvbmFsIEV4cGVjdGF0aW9ucyBvZiBTREgsIE9UTiBh bmQgRXRoZXJuZXQgVHJhbnNwb3J0IE5ldHdvcmsgT3BlcmF0b3JzPGJyPg0KQXV0aG9ycyA6IEpl b25nLWRvbmcgUnlvbzxicj4NCkVyaWMgR3JheTxicj4NCkh1dWIgdmFuIEhlbHZvb3J0PGJyPg0K QWxlc3NhbmRybyBEJ0FsZXNzYW5kcm88YnI+DQpUYWVzaWsgQ2hldW5nPGJyPg0KRXJpYyBPc2Jv cm5lPGJyPg0KRmlsZW5hbWUgOiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMi50eHQ8YnI+ DQpQYWdlcyA6IDM4PGJyPg0KRGF0ZSA6IDIwMTQtMDItMDg8YnI+DQo8YnI+DQpBYnN0cmFjdDo8 YnI+DQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbHRlcm5hdGUgbWVjaGFuaXNtcyB0byBwZXJm b3JtIHNvbWUgb2YgdGhlPGJyPg0Kc3ViLWZ1bmN0aW9ucyBvZiBNUExTIFRyYW5zcG9ydCBQcm9m aWxlIChNUExTLVRQKSBsaW5lYXIgcHJvdGVjdGlvbjxicj4NCmRlZmluZWQgaW4gUkZDIDYzNzgs IGFuZCBhbHNvIGRlZmluZXMgYWRkaXRpb25hbCBtZWNoYW5pc21zLiBUaGU8YnI+DQpwdXJwb3Nl IG9mIHRoZXNlIGFsdGVybmF0ZSBhbmQgYWRkaXRpb25hbCBtZWNoYW5pc21zIGlzIHRvIHByb3Zp ZGU8YnI+DQpvcGVyYXRvciBjb250cm9sIGFuZCBleHBlcmllbmNlIHRoYXQgbW9yZSBjbG9zZWx5 IG1vZGVscyB0aGUgYmVoYXZpb3I8YnI+DQpvZiBsaW5lYXIgcHJvdGVjdGlvbiBzZWVuIGluIG90 aGVyIHRyYW5zcG9ydCBuZXR3b3Jrcy48YnI+DQo8YnI+DQpUaGlzIGRvY3VtZW50IGFsc28gaW50 cm9kdWNlcyBjYXBhYmlsaXRpZXMgYW5kIG1vZGVzIGZvciBsaW5lYXI8YnI+DQpwcm90ZWN0aW9u LiBBIGNhcGFiaWxpdHkgaXMgYW4gaW5kaXZpZHVhbCBiZWhhdmlvciwgYW5kIGEgbW9kZSBpcyBh PGJyPg0KcGFydGljdWxhciBjb21iaW5hdGlvbiBvZiBjYXBhYmlsaXRpZXMuIFR3byBtb2RlcyBh cmUgZGVmaW5lZCBpbjxicj4NCnRoaXMgZG9jdW1lbnQ6IFByb3RlY3Rpb24gU3RhdGUgQ29vcmRp bmF0aW9uIChQU0MpIG1vZGUgYW5kIEF1dG9tYXRpYzxicj4NClByb3RlY3Rpb24gU3dpdGNoaW5n IChBUFMpIG1vZGUuPGJyPg0KPGJyPg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGJlaGF2 aW9yIG9mIHRoZSBQU0MgcHJvdG9jb2wgaW5jbHVkaW5nPGJyPg0KcHJpb3JpdHkgbG9naWMgYW5k IHN0YXRlIG1hY2hpbmUgd2hlbiBhbGwgdGhlIGNhcGFiaWxpdGllcyBhc3NvY2lhdGVkPGJyPg0K d2l0aCB0aGUgQVBTIG1vZGUgYXJlIGVuYWJsZWQuPGJyPg0KPGJyPg0KVGhpcyBkb2N1bWVudCB1 cGRhdGVzIFJGQyA2Mzc4IGluIHRoYXQgdGhlIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudDxicj4N Cm1ldGhvZCBkZWZpbmVkIGhlcmUgaXMgYW4gYWRkaXRpb24gdG8gdGhhdCBkb2N1bWVudC48YnI+ DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczo8YnI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW1wbHMtdHAtcHNjLWl0dS88YnI+DQo8YnI+DQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJz aW9uIGF2YWlsYWJsZSBhdDo8YnI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dS0wMjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMjxicj4NCjxicj4NCjxicj4NClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj4NCjxicj4NCkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQpmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+ DQptcGxzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18SMTP2etriinfo_-- From lizho.jin@gmail.com Sat Feb 8 22:50: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 668AE1A05A9 for ; Sat, 8 Feb 2014 22:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 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, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljoCRa5ex1Bn for ; Sat, 8 Feb 2014 22:50:43 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DD3481A0214 for ; Sat, 8 Feb 2014 22:50:42 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so4890854pad.13 for ; Sat, 08 Feb 2014 22:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=DLPmV4N+khoQ5gXG6KIio3HXMvqM46OJM/TIzYGCsVo=; b=T6jiSi0l60dHQszyZBM/anXb2qNnQicY0P7ucIWIW/YkonSW1rFWhHh4+xOm9EWGyZ pE+XCOjkLWCvWr2oo99yTAC1++n9Twm6jOh/b3eC+Wfjd+D2M8nzNcrWt35Yf/l4Xj+v h0LBysdZOIFazSShDz36HK6PPw0s7ImXRun1TckPK0mjRA1yKDgfjroP5luVz8p+vtWu W6PaBBZ8mRYJz1lmAEkwdAsPDOS4N/W+R+oRmmosFNJV7ZLXom778TgoDRSUAnlzQY/o W48npww+WJSOBnSNsYTtlHf5/NhVdGkUdumz3njlmWUiEVJMe+H9bmmFcT54UETKbSoi Bdpw== X-Received: by 10.68.51.39 with SMTP id h7mr30046774pbo.101.1391928643207; Sat, 08 Feb 2014 22:50:43 -0800 (PST) Received: from LIZHONGJ ([140.206.240.6]) by mx.google.com with ESMTPSA id un5sm77803358pab.3.2014.02.08.22.50.38 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 08 Feb 2014 22:50:42 -0800 (PST) From: "Lizhong Jin" To: "'Huaimo Chen'" , "'Ross Callon'" , "'Eric Gray'" , "'Tarek Saad \(tsaad\)'" References: <1684242330fd4f2e98ae1a792d1639c1@CO2PR05MB636.namprd05.prod.outlook.com> <000001cf241b$15a9a4f0$40fceed0$@gmail.com> <5316A0AB3C851246A7CA5758973207D445C35C06@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C35C06@SJCEML701-CHM.china.huawei.com> Date: Sun, 9 Feb 2014 14:50:29 +0800 Message-ID: <035501cf2563$3b7272e0$b25758a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0356_01CF25A6.499823E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGaNIxzciPExEO4uTznjbYOEPYdYAGBXowsAW/lmpya/sfdYA== Content-Language: zh-cn Cc: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Feb 2014 06:50:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0356_01CF25A6.499823E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Huaimo, Thank you for the explanations. But I will consider the signaling = protocol selection from another perspective. In many metro network cases, the primary and backup ingress are service router, and not directly connected. And the only requirement for the signaling protocol is to exchange necessary protection information. The = TCP based signaling protocol will surely provide more reliable connection = than RSVP-TE which is a hop-by-hop IP protocol. TCP has its own flow control mechanism, and could provide more reliable connection. Since TCP based ICCP = (http://tools.ietf.org/html/draft-ietf-pwe3-iccp-13) has already been defined by IETF to do node protection, I personally = prefer ICCP to do ingress node protection for RSVP-TE tunnel. Hope to see more views from the list. =20 Regards Lizhong =20 =20 From: Huaimo Chen [mailto:huaimo.chen@huawei.com]=20 Sent: 2014=C4=EA2=D4=C28=C8=D5 6:49 To: Lizhong Jin; 'Ross Callon'; 'Eric Gray'; 'Tarek Saad (tsaad)' Cc: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org; = mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 =20 Hi Lizhong, =20 Thanks much for your comments! My explanations/answers are inline below. =20 Best Regards, Huaimo -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, February 07, 2014 10:41 AM To: 'Ross Callon'; 'Eric Gray'; 'Tarek Saad (tsaad)' Cc: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org; = mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 =20 Hi authors, I review this draft, and I think the problem the draft tries to solve is = a real problem in operational networks.=20 But from the technical point of view, whether RSVP-TE is the right = signaling protocol between primary and backup ingress node needs to be discussed = in the WG list. This document uses RSVP-TE as a pure signaling protocol between primary ingress and backup ingress node, to exchange necessary protection information. Then the behavior of RSVP-TE signaling on backup ingress = node will only exchange control information, but will not create any = forwarding status (for off-path case). Such kind of behavior is different with traditional RSVP-TE protocol.=20 1. This new behavior changes RSVP-TE fundamentally, and RSVP-TE becomes = a pure signaling protocol, not a path setup protocol between primary and backup node. 2. RSVP is a hop-by-hop protocol, and requires logical direct connection between primary ingress and backup ingress node, which is an additional burden for network operation.=20 Then I don't think RSVP-TE is a good candidate for the mechanism = described in this draft. Some TCP based signaling protocol maybe more suitable, = e.g, ICCP. =20 [Huaimo (start)]:=20 We considered to use other protocols such as OSPF as a signaling = protocol between a primary and a backup ingress node. In some early versions of = the draft, there is a section about this. It seems that it is more = complicated for us to use another protocol (e.g., OSPF/ICCP/BGP) as the signaling protocol.=20 If another protocol (e.g., OSPF/ICCP/BGP) is used, then two protocols = need to be changed and changed more. At first, the other protocol (e.g., OSPF/ICCP/BGP) needs to be extended for transporting/exchanging the necessary protection information between the primary ingress and backup ingress node.=20 Secondly, this protocol component (e.g., OSPF/ICCP/BGP process/thread) = has to dynamically obtain the necessary protection information from protocol RSVP-TE component on the primary ingress, and give the information to protocol RSVP-TE on the backup ingress node, and vise versa.=20 Thirdly, RSVP-TE component (process/thread) is required to be extended = for receiving the protection information from another protocol component = (e.g., OSPF/ICCP/BGP process/thread) and also providing the protection = information to another protocol component.=20 Moreover, RSVP-TE protocol needs to be extended for creating a backup = LSP and its corresponding states according to the protection information received from another protocol. And so on. =20 Using just one protocol RSVP-TE is simpler. A couple of new objects need = to be added to the existing RSVP-TE messages and used for transporting/exchanging the necessary protection information between the primary and backup ingress. On the backup ingress, RSVP-TE creates a = backup LSP and its corresponding states according to the protection information = in the RSVP-TE messages received from the primary ingress. [Huaimo (end)] =20 The above personal concern is the technical direction of this draft, and = I think the WG should get consensus before adoption. =20 Regards Lizhong =20 =20 > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: 2014=C4=EA1=D4=C223=C8=D5 0:19 > To: Eric Gray; Tarek Saad (tsaad); Lizhong Jin > Cc: mpls-chairs@tools.ietf.org; draft-chen-mpls-p2mp-ingress-=20 > protection@tools.ietf.org; Martin Vigoureux > Subject: MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10 >=20 > Eric, Tarek, Lizhong; >=20 > You have been selected as MPLS Review team reviewers for draft-chen-=20 > mpls-p2mp-ingress-protection-10. >=20 > Note to authors: You have been CC'd on this email so that you can know that > this review is going on. However, please do not review your own = document. >=20 > Reviews should comment on whether the document is coherent, is it=20 > useful (ie, is it likely to be actually useful in operational=20 > networks), and is the > document technically sound? Also, is the text and grammar=20 > understandable (it doesn't need to be perfect at this point, but=20 > should be reasonably clear). > We are interested in knowing whether the document is ready to be=20 > considered for WG adoption (ie, it doesn't have to be perfect at this point, > but should be a good start). >=20 > Reviews should be sent to the document authors, WG co-chairs and WG=20 > secretary, and CC'd to the MPLS WG email list. If necessary, Comments=20 > may be sent privately to only the WG chairs. >=20 > Are you able to review this draft by February 6, 2014? >=20 > Thanks, Ross > (as MPLS WG chair) >=20 >=20 =20 =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ------=_NextPart_000_0356_01CF25A6.499823E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

Thank you for the explanations. But I will = consider the signaling protocol selection from another = perspective.

In many metro network cases, the primary = and backup ingress are service router, and not directly connected. And = the only requirement for the signaling protocol is to exchange necessary = protection information. The TCP based signaling protocol will surely = provide more reliable connection than RSVP-TE which is a hop-by-hop IP = protocol. TCP has its own flow control mechanism, and could provide more = reliable connection.

Since TCP based ICCP (http://tools.= ietf.org/html/draft-ietf-pwe3-iccp-13) has already been defined by = IETF to do node protection, I personally prefer ICCP to do ingress node = protection for RSVP-TE tunnel. Hope to see more views from the = list.

 

Regards

Lizhong

 

 

From:= = Huaimo Chen [mailto:huaimo.chen@huawei.com]
Sent: = 2014=C4=EA2=D4=C28=C8=D5 = 6:49
To: Lizhong Jin; 'Ross Callon'; 'Eric Gray'; 'Tarek Saad = (tsaad)'
Cc: = draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org; mpls@ietf.org; = mpls-chairs@tools.ietf.org
Subject: RE: [mpls] MPLS-RT review = of = draft-chen-mpls-p2mp-ingress-protection-10

 

Hi = Lizhong,

 <= /p>

    = Thanks much for your comments!

    My = explanations/answers are inline = below.

 

Best = Regards,

Huaimo<= /p>

-----Original = Message-----
From: mpls [mailto:mpls-bounces@ietf.org] = On Behalf Of Lizhong Jin
Sent: Friday, February 07, 2014 10:41 = AM
To: 'Ross Callon'; 'Eric Gray'; 'Tarek Saad (tsaad)'
Cc: dr= aft-chen-mpls-p2mp-ingress-protection@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org=
Subject: Re: [mpls] MPLS-RT review of = draft-chen-mpls-p2mp-ingress-protection-10

 

Hi = authors,

I review this draft, and = I think the problem the draft tries to solve is a real problem in = operational networks.

But from the technical = point of view, whether RSVP-TE is the right signaling protocol between = primary and backup ingress node needs to be discussed in the WG = list.

This document uses = RSVP-TE as a pure signaling protocol between primary ingress and backup = ingress node, to exchange necessary protection information. Then the = behavior of RSVP-TE signaling on backup ingress node will only exchange = control information, but will not create any forwarding status (for = off-path case).  Such kind of behavior is different with = traditional RSVP-TE protocol.

1. This new behavior = changes RSVP-TE fundamentally, and RSVP-TE becomes a pure signaling = protocol, not a path setup protocol between primary and backup = node.

2. RSVP is a hop-by-hop = protocol, and requires logical direct connection between primary ingress = and backup ingress node, which is an additional burden for network = operation.

Then I don't think = RSVP-TE is a good candidate for the mechanism described in this draft. = Some TCP based signaling protocol maybe more suitable, e.g, = ICCP.

 

[Huaimo = (start)]:

We considered = to use other protocols such as OSPF as a signaling protocol between a = primary and a backup ingress node. In some early versions of the draft, = there is a section about this. It seems that it is more complicated for = us to use another protocol (e.g., OSPF/ICCP/BGP) as the signaling = protocol.

If another = protocol (e.g., OSPF/ICCP/BGP) is used, then two protocols need to be = changed and changed more. At first, the other protocol (e.g., = OSPF/ICCP/BGP) needs to be extended for transporting/exchanging the = necessary protection information between the primary ingress and backup = ingress node.

Secondly, = this protocol component (e.g., OSPF/ICCP/BGP process/thread) has to = dynamically obtain the necessary protection information from protocol = RSVP-TE component on the primary ingress, and give the information to = protocol RSVP-TE on the backup ingress node, and vise versa. =

Thirdly, = RSVP-TE component (process/thread) is required to be extended for = receiving the protection information from another protocol component = (e.g., OSPF/ICCP/BGP process/thread) and also providing the protection = information to another protocol component.

Moreover, = RSVP-TE protocol needs to be extended for creating a backup LSP and its = corresponding states according to the protection information received = from another protocol. And so on.

 

Using just = one protocol RSVP-TE is simpler. A couple of new objects need to be = added to the existing RSVP-TE messages and used for = transporting/exchanging the necessary protection information between the = primary and backup ingress. On the backup ingress, RSVP-TE creates a = backup LSP and its corresponding states according to the protection = information in the RSVP-TE messages received from the primary = ingress.

[Huaimo = (end)]

 

The above personal = concern is the technical direction of this draft, and I think the WG = should get consensus before adoption.

 <= /p>

Regards=

Lizhong=

 <= /p>

 <= /p>

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

> From: Ross Callon = [mailto:rcallon@juniper.net]<= /o:p>

> Sent: = 2014=C4=EA1=D4=C223=C8=D5 = 0:19

> To: Eric Gray; = Tarek Saad (tsaad); Lizhong Jin

> Cc: mpls-chairs@tools.ietf.org= ; draft-chen-mpls-p2mp-ingress-

> protection@tools.ietf.org; = Martin Vigoureux

> Subject: MPLS-RT = review of = draft-chen-mpls-p2mp-ingress-protection-10

> =

> Eric, Tarek, = Lizhong;

> 

> You have been = selected as MPLS Review team reviewers for draft-chen- =

> = mpls-p2mp-ingress-protection-10.

> =

> 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,<= /p>

> 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 February 6, = 2014?

> =

> Thanks, = Ross

> (as MPLS WG = chair)

> =

> =

 <= /p>

 <= /p>

_________________________= ______________________

mpls mailing = list

mpls@ietf.org

------=_NextPart_000_0356_01CF25A6.499823E0-- From loa@pi.nu Sun Feb 9 01:00: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 A562C1A06AA for ; Sun, 9 Feb 2014 01:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeJWwQp3ge9j for ; Sun, 9 Feb 2014 01:00:35 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 435AC1A05DC for ; Sun, 9 Feb 2014 01:00:35 -0800 (PST) Received: from [192.168.1.4] (unknown [112.208.36.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B4D10180145E; Sun, 9 Feb 2014 10:00:31 +0100 (CET) Message-ID: <52F743A4.2040804@pi.nu> Date: Sun, 09 Feb 2014 17:00:20 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: [mpls] implementation poll on draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Feb 2014 09:00:37 -0000 Working Group, We are preparing the Shepherd write-up for draft-ietf-mpls-tp-psc-itu and need to know about existing implementations. If you have an implementation please send a mail to the working group mailing list, the working group chairs or the document shepherd to let us know. Mails directly to chairs or shepherd is fully acceptable. /Loa mpls wg co-chair document shepherd -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Sun Feb 9 01:12: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 6404E1A06B5 for ; Sun, 9 Feb 2014 01:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l79o1miaHFgf for ; Sun, 9 Feb 2014 01:12:33 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 53D261A06B4 for ; Sun, 9 Feb 2014 01:12:33 -0800 (PST) Received: from [192.168.1.4] (unknown [112.208.36.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D021A180145E; Sun, 9 Feb 2014 10:12:31 +0100 (CET) Message-ID: <52F74674.4070809@pi.nu> Date: Sun, 09 Feb 2014 17:12:20 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Ryoo, Jeong-dong" , "mpls@ietf.org" References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18@SMTP2.etri.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] New (02) version of draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Feb 2014 09:12:36 -0000 Jeong-dong and Eric, Thanks for all the effort that has gone into this. Thanks also to the authors and all who have commented on the draft while preparing it to be sent to the IESG. Two things now remains: - responding to the implementation poll that we've just sent out. Note: I will not hold the publication request to lack of the responses on the implementation poll, but update the Shepherd Write-up as I get the responses. Please respond timely. - I need to complete the Shepherd Write-up and hope to do that today authors/editors/chairs should comment on the write-up as soon as I send it out for review. We are still within the schedule to deliver this on time for the SG15 meeting but we are eating up the buffer. /Loa mpls wg co-chair PS It is always possible to find the shepherd write-up's from the document status page. In this case: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ Just click on the link that sasy: Shepherd Write-Up: Last changed 2014-xx-xx Note you could find "work in progress". On 2014-02-09 13:01, Ryoo, Jeong-dong wrote: > Dear all, > The 02 version of draft-ietf-mpls-tp-psc-itu has been uploaded. > In this version, the Authors of this document have been able to > accommodate all the comments raised during the MPLS WG LC > except the one on the version number change from Yaacov. > Thanks for those who sent their comments to the WG list or to > the authors off the list. > Best regards, > Jeong-dong > > > > ------------------------------------------------------------------------ > *From : *"internet-drafts@ietf.org" > *Sent : *2014-02-09 13:51:08 ( +09:00 ) > *To : *i-d-announce@ietf.org > *Cc : *mpls@ietf.org > *Subject : *[mpls] I-D Action: draft-ietf-mpls-tp-psc-itu-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > Title : MPLS Transport Profile (MPLS-TP) Linear Protection to Match the > Operational Expectations of SDH, OTN and Ethernet Transport Network > Operators > Authors : Jeong-dong Ryoo > Eric Gray > Huub van Helvoort > Alessandro D'Alessandro > Taesik Cheung > Eric Osborne > Filename : draft-ietf-mpls-tp-psc-itu-02.txt > Pages : 38 > Date : 2014-02-08 > > Abstract: > This document describes alternate mechanisms to perform some of the > sub-functions of MPLS Transport Profile (MPLS-TP) linear protection > defined in RFC 6378, and also defines additional mechanisms. The > purpose of these alternate and additional mechanisms is to provide > operator control and experience that more closely models the behavior > of linear protection seen in other transport networks. > > This document also introduces capabilities and modes for linear > protection. A capability is an individual behavior, and a mode is a > particular combination of capabilities. Two modes are defined in > this document: Protection State Coordination (PSC) mode and Automatic > Protection Switching (APS) mode. > > This document describes the behavior of the PSC protocol including > priority logic and state machine when all the capabilities associated > with the APS mode are enabled. > > This document updates RFC 6378 in that the capability advertisement > method defined here is an addition to that document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-psc-itu-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-psc-itu-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > 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 adrian@olddog.co.uk Sun Feb 9 02:35:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810031A06D1 for ; Sun, 9 Feb 2014 02:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.218 X-Spam-Level: X-Spam-Status: No, score=0.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] 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 pt2RhB1FXgpo for ; Sun, 9 Feb 2014 02:35:11 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id D6A291A0281 for ; Sun, 9 Feb 2014 02:35:10 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s19AZ63e009206; Sun, 9 Feb 2014 10:35:06 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s19AZ0wx009187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Feb 2014 10:35:04 GMT From: "Adrian Farrel" To: "'Ryoo, Jeong-dong'" , References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18@SMTP2.etri.info> Date: Sun, 9 Feb 2014 10:35:00 -0000 Message-ID: <006e01cf2582$98a6acf0$c9f406d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01CF2582.98A91DF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAtRVj9ke8Mh+EHlCOXwo0H9oSuJpJmrVQ Content-Language: en-gb Subject: Re: [mpls] New (02) version of draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 10:35:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006F_01CF2582.98A91DF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the work which I can confirm addresses my review comments. =20 In the light of... =20 "We would also like to acknowledge explicit text provided by Loa Andersson and Adrian Farrel." =20 ...I also confirm that I am unaware of any IPR affecting this document = that is not already disclosed. =20 Adrian =20 From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ryoo, Jeong-dong Sent: 09 February 2014 05:02 To: mpls@ietf.org Subject: [mpls] New (02) version of draft-ietf-mpls-tp-psc-itu =20 Dear all, =20 The 02 version of draft-ietf-mpls-tp-psc-itu has been uploaded. In this version, the Authors of this document have been able to = accommodate all the comments raised during the MPLS WG LC=20 except the one on the version number change from Yaacov. Thanks for those who sent their comments to the WG list or to the = authors off the list. =20 Best regards, =20 Jeong-dong =20 =20 _____ =20 >From : "internet-drafts@ietf.org" Sent : 2014-02-09 13:51:08 ( +09:00 ) To : i-d-announce@ietf.org Cc : mpls@ietf.org Subject : [mpls] I-D Action: draft-ietf-mpls-tp-psc-itu-02.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Multiprotocol Label Switching Working = Group of the IETF. Title : MPLS Transport Profile (MPLS-TP) Linear Protection to Match the = Operational Expectations of SDH, OTN and Ethernet Transport Network = Operators Authors : Jeong-dong Ryoo Eric Gray Huub van Helvoort Alessandro D'Alessandro Taesik Cheung Eric Osborne Filename : draft-ietf-mpls-tp-psc-itu-02.txt Pages : 38 Date : 2014-02-08 Abstract: This document describes alternate mechanisms to perform some of the sub-functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-psc-itu-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-psc-itu-02 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_006F_01CF2582.98A91DF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for the work which I = can confirm addresses my review comments.

 

In the light = of...

 

"We would also like to = acknowledge explicit text provided by Loa

=C2=A0 Andersson and Adrian = Farrel."

 

...I also confirm that I am = unaware of any IPR affecting this document that is not already = disclosed.

 

Adrian

 

From: mpls = [mailto:mpls-bounces@ietf.org] On Behalf Of Ryoo, = Jeong-dong
Sent: 09 February 2014 05:02
To: = mpls@ietf.org
Subject: [mpls] New (02) version of = draft-ietf-mpls-tp-psc-itu

 

Dear = all,

 

The 02 version of = draft-ietf-mpls-tp-psc-itu has = been uploaded.

In this version, the Authors of this = document have been able to accommodate all the comments raised during = the MPLS WG LC

except the one on the version number = change from Yaacov.

Thanks for those who sent their comments to = the WG list or to the authors off the = list.

 

Best = regards,

 

Jeong-dong



 

 

From : "internet-drafts@ietf.org" = <internet-drafts@ietf.org>
Sent : 2014-02-09 13:51:08 ( = +09:00 )
To : i-d-announce@ietf.org = <i-d-announce@ietf.org>
Cc : mpls@ietf.org = <mpls@ietf.org>
Subject : [mpls] I-D Action: = draft-ietf-mpls-tp-psc-itu-02.txt


A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This draft is = a work item of the Multiprotocol Label Switching Working Group of the = IETF.

Title : MPLS Transport Profile (MPLS-TP) Linear Protection = to Match the Operational Expectations of SDH, OTN and Ethernet Transport = Network Operators
Authors : Jeong-dong Ryoo
Eric Gray
Huub van = Helvoort
Alessandro D'Alessandro
Taesik Cheung
Eric = Osborne
Filename : draft-ietf-mpls-tp-psc-itu-02.txt
Pages : = 38
Date : 2014-02-08

Abstract:
This document describes = alternate mechanisms to perform some of the
sub-functions of MPLS = Transport Profile (MPLS-TP) linear protection
defined in RFC 6378, = and also defines additional mechanisms. The
purpose of these = alternate and additional mechanisms is to provide
operator control = and experience that more closely models the behavior
of linear = protection seen in other transport networks.

This document also = introduces capabilities and modes for linear
protection. A capability = is an individual behavior, and a mode is a
particular combination of = capabilities. Two modes are defined in
this document: Protection = State Coordination (PSC) mode and Automatic
Protection Switching = (APS) mode.

This document describes the behavior of the PSC = protocol including
priority logic and state machine when all the = capabilities associated
with the APS mode are enabled.

This = document updates RFC 6378 in that the capability advertisement
method = defined here is an addition to that document.


The IETF = datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/
There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-mpls-tp-psc-itu-02

A = diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-psc-itu-02

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

Internet-Drafts are also available by anonymous = FTP = at:
ftp://ftp.ietf.org/internet-drafts/

_______________________= ________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<= /o:p>

------=_NextPart_000_006F_01CF2582.98A91DF0-- From loa@pi.nu Sun Feb 9 02:49: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 7EDC31A0381 for ; Sun, 9 Feb 2014 02:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmNn3vhSVZZI for ; Sun, 9 Feb 2014 02:49:09 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 841D51A00AB for ; Sun, 9 Feb 2014 02:49:06 -0800 (PST) Received: from [192.168.1.4] (unknown [112.208.36.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 46E2B180145E; Sun, 9 Feb 2014 11:49:04 +0100 (CET) Message-ID: <52F75D17.3080608@pi.nu> Date: Sun, 09 Feb 2014 18:48:55 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Ryoo, Jeong-dong'" , mpls@ietf.org References: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B6F18@SMTP2.etri.info> <006e01cf2582$98a6acf0$c9f406d0$@olddog.co.uk> In-Reply-To: <006e01cf2582$98a6acf0$c9f406d0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] New (02) version of draft-ietf-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Feb 2014 10:49:11 -0000 Folks, I want to echo Adrian! This version address my comments, and I'm ot aware of any IPRs related to this draft, other than those already disclosed. /Loa On 2014-02-09 18:35, Adrian Farrel wrote: > Thanks for the work which I can confirm addresses my review comments. > > In the light of... > > "We would also like to acknowledge explicit text provided by Loa > > Andersson and Adrian Farrel." > > ...I also confirm that I am unaware of any IPR affecting this document > that is not already disclosed. > > Adrian > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ryoo, Jeong-dong > *Sent:* 09 February 2014 05:02 > *To:* mpls@ietf.org > *Subject:* [mpls] New (02) version of draft-ietf-mpls-tp-psc-itu > > Dear all, > > The 02 version of draft-ietf-mpls-tp-psc-itu has been uploaded. > > In this version, the Authors of this document have been able to > accommodate all the comments raised during the MPLS WG LC > > except the one on the version number change from Yaacov. > > Thanks for those who sent their comments to the WG list or to > the authors off the list. > > Best regards, > > Jeong-dong > > > > ------------------------------------------------------------------------ > > *From : *"internet-drafts@ietf.org" > *Sent : *2014-02-09 13:51:08 ( +09:00 ) > *To : *i-d-announce@ietf.org > *Cc : *mpls@ietf.org > *Subject : *[mpls] I-D Action: draft-ietf-mpls-tp-psc-itu-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > Title : MPLS Transport Profile (MPLS-TP) Linear Protection to Match the > Operational Expectations of SDH, OTN and Ethernet Transport Network > Operators > Authors : Jeong-dong Ryoo > Eric Gray > Huub van Helvoort > Alessandro D'Alessandro > Taesik Cheung > Eric Osborne > Filename : draft-ietf-mpls-tp-psc-itu-02.txt > Pages : 38 > Date : 2014-02-08 > > Abstract: > This document describes alternate mechanisms to perform some of the > sub-functions of MPLS Transport Profile (MPLS-TP) linear protection > defined in RFC 6378, and also defines additional mechanisms. The > purpose of these alternate and additional mechanisms is to provide > operator control and experience that more closely models the behavior > of linear protection seen in other transport networks. > > This document also introduces capabilities and modes for linear > protection. A capability is an individual behavior, and a mode is a > particular combination of capabilities. Two modes are defined in > this document: Protection State Coordination (PSC) mode and Automatic > Protection Switching (APS) mode. > > This document describes the behavior of the PSC protocol including > priority logic and state machine when all the capabilities associated > with the APS mode are enabled. > > This document updates RFC 6378 in that the capability advertisement > method defined here is an addition to that document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-psc-itu-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-psc-itu-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > 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 loa@pi.nu Sun Feb 9 08:11: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 7D6BC1A03B3 for ; Sun, 9 Feb 2014 08:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zloa_wXvYa4O for ; Sun, 9 Feb 2014 08:11:17 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 095231A017E for ; Sun, 9 Feb 2014 08:11:17 -0800 (PST) Received: from [192.168.1.4] (unknown [112.208.36.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CEB87180150F; Sun, 9 Feb 2014 17:11:15 +0100 (CET) Message-ID: <52F7A899.6030003@pi.nu> Date: Mon, 10 Feb 2014 00:11:05 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] cut off date for ID's for London X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Feb 2014 16:11:25 -0000 Hi, Please note that for this IETF the draft submission date is (quite unusal) on Friday (2011-01-14) rather than on the following Monday. It is on Friday THIS WEEK according to the list of important dates: 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. /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 quintin.zhao@huawei.com Sun Feb 9 11:42: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 1419B1A0545 for ; Sun, 9 Feb 2014 11:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 7HyFESUT9NgV for ; Sun, 9 Feb 2014 11:42:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 546751A06F3 for ; Sun, 9 Feb 2014 11:42:43 -0800 (PST) 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 BDK23446; Sun, 09 Feb 2014 19:42:42 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 9 Feb 2014 19:41:34 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 9 Feb 2014 19:42:41 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Sun, 9 Feb 2014 11:42:27 -0800 From: Quintin zhao To: Loa Andersson , "mpls@ietf.org" Thread-Topic: poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4bEXhZzdeSCkeoAI5WqauvbZqrqYCAgAGp6yA= Date: Sun, 9 Feb 2014 19:42:26 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C03071B1FA@SJCEML701-CHM.china.huawei.com> References: <52F5F53A.9010107@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.247] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25z?= =?gb2312?b?ZW5zdXMgdG8gYWRvcHQgZHJhZnQtcmVraHRlci1tcGxzLXBpbS1zbS1vdmVy?= =?gb2312?b?LW1sZHAgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Feb 2014 19:42:46 -0000 TG9hLA0KDQpJIHN1cHBvcnQgYXMgY28tYXV0aG9yLg0KDQpRdWludGluDQoNCk9uIDA4LzAyLzE0 IDEwOjEzLCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4gd3JvdGU6DQoNCj4NCj5Xb3JraW5n IEdyb3VwLA0KPg0KPlRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIGFkb3B0aW5n IA0KPmRyYWZ0LXJla2h0ZXItbXBscy1waW0tc20tb3Zlci1tbGQgYXMgYW4gTVBMUyB3b3JraW5n IGdyb3VwIGRvY3VtZW50Lg0KPg0KPlBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQv bm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcgDQo+Z3JvdXAgbWFpbGluZyBsaXN0ICht cGxzQGlldGYub3JnKS4gUGxlYXNlIGdpdmUgYSB0ZWNobmljYWwgbW90aXZhdGlvbiANCj5mb3Ig eW91ciBzdXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0IHRo ZSBkb2N1bWVudCANCj5zaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRv Y3VtZW50Lg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgd2UgaGF2ZSBpZGVudGlmaWVkIGFuIG92ZXJs YXAgYmV0d2VlbiB0aGlzIGRvY3VtZW50IA0KPmFuZCBkcmFmdC13aWpuYW5kcy1tcGxzLW1sZHAt aW4tYmFuZC13aWxkY2FyZC1lbmNvZGluZy4gVGhpcyBkb2N1bWVudCANCj5pbmNsdWRlcyB0ZXh0 IHRvIGNvdmVyIHRoaXMuDQo+DQo+VGhlcmUgYXJlIDEgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBk b2N1bWVudC4NCj4NCj5UaGUgYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJlIA0KPm5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBS IGNsYWltcyBhZ2FpbnN0IHRoaXMgZHJhZnQuDQo+DQo+SG93ZXZlciBpZiB5b3UgYXJlIG9uIHRo ZSB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBhbmQgYXdhcmUgDQo+b2YgSVBS IHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9zZSB0aGlzIGlz IG5vdy4NCj4NCj5UaGlzIHBvbGwgZW5kcyBGZWJydWFyeSAyMiwgMjAxNC4NCj4NCj4vTG9hDQo+ KG1wbHMgd2cgY28tY2hhaXIpDQo+LS0NCj4NCj4NCj5Mb2EgQW5kZXJzc29uICAgICAgICAgICAg ICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPlNlbmlvciBNUExTIEV4 cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+SHVhd2VpIFRlY2hub2xv Z2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoNCg== From zzhang@juniper.net Sun Feb 9 12:31: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 B93A71A0594 for ; Sun, 9 Feb 2014 12:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V85xLZMePPsQ for ; Sun, 9 Feb 2014 12:31:16 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id CE63B1A03E4 for ; Sun, 9 Feb 2014 12:31:15 -0800 (PST) Received: from mail105-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Sun, 9 Feb 2014 20:31:15 +0000 Received: from mail105-tx2 (localhost [127.0.0.1]) by mail105-tx2-R.bigfish.com (Postfix) with ESMTP id A8C16C0757; Sun, 9 Feb 2014 20:31:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(z579ehz62a3I9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h9a9j1155h) Received-SPF: pass (mail105-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=zzhang@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(252514010)(51704005)(13464003)(377454003)(199002)(189002)(79102001)(66066001)(63696002)(80022001)(65816001)(53806001)(77982001)(33646001)(59766001)(76576001)(76786001)(69226001)(46102001)(2656002)(4396001)(77096001)(76796001)(87936001)(54316002)(56776001)(54356001)(76482001)(51856001)(19580405001)(83322001)(19580395003)(80976001)(85306002)(81542001)(81342001)(49866001)(47976001)(47736001)(50986001)(87266001)(81816001)(81686001)(94946001)(74876001)(92566001)(94316002)(74706001)(93136001)(93516002)(86362001)(85852003)(83072002)(74502001)(31966008)(74662001)(47446002)(90146001)(56816005)(74316001)(95416001)(74366001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB080; H:BY2PR05MB079.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:FEDEC4D5.96C65BCE.1EE83DB.6E8D1ED.2024F; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail105-tx2 (localhost.localdomain [127.0.0.1]) by mail105-tx2 (MessageSwitch) id 1391977872713324_12602; Sun, 9 Feb 2014 20:31:12 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.240]) by mail105-tx2.bigfish.com (Postfix) with ESMTP id A80A33800C8; Sun, 9 Feb 2014 20:31:11 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 9 Feb 2014 20:31:10 +0000 Received: from BY2PR05MB080.namprd05.prod.outlook.com (10.242.38.17) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Sun, 9 Feb 2014 20:31:08 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB080.namprd05.prod.outlook.com (10.242.38.17) with Microsoft SMTP Server (TLS) id 15.0.868.8; Sun, 9 Feb 2014 20:31:05 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.154]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.51]) with mapi id 15.00.0868.013; Sun, 9 Feb 2014 20:31:05 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4j+l0LIcKPGUaOKpYcp1646JqtYizQ Date: Sun, 9 Feb 2014 20:31:04 +0000 Message-ID: <25820e3ff5194a709fb89fb55ec2e6cd@BY2PR05MB079.namprd05.prod.outlook.com> References: <52F5F53A.9010107@pi.nu> In-Reply-To: <52F5F53A.9010107@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-forefront-prvs: 011787B9DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 20:31:18 -0000 I have been following this draft and I support its adoption. Jeffrey > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Saturday, February 08, 2014 4:14 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-rekhter-mpls-pim-sm-over- > mldp@tools.ietf.org > Subject: [mpls] poll to see if we have consensus to adopt draft- > rekhter-mpls-pim-sm-over-mldp as a working group document >=20 >=20 > Working Group, >=20 > This is to start a two week poll on adopting draft-rekhter-mpls-pim-sm- > over-mld as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical motivation > for your support/not support, especially if you think that the document > should not be adopted as a working group document. >=20 > Please note that we have identified an overlap between this document > and draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document > includes text to cover this. >=20 > There are 1 IPR claim against this document. >=20 > The authors has stated on the working group mailing list that they are > not aware of any other IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and aware > of IPR that relates to this draft, the time to disclose this is now. >=20 > This poll ends February 22, 2014. >=20 > /Loa > (mpls wg co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From gorry@erg.abdn.ac.uk Sat Feb 8 01:10:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FD01ADF35; Sat, 8 Feb 2014 01:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 F2pLJ_JLwBUQ; Sat, 8 Feb 2014 01:10:39 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id DDE071AD7C2; Sat, 8 Feb 2014 01:10:38 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 03E842B44A5; Sat, 8 Feb 2014 09:10:37 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sat, 8 Feb 2014 09:10:38 -0000 Message-ID: <5c681647fc1797620535945f8de824ac.squirrel@www.erg.abdn.ac.uk> Date: Sat, 8 Feb 2014 09:10:38 -0000 From: gorry@erg.abdn.ac.uk To: mpls@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Sun, 09 Feb 2014 13:24:30 -0800 Cc: draft-ietf-mpls-in-udp@tools.ietf.org, tsv-ads@ietf.org Subject: [mpls] Transport problems in draft-ietf-mpls-in-udp-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: Sat, 08 Feb 2014 09:10:41 -0000 I have three comments on the updated draft: (1) The current text informatively cites RFCs that it normatively relies upon. The choice of words in revision 05, section 3 seems quite odd to me: " If the UDP checksum needs to be disabled for performance or implementation reasons, the considerations described in [RFC6935] [RFC6936] MUST be examined." Do we require people to examine standards-track documents for "consideration" or to comply with the requirements? I think the latter. If the UDP checksum needs to be disabled for performance or implementation zero checksum with IPv6, it MUST use the method in RFC6935, including the requirements defined in section 5 of RFC 6936. The text should either say MUST NOT use a zero checksum with IPv6, or it needs to cite these as normative references. Both of these were published as Proposed Standard, not as informational/BCP guidelines. --- (2) Does it meet the requirements dictated by the under-lying protocol? If the intention is to allow the method in RFC6935 is to be used, does the method comply with the requirements for tunnels in section 5 of RFC 6936? - Reading the text I can not see whether these specific requirements would be met by this use-case or not. --- (3) The new text improves the use-case explanation, but does not appear to explain this. I'm not sure what this means: Section 5: "Given the fact that the MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation technologies have been successfully deployed within a SP network or networks of an adjacent set of co-operating SPs which is a restricted network environment without any congestion control mechanism and the fact that the current MPLS technology couldn't provide congestion control without major changes, the MPLS-in-UDP encapsulation MUST only be deployed within a SP network or networks of an adjacent set of co-operating SPs as well. mechanism and the fact that the current MPLS technology couldn't provide congestion control without major changes," So, I agree RFC5405 provides applicable guidance on congestion control. To me, there are two paths that this can go: 1) The specification is only for use within controlled environments where there is pre-provisioned capacity. This appears to be what is currently stated. In this case, I think this really needs to be clearly called-out in the abstract and introduction - at the moment it's veiled. 2) The specification is not intended for use on pre-provisioned capacity paths. In which case, I do not understand from the text why there can be no control loop for this deployed environment. I do not understand why this could not include some form f circuit-breaker function that prevents excessive congestion overload. The text above seems to try to avoid discussing this, by hinting (I think) that it should only be used with pre-assigned capacity within controlled environments, but to me at least this isn't yet clear. Congestion control isn't just TCP-like rate adaptation. In summary, this text really needs review by someone with transport expertise. Before that review, the WG need to decide if the case for deployment is based, as it currently states on "reserved path capacity" "where the congestion control is not a concern". --- Gorry From jonathan.beasley@thomsonreuters.com Thu Feb 6 09:05: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 60E401A0424 for ; Thu, 6 Feb 2014 09:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.435 X-Spam-Level: X-Spam-Status: No, score=-7.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNjL4tNLoEO6 for ; Thu, 6 Feb 2014 09:05:28 -0800 (PST) Received: from mailout2-trm.thomsonreuters.com (mailout2-trm.thomsonreuters.com [159.220.9.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2D11A041F for ; Thu, 6 Feb 2014 09:05:27 -0800 (PST) Received: from ukbp-erfsmlr01.erf.thomson.com (relay1 [10.29.2.22]) by mailout2-trm.thomsonreuters.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s16H5Pl9028594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Feb 2014 17:05:25 GMT Received: from UK2P-ERFMHUB02.ERF.thomson.com (xch2 [10.29.4.13]) by ukbp-erfsmlr01.erf.thomson.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s16H5KVe023834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Feb 2014 17:05:24 GMT Received: from UK2P-ERFMMBX11.ERF.thomson.com ([fe80::2469:60e6:1d6a:69ca]) by UK2P-ERFMHUB02.ERF.thomson.com ([::1]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 17:05:15 +0000 From: To: Thread-Topic: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQHPIjut270tDLb2ukyCu7UnvpR9bpqodeeV Date: Thu, 6 Feb 2014 17:05:14 +0000 Message-ID: <7F94BEBB6FEBE544AE073A3D6B55B9112B06C0F0@UK2P-ERFMMBX11.ERF.thomson.com> References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.29.1.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 09 Feb 2014 13:24:40 -0800 Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 11:14:15 -0000 support - shared trees are used within TR. Without this draft we will find= adoption of MLDP a challenge.=0A= ________________________________________=0A= From: Loa Andersson [loa@pi.nu]=0A= Sent: 05 February 2014 06:29=0A= To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); = draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org=0A= Subject: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-enco= ding=0A= =0A= Working Group,=0A= =0A= This is to start a two week poll on adopting=0A= draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working=0A= group document.=0A= =0A= Please send your comments (support/not support) to the mpls working=0A= group mailing list (mpls@ietf.org). Please give a technical=0A= motivation for your support/not support, especially if you think that=0A= the document should not be adopted as a working group document.=0A= =0A= Please note that we have identified an overlap between this document=0A= and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this=0A= document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp=0A= to cover this.=0A= =0A= There are no IPR claims against this document.=0A= =0A= The authors has stated on the working group mailing list=0A= that they are not aware of any other IPR claims against this draft.=0A= =0A= However if you are on the the mpls working group mailing list and=0A= aware of IPR that relates to this draft, the time to disclose=0A= this is now.=0A= =0A= This poll ends February 19, 2014.=0A= =0A= /Loa=0A= (mpls wg co-chair)=0A= --=0A= =0A= =0A= Loa Andersson email: loa@mail01.huawei.com=0A= Senior MPLS Expert loa@pi.nu=0A= Huawei Technologies (consultant) phone: +46 739 81 21 64=0A= From xuxiaohu@huawei.com Sun Feb 9 18:56: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 C1D4C1A0674 for ; Sun, 9 Feb 2014 18:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 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.548, 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 T_yH03xohcIW for ; Sun, 9 Feb 2014 18:56:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 024971A0670 for ; Sun, 9 Feb 2014 18:56:11 -0800 (PST) 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 BAY34946; Mon, 10 Feb 2014 02:56:10 +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; Mon, 10 Feb 2014 02:54:59 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 02:55:50 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 10:55:44 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" Thread-Topic: [mpls] fwd: New Version Notification - draft-ietf-mpls-in-udp-05.txt Thread-Index: AQHPHiUsdC+9Zo2d10ei8WC/4ntlhZqtwv3g Date: Mon, 10 Feb 2014 02:55:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824B6DC@NKGEML512-MBS.china.huawei.com> References: Your message of "Fri, 24 Jan 2014 08:33:49 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247A2B@NKGEML512-MBS.china.huawei.com> <201401310138.s0V1cT4c068414@maildrop2.v6ds.occnc.com> In-Reply-To: <201401310138.s0V1cT4c068414@maildrop2.v6ds.occnc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] fwd: New Version Notification - draft-ietf-mpls-in-udp-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: Mon, 10 Feb 2014 02:56:16 -0000 SGkgQ3VydGlzLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4g UGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmUuDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ ILeivP7IyzogQ3VydGlzIFZpbGxhbWl6YXIgW21haWx0bzpjdXJ0aXNAaXB2Ni5vY2NuYy5jb21d DQo+ILeiy83KsbzkOiAyMDE0xOox1MIzMcjVIDk6MzgNCj4gytW8/sjLOiBYdXhpYW9odQ0KPiCz rcvNOiBtcGxzQGlldGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10gZndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA1LnR4dA0KPiANCj4gDQo+IElu IG1lc3NhZ2UNCj4gPDFGRUUzRjhGNUNDREU2NEM5QThFOEY0QUQyN0MxOUVFMDgyNDdBMkJATktH RU1MNTEyLU1CUy5jaGluYS4NCj4gaHVhd2VpLmNvbT4NCj4gWHV4aWFvaHUgd3JpdGVzOg0KPiAN Cj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uICgtMDUpIGhhcyBiZWVuIHN1Ym1p dHRlZCBmb3IgZHJhZnQtaWV0Zi1tcGxzLWluLXVkcDoNCj4gPiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTA1LnR4dA0KPiA+DQo+ID4g RGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb246DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNQ0KPiA+DQo+ID4gVGhlIGNvbW1lbnRz IGFuZCBzdWdnZXN0aW9ucyByZWNlaXZlZCBkdXJpbmcgdGhlIExhc3QgQ2FsbCBoYXMgYmVlbg0K PiA+IGluY29ycG9yYXRlZCBpbiB0aGlzIHJldmlzaW9uLCBlc3BlY2lhbGx5IHRoZSByb3VnaCBj b25zZW5zdXMgb24NCj4gPiBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIGNoZWNrc3VtLiBUaGFua3Mg YSBsb3QgZm9yIHRob3NlIHBlb3BsZSB3aG8NCj4gPiBoYXZlIGNvbnRyaWJ1dGVkIHRoZWlyIHRp bWUgYW5kIGVuZXJneSB0byByZXZpZXcgYW5kIGhlbHAgaW1wcm92aW5nDQo+ID4gdGhpcyBkb2Mu DQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1IChvbiBiZWhhbGYgb2YgYWxsIGNv LWF1dGhvcnMpDQo+IA0KPiANCj4gWGlhb2h1LA0KPiANCj4gSXQgbG9va3MgbGlrZSBJIGdldCB0 byBiZSB0aGUgZmlyc3QgdG8gY29tbWVudCBvbiB0aGUgbmV3IHZlcnNpb24gb2YgdGhpcyBkcmFm dCwNCj4gdGhvdWdoIHRoZXJlIGhhcyBiZWVuIGNvbnNpZGVyYWJsZSBub2lzZV5IXkheSF5IXkgg ZGlzY3Vzc2lvbiB0YW5nZW50aWFsbHkNCj4gcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0KPiANCj4g U3Vic3RhbnRpdmUgKHRob3VnaCBwZXJoYXBzIG5vdCBtYWpvcik6DQo+IA0KPiAgIFBsZWFzZSBj b25zaWRlciB0aGlzIGNoYW5nZSB0byAiVURQIENoZWNrc3VtIiBpbiBTZWN0aW9uIDM6DQo+IA0K PiAgICBPTEQNCj4gDQo+ICAgICAgIFRoZSB1c2FnZSBvZiB0aGlzIGZpZWxkIGlzIGluIGFjY29y ZGFuY2Ugd2l0aCB0aGUgY3VycmVudCBVRFANCj4gICAgICAgc3BlY2lmaWNhdGlvbiBbUkZDNzY4 XS4gSW4gdGhlIElQdjQgVURQIGVuY2Fwc3VsYXRpb24gY2FzZSwgdGhpcw0KPiAgICAgICBmaWVs ZCBpcyBSRUNPTU1FTkRFRCB0byBiZSBzZXQgdG8gemVyby4gSW4gdGhlIElQdjYgVURQDQo+ICAg ICAgIGVuY2Fwc3VsYXRpb24gY2FzZSwgdGhpcyBmaWVsZCBTSE9VTEQgTk9UIGJlIHNldCB0byB6 ZXJvLiBJZiB0aGUNCj4gICAgICAgVURQIGNoZWNrc3VtIG5lZWRzIHRvIGJlIGRpc2FibGVkIGZv ciBwZXJmb3JtYW5jZSBvcg0KPiAgICAgICBpbXBsZW1lbnRhdGlvbiByZWFzb25zLCB0aGUgY29u c2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluDQo+ICAgICAgIFtSRkM2OTM1XSBbUkZDNjkzNl0gTVVT VCBiZSBleGFtaW5lZC4NCj4gDQo+ICAgIE5FVw0KPiANCj4gICAgICAgVGhlIHVzYWdlIG9mIHRo aXMgZmllbGQgaXMgYXMgZGVmaW5lZCBpbiB0aGUgY3VycmVudCBVRFANCj4gICAgICAgc3BlY2lm aWNhdGlvbiBbUkZDNzY4XS4gIFVEUCBhbGxvd3MgdGhlIFVEUCBjaGVja3N1bSB0byBiZSBzZXQN Cj4gICAgICAgdG8gemVybyBpbmRpY2F0aW5nIHRoYXQgbm8gY2hlY2tzdW0gd2FzIGNvbXB1dGVk LiAgRXhjZXB0IGluDQo+ICAgICAgIGV4dHJvaWRpbmFyeSBjYXNlcywgbm9uLXplcm8gVURQIGNo ZWNrc3VtIFNIT1VMRCBiZSB1c2VkLiBUaGUNCj4gICAgICAgY29uc2lkZXJhdGlvbnMgZGVzY3Jp YmVkIGluIGRldGFpbCBpbiBbUkZDNjkzNV0gW1JGQzY5MzZdIE1VU1QNCj4gICAgICAgYmUgZXhh bWluZWQgaWYgVURQIGNoZWNrc3VtcyBuZWVkIHRvIGJlIGRpc2FibGVkIGZvciBwZXJmb3JtYW5j ZQ0KPiAgICAgICBvciBpbXBsZW1lbnRhdGlvbiByZWFzb25zLiAgVURQIGNoZWNrc3VtIHNob3Vs ZCBvbmx5IGJlIGRpc2FibGVkDQo+ICAgICAgIG9uIHByaXZhdGUgbmV0d29ya3Mgb3Igd2hlcmUg TVBMUyBpbiBVRFAgZW5jYXBzdWFsYXRpb24gaXMgYWRkZWQNCj4gICAgICAgYnkgYSBzZXJ2aWNl IHByb3ZpZGVyIHdpdGggTVBMUyBpbiBVRFAgdHJhZmZpYyBlbnRpcmVseSBjb25maW5lZA0KPiAg ICAgICB0byB0aGUgbmV0d29yayBvZiB0aGF0IHNlcnZpY2UgcHJvdmlkZXIgb3Igd2l0aGluIGNv b3BlcmF0aW5nDQo+ICAgICAgIHNlcnZpY2UgcHJvdmlkZXJzIHdpdGggZXhwbGljaXQgcGVybWlz c2lvbi4NCj4gDQo+ICAgICAgIFdoZXJlIGl0IGlzIG5vdCBwb3NzaWJsZSB0byB1c2UgZnVsbCBV RFAgY2hlY2tzdW0sIGFuZCBpZiB1c2luZw0KPiAgICAgICBVRFAtTGl0ZSBbUkZDMzgyOF0gaXMg ZmVhc2libGUsIFVEUC1MaXRlIFNIT1VMRCBiZSB1c2VkIHJhdGhlcg0KPiAgICAgICB0aGFuIFVE UCB3aXRoIGRpc2FibGVkIGNoZWNrc3Vtcy4NCg0KVGhlIGFib3ZlIGNoYW5nZSBsb29rcyBmaW5l IHRvIG1lLiBUaGFua3MuDQoNCj4gICBUaGUgYWJvdmUgaXMgbW9yZSBwYWxhdGFibGUgdG8gc29t ZSBwZW9wbGUgd2hvIG9iamVjdCB0byBub3QgdXNpbmcNCj4gICBjaGVja3N1bXMgYnV0IGFsbG93 cyB6ZXJvIGNoZWNrc3VtcyBpZiB0aGVyZSBpcyBubyBvdGhlciBvcHRpb24uDQo+IA0KPiAgIEFs c28gcGxlYXNlIGNoYW5nZSB0aGUgIkNvbmdlc3Rpb24gQ29uc2lkZXJhdGlvbnMiIHdvcmRpbmcu ICBUaGUNCj4gICBkZWxldGlvbnMgYW5kIGFkZGl0aW9ucyBhcmUgaGlnaGxpZ2h0ZWQgd2l0aCBi ZWdpbm5pbmcgb2YgbGluZQ0KPiAgIG1hcmtpbmdzIHNpbWlsYXIgdG8gdW5pZmllZCBkaWZmcy4N Cj4gDQo+ICAgIE9MRA0KPiANCj4gLSAgICAgU2luY2UgdGhlIE1QTFMtaW4tVURQIGVuY2Fwc3Vs YXRpb24gY2F1c2VzIE1QTFMgcGFja2V0cyB0byBiZQ0KPiAtICAgICBmb3J3YXJkZWQgdGhyb3Vn aCAiVURQIHR1bm5lbHMiLCB0aGUgY29uZ2VzdGlvbiBjb250cm9sDQo+ICAgICAgIGd1aWRlbGlu ZXMgZm9yIFVEUCB0dW5uZWxzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuMyBvZg0KPiAgICAg ICBbUkZDNTQwNV0gU0hPVUxEIGJlIGZvbGxvd2VkLiBTcGVjaWZpY2FsbHksIGFzIHN0YXRlZCBp biBTZWN0aW9uDQo+ICAgICAgIDMuMS4zIG9mIFtSRkM1NDA1XSwgInNvbWUgYnVsayB0cmFuc2Zl ciBhcHBsaWNhdGlvbnMgbWF5IGNob29zZQ0KPiAgICAgICBub3QgdG8gaW1wbGVtZW50IGFueSBj b25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIGFuZCBpbnN0ZWFkDQo+ICAgICAgIHJlbHkgb24g dHJhbnNtaXR0aW5nIGFjcm9zcyByZXNlcnZlZCBwYXRoIGNhcGFjaXR5LiBUaGlzIG1pZ2h0DQo+ ICAgICAgIGJlIGFuIGFjY2VwdGFibGUgY2hvaWNlIGZvciBhIHN1YnNldCBvZiByZXN0cmljdGVk IG5ldHdvcmtpbmcNCj4gICAgICAgZW52aXJvbm1lbnRzLCBidXQgaXMgYnkgbm8gbWVhbnMgYSBz YWZlIHByYWN0aWNlIGZvciBvcGVyYXRpb24NCj4gICAgICAgaW4gdGhlIEludGVybmV0LiINCj4g LSAgICAgR2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGUNCj4gICAgICAgTVBMUy1pbi1HUkUgYW5kIE1Q TFMtaW4tSVAgW1JGQzQwMjNdDQo+IC0gICAgIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9naWVzDQo+ ICAgICAgIGhhdmUgYmVlbiBzdWNjZXNzZnVsbHkgZGVwbG95ZWQNCj4gLSAgICAgd2l0aGluIGEg U1AgbmV0d29yayBvciBuZXR3b3JrcyBvZiBhbiBhZGphY2VudCBzZXQgb2YNCj4gLSAgICAgY28t b3BlcmF0aW5nIFNQcyB3aGljaCBpcyBhIHJlc3RyaWN0ZWQgbmV0d29yayBlbnZpcm9ubWVudA0K PiAgICAgICB3aXRob3V0IGFueSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtDQo+IC0gICAg IGFuZCB0aGUgZmFjdCB0aGF0IHRoZSBjdXJyZW50IE1QTFMgdGVjaG5vbG9neSBjb3VsZG4ndCBw cm92aWRlDQo+IC0gICAgIGNvbmdlc3Rpb24gY29udHJvbCB3aXRob3V0IG1ham9yIGNoYW5nZXMs IHRoZSBNUExTLWluLVVEUA0KPiAtICAgICBlbmNhcHN1bGF0aW9uIE1VU1Qgb25seSBiZSBkZXBs b3llZCB3aXRoaW4gYSBTUCBuZXR3b3JrIG9yDQo+IC0gICAgIG5ldHdvcmtzIG9mIGFuIGFkamFj ZW50IHNldCBvZiBjby1vcGVyYXRpbmcgU1BzIGFzIHdlbGwuDQo+IA0KPiAgICBORVcNCj4gDQo+ ICsgICAgIE1QTFMtaW4tVURQIGlzIGFwcGxpY2FibGUgaW4gbGltaXRlZCBjaXJjdW1zdGFuY2Vz IChTZWUgU2VjdGlvbg0KPiArICAgICAxLjMpLiAgSWYgZGVwbG95ZWQgaW4gYSBtYW5uZXIgY29u c2lzdGVudCB3aXRoIHRoaXMNCj4gKyAgICAgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQsIHRoZW4N Cj4gICAgICAgZ3VpZGVsaW5lcyBmb3IgVURQIHR1bm5lbHMgYXMgZGVmaW5lZCBpbiBTZWN0aW9u IDMuMS4zIG9mDQo+ICAgICAgIFtSRkM1NDA1XSBTSE9VTEQgYmUgZm9sbG93ZWQuIFNwZWNpZmlj YWxseSwgYXMgc3RhdGVkIGluIFNlY3Rpb24NCj4gICAgICAgMy4xLjMgb2YgW1JGQzU0MDVdOg0K PiANCj4gICAgICAgICAic29tZSBidWxrIHRyYW5zZmVyIGFwcGxpY2F0aW9ucyBtYXkgY2hvb3Nl IG5vdCB0byBpbXBsZW1lbnQNCj4gICAgICAgICBhbnkgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hh bmlzbSBhbmQgaW5zdGVhZCByZWx5IG9uDQo+ICAgICAgICAgdHJhbnNtaXR0aW5nIGFjcm9zcyBy ZXNlcnZlZCBwYXRoIGNhcGFjaXR5LiBUaGlzIG1pZ2h0IGJlIGFuDQo+ICAgICAgICAgYWNjZXB0 YWJsZSBjaG9pY2UgZm9yIGEgc3Vic2V0IG9mIHJlc3RyaWN0ZWQgbmV0d29ya2luZw0KPiAgICAg ICAgIGVudmlyb25tZW50cywgYnV0IGlzIGJ5IG5vIG1lYW5zIGEgc2FmZSBwcmFjdGljZSBmb3Ig b3BlcmF0aW9uDQo+ICAgICAgICAgaW4gdGhlIEludGVybmV0LiINCj4gDQo+ICsgICAgIFRoaXMg dXNhZ2UgaXMgY29uc2lzdGVudCB3aXRoDQo+ICAgICAgIE1QTFMtaW4tR1JFIGFuZCBNUExTLWlu LUlQIFtSRkM0MDIzXQ0KPiArICAgICB3aGljaCBoYXZlIGJlZW4NCj4gICAgICAgc3VjY2Vzc2Z1 bGx5IGRlcGxveWVkDQo+ICsgICAgIGluIGRlcGxveW1lbnRzIGNvbnNpc3RlbnQgd2l0aCB0aGUg YXBwbGljYWJpbGl0eSBvZiBNUExTLWluLVVEUA0KPiArICAgICBkZWZpbmVkIGluIFNlY3Rpb24g MS4zIGFuZCBoYXZlIGJlZW4gZGVwbG95ZWQNCj4gICAgICAgd2l0aG91dCBhbnkgY29uZ2VzdGlv biBjb250cm9sIG1lY2hhbmlzbS4NCg0KVGhlIGFib3ZlIGNoYW5nZSBsb29rcyBmaW5lIHRvIG1l LiBUaGFua3MuDQoNCj4gICAgICAgSWYgTVBMUy1pbi1VRFAgaXMgZGVwbG95ZWQgaW4gYSBtYW5u ZXIgdGhhdCBpcyBub3QgY29uc2lzdGVudA0KPiAgICAgICB3aXRoIHRoZSBhcHBsaWNhYmlsaXR5 IG9mIE1QTFMtaW4tVURQIGRlZmluZWQgaW4gU2VjdGlvbiAxLjMsDQo+ICAgICAgIHRoZW4gb25l IG9mIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBTSE9VTEQgYmUgbWV0Og0KPiANCj4gICAgICAg ICAxLiAgVGhlIHRyYWZmaWMgd2l0aGluIHRoZSBlbmNhcHN1bGF0ZWQgTVBMUyBwYXlsb2FkIGlz IGtub3duDQo+ICAgICAgICAgICAgIHRvIGJlIHByZWRvbWluYW50bHkgZWl0aGVyIFRDUCBkb21p bmF0ZWQgSVAgdHJhZmZpYyB3aGljaA0KPiAgICAgICAgICAgICBzdXBwb3J0cyBlbmQtdG8tZW5k IGNvbmdlc3Rpb24gY29udHJvbCwgb3IgYW5vdGhlciB0eXBlIG9mDQo+ICAgICAgICAgICAgIHRy YWZmaWMgd2hpY2ggc3VwcG9ydHMgZW5kLXRvLWVuZCBjb25nZXN0aW9uIGNvbnRyb2wuDQoNCj4g ICAgICAgICAtLSBPUiAtLQ0KPiANCj4gICAgICAgICAyLiAgRENDUCBbUkZDNDM0MF0gU0hPVUxE IGJlIHVzZWQgaW4gcGxhY2Ugb2YgVURQLiAgQ0NJRCAzIGFzDQo+ICAgICAgICAgICAgIGRlZmlu ZWQgaW4gUkZDIDQzNDAgaXMgUkVDT01NRU5ERUQgc2luY2UgaXQgd2lsbCBwcm92ZGUNCj4gICAg ICAgICAgICAgYmV0dGVyIHBlcmZvcm1hbmNlIGlmIHRoZSBNUExTIGVuY2Fwc3VsYXRlZCBwYXls b2FkIGlzIFRDUA0KPiAgICAgICAgICAgICBkb21pbmF0ZWQgb3IgaXMgVENQLWxpa2UgaW4gaXRz IHJlc3BvbnNlIHRvIGNvbmdlc3Rpb24uDQo+IA0KDQpJdCBoYXMgYmVlbiBzYWlkIGluIHRoZSBh cHBsaWNhYmlsaXR5IHN0YXRlbWVudCB0aGF0ICIgVGhlIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRp b24gdGVjaG5vbG9neSBNVVNUIG9ubHkgYmUgZGVwbG95ZWQgLi4uIi4gSW4gb3RoZXIgd29yZCwg dGhpcyB0ZWNobm9sb2d5IE1VU1QgT05MWSBiZSBkZXBsb3llZCBpbiBhIHJlc3RyaWN0ZWQgbmV0 d29yayBlbnZpcm9ubWVudC4gSGVuY2UgSSB3b25kZXIgd2hldGhlciBpdCdzIHN0aWxsIG5lY2Vz c2FyeSB0byBzcGVjaWZ5IGd1aWRlbGluZXMgZm9yIHRoZSBkZXBsb3ltZW50IGNhc2Ugd2hpY2gg aXMgbm90IGluIGFjY29yZGFuY2Ugd2l0aCB0aGF0IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50Lg0K DQo+ICAgVGhlIGFib3ZlIHRleHQgbWFrZXMgYSByZWNvbW1lbmRhdGlvbiBmb3IgdGhlIHR5cGUg b2YgY29uZ2VzdGlvbg0KPiAgIGNvbnRyb2wgdG8gYmUgdXNlZCBpZiB0aGUgYXBwbGljYWJpbGl0 eSBzdGF0ZW1lbnQgaXMgbm90IGFkaGVyZWQNCj4gICB0by4gIFRoaXMgbWF5IGJlIG1vcmUgcGFs YXRhYmxlIHRvIHRob3NlIHdobyBoYXZlIG9iamVjdGVkIHRvIHRoZQ0KPiAgIGN1cnJlbnQgc3Rh dGVtZW50cyBvbiBjb25nZXN0aW9uIGluIHRoaXMgZG9jdW1lbnQuICBUaGUgY2hhbmdlIHRvDQo+ ICAgdGhlIG9yaWdpbmFsIHRleHQgaXMgbW9zdGx5IHdvcmRpbmcgY2hhbmdlcywgYnV0IGVzc2V0 aWFsbHkgc2F5cyB0aGUNCj4gICBzYW1lIHRoaW5nLCBidXQgd2l0aCBhbiBlbXBoYXNpcyBvbiBt ZWV0aW5nIHRoZSBhcHBsaWNhYmlsaXR5Lg0KPiANCj4gTWF5IGJlIHNpZ25pZmljYW50Og0KPiAN Cj4gICBUaGlzIChpbiAiUHJvY2Vzc2luZyBQcm9jZWR1cmVzIikgZG9lc24ndCBtYWtlIHNlbnNl IHRvIG1lOg0KPiANCj4gICAgT0xEDQo+IA0KPiAgICAgIEFzIGZvciB3aGV0aGVyIHRoZSB0b3Ag bGFiZWwgaW4gdGhlIE1QTFMgbGFiZWwgc3RhY2sgaXMNCj4gICAgICBkb3duc3RyZWFtLWFzc2ln bmVkIG9yIHVwc3RyZWFtLWFzc2lnbmVkLCBpdCBTSE9VTEQgYmUgZGV0ZXJtaW5lZA0KPiAgICAg IGJhc2VkIG9uIHRoZSB0dW5uZWwgZGVzdGluYXRpb24gSVAgYWRkcmVzcy4gVGhhdCBpcyB0byBz YXksIGlmDQo+ICAgICAgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgaXMgYSBtdWx0aWNhc3Qg YWRkcmVzcywgdGhlIHRvcCBsYWJlbA0KPiAgICAgIFNIT1VMRCBiZSB1cHN0cmVhbS1hc3NpZ25l ZCwgb3RoZXJ3aXNlIGlmIHRoZSBkZXN0aW5hdGlvbiBJUA0KPiAgICAgIGFkZHJlc3MgaXMgYSB1 bmljYXN0IGFkZHJlc3MsIGl0IFNIT1VMRCBiZSBkb3duc3RyZWFtLWFzc2lnbmVkLg0KDQpUaGUg YWJvdmUgZGVzY3JpcHRpb24gaXMgaW50ZW5kZWQgdG8gYmUgY29uc2lzdGVudCB3aXRoIHRoZSBj b3JyZXNwb25kaW5nIHNwZWNpZmljYXRpb24gaW4gdGhlIE1QTFMtaW4tR1JFIGFuZCBNUExTLWlu LUlQIGNhc2VzLiBTaW5jZSB0aGUgb3V0ZXJtb3N0IExTUCB0dW5uZWwgaXMgbm93IHJlcGxhY2Vk IHdpdGggdGhlIElQLWJhc2VkIHR1bm5lbCAoaS5lLiwgdGhlIFVEUCB0dW5uZWwgaGVyZSksIHdo ZXRoZXIgdGhlIHRvcCBsYWJlbCBpbiB0aGUgTVBMUyBsYWJlbCBzdGFjayBpcyBkb3duc3RyZWFt LWFzc2lnbmVkIG9yIHVwc3RyZWFtLWFzc2lnbmVkIHNob3VsZCBiZSBpZGVudGlmaWVkIGFjY29y ZGluZyB0byB0aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzcyBvZiB0aGUgSVAtYmFzZWQgdHVubmVs Lg0KDQo+ICAgVGhlIGVuY2Fwc3VsYXRvciBhcyBhbiBMU1IgKG5vdCBMRVIpIHNob3VsZCBiZSBy ZWNlaXZpbmcgTVBMUw0KPiAgIHBhY2tldHMgd2l0aCBhIE1QTFMgbGFiZWwgc3RhY2suICBJdCBz aG91bGQgZG8gYSBsYWJlbCBvcGVyYXRpb24sDQo+ICAgc3VjaCBhcyBhIGxhYmVsIHN3YXAsIGFu ZCB0aGVuIHB1dCBhIElQIGFuZCBVRFAgZW5jYXBzdWxhdGlvbiBpbg0KPiAgIGZyb250IG9mIHRo ZSBwYWNrZXQuICBXaGF0IE1QTFMgb3BlcmF0aW9uIHRvIGFwcGx5IHNob3VsZCBiZSBvdXQgb2YN Cj4gICBzY29wZSBmb3IgdGhpcyBkb2N1bWVudCBzaW5jZSBpdCB3aWxsIGJlIHRoZSByZXN1bHQg b2YgZWl0aGVyIDEpIGENCj4gICBsb25nLWRpc3RhbmQgTERQIChULUxEUCkgc2Vzc2lvbiwgb3Ig MikgYSBsb25nIGRpc3RhbmNlIFJTVlAtVEUgKG5vDQo+ICAgc3BlY2lhbCBuYW1lLCBqdXN0IFRU TD4xKSBzZXNzaW9uLCBvciBzb21lIGZvcm0gb2YgbWFuYWdlbWVudCBtYWdpYw0KPiAgIHRoYXQg ZGlyZWN0bHkgcHJvZ3JhbXMgYSBsYWJlbCBvcGVyYXRpb24gZm9yIGEgZ2l2ZW4gaW5ib3VuZCBs YWJlbC4NCg0KVGhlIGVuY2Fwc3VsYXRvciBjb3VsZCBhbHNvIGJlIGEgUEUgcm91dGVyLiBJbiB0 aGlzIGNhc2UsIHRoZSB0b3AgbGFiZWwgaW4gdGhlIE1QTFMgbGFiZWwgc3RhY2sgY291bGQgYmUg YSBWUE4gbGFiZWwgd2hpY2ggbWF5IGJlIGRvd25zdHJlYW0tYXNzaWduZWQgb3IgdXBzdHJlYW0t YXNzaWduZWQuDQoNCj4gICBJIHN1Z2dlc3QgdGhhdCB5b3UgY2hhbmdlIHRoaXMgdGV4dCB0byB0 aGlzIGFuZCBzdGFydCBhIG5ldw0KPiAgIHBhcmFncmFwaC4NCj4gDQo+ICAgICAgVGhlIGVuY2Fw c3VsYXRvciBhY3RpbmcgaW4gYW4gTFNSIHJvbGUgZm9yIHNvbWUgc2V0IG9mIExTUCBpcw0KPiAg ICAgIGFzc3VtZWQgdG8gcmVjZWl2ZSBNUExTIGVuY2Fwc3VsYXRlZCB0cmFmZmljLCBwZXJmb3Jt IHNvbWUgbGFiZWwNCj4gICAgICBvcGVyYXRpb24sIGFuZCBmb3J3YXJkIHRoZSBwYWNrZXQgd2l0 aCBNUExTLWluLVVEUCBJUCBhbmQgVURQDQo+ICAgICAgZW5jYXBzdWxhdGlvbiBhZGRlZC4gIFRo ZSBlbmNhcHN1bGF0b3IgYWN0aW5nIGluIHRoZSBMRVIgcm9sZSBmb3INCj4gICAgICBzb21lIHNl dCBvZiBMU1AgaXMgYXNzdW1lZCB0byByZWNlaXZlIG5vbi1NUExTIHRyYWZmaWMsIHB1c2ggTVBM Uw0KPiAgICAgIGxhYmVscyBhbmQgZm9yd2FyZCB0aGUgcGFja2V0IHdpdGggTVBMUy1pbi1VRFAg SVAgYW5kIFVEUA0KPiAgICAgIGVuY2Fwc3VsYXRpb24gYWRkZWQuICBIb3cgdGhlIGxhYmVsIG9w ZXJhdGlvbnMgdG8gYmUgY2FycmllZCBvdXQNCj4gICAgICBhcmUgZGV0ZXJtaW5lZCBpcyBvdXQg b2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQgYnV0IGlzIGV4cGVjdGVkDQo+ICAgICAgdG8gYmUg bW9zdCBvZnRlbiBkZXRlcm1pbmVkIHRocm91Z2ggTERQIG9yIFJTVlAtVEUgc2lnbmFsaW5nLCBv cg0KPiAgICAgIHRocm91Z2ggbWFuYWdlbWVudCBwbGFuZSBhY3Rpb25zLg0KDQoNCj4gICBOaXQ6 IFRoZW4gaW4gbmV4dCBwYXJhZ3JhcGggcy9BcyBzdWNoLCBpbnRlcm1lZGlhdGUvSW50ZXJtZWRp YXRlLw0KDQpGaXhlZCwgdGhhbmtzLg0KDQo+ICAgTml0OiBOZXh0IHBhcmFncmFwaCBzL0FzIGZv ciBvdGhlci9Gb3Igb3RoZXIvDQoNCkZpeGVkLCB0aGFua3MuDQoNCj4gTWlub3I6DQo+IA0KPiAg IFRoZXJlIGFyZSB0d28gY2FzZXMgZm9yIHNldHRpbmcgdGhlIHNvdXJjZSBwb3J0Lg0KPiANCj4g ICAgT0xEDQo+IA0KPiAgICAgIEluIHRoZSBjYXNlIHdoZXJlIHRoZSB0dW5uZWwgZG9lcyBub3Qg bmVlZCBlbnRyb3B5LCB0aGlzIGZpZWxkIG9mDQo+ICAgICAgYWxsIHBhY2tldHMgYmVsb25naW5n IHRvIGEgZ2l2ZW4gZmxvdyBTSE9VTEQgYmUgc2V0IHRvIGEgcmFuZG9tbHkNCj4gICAgICBzZWxl Y3RlZCBjb25zdGFudCB2YWx1ZSBzbyBhcyB0byBhdm9pZCBwYWNrZXQgcmVvcmRlcmluZy4NCj4g DQo+ICAgIE5FVw0KPiANCj4gICAgICBXaGVyZSB0aGUgdHVubmVsIG5lZWRzIGVudHJvcHksIHRo ZSBzb3VyY2UgcG9ydCBmb3IgYWxsIHBhY2tldHMNCj4gICAgICBiZWxvbmdpbmcgdG8gYSBnaXZl biBmbG93IFNIT1VMRCBiZSBzZXQgdG8gdGhlIHNhbWUgdmFsdWUgdG8NCj4gICAgICBhdm9pZCBy ZW9yZGVyaW5nIHdpdGhpbiBhIG1pY3JvZmxvdy4gIFdoZXJlIHRoZSB0dW5uZWwgZG9lcyBub3QN Cg0KSGFzIHRoZSBtZWFuaW5nIG9mIHRoZSBhYm92ZSBzZW50ZW5jZSBiZWVuIGV4cHJlc3NlZCBi eSB0aGUgZm9sbG93aW5nIG9uZToNCg0KIlRoaXMgZmllbGQgY29udGFpbnMgYSAxNi1iaXQgZW50 cm9weSB2YWx1ZSB0aGF0IGlzDQogICAgICAgICAgICAgICAgZ2VuZXJhdGVkIGJ5IHRoZSBlbmNh cHN1bGF0b3IgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYQ0KICAgICAgICAgICAgICAgIGZsb3cuIg0K DQo+ICAgICAgbmVlZCBlbnRyb3B5LCB0aGUgc291cmNlIHBvcnQgZm9yIGFsbCBwYWNrZXRzIGJl bG9uZ2luZyB0byBhDQo+ICAgICAgZ2l2ZW4gTVBMUyBMU1AgU0hPVUxEIGJlIHNldCB0byBhIHJh bmRvbWx5IHNlbGVjdGVkIHBlciBMU1ANCj4gICAgICBjb25zdGFudCB2YWx1ZSBzbyBhcyB0byBh dm9pZCBwYWNrZXQgcmVvcmRlcmluZyB3aXRoaW4gYW55IGdpdmVuDQo+ICAgICAgTFNQLg0KPiAN Cj4gICBUaGUgYWJvdmUgdHdvIHNlbnRlbmNlcyBzaG91bGQgcHJvYmFibHkgc3RhcnQgYSBuZXcg cGFyYWdyYXBoLg0KPiANCj4gTml0Og0KPiANCj4gICBEcm9wICJOb3RlIHRoYXQiIGluIHRoZSBi ZWdnaW5naW5nIG9mIHRoZSBzZWNvbmQgc2VudGVuY2Ugb2YgdGhlDQo+ICAgYWJzdHJhY3QsIGJ1 dCBrZWVwIHRoZSBzZW50ZW5jZS4NCj4gICBzL3RoZSBjb25nZXN0aW9uIGNvbnRyb2wvY29uZ2Vz dGlvbiBjb250cm9sLw0KPiANCj4gICBzL1tSRkMgNjgzMF0vW1JGQzY4MzBdLw0KPiANCj4gICBS ZW1vdmUgcmVkdW5kYW5jeToNCj4gICAvQ3VycmVudGx5LCBtb3N0IGV4aXN0aW5nIHJvdXRlcnMv Q3VycmVudGx5LCBtb3N0IHJvdXRlcnMvDQo+ICAgb3INCj4gICAvQ3VycmVudGx5LCBtb3N0IGV4 aXN0aW5nIHJvdXRlcnMvTW9zdCBleGlzdGluZyByb3V0ZXJzLw0KPiANCj4gICBzL3doZXJlIHRo ZSBjb25nZXN0aW9uIGNvbnRyb2wgaXMgYSBtdXN0Lg0KPiAgICAvd2hlcmUgdGhlIGNvbmdlc3Rp b24gY29udHJvbCBpcyByZXF1aXJlZC4vDQo+IA0KPiAgIHMvc28gYXMgdG8vdG8vDQoNCj4gICBJ ZG5pdHMgd2lsbCBnZXQgeW91IG9uIGEgbG9uZyBsaW5lIGluICJNUExTIExhYmVsIFN0YWNrIiBl bmRpbmcgaW4NCj4gICBsb3RzIG9mIHNwYWNlcyBhbmQgW1JGQzMwMzJdLiAgRG9uJ3QgdXNlIG1z LXdvcmQgZm9yIFJGQ3MgYW5kIHlvdSdsbA0KPiAgIGhhdmUgbGVzcyBvZiB0aGlzIHNvcnQgb2Yg aGVhZGFjaGUuDQo+IA0KPiAgIERyb3AgImFzIHdlbGwiIGluIHRoZSBzZW50ZW5jZSB0aGF0IHN0 YXJ0cyB3aXRoICJXaGF0IGFsZ29yaXRobSBpcw0KPiAgIGFjdHVhbGx5IHVzZWQgIiBpbiAiU291 cmNlIFBvcnQgb2YgVURQIi4NCj4gDQo+ICAgSWRuaXRzIHdpbGwgZ2V0IHlvdSBvbiBhIGxvbmcg bGluZSBpbiBSRkM3NjggaW4gcmVmZXJlbmNlcywgYWxzbw0KPiAgIFJGQzMwMzIsIFJGQzYzNDcs IFJGQzY0MzgsIFJGQzY4MzAuICBZb3Ugc2hvdWxkIGNoZWNrIElkbml0cyB3aGVuDQo+ICAgeW91 IHN1Ym1pdCBzbyB5b3UgY2FuIHBpY2sgdXAgc21hbGwgZWFzeSB0byBmaXggc3R1ZmYgbGlrZSB0 aGlzLg0KDQpBbGwgdGhlIGFib3ZlIG5pdHMgd291bGQgYmUgZml4ZWQsIHRoYW5rcy4NCg0KPiBP dGhlcjoNCj4gDQo+ICAgU2VjdXJpdHkgQURzIHdpbGwgbGlrZWx5IHJld29yZCAiU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMiLg0KPiANCj4gUGxlYXNlIHJlcGx5IGFuZCBpbmRpY2F0ZSB3aGV0aGVy IHlvdSBhZ3JlZSB3aXRoIHRoZSAic3Vic3RhbnRpdmUgY2hhbmdlcyINCj4gYWJvdmUgc28gdGhl IFdHIGNhbiBkaXNjdXNzIHRoaXMuDQoNCk1vc3Qgb2YgeW91ciBwcm9wb3NlZCBjaGFuZ2VzIGxv b2sgZmluZSB0byBtZS4gVGhhbmtzIGEgbG90IGFnYWluIGZvciB5b3VyIGRldGFpbGVkIHJldmll dyBhbmQgY29tbWVudHMuDQoNCj4gV2l0aCBhbnkgbHVjayB0aGVyZSB3aWxsIGJlIG5vIG9iamVj dGlvbiBzaW1wbHkgYmVjYXVzZSBldmVyeW9uZSBhbHJlYWR5IGhhcw0KPiBtcGxzLWluLXVkcCBp biB0aGVpciBwcm9jbWFpbCBmaWx0ZXJzLiAgOi0pDQoNCkkgaG9wZSBzbyB0b287KQ0KDQpCZXN0 IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBSZWdhcmRzLA0KPiANCj4gQ3VydGlzDQo= From xuxiaohu@huawei.com Sun Feb 9 19:23: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 4FAB21A0793; Sun, 9 Feb 2014 19:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 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.548, 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 lLuj23uSxELg; Sun, 9 Feb 2014 19:23:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 131A11A0791; Sun, 9 Feb 2014 19:23:00 -0800 (PST) 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 BAY36649; Mon, 10 Feb 2014 03:23:00 +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; Mon, 10 Feb 2014 03:21:43 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 03:22:51 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 11:22:48 +0800 From: Xuxiaohu To: "gorry@erg.abdn.ac.uk" , "mpls@ietf.org" Thread-Topic: Transport problems in draft-ietf-mpls-in-udp-05.txt Thread-Index: AQHPJK2uGbhAdkgufkSlq1OmlgQO+JqtrVbw Date: Mon, 10 Feb 2014 03:22:47 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824B700@NKGEML512-MBS.china.huawei.com> References: <5c681647fc1797620535945f8de824ac.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <5c681647fc1797620535945f8de824ac.squirrel@www.erg.abdn.ac.uk> 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 Cc: "draft-ietf-mpls-in-udp@tools.ietf.org" , "tsv-ads@ietf.org" Subject: Re: [mpls] Transport problems in draft-ietf-mpls-in-udp-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: Mon, 10 Feb 2014 03:23:04 -0000 SGkgR29ycnksDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBteSByZXNw b25zZSBpbmxpbmUuDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogZ29ycnlAZXJn LmFiZG4uYWMudWsgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10NCj4gt6LLzcqxvOQ6IDIw MTTE6jLUwjjI1SAxNzoxMQ0KPiDK1bz+yMs6IG1wbHNAaWV0Zi5vcmcNCj4gs63LzTogZHJhZnQt aWV0Zi1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgdHN2LWFkc0BpZXRmLm9yZw0KPiDW98zi OiBUcmFuc3BvcnQgcHJvYmxlbXMgaW4gZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0wNS50eHQNCj4g DQo+IEkgaGF2ZSB0aHJlZSBjb21tZW50cyBvbiB0aGUgdXBkYXRlZCBkcmFmdDoNCj4gDQo+ICgx KSBUaGUgY3VycmVudCB0ZXh0IGluZm9ybWF0aXZlbHkgY2l0ZXMgUkZDcyB0aGF0IGl0IG5vcm1h dGl2ZWx5IHJlbGllcyB1cG9uLg0KPiANCj4gVGhlIGNob2ljZSBvZiB3b3JkcyBpbiByZXZpc2lv biAwNSwgc2VjdGlvbiAzIHNlZW1zIHF1aXRlIG9kZCB0byBtZToNCj4gDQo+ICIgSWYgdGhlIFVE UCBjaGVja3N1bSBuZWVkcyB0byBiZSBkaXNhYmxlZCBmb3IgcGVyZm9ybWFuY2Ugb3IgaW1wbGVt ZW50YXRpb24NCj4gcmVhc29ucywgdGhlIGNvbnNpZGVyYXRpb25zIGRlc2NyaWJlZCBpbiBbUkZD NjkzNV0gW1JGQzY5MzZdIE1VU1QgYmUNCj4gZXhhbWluZWQuIg0KPiANCj4gRG8gd2UgcmVxdWly ZSBwZW9wbGUgdG8gZXhhbWluZSBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnRzIGZvcg0KPiAiY29u c2lkZXJhdGlvbiIgb3IgdG8gY29tcGx5IHdpdGggdGhlIHJlcXVpcmVtZW50cz8gSSB0aGluayB0 aGUgbGF0dGVyLg0KPiANCj4gSWYgdGhlIFVEUCBjaGVja3N1bSBuZWVkcyB0byBiZSBkaXNhYmxl ZCBmb3IgcGVyZm9ybWFuY2Ugb3IgaW1wbGVtZW50YXRpb24NCj4gemVybyBjaGVja3N1bSB3aXRo IElQdjYsIGl0IE1VU1QgdXNlIHRoZSBtZXRob2QgaW4gUkZDNjkzNSwgaW5jbHVkaW5nIHRoZQ0K PiByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBzZWN0aW9uIDUgb2YgUkZDIDY5MzYuDQo+IA0KPiAN Cj4gVGhlIHRleHQgc2hvdWxkIGVpdGhlciBzYXkgTVVTVCBOT1QgdXNlIGEgemVybyBjaGVja3N1 bSB3aXRoIElQdjYsIG9yIGl0IG5lZWRzDQo+IHRvIGNpdGUgdGhlc2UgYXMgbm9ybWF0aXZlIHJl ZmVyZW5jZXMuIEJvdGggb2YgdGhlc2Ugd2VyZSBwdWJsaXNoZWQgYXMgUHJvcG9zZWQNCj4gU3Rh bmRhcmQsIG5vdCBhcyBpbmZvcm1hdGlvbmFsL0JDUCBndWlkZWxpbmVzLg0KDQpPSywgSSB3aWxs IG1vdmUgdGhlc2UgdHdvIFJGQ3MgdG8gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2UgbGlzdCBpbiB0 aGUgbmV4dCB2ZXJzaW9uLg0KDQo+ICgyKSBEb2VzIGl0IG1lZXQgdGhlIHJlcXVpcmVtZW50cyBk aWN0YXRlZCBieSB0aGUgdW5kZXItbHlpbmcgcHJvdG9jb2w/DQo+IA0KPiBJZiB0aGUgaW50ZW50 aW9uIGlzIHRvIGFsbG93IHRoZSBtZXRob2QgaW4gUkZDNjkzNSBpcyB0byBiZSB1c2VkLCBkb2Vz IHRoZSBtZXRob2QNCj4gY29tcGx5IHdpdGggdGhlIHJlcXVpcmVtZW50cyBmb3IgdHVubmVscyBp biBzZWN0aW9uIDUgb2YgUkZDIDY5MzY/DQo+IC0gUmVhZGluZyB0aGUgdGV4dCBJIGNhbiBub3Qg c2VlIHdoZXRoZXIgdGhlc2Ugc3BlY2lmaWMgcmVxdWlyZW1lbnRzIHdvdWxkIGJlDQo+IG1ldCBi eSB0aGlzIHVzZS1jYXNlIG9yIG5vdC4NCg0KSSB3b25kZXIgd2hldGhlciB0aGUgdGV4dCAoc2Vl IGJlbG93KSBwcm9wb3NlZCBieSBDdXJ0aXMgaW4gdGhpcyByZWdhcmQgbG9va3MgZmluZSB0byB5 b3UuDQoNCjx0ZXh0IHByb3Bvc2VkIGJ5IEN1cnRpcz4NCg0KPiAgICAgICBUaGUgdXNhZ2Ugb2Yg dGhpcyBmaWVsZCBpcyBhcyBkZWZpbmVkIGluIHRoZSBjdXJyZW50IFVEUA0KPiAgICAgICBzcGVj aWZpY2F0aW9uIFtSRkM3NjhdLiAgVURQIGFsbG93cyB0aGUgVURQIGNoZWNrc3VtIHRvIGJlIHNl dA0KPiAgICAgICB0byB6ZXJvIGluZGljYXRpbmcgdGhhdCBubyBjaGVja3N1bSB3YXMgY29tcHV0 ZWQuICBFeGNlcHQgaW4NCj4gICAgICAgZXh0cm9pZGluYXJ5IGNhc2VzLCBub24temVybyBVRFAg Y2hlY2tzdW0gU0hPVUxEIGJlIHVzZWQuIFRoZQ0KPiAgICAgICBjb25zaWRlcmF0aW9ucyBkZXNj cmliZWQgaW4gZGV0YWlsIGluIFtSRkM2OTM1XSBbUkZDNjkzNl0gTVVTVA0KPiAgICAgICBiZSBl eGFtaW5lZCBpZiBVRFAgY2hlY2tzdW1zIG5lZWQgdG8gYmUgZGlzYWJsZWQgZm9yIHBlcmZvcm1h bmNlDQo+ICAgICAgIG9yIGltcGxlbWVudGF0aW9uIHJlYXNvbnMuICBVRFAgY2hlY2tzdW0gc2hv dWxkIG9ubHkgYmUgZGlzYWJsZWQNCj4gICAgICAgb24gcHJpdmF0ZSBuZXR3b3JrcyBvciB3aGVy ZSBNUExTIGluIFVEUCBlbmNhcHN1YWxhdGlvbiBpcyBhZGRlZA0KPiAgICAgICBieSBhIHNlcnZp Y2UgcHJvdmlkZXIgd2l0aCBNUExTIGluIFVEUCB0cmFmZmljIGVudGlyZWx5IGNvbmZpbmVkDQo+ ICAgICAgIHRvIHRoZSBuZXR3b3JrIG9mIHRoYXQgc2VydmljZSBwcm92aWRlciBvciB3aXRoaW4g Y29vcGVyYXRpbmcNCj4gICAgICAgc2VydmljZSBwcm92aWRlcnMgd2l0aCBleHBsaWNpdCBwZXJt aXNzaW9uLg0KPiANCj4gICAgICAgV2hlcmUgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHVzZSBmdWxs IFVEUCBjaGVja3N1bSwgYW5kIGlmIHVzaW5nDQo+ICAgICAgIFVEUC1MaXRlIFtSRkMzODI4XSBp cyBmZWFzaWJsZSwgVURQLUxpdGUgU0hPVUxEIGJlIHVzZWQgcmF0aGVyDQo+ICAgICAgIHRoYW4g VURQIHdpdGggZGlzYWJsZWQgY2hlY2tzdW1zLg0KDQo8L3RleHQgcHJvcG9zZWQgYnkgQ3VydGlz Pg0KDQpPciBkbyB5b3UgZXhwZWN0IHRvIGFkZCB0aGUgZm9sbG93aW5nIHRleHQgZnVydGhlciB0 byB0aGUgYWJvdmUgdGV4dC4NCg0KICAgICAgICAgICAgICAgICIuLi5TcGVjaWZpY2FsbHksIHRo ZSBVRFAgY2hlY2tzdW0gTVVTVCBOT1QgYmUgZGlzYWJsZWQgDQogICAgICAgICAgICAgICAgdW5s ZXNzIDEpIHRoZSBNUExTIHBheWxvYWQgaXMgSW50ZXJuZXQgUHJvdG9jb2wgKElQdjQgb3IgSVB2 NikgcGFja2V0cyBhbmQgdGhlIGlubmVyIHBhY2tldA0KICAgICAgICAgICAgICAgIGludGVncml0 eSBjaGVja3MgaXMgYXZhaWxhYmxlOyAyKSBvciB0aGUgTVBMUyBwYXlsb2FkIGlzIG5vbi1JUCBw YWNrZXQgYnV0IGl0IGlzIHNwZWNpZmljYWxseSBkZXNpZ25lZA0KICAgICAgICAgICAgICAgIGZv ciB0cmFuc21pc3Npb24gb3ZlciBhIGxvd2VyIGxheWVyIHRoYXQgZG9lcyBub3QgcHJvdmlkZSBh IHBhY2tldCBpbnRlZ3JpdHkgZ3VhcmFudGVlLg0KDQo+ICgzKSBUaGUgbmV3IHRleHQgaW1wcm92 ZXMgdGhlIHVzZS1jYXNlIGV4cGxhbmF0aW9uLCBidXQgZG9lcyBub3QgYXBwZWFyIHRvDQo+IGV4 cGxhaW4gdGhpcy4NCj4gDQo+IEknbSBub3Qgc3VyZSB3aGF0IHRoaXMgbWVhbnM6DQo+IA0KPiBT ZWN0aW9uIDU6DQo+IA0KPiAiR2l2ZW4gdGhlDQo+ICAgIGZhY3QgdGhhdCB0aGUgTVBMUy1pbi1H UkUgYW5kIE1QTFMtaW4tSVAgW1JGQzQwMjNdIGVuY2Fwc3VsYXRpb24NCj4gICAgdGVjaG5vbG9n aWVzIGhhdmUgYmVlbiBzdWNjZXNzZnVsbHkgZGVwbG95ZWQgd2l0aGluIGEgU1AgbmV0d29yayBv cg0KPiAgICBuZXR3b3JrcyBvZiBhbiBhZGphY2VudCBzZXQgb2YgY28tb3BlcmF0aW5nIFNQcyB3 aGljaCBpcyBhDQo+ICAgIHJlc3RyaWN0ZWQgbmV0d29yayBlbnZpcm9ubWVudCB3aXRob3V0IGFu eSBjb25nZXN0aW9uIGNvbnRyb2wNCj4gICAgbWVjaGFuaXNtIGFuZCB0aGUgZmFjdCB0aGF0IHRo ZSBjdXJyZW50IE1QTFMgdGVjaG5vbG9neSBjb3VsZG4ndA0KPiAgICBwcm92aWRlIGNvbmdlc3Rp b24gY29udHJvbCB3aXRob3V0IG1ham9yIGNoYW5nZXMsIHRoZSBNUExTLWluLVVEUA0KPiAgICBl bmNhcHN1bGF0aW9uIE1VU1Qgb25seSBiZSBkZXBsb3llZCB3aXRoaW4gYSBTUCBuZXR3b3JrIG9y IG5ldHdvcmtzDQo+ICAgIG9mIGFuIGFkamFjZW50IHNldCBvZiBjby1vcGVyYXRpbmcgU1BzIGFz IHdlbGwuICAgbWVjaGFuaXNtIGFuZCB0aGUNCj4gZmFjdCB0aGF0IHRoZSBjdXJyZW50IE1QTFMg dGVjaG5vbG9neSBjb3VsZG4ndA0KPiAgICBwcm92aWRlIGNvbmdlc3Rpb24gY29udHJvbCB3aXRo b3V0IG1ham9yIGNoYW5nZXMsIg0KPiANCj4gU28sIEkgYWdyZWUgUkZDNTQwNSBwcm92aWRlcyBh cHBsaWNhYmxlIGd1aWRhbmNlIG9uIGNvbmdlc3Rpb24gY29udHJvbC4gVG8gbWUsDQo+IHRoZXJl IGFyZSB0d28gcGF0aHMgdGhhdCB0aGlzIGNhbiBnbzoNCj4gDQo+IDEpIFRoZSBzcGVjaWZpY2F0 aW9uIGlzIG9ubHkgZm9yIHVzZSB3aXRoaW4gY29udHJvbGxlZCBlbnZpcm9ubWVudHMgd2hlcmUg dGhlcmUgaXMNCj4gcHJlLXByb3Zpc2lvbmVkIGNhcGFjaXR5LiBUaGlzIGFwcGVhcnMgdG8gYmUg d2hhdCBpcyBjdXJyZW50bHkgc3RhdGVkLiBJbiB0aGlzIGNhc2UsDQo+IEkgdGhpbmsgdGhpcyBy ZWFsbHkgbmVlZHMgdG8gYmUgY2xlYXJseSBjYWxsZWQtb3V0IGluIHRoZSBhYnN0cmFjdCBhbmQg aW50cm9kdWN0aW9uIC0NCj4gYXQgdGhlIG1vbWVudCBpdCdzIHZlaWxlZC4NCg0KWWVzLCB0aGlz IGlzIHRoZSBjdXJyZW50IHJvdWdoIGNvbnNlbnN1cyAoaS5lLiwgcmVzdHJpY3QgdGhlIGFwcGxp Y2FiaWxpdHkgb2YgdGhpcyB0ZWNobm9sb2d5IHdpdGhpbiBjb250cm9sbGVkIGVudmlyb25tZW50 cykgcmVhY2hlZCBhZnRlciBsb25nIGRpc2N1c3Npb25zLiBUaGF0J3Mgd2h5IHRoZSBhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCBpcyBhZGRlZCB0byB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24gYW5k IGFic3RyYWN0IHNlY3Rpb24uDQoNCj4gMikgVGhlIHNwZWNpZmljYXRpb24gaXMgbm90IGludGVu ZGVkIGZvciB1c2Ugb24gcHJlLXByb3Zpc2lvbmVkIGNhcGFjaXR5IHBhdGhzLiBJbg0KPiB3aGlj aCBjYXNlLCBJIGRvIG5vdCB1bmRlcnN0YW5kIGZyb20gdGhlIHRleHQgd2h5IHRoZXJlIGNhbiBi ZSBubyBjb250cm9sIGxvb3ANCj4gZm9yIHRoaXMgZGVwbG95ZWQgZW52aXJvbm1lbnQuDQo+IA0K PiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB0aGlzIGNvdWxkIG5vdCBpbmNsdWRlIHNvbWUgZm9y bSBmIGNpcmN1aXQtYnJlYWtlcg0KPiBmdW5jdGlvbiB0aGF0IHByZXZlbnRzIGV4Y2Vzc2l2ZSBj b25nZXN0aW9uIG92ZXJsb2FkLiBUaGUgdGV4dCBhYm92ZSBzZWVtcyB0bw0KPiB0cnkgdG8gYXZv aWQgZGlzY3Vzc2luZyB0aGlzLCBieSBoaW50aW5nIChJIHRoaW5rKSB0aGF0IGl0IHNob3VsZCBv bmx5IGJlIHVzZWQgd2l0aA0KPiBwcmUtYXNzaWduZWQgY2FwYWNpdHkgd2l0aGluIGNvbnRyb2xs ZWQgZW52aXJvbm1lbnRzLCBidXQgdG8gbWUgYXQgbGVhc3QgdGhpcw0KPiBpc24ndCB5ZXQgY2xl YXIuIENvbmdlc3Rpb24gY29udHJvbCBpc24ndCBqdXN0IFRDUC1saWtlIHJhdGUgYWRhcHRhdGlv bi4NCg0KSSB3b25kZXIgd2hldGhlciB0aGUgYmVsb3cgdGV4dCBwcm9wb3NlZCBieSBDdXJ0aXMg aW4gdGhpcyByZWdhcmQgbG9va3MgZmluZSB0byB5b3UuIElmIHlvdSBiZWxpZXZlIGl0IGlzbid0 IHlldCBjbGVhciwgd291bGQgeW91IHBsZWFzZSBzdWdnZXN0IGFueSB0ZXh0IHdoaWNoIGNvdWxk IG1ha2UgaXQgbW9yZSBjbGVhcj8NCg0KPHRleHQgcHJvcG9zZWQgYnkgQ3VydGlzPg0KDQo+ICsg ICAgIE1QTFMtaW4tVURQIGlzIGFwcGxpY2FibGUgaW4gbGltaXRlZCBjaXJjdW1zdGFuY2VzIChT ZWUgU2VjdGlvbg0KPiArICAgICAxLjMpLiAgSWYgZGVwbG95ZWQgaW4gYSBtYW5uZXIgY29uc2lz dGVudCB3aXRoIHRoaXMNCj4gKyAgICAgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQsIHRoZW4NCj4g ICAgICAgZ3VpZGVsaW5lcyBmb3IgVURQIHR1bm5lbHMgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMu MS4zIG9mDQo+ICAgICAgIFtSRkM1NDA1XSBTSE9VTEQgYmUgZm9sbG93ZWQuIFNwZWNpZmljYWxs eSwgYXMgc3RhdGVkIGluIFNlY3Rpb24NCj4gICAgICAgMy4xLjMgb2YgW1JGQzU0MDVdOg0KPiAN Cj4gICAgICAgICAic29tZSBidWxrIHRyYW5zZmVyIGFwcGxpY2F0aW9ucyBtYXkgY2hvb3NlIG5v dCB0byBpbXBsZW1lbnQNCj4gICAgICAgICBhbnkgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlz bSBhbmQgaW5zdGVhZCByZWx5IG9uDQo+ICAgICAgICAgdHJhbnNtaXR0aW5nIGFjcm9zcyByZXNl cnZlZCBwYXRoIGNhcGFjaXR5LiBUaGlzIG1pZ2h0IGJlIGFuDQo+ICAgICAgICAgYWNjZXB0YWJs ZSBjaG9pY2UgZm9yIGEgc3Vic2V0IG9mIHJlc3RyaWN0ZWQgbmV0d29ya2luZw0KPiAgICAgICAg IGVudmlyb25tZW50cywgYnV0IGlzIGJ5IG5vIG1lYW5zIGEgc2FmZSBwcmFjdGljZSBmb3Igb3Bl cmF0aW9uDQo+ICAgICAgICAgaW4gdGhlIEludGVybmV0LiINCj4gDQo+ICsgICAgIFRoaXMgdXNh Z2UgaXMgY29uc2lzdGVudCB3aXRoDQo+ICAgICAgIE1QTFMtaW4tR1JFIGFuZCBNUExTLWluLUlQ IFtSRkM0MDIzXQ0KPiArICAgICB3aGljaCBoYXZlIGJlZW4NCj4gICAgICAgc3VjY2Vzc2Z1bGx5 IGRlcGxveWVkDQo+ICsgICAgIGluIGRlcGxveW1lbnRzIGNvbnNpc3RlbnQgd2l0aCB0aGUgYXBw bGljYWJpbGl0eSBvZiBNUExTLWluLVVEUA0KPiArICAgICBkZWZpbmVkIGluIFNlY3Rpb24gMS4z IGFuZCBoYXZlIGJlZW4gZGVwbG95ZWQNCj4gICAgICAgd2l0aG91dCBhbnkgY29uZ2VzdGlvbiBj b250cm9sIG1lY2hhbmlzbS4NCjwvdGV4dCBwcm9wb3NlZCBieSBDdXJ0aXM+DQoNCkJlc3QgcmVn YXJkcywNClhpYW9odQ0KDQo+IEluIHN1bW1hcnksIHRoaXMgdGV4dCByZWFsbHkgbmVlZHMgcmV2 aWV3IGJ5IHNvbWVvbmUgd2l0aCB0cmFuc3BvcnQgZXhwZXJ0aXNlLg0KPiBCZWZvcmUgdGhhdCBy ZXZpZXcsIHRoZSBXRyBuZWVkIHRvIGRlY2lkZSBpZiB0aGUgY2FzZSBmb3IgZGVwbG95bWVudCBp cyBiYXNlZCwNCj4gYXMgaXQgY3VycmVudGx5IHN0YXRlcyBvbiAicmVzZXJ2ZWQgcGF0aCBjYXBh Y2l0eSINCj4gIndoZXJlIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgaXMgbm90IGEgY29uY2VybiIu DQo+IA0KPiAtLS0NCj4gDQo+IEdvcnJ5DQo+IA0KPiANCj4gDQo+IA0KDQo= From internet-drafts@ietf.org Sun Feb 9 19:36: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 9FF921A079C; Sun, 9 Feb 2014 19:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUdy55fUWQv2; Sun, 9 Feb 2014 19:36:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7031A0678; Sun, 9 Feb 2014 19:36:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210033610.23000.26853.idtracker@ietfa.amsl.com> Date: Sun, 09 Feb 2014 19:36:10 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-chen-mpls-p2mp-egress-protection-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 03:36:12 -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 : Extensions to RSVP-TE for LSP Egress Local Protection Authors : Huaimo Chen Ning So Autumn Liu Fengman Xu Mehmet Toy Lu Huang Lei Liu Filename : draft-chen-mpls-p2mp-egress-protection-11.txt Pages : 15 Date : 2014-02-09 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-mpls-p2mp-egress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-mpls-p2mp-egress-protection-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-chen-mpls-p2mp-egress-protection-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Feb 10 06:26:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696781A02FA; Mon, 10 Feb 2014 06:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPNlsR1430Nm; Mon, 10 Feb 2014 06:26:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CB01A02E3; Mon, 10 Feb 2014 06:26:53 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140210142653.2907.55907.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 06:26:53 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Label Advertisement Discipline for LDP FECs) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:26:55 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Advertisement Discipline for LDP FECs' 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-02-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The label advertising behavior of an LDP speaker for a given FEC is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear, as well as updates RFC 3212, RFC 4447, RFC 5918, and RFC 6388 by specifying the label advertisement mode for all currently defined FECs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-applicability-label-adv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-applicability-label-adv/ballot/ No IPR declarations have been submitted directly on this I-D. From dhruv.ietf@gmail.com Mon Feb 10 10:51: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 B958C1A0342 for ; Mon, 10 Feb 2014 10:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjVUGCPa-CfW for ; Mon, 10 Feb 2014 10:51:02 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EB6CD1A0308 for ; Mon, 10 Feb 2014 10:51:01 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tp5so3816436ieb.35 for ; Mon, 10 Feb 2014 10:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AnZOJquPIZBPbtKXVJlQsSZ7sg4Z7FRBEvF7F6y4vks=; b=BVow/h0S11tusYd2TswuM96HyH9HlY4SiVYvgiIbIn13AszASPk/S6SnAdWdQE5EpK dl/UCtbPt24P+j8SJ059GkwdxhmS0is5IjV8/pGcVEJFzt1JemYvPX4PiqW2tFWjvpdy ACDlUOmpzUHUsh5WxDLkhwLilIsig7xkeL/WpIQlaoV/yL1MwLnwpTshpYVkdXLg/zmb EtNDbMIUi+sNpPbr/WTU8qMbhTbGJRtcx6rx1JUGCvCv3tP7vQ3JFpWKf+FAbA5KXUG1 ABHU1a0kOwgxYP7uwiCKBxo7qRmJpN1WiBM4YzwbOleN5l03ABYloUXFrLAzcYRjcTqQ meGA== MIME-Version: 1.0 X-Received: by 10.42.65.73 with SMTP id k9mr3234803ici.44.1392058261747; Mon, 10 Feb 2014 10:51:01 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.160.231 with HTTP; Mon, 10 Feb 2014 10:51:01 -0800 (PST) In-Reply-To: <52F5F53A.9010107@pi.nu> References: <52F5F53A.9010107@pi.nu> Date: Tue, 11 Feb 2014 00:21:01 +0530 X-Google-Sender-Auth: P-f4UaQ1MSFsr2v9AE8jglEaFgs Message-ID: From: Dhruv Dhody To: Loa Andersson Content-Type: multipart/alternative; boundary=90e6ba3fcd1732bf0d04f211d2e8 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:51:04 -0000 --90e6ba3fcd1732bf0d04f211d2e8 Content-Type: text/plain; charset=ISO-8859-1 Support! Regards, Dhruv On Sat, Feb 8, 2014 at 2:43 PM, Loa Andersson wrote: > > Working Group, > > This is to start a two week poll on adopting > draft-rekhter-mpls-pim-sm-over-mld as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > Please note that we have identified an overlap between this document > and draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document > includes text to cover this. > > There are 1 IPR claim against this document. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends February 22, 2014. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --90e6ba3fcd1732bf0d04f211d2e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support!=A0

Regards,
Dhruv


On S= at, Feb 8, 2014 at 2:43 PM, Loa Andersson <loa@pi.nu> wrote:

Working Group,

This is to start a two week poll on adopting
draft-rekhter-mpls-pim-sm-over-mld as an MPLS working group document= .

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

Please note that we have identified an overlap between this document
and draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This documen= t
includes text to cover this.

There are 1 IPR claim against this document.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.

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

This poll ends February 22, 2014.

/Loa
(mpls wg co-chair)
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--90e6ba3fcd1732bf0d04f211d2e8-- From renwei.li@huawei.com Mon Feb 10 11:01: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 DF9BA1A05E1 for ; Mon, 10 Feb 2014 11:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 LrO7J9WJ70Aq for ; Mon, 10 Feb 2014 11:01:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CED391A0433 for ; Mon, 10 Feb 2014 11:01:44 -0800 (PST) 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 BAZ14125; Mon, 10 Feb 2014 19:01:44 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 19:00:49 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 19:01:43 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 11:01:31 -0800 From: Richard Li To: Loa Andersson , "mpls@ietf.org" Thread-Topic: poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4buEj7twAiEUuUkN/oCpqW45qrqYCAgAIxXgCAAOpFcA== Date: Mon, 10 Feb 2014 19:01:30 +0000 Message-ID: References: <52F5F53A.9010107@pi.nu> <11208E03C9803E4CB4C3D898F153D6C03071B1FA@SJCEML701-CHM.china.huawei.com> In-Reply-To: <11208E03C9803E4CB4C3D898F153D6C03071B1FA@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:01:47 -0000 Loa, I support it as its co-author for the main reason that the approach and mec= hanism described in this draft fit as maximally as possible with other comp= onents. Regards, Richard On 08/02/14 10:13, "Loa Andersson" wrote: > >Working Group, > >This is to start a two week poll on adopting=20 >draft-rekhter-mpls-pim-sm-over-mld as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working=20 >group mailing list (mpls@ietf.org). Please give a technical motivation=20 >for your support/not support, especially if you think that the document=20 >should not be adopted as a working group document. > >Please note that we have identified an overlap between this document=20 >and draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document=20 >includes text to cover this. > >There are 1 IPR claim against this document. > >The authors has stated on the working group mailing list that they are=20 >not aware of any other IPR claims against this draft. > >However if you are on the the mpls working group mailing list and aware=20 >of IPR that relates to this draft, the time to disclose this is now. > >This poll ends February 22, 2014. > >/Loa >(mpls wg co-chair) >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From huaimo.chen@huawei.com Mon Feb 10 11:34: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 112E51A0405 for ; Mon, 10 Feb 2014 11:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 V9Ux1I7kcwdh for ; Mon, 10 Feb 2014 11:34:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57B1A0128 for ; Mon, 10 Feb 2014 11:34:35 -0800 (PST) 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 BAZ15581; Mon, 10 Feb 2014 19:34:34 +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; Mon, 10 Feb 2014 19:33:39 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 19:34:33 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 11:34:26 -0800 From: Huaimo Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4gUQ1m5adNAUaC32qgiSP7Wpqu4/Fg Date: Mon, 10 Feb 2014 19:34:25 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C360E3@SJCEML701-CHM.china.huawei.com> References: <52F5F53A.9010107@pi.nu> In-Reply-To: <52F5F53A.9010107@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:34:38 -0000 Support! Best Regards, Huaimo -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, February 08, 2014 4:14 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-rekhter-mpls-pim-sm-over-mldp@tools.i= etf.org Subject: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpl= s-pim-sm-over-mldp as a working group document Working Group, This is to start a two week poll on adopting draft-rekhter-mpls-pim-sm-over= -mld as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. Please note that we have identified an overlap between this document and dr= aft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document includes te= xt to cover this. There are 1 IPR claim against this document. The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends February 22, 2014. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From alan.eng@ipc.com Mon Feb 10 11:34: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 9D3161A0813 for ; Mon, 10 Feb 2014 11:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOOA9EK9BJqV for ; Mon, 10 Feb 2014 11:34:41 -0800 (PST) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by ietfa.amsl.com (Postfix) with ESMTP id 62F981A0548 for ; Mon, 10 Feb 2014 11:34:41 -0800 (PST) Received: from unknown [38.113.92.52] (EHLO mail.ipc.com) by p01c11o145.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 0d929f25.0.15110.00-316.43256.p01c11o145.mxlogic.net (envelope-from ); Mon, 10 Feb 2014 12:34:41 -0700 (MST) X-MXL-Hash: 52f929d177d1ae0b-4561ae4a7ebee181aef80910d60dce98ed941fe7 Received: from NWKNJEXMBX2.corp.root.ipc.com ([fe80::df4:1c6f:d8af:c748]) by NWKNJEXHTCAS1.corp.root.ipc.com ([fe80::b913:2343:c013:d109%12]) with mapi id 14.02.0342.003; Mon, 10 Feb 2014 14:34:40 -0500 From: "Eng, Alan" To: "mpls@ietf.org" Thread-Topic: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQHPIjut270tDLb2ukyCu7UnvpR9bpqqTGzQ Date: Mon, 10 Feb 2014 19:34:40 +0000 Message-ID: References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.10.49] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=SclAgItu c=1 sm=1 a=02PC2Vc9u4sKx+biGExYpQ==:17 a] X-AnalysisOut: [=lCc8-jNt9F8A:10 a=ng4jgGLqy_sA:10 a=BLceEmwcHowA:10 a=8nJ] X-AnalysisOut: [EP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=vvKfUcgjAAAA:8 a=xySJp4xP] X-AnalysisOut: [aLsA:10 a=v3x2drgrAAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8] X-AnalysisOut: [ a=i0EeH86SAAAA:8 a=IH3bd_cr2zW41-2WMQEA:9 a=wPNLvfGTeEIA:] X-AnalysisOut: [10 a=IQcSMmYeK44A:10 a=HmrZfMy9ltsA:10 a=4OvTmSHXlXYA:10 a] X-AnalysisOut: [=OeN1TrMypwAA:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a=h8x] X-AnalysisOut: [_BkiqTQ52DKaP:21 a=seNMSP2J124ZyQPj:21] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014021017); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [38.113.92.52] Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:34:46 -0000 Hi, I've been following the draft for this and I would like to vote in support = of having this draft adopted as a working group document. In working for a service provider which specializes on VPNs and Extranets f= or the Finance sector, I see this being helpful in reducing state in the tr= ansport network and allowing for more scalability. There are also other ca= ses where using (*,G) can help with integration of exchange multicast feeds= into customer networks by simplifying the routes required for RPF checks t= oward the Extranet (i.e. only need to RPF toward the route to RP instead of= the specific group sources). Alan Eng | Product Architect | Network Services Engineering | alan.eng@ipc.= com IPC Systems, Inc.=20 One State Street Plaza, 12th Floor, New York, NY 10004 Phone: +1 212 709 1157 | Mobile: +1 347 931 0643 Web:=A0www.ipc.com | New: View our Network Services solutions at IPCGlobalN= etworks.com -----Original Message----- From: loa@pi.nu [mailto:loa@pi.nu]=20 Sent: Wednesday, February 05, 2014 1:29 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; martin.vigoureux@alcatel-luc= ent.com; draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org Subject: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-enco= ding Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-in-ba= nd-wildcard-encoding as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. Please note that we have identified an overlap between this document and dr= aft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this document = unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp to cover this. There are no IPR claims against this document. The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends February 19, 2014. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From curtis@ipv6.occnc.com Mon Feb 10 11:40: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 B954E1A01A8 for ; Mon, 10 Feb 2014 11:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, RP_MATCHES_RCVD=-0.548, 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 RY3aDfGBQFoF for ; Mon, 10 Feb 2014 11:40:12 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id E33CD1A06AF for ; Mon, 10 Feb 2014 11:38:39 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s1AJKO0E033821; Mon, 10 Feb 2014 14:20:25 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402101920.s1AJKO0E033821@maildrop2.v6ds.occnc.com> To: Xuxiaohu From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Feb 2014 02:55:43 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824B6DC@NKGEML512-MBS.china.huawei.com> Date: Mon, 10 Feb 2014 14:20:24 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] fwd: New Version Notification - draft-ietf-mpls-in-udp-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:40:20 -0000 In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824B6DC@NKGEML512-MBS.china.huawei.com> Xuxiaohu writes: > Hi Curtis, > > Thanks a lot for your review and comments. Please see my response inline. I think we have agreement and are discussing only minor wording changes to improve clarity. See inline. > > -----ʼԭ----- > > : Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > ʱ: 2014131 9:38 > > ռ: Xuxiaohu > > : mpls@ietf.org > > : Re: [mpls] fwd: New Version Notification - draft-ietf-mpls-in-udp-05.txt > > > > > > In message > > <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08247A2B@NKGEML512-MBS.china. > > huawei.com> > > Xuxiaohu writes: > > > > > Hi all, > > > > > > A new version (-05) has been submitted for draft-ietf-mpls-in-udp: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-udp-05.txt > > > > > > Diff from previous version: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-05 > > > > > > The comments and suggestions received during the Last Call has been > > > incorporated in this revision, especially the rough consensus on > > > congestion control and checksum. Thanks a lot for those people who > > > have contributed their time and energy to review and help improving > > > this doc. > > > > > > Best regards, > > > Xiaohu (on behalf of all co-authors) > > > > > > Xiaohu, > > > > It looks like I get to be the first to comment on the new version of this draft, > > though there has been considerable noise^H^H^H^H^H discussion tangentially > > related to this draft. > > > > Substantive (though perhaps not major): > > > > Please consider this change to "UDP Checksum" in Section 3: > > > > OLD > > > > The usage of this field is in accordance with the current UDP > > specification [RFC768]. In the IPv4 UDP encapsulation case, this > > field is RECOMMENDED to be set to zero. In the IPv6 UDP > > encapsulation case, this field SHOULD NOT be set to zero. If the > > UDP checksum needs to be disabled for performance or > > implementation reasons, the considerations described in > > [RFC6935] [RFC6936] MUST be examined. > > > > NEW > > > > The usage of this field is as defined in the current UDP > > specification [RFC768]. UDP allows the UDP checksum to be set > > to zero indicating that no checksum was computed. Except in > > extroidinary cases, non-zero UDP checksum SHOULD be used. The > > considerations described in detail in [RFC6935] [RFC6936] MUST > > be examined if UDP checksums need to be disabled for performance > > or implementation reasons. UDP checksum should only be disabled > > on private networks or where MPLS in UDP encapsualation is added > > by a service provider with MPLS in UDP traffic entirely confined > > to the network of that service provider or within cooperating > > service providers with explicit permission. > > > > Where it is not possible to use full UDP checksum, and if using > > UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather > > than UDP with disabled checksums. > > The above change looks fine to me. Thanks. > > > The above is more palatable to some people who object to not using > > checksums but allows zero checksums if there is no other option. > > > > Also please change the "Congestion Considerations" wording. The > > deletions and additions are highlighted with beginning of line > > markings similar to unified diffs. > > > > OLD > > > > - Since the MPLS-in-UDP encapsulation causes MPLS packets to be > > - forwarded through "UDP tunnels", the congestion control > > guidelines for UDP tunnels as defined in Section 3.1.3 of > > [RFC5405] SHOULD be followed. Specifically, as stated in Section > > 3.1.3 of [RFC5405], "some bulk transfer applications may choose > > not to implement any congestion control mechanism and instead > > rely on transmitting across reserved path capacity. This might > > be an acceptable choice for a subset of restricted networking > > environments, but is by no means a safe practice for operation > > in the Internet." > > - Given the fact that the > > MPLS-in-GRE and MPLS-in-IP [RFC4023] > > - encapsulation technologies > > have been successfully deployed > > - within a SP network or networks of an adjacent set of > > - co-operating SPs which is a restricted network environment > > without any congestion control mechanism > > - and the fact that the current MPLS technology couldn't provide > > - congestion control without major changes, the MPLS-in-UDP > > - encapsulation MUST only be deployed within a SP network or > > - networks of an adjacent set of co-operating SPs as well. > > > > NEW > > > > + MPLS-in-UDP is applicable in limited circumstances (See Section > > + 1.3). If deployed in a manner consistent with this > > + applicability statement, then > > guidelines for UDP tunnels as defined in Section 3.1.3 of > > [RFC5405] SHOULD be followed. Specifically, as stated in Section > > 3.1.3 of [RFC5405]: > > > > "some bulk transfer applications may choose not to implement > > any congestion control mechanism and instead rely on > > transmitting across reserved path capacity. This might be an > > acceptable choice for a subset of restricted networking > > environments, but is by no means a safe practice for operation > > in the Internet." > > > > + This usage is consistent with > > MPLS-in-GRE and MPLS-in-IP [RFC4023] > > + which have been > > successfully deployed > > + in deployments consistent with the applicability of MPLS-in-UDP > > + defined in Section 1.3 and have been deployed > > without any congestion control mechanism. > > The above change looks fine to me. Thanks. > > > If MPLS-in-UDP is deployed in a manner that is not consistent > > with the applicability of MPLS-in-UDP defined in Section 1.3, > > then one of the following conditions SHOULD be met: > > > > 1. The traffic within the encapsulated MPLS payload is known > > to be predominantly either TCP dominated IP traffic which > > supports end-to-end congestion control, or another type of > > traffic which supports end-to-end congestion control. > > > -- OR -- > > > > 2. DCCP [RFC4340] SHOULD be used in place of UDP. CCID 3 as > > defined in RFC 4340 is RECOMMENDED since it will provde > > better performance if the MPLS encapsulated payload is TCP > > dominated or is TCP-like in its response to congestion. > > > > It has been said in the applicability statement that " The > MPLS-in-UDP encapsulation technology MUST only be deployed > ...". In other word, this technology MUST ONLY be deployed in a > restricted network environment. Hence I wonder whether it's still > necessary to specify guidelines for the deployment case which is > not in accordance with that applicability statement. If no one else objects, I'm fine with leaving this out. The one or two people making all the noise have not commented on the change. > > The above text makes a recommendation for the type of congestion > > control to be used if the applicability statement is not adhered > > to. This may be more palatable to those who have objected to the > > current statements on congestion in this document. The change to > > the original text is mostly wording changes, but essetially says the > > same thing, but with an emphasis on meeting the applicability. > > > > May be significant: > > > > This (in "Processing Procedures") doesn't make sense to me: > > > > OLD > > > > As for whether the top label in the MPLS label stack is > > downstream-assigned or upstream-assigned, it SHOULD be determined > > based on the tunnel destination IP address. That is to say, if > > the destination IP address is a multicast address, the top label > > SHOULD be upstream-assigned, otherwise if the destination IP > > address is a unicast address, it SHOULD be downstream-assigned. > > The above description is intended to be consistent with the > corresponding specification in the MPLS-in-GRE and MPLS-in-IP > cases. Since the outermost LSP tunnel is now replaced with the > IP-based tunnel (i.e., the UDP tunnel here), whether the top > label in the MPLS label stack is downstream-assigned or > upstream-assigned should be identified according to the > destination IP address of the IP-based tunnel. To be honest, I never paid much attention to MPLS-in-GRE and MPLS-in-IP. Whether downstream-assigned or upstream-assigned doesn't really depend on whether the dest IP is unicast or multicast. > > The encapsulator as an LSR (not LER) should be receiving MPLS > > packets with a MPLS label stack. It should do a label operation, > > such as a label swap, and then put a IP and UDP encapsulation in > > front of the packet. What MPLS operation to apply should be out of > > scope for this document since it will be the result of either 1) a > > long-distand LDP (T-LDP) session, or 2) a long distance RSVP-TE (no > > special name, just TTL>1) session, or some form of management magic > > that directly programs a label operation for a given inbound label. > > The encapsulator could also be a PE router. In this case, the top > label in the MPLS label stack could be a VPN label which may be > downstream-assigned or upstream-assigned. So what? The point is that the label allocation is done be 1) RSVP-TE PTP, 2) RSVP-TE P2MP, 3) LDP PTP, LDP P2MP, and the new LDP MP2MP used to support <*,G>. It doesn't matter to the tunnel functionality which end does the label allocation. In any case, I don't think this is clearly written, but if it was good enough for MPLS-in-GRE and MPLS-in-IP, then I'm fine with leaving it in as-is. > > I suggest that you change this text to this and start a new > > paragraph. > > > > The encapsulator acting in an LSR role for some set of LSP is > > assumed to receive MPLS encapsulated traffic, perform some label > > operation, and forward the packet with MPLS-in-UDP IP and UDP > > encapsulation added. The encapsulator acting in the LER role for > > some set of LSP is assumed to receive non-MPLS traffic, push MPLS > > labels and forward the packet with MPLS-in-UDP IP and UDP > > encapsulation added. How the label operations to be carried out > > are determined is out of scope for this document but is expected > > to be most often determined through LDP or RSVP-TE signaling, or > > through management plane actions. > > > > Nit: Then in next paragraph s/As such, intermediate/Intermediate/ > > Fixed, thanks. > > > Nit: Next paragraph s/As for other/For other/ > > Fixed, thanks. > > > Minor: > > > > There are two cases for setting the source port. > > > > OLD > > > > In the case where the tunnel does not need entropy, this field of > > all packets belonging to a given flow SHOULD be set to a randomly > > selected constant value so as to avoid packet reordering. > > > > NEW > > > > Where the tunnel needs entropy, the source port for all packets > > belonging to a given flow SHOULD be set to the same value to > > avoid reordering within a microflow. Where the tunnel does not > > Has the meaning of the above sentence been expressed by the following one: > > "This field contains a 16-bit entropy value that is > generated by the encapsulator to uniquely identify a > flow." > > > need entropy, the source port for all packets belonging to a > > given MPLS LSP SHOULD be set to a randomly selected per LSP > > constant value so as to avoid packet reordering within any given > > LSP. > > > > The above two sentences should probably start a new paragraph. I think the suggested rewording is more clear, but I'm OK with you not accepting this change. > > Nit: > > > > Drop "Note that" in the begginging of the second sentence of the > > abstract, but keep the sentence. > > s/the congestion control/congestion control/ > > > > s/[RFC 6830]/[RFC6830]/ > > > > Remove redundancy: > > /Currently, most existing routers/Currently, most routers/ > > or > > /Currently, most existing routers/Most existing routers/ > > > > s/where the congestion control is a must. > > /where the congestion control is required./ > > > > s/so as to/to/ > > > Idnits will get you on a long line in "MPLS Label Stack" ending in > > lots of spaces and [RFC3032]. Don't use ms-word for RFCs and you'll > > have less of this sort of headache. > > > > Drop "as well" in the sentence that starts with "What algorithm is > > actually used " in "Source Port of UDP". > > > > Idnits will get you on a long line in RFC768 in references, also > > RFC3032, RFC6347, RFC6438, RFC6830. You should check Idnits when > > you submit so you can pick up small easy to fix stuff like this. > > All the above nits would be fixed, thanks. > > > Other: > > > > Security ADs will likely reword "Security Considerations". > > > > Please reply and indicate whether you agree with the "substantive changes" > > above so the WG can discuss this. > > Most of your proposed changes look fine to me. Thanks a lot again > for your detailed review and comments. > > > With any luck there will be no objection simply because everyone already has > > mpls-in-udp in their procmail filters. :-) > > I hope so too;) > > Best regards, > Xiaohu > > > Regards, > > > > Curtis The only changes still discussed above are for clarity only and I'm OK with you not accepting those changes. Thanks for considering thosee suggestions as well as making the few changes and nit fixes that you have agreed to so far. Since I'm OK with you not accepting the remaining "just for clarity" changes, I think we're done. Curtis From roberttao@huawei.com Mon Feb 10 11:42: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 C7B231A01A8 for ; Mon, 10 Feb 2014 11:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 rzXCW-KBuRVJ for ; Mon, 10 Feb 2014 11:42:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFF621A050F for ; Mon, 10 Feb 2014 11:42:18 -0800 (PST) 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 BDL28757; Mon, 10 Feb 2014 19:42:17 +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; Mon, 10 Feb 2014 19:41:06 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 19:42:16 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 11:42:04 -0800 From: Roberttao To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4eDlrUPhL880eGHQPSCy7kK5qu5Pow Date: Mon, 10 Feb 2014 19:42:03 +0000 Message-ID: <9E378A6551FE484FA7759260D56BD5FE17E92249@SJCEML701-CHM.china.huawei.com> References: <52F5F53A.9010107@pi.nu> In-Reply-To: <52F5F53A.9010107@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:42:24 -0000 Support. Robert -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, February 08, 2014 1:14 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-rekhter-mpls-pim-sm-over-mldp@tools.i= etf.org Subject: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpl= s-pim-sm-over-mldp as a working group document Working Group, This is to start a two week poll on adopting draft-rekhter-mpls-pim-sm-over-mld as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. Please note that we have identified an overlap between this document and draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document includes text to cover this. There are 1 IPR claim against this document. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends February 22, 2014. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From rcallon@juniper.net Mon Feb 10 13:51: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 C90021A0433 for ; Mon, 10 Feb 2014 13:51:36 -0800 (PST) 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 ycP6_xaaTvBT for ; Mon, 10 Feb 2014 13:51:35 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D71A0274 for ; Mon, 10 Feb 2014 13:51:34 -0800 (PST) Received: from mail22-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE024.bigfish.com (10.3.207.146) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Feb 2014 21:51:33 +0000 Received: from mail22-am1 (localhost [127.0.0.1]) by mail22-am1-R.bigfish.com (Postfix) with ESMTP id CD8661C0D92; Mon, 10 Feb 2014 21:51:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail22-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(164054003)(85306002)(87266001)(74316001)(2656002)(87936001)(49866001)(47976001)(69226001)(4396001)(83322001)(80976001)(47736001)(56816005)(90146001)(81342001)(81542001)(74366001)(85852003)(50986001)(76576001)(76786001)(76176001)(56776001)(59766001)(83072002)(63696002)(74876001)(65816001)(76796001)(66066001)(80022001)(79102001)(76482001)(54356001)(54316002)(74706001)(92566001)(77982001)(53806001)(95416001)(31966008)(81686001)(74662001)(33646001)(51856001)(81816001)(94316002)(93516002)(46102001)(94946001)(93136001)(95666001)(47446002)(86362001)(74502001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:EEE6489D.ACF283DE.9DC1EB3.86DA9BB1.201DE; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail22-am1 (localhost.localdomain [127.0.0.1]) by mail22-am1 (MessageSwitch) id 1392069091590597_21999; Mon, 10 Feb 2014 21:51:31 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.244]) by mail22-am1.bigfish.com (Postfix) with ESMTP id 835C6100072; Mon, 10 Feb 2014 21:51:31 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Feb 2014 21:51:31 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Mon, 10 Feb 2014 21:51:18 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.868.8; Mon, 10 Feb 2014 21:51:16 +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.0868.013; Mon, 10 Feb 2014 21:51:15 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHPJqo4ypWXuvo0GkKTwKBGWrlxJw== Date: Mon, 10 Feb 2014 21:51:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-forefront-prvs: 0118CD8765 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 10 Feb 2014 21:51:37 -0000 Working Group, The authors of draft-chen-mpls-p2mp-egress-protection have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to=20 draft-chen-mpls-p2mp-egress-protection? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The=20 documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) From Ning.So@tatacommunications.com Mon Feb 10 13:53: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 E0E081A0823 for ; Mon, 10 Feb 2014 13:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnrg4gIo9TSG for ; Mon, 10 Feb 2014 13:53:23 -0800 (PST) Received: from vmx3.tatacommunications.com (vmx3.tatacommunications.com [66.198.167.208]) by ietfa.amsl.com (Postfix) with ESMTP id BD1FA1A06F3 for ; Mon, 10 Feb 2014 13:53:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,820,1384318800"; d="scan'208";a="30937132" Received: from unknown (HELO wv1-cas-02.vsnl.co.in) ([64.86.157.138]) by mx3-2.tatacommunications.com with ESMTP; 10 Feb 2014 16:53:20 -0500 Received: from uswv1vcas03.vsnl.co.in (64.86.157.183) by wv1-cas-02.vsnl.co.in (64.86.157.138) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Feb 2014 16:53:20 -0500 Received: from USWV1VDAG02.vsnl.co.in ([fe80::7c6a:fd71:7022:40b6]) by uswv1vcas03.vsnl.co.in ([fe80::3911:1b21:3511:593b%13]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 16:53:20 -0500 From: Ning So To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHPJqo4ypWXuvo0GkKTwKBGWrlxJ5qvB4oQ Date: Mon, 10 Feb 2014 21:53:20 +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: [64.86.157.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 10 Feb 2014 21:53:27 -0000 I am not aware of any IPR associated with this draft. =20 Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications=20 (Cell) 972-955-0914 -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Monday, February 10, 2014 3:51 PM To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection Working Group, The authors of draft-chen-mpls-p2mp-egress-protection have told the working= group chairs that the draft is ready to be adopted as a working group docu= ment. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protec= tion? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) From liulei.kddi@gmail.com Mon Feb 10 14:32: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 436E31A0488 for ; Mon, 10 Feb 2014 14:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCSnnqBXT11e for ; Mon, 10 Feb 2014 14:32:12 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B51841A05F2 for ; Mon, 10 Feb 2014 14:32:12 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so1305696ier.18 for ; Mon, 10 Feb 2014 14:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VeplgOC+yaFo8gzt5IHf+/wJTUoYT8p2QRn5k6lphDQ=; b=lzEWqnE77OByyQMjn4IRRKaWbPdwZbR20kUg7T85fs+6Y8iIEWx2pD/lBfXNBD8b23 QvtiZIAamHqLuamdn/Jcxfw/DY1i9NNiEEVn34VSfEwSKsvdDVcX7RE4iSvWq80lboVA qDs4Pglc57xDQMVRTjpr+o1MTeC7nU1gy4pIxi4n5OPVyFVYF6zOqYKY6wd0ntzMOhaG nUnKsGkI3xk5rUKi/GmGP6eB2OaireIbgVmgUKF4VJpeth8af7wZiFOrtGkg0zukV0aS kP14l064kyW4oMJAShu9gTrc0WAm6GuNOtKdG2mveprdfHijVaWLKm2I2/UEIgsMw5NA UmSw== MIME-Version: 1.0 X-Received: by 10.42.230.147 with SMTP id jm19mr3222193icb.64.1392071532299; Mon, 10 Feb 2014 14:32:12 -0800 (PST) Received: by 10.50.129.34 with HTTP; Mon, 10 Feb 2014 14:32:12 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Feb 2014 14:32:12 -0800 Message-ID: From: LEI LIU To: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a11c3bdf02f493304f214e96a Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 10 Feb 2014 22:32:15 -0000 --001a11c3bdf02f493304f214e96a Content-Type: text/plain; charset=ISO-8859-1 I am not aware of any IPR associated with this draft. Best regards, Lei Liu 2014-02-10 13:53 GMT-08:00 Ning So : > I am not aware of any IPR associated with this draft. > > Best regards, > > Ning So > Head of Network Architecture > Mobile Broadband Services > Tata Communications > (Cell) 972-955-0914 > > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: Monday, February 10, 2014 3:51 PM > To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux > Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection > > Working Group, > > The authors of draft-chen-mpls-p2mp-egress-protection have told the > working group chairs that the draft is ready to be adopted as a working > group document. > > Before starting the the poll to see if we have consensus to make this a > working group document we need to do an IPR poll. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-chen-mpls-p2mp-egress-protection? > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant IPR. > The response needs to be sent to the MPLS wg mailing list. The documents > will not advance to the next stage until a response has been received from > each author and each contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Ross > (as MPLS WG co-chair) > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- -- __________________________________ Best Regards, Sincerely Yours, Lei Liu, Ph.D -------------------- Photonic Transport Network Laboratory, KDDI R&D Laboratories Inc., 2-1-15 Ohara Fujimino-shi, Saitama, Japan TELE: +81-49-278-7536 FAX: +81-49-278-7510 ZIP: 356-8502 E-mail: le-liu@kddilabs.jp / liulei@ieee.org --001a11c3bdf02f493304f214e96a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR associated with this=A0draft.

Best regards,
Lei Liu
=


2014-02-10 13:53 GMT-08:00 Ning So <Ning.So@tatacommunications.com>:
I am not aware of any IPR associated with this draft.

Best regards,

Ning So
Head of Network Architecture
Mobile Broadband Services
Tata Communications
(Cell) 972-955-0914=

-----Original Message-----
From: Ross Callon [mailto:rcallon@ju= niper.net]
Sent: Monday, February 10, 2014 3:51 PM
To: mpls@ietf.org; draft-chen-mpls-p2mp-= egress-protection@tools.ietf.org
Cc: mpls-chairs@tools.ietf.or= g; Martin Vigoureux
Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection

Working Group,

The authors of draft-chen-mpls-p2mp-egress-protection have told the working= group chairs that the draft is ready to be adopted as a working group docu= ment.

Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protec= tion?

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

If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor.

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

Thanks, Ross
(as MPLS WG co-chair)


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



--
=
--=A0
__________________________________
Best Rega= rds,

Sincerely Yours,
Lei Liu, Ph.D
--------------------
Photonic Transport Network Laboratory,<= /div>
KDDI R&D Laboratories Inc.,
2-1-15 Ohara Fujimino-s= hi, Saitama, Japan=A0
TELE: +81-49-278-7536
FAX: +81-49= -278-7510
ZIP: 356-8502
--001a11c3bdf02f493304f214e96a-- From iesg-secretary@ietf.org Mon Feb 10 14:57:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3901A08BE; Mon, 10 Feb 2014 14:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T8E-5Um0757; Mon, 10 Feb 2014 14:56:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 736991A060D; Mon, 10 Feb 2014 14:56:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140210225657.12423.95859.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 14:56:57 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:57:01 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators' 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-02-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes alternate mechanisms to perform some of the sub-functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2306/ From autumn.liu@ericsson.com Mon Feb 10 15:00: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 1B6BF1A0488 for ; Mon, 10 Feb 2014 15:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nYtmFcYd-xyb for ; Mon, 10 Feb 2014 15:00:31 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id F19591A0892 for ; Mon, 10 Feb 2014 15:00:29 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-68-52f95a0d8ff7 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 13.D6.11484.D0A59F25; Tue, 11 Feb 2014 00:00:29 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 18:00:28 -0500 From: Autumn Liu To: LEI LIU , Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHPJqo4ypWXuvo0GkKTwKBGWrlxJ5qvB4oQgABe1QD//7PJAA== Date: Mon, 10 Feb 2014 23:00:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, 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_E4F89EAEF1386F42AA8E6FB5C35399A61C0C72B1eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPrC5v1M8gg809Bha9s7czWpzsnc9u 8f3SEhaLW0tXslr8XXGFxYHVY+esu+weS5b8ZPK43nSV3ePL5c9sASxRXDYpqTmZZalF+nYJ XBm3Zv1mLmgIq5hyqZmtgbHdu4uRk0NCwERi0oFdTBC2mMSFe+vZuhi5OIQEjjBKfN71ihHC Wc4o8W79QjaQKjYBLYl9+9+xgyREBGYzSXxcPJEFJCEs4CZx8OkxRhBbRMBd4tD9F0wQtpPE 3d/vmEFsFgFVidcPd4PZvAK+Emc+HoFa94BRYv2zmWAJToFAiROrLrKC2IwCshLTHt0HG8Qs IC5x68l8qFsFJJbsOc8MYYtKvHz8jxXCVpTY1z+dHaI+X6L520WoZYISJ2c+YZnAKDILyahZ SMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQKj7pgEm+MO xgWfLA8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsUusO+B5u5ku75Lb zgWep26dc3qv5Tr1QUWehBGD//yDzLIGso+eO84tZNw4LaYzT6603nDHdlaHrdlee+LShFZ6 LpHgqb9a7GvsX7r4fCCTLqdMexvDVo8P5RN6n01ZF6re1b/6K5/hy6+vcpiUHdXeMuzivvAl MK7+xXmPMFGZ0787lx9SYinOSDTUYi4qTgQAbCsTXIgCAAA= Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 10 Feb 2014 23:00:35 -0000 --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C0C72B1eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR which applies to this draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of LEI LIU Sent: Monday, February 10, 2014 2:32 PM To: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection I am not aware of any IPR associated with this draft. Best regards, Lei Liu 2014-02-10 13:53 GMT-08:00 Ning So >: I am not aware of any IPR associated with this draft. Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications (Cell) 972-955-0914 -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net] Sent: Monday, February 10, 2014 3:51 PM To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protec= tion@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin V= igoureux Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection Working Group, The authors of draft-chen-mpls-p2mp-egress-protection have told the working= group chairs that the draft is ready to be adopted as a working group docu= ment. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protec= tion? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- -- __________________________________ Best Regards, Sincerely Yours, Lei Liu, Ph.D -------------------- Photonic Transport Network Laboratory, KDDI R&D Laboratories Inc., 2-1-15 Ohara Fujimino-shi, Saitama, Japan TELE: +81-49-278-7536 FAX: +81-49-278-7510 ZIP: 356-8502 E-mail: le-liu@kddilabs.jp / liulei@ieee.org --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C0C72B1eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR= which applies to this draft.

-Autumn=

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of LEI LIU
Sent: Monday, February 10, 2014 2:32 PM
To: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protecti= on

 

I am not aware of any IPR associated with= this draft.

Best regards,

Lei Liu

 

2014-02-10 13:53 GMT-08:00 Ning So <Ning.So@tatacommunic= ations.com>:

I am not aware of any IPR associated with this draft= .

Best regards,

Ning So
Head of Network Architecture
Mobile Broadband Services
Tata Communications
(Cell) 972-955-0914


-----Original Message-----
From: Ross Callon [mailto:rcallon@ju= niper.net]
Sent: Monday, February 10, 2014 3:51 PM
To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Cc: mpls-chairs@tools.ietf.or= g; Martin Vigoureux
Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection

Working Group,

The authors of draft-chen-mpls-p2mp-egress-protection have told the working= group chairs that the draft is ready to be adopted as a working group docu= ment.

Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protec= tion?

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

If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each author and each contributor.

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

Thanks, Ross
(as MPLS WG co-chair)


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



 

--

-- 

__________________________________

Best Regards,

 

Sincerely Yours,

Lei Liu, Ph.D

--------------------

Photonic Transport Network Laboratory,

KDDI R&D Laboratories Inc.,

2-1-15 Ohara Fujimino-shi, Saitama, Japan =

TELE: +81-49-278-7536

FAX: +81-49-278-7510

ZIP: 356-8502

--_000_E4F89EAEF1386F42AA8E6FB5C35399A61C0C72B1eusaamb103erics_-- From xuxiaohu@huawei.com Mon Feb 10 17:02: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 B18D61A071E for ; Mon, 10 Feb 2014 17:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 ExVP4858HCZS for ; Mon, 10 Feb 2014 17:02:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D08301A066B for ; Mon, 10 Feb 2014 17:02:34 -0800 (PST) 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 BDL42421; Tue, 11 Feb 2014 01:02:33 +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; Tue, 11 Feb 2014 01:02:22 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 01:02:31 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 09:02:24 +0800 From: Xuxiaohu To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4f7GAeUFkD7kykrlT4M3KszZqvQG1g Date: Tue, 11 Feb 2014 01:02:24 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824BC0E@NKGEML512-MBS.china.huawei.com> References: <52F5F53A.9010107@pi.nu> In-Reply-To: <52F5F53A.9010107@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29u?= =?gb2312?b?c2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXJla2h0ZXItbXBscy1waW0tc20tb3Zl?= =?gb2312?b?ci1tbGRwIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Feb 2014 01:02:37 -0000 U3VwcG9ydC4NCg0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBs cyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMb2EgQW5kZXJzc29uDQo+ILei y83KsbzkOiAyMDE0xOoy1MI4yNUgMTc6MTQNCj4gytW8/sjLOiBtcGxzQGlldGYub3JnDQo+ILOt y806IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOw0KPiBkcmFmdC1yZWtodGVyLW1wbHMtcGlt LXNtLW92ZXItbWxkcEB0b29scy5pZXRmLm9yZw0KPiDW98ziOiBbbXBsc10gcG9sbCB0byBzZWUg aWYgd2UgaGF2ZSBjb25zZW5zdXMgdG8gYWRvcHQNCj4gZHJhZnQtcmVraHRlci1tcGxzLXBpbS1z bS1vdmVyLW1sZHAgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQo+IA0KPiANCj4gV29ya2lu ZyBHcm91cCwNCj4gDQo+IFRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIGFkb3B0 aW5nIGRyYWZ0LXJla2h0ZXItbXBscy1waW0tc20tb3Zlci1tbGQNCj4gYXMgYW4gTVBMUyB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50Lg0KPiANCj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3Vw cG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cA0KPiBtYWlsaW5nIGxp c3QgKG1wbHNAaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhIHRlY2huaWNhbCBtb3RpdmF0aW9uIGZv ciB5b3VyDQo+IHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYgeW91IHRoaW5rIHRo YXQgdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUNCj4gYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3Jv dXAgZG9jdW1lbnQuDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IHdlIGhhdmUgaWRlbnRpZmllZCBh biBvdmVybGFwIGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQNCj4gZHJhZnQtd2lqbmFuZHMtbXBs cy1tbGRwLWluLWJhbmQtd2lsZGNhcmQtZW5jb2RpbmcuIFRoaXMgZG9jdW1lbnQgaW5jbHVkZXMN Cj4gdGV4dCB0byBjb3ZlciB0aGlzLg0KPiANCj4gVGhlcmUgYXJlIDEgSVBSIGNsYWltIGFnYWlu c3QgdGhpcyBkb2N1bWVudC4NCj4gDQo+IFRoZSBhdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IHRoYXQgdGhleSBhcmUgbm90IGF3YXJlDQo+IG9mIGFu eSBvdGhlciBJUFIgY2xhaW1zIGFnYWluc3QgdGhpcyBkcmFmdC4NCj4gDQo+IEhvd2V2ZXIgaWYg eW91IGFyZSBvbiB0aGUgdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgYW5kIGF3 YXJlIG9mIElQUg0KPiB0aGF0IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdCwgdGhlIHRpbWUgdG8gZGlz Y2xvc2UgdGhpcyBpcyBub3cuDQo+IA0KPiBUaGlzIHBvbGwgZW5kcyBGZWJydWFyeSAyMiwgMjAx NC4NCj4gDQo+IC9Mb2ENCj4gKG1wbHMgd2cgY28tY2hhaXIpDQo+IC0tDQo+IA0KPiANCj4gTG9h IEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdl aS5jb20NCj4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FA cGkubnUNCj4gSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From mach.chen@huawei.com Mon Feb 10 17:04: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 E21071A0727 for ; Mon, 10 Feb 2014 17:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 UycKKLygaNKZ for ; Mon, 10 Feb 2014 17:04:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 684001A072A for ; Mon, 10 Feb 2014 17:04:10 -0800 (PST) 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 BAZ29446; Tue, 11 Feb 2014 01:02:36 +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; Tue, 11 Feb 2014 01:02:26 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 01:02:35 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 09:02:30 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4fepzMnY/TykGkQFc1RHncDpqvQGSw Date: Tue, 11 Feb 2014 01:02:29 +0000 Message-ID: References: <52F5F53A.9010107@pi.nu> In-Reply-To: <52F5F53A.9010107@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 01:04:22 -0000 Yes/Support. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Saturday, February 08, 2014 5:14 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; > draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org > Subject: [mpls] poll to see if we have consensus to adopt > draft-rekhter-mpls-pim-sm-over-mldp as a working group document >=20 >=20 > Working Group, >=20 > This is to start a two week poll on adopting draft-rekhter-mpls-pim-sm-ov= er-mld > as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working group > mailing list (mpls@ietf.org). Please give a technical motivation for your > support/not support, especially if you think that the document should not= be > adopted as a working group document. >=20 > Please note that we have identified an overlap between this document and > draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document include= s > text to cover this. >=20 > There are 1 IPR claim against this document. >=20 > The authors has stated on the working group mailing list that they are no= t aware > of any other IPR claims against this draft. >=20 > However if you are on the the mpls working group mailing list and aware o= f IPR > that relates to this draft, the time to disclose this is now. >=20 > This poll ends February 22, 2014. >=20 > /Loa > (mpls wg co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From liuzhiheng@chinamobile.com Mon Feb 10 18:05: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 725F01A0724 for ; Mon, 10 Feb 2014 18:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.274 X-Spam-Level: *** X-Spam-Status: No, score=3.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 ZUmMZrvoijPe for ; Mon, 10 Feb 2014 18:05:14 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 54D591A065F for ; Mon, 10 Feb 2014 18:05:12 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee252f984d2ed2-b1ed2; Tue, 11 Feb 2014 10:02:58 +0800 (CST) X-RM-TRANSID: 2ee252f984d2ed2-b1ed2 Received: from vicwork (unknown[10.2.54.188]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee352f984d1830-43871; Tue, 11 Feb 2014 10:02:58 +0800 (CST) X-RM-TRANSID: 2ee352f984d1830-43871 From: =?gb2312?B?wfXWvrrjVmljIExpdQ==?= To: , , Date: Tue, 11 Feb 2014 10:05:15 +0800 Message-ID: <002b01cf26cd$b4f94560$1eebd020$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8mzaKj9rgQaGmKRxObJx1p1H45sQ== Content-Language: zh-cn Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Feb 2014 02:05:16 -0000 I am not aware of any IPR associated with this draft. Vic Liu Network Research Institute China Mobile LiuZhiheng@chinamobile.com -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net] Sent: Monday, February 10, 2014 3:51 PM To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection Working Group, The authors of draft-chen-mpls-p2mp-egress-protection have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protection? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and each contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lizhenbin@huawei.com Mon Feb 10 18:35: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 D368A1A073E for ; Mon, 10 Feb 2014 18:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 dw5V0uyouWvO for ; Mon, 10 Feb 2014 18:35:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9541A0741 for ; Mon, 10 Feb 2014 18:35:28 -0800 (PST) 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 BAZ34132; Tue, 11 Feb 2014 02:35:27 +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, 11 Feb 2014 02:34:32 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 02:35:26 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 10:35:20 +0800 From: Lizhenbin To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHPJqo4ypWXuvo0GkKTwKBGWrlxJ5qvVmCw Date: Tue, 11 Feb 2014 02:35:18 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EA023@nkgeml506-mbx.china.huawei.com> References: 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.76.77] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogSVBSIFBvbGwgb24gZHJhZnQtY2hlbi1tcGxz?= =?gb2312?b?LXAybXAtZWdyZXNzLXByb3RlY3Rpb24=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Feb 2014 02:35:31 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhc3NvY2lhdGVkIHdpdGggdGhpcyBkcmFmdC4NCg0K QmVzdCByZWdhcmRzLA0KWmhlbmJpbiBMaQ0KDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+ yMs6IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9zcyBDYWxsb24N Creiy83KsbzkOiAyMDE0xOoy1MIxMcjVIDU6NTENCsrVvP7IyzogbXBsc0BpZXRmLm9yZzsgZHJh ZnQtY2hlbi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNCrOty806 IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQrW98ziOiBbbXBsc10gSVBSIFBvbGwgb24gZHJh ZnQtY2hlbi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb24NCg0KV29ya2luZyBHcm91cCwNCg0K VGhlIGF1dGhvcnMgb2YgZHJhZnQtY2hlbi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb24gaGF2 ZSB0b2xkIHRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyB0aGF0IHRoZSBkcmFmdCBpcyByZWFkeSB0 byBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0KQmVmb3JlIHN0YXJ0 aW5nIHRoZSB0aGUgcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5zdXMgdG8gbWFrZSB0aGlz IGEgd29ya2luZyBncm91cCBkb2N1bWVudCB3ZSBuZWVkIHRvIGRvIGFuIElQUiBwb2xsLg0KDQpU aGlzIG1haWwgc3RhcnRzIHRoYXQgSVBSIHBvbGwuDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtY2hlbi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb24/ DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRo IElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBt b3JlIGRldGFpbHMpLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBv ciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGUgcmVz cG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QuIFRoZSBk b2N1bWVudHMgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3Bv bnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGVhY2ggY29udHJpYnV0 b3IuDQoNCklmIHlvdSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBs aXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5 IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHll dCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5r cywgUm9zcw0KKGFzIE1QTFMgV0cgY28tY2hhaXIpDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From lizhenbin@huawei.com Mon Feb 10 19:00: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 DDF1B1A0765 for ; Mon, 10 Feb 2014 19:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Id5L-ET5YeE2 for ; Mon, 10 Feb 2014 19:00:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DD83E1A0760 for ; Mon, 10 Feb 2014 19:00:03 -0800 (PST) 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 BAZ35573; Tue, 11 Feb 2014 03:00:02 +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, 11 Feb 2014 02:59:07 +0000 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; Tue, 11 Feb 2014 03:00:01 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 10:59:57 +0800 From: Lizhenbin To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4f6S0LxMKRsEyBPi+CjorN8JqvYT+A Date: Tue, 11 Feb 2014 02:59:57 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EA04E@nkgeml506-mbx.china.huawei.com> References: <52F5F53A.9010107@pi.nu> In-Reply-To: <52F5F53A.9010107@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29u?= =?gb2312?b?c2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXJla2h0ZXItbXBscy1waW0tc20tb3Zl?= =?gb2312?b?ci1tbGRwIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Feb 2014 03:00:08 -0000 U3VwcG9ydC4NCg0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBtcGxzIFttYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExvYSBBbmRlcnNzb24NCreiy83KsbzkOiAyMDE0 xOoy1MI4yNUgMTc6MTQNCsrVvP7IyzogbXBsc0BpZXRmLm9yZw0Ks63LzTogbXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LXJla2h0ZXItbXBscy1waW0tc20tb3Zlci1tbGRwQHRvb2xz LmlldGYub3JnDQrW98ziOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5zdXMg dG8gYWRvcHQgZHJhZnQtcmVraHRlci1tcGxzLXBpbS1zbS1vdmVyLW1sZHAgYXMgYSB3b3JraW5n IGdyb3VwIGRvY3VtZW50DQoNCg0KV29ya2luZyBHcm91cCwNCg0KVGhpcyBpcyB0byBzdGFydCBh IHR3byB3ZWVrIHBvbGwgb24gYWRvcHRpbmcgZHJhZnQtcmVraHRlci1tcGxzLXBpbS1zbS1vdmVy LW1sZCBhcyBhbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNClBsZWFzZSBzZW5kIHlv dXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3Jv dXAgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKS4gUGxlYXNlIGdpdmUgYSB0ZWNobmljYWwg bW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlv dSB0aGluayB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHdlIGhhdmUgaWRlbnRpZmll ZCBhbiBvdmVybGFwIGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQgZHJhZnQtd2lqbmFuZHMtbXBs cy1tbGRwLWluLWJhbmQtd2lsZGNhcmQtZW5jb2RpbmcuIFRoaXMgZG9jdW1lbnQgaW5jbHVkZXMg dGV4dCB0byBjb3ZlciB0aGlzLg0KDQpUaGVyZSBhcmUgMSBJUFIgY2xhaW0gYWdhaW5zdCB0aGlz IGRvY3VtZW50Lg0KDQpUaGUgYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBSIGNs YWltcyBhZ2FpbnN0IHRoaXMgZHJhZnQuDQoNCkhvd2V2ZXIgaWYgeW91IGFyZSBvbiB0aGUgdGhl IG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgYW5kIGF3YXJlIG9mIElQUiB0aGF0IHJl bGF0ZXMgdG8gdGhpcyBkcmFmdCwgdGhlIHRpbWUgdG8gZGlzY2xvc2UgdGhpcyBpcyBub3cuDQoN ClRoaXMgcG9sbCBlbmRzIEZlYnJ1YXJ5IDIyLCAyMDE0Lg0KDQovTG9hDQoobXBscyB3ZyBjby1j aGFpcikNCi0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFp bDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAg ICAgICAgICAgICAgIGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkg ICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From mehmet_toy@cable.comcast.com Mon Feb 10 19:50: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 1B7891A0773 for ; Mon, 10 Feb 2014 19:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, 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 HF-dG_V91qmz for ; Mon, 10 Feb 2014 19:50:31 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 702561A0778 for ; Mon, 10 Feb 2014 19:50:31 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.82815928; Mon, 10 Feb 2014 22:50:28 -0500 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.77]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 22:50:28 -0500 From: "Toy, Mehmet" To: "Ross Callon (rcallon@juniper.net)" , "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHPJqo4ypWXuvo0GkKTwKBGWrlxJ5qvB4oQgAACfTCAAF/rsA== Date: Tue, 11 Feb 2014 03:50:16 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D445C361D7@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C361D7@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Feb 2014 03:50:33 -0000 Ross, I am not aware of an IPR issue with this draft either. Mehmet -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ning So Sent: Monday, February 10, 2014 4:53 PM To: Ross Callon; mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tool= s.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection I am not aware of any IPR associated with this draft. =20 Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications=20 (Cell) 972-955-0914 -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Monday, February 10, 2014 3:51 PM To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection Working Group, The authors of draft-chen-mpls-p2mp-egress-protection have told the working= group chairs that the draft is ready to be adopted as a working group docu= ment. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protec= tion? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Mon Feb 10 23:11:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DA01A0741 for ; Mon, 10 Feb 2014 23:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOM3W1m2Abkf for ; Mon, 10 Feb 2014 23:11:23 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBF71A0623 for ; Mon, 10 Feb 2014 23:11:23 -0800 (PST) Received: from [192.168.1.4] (unknown [119.95.142.126]) (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 053B51802AAD; Tue, 11 Feb 2014 08:11:20 +0100 (CET) Message-ID: <52F9CD0E.6070309@pi.nu> Date: Tue, 11 Feb 2014 15:11:10 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , draft-ietf-mpls-psc-updates@tools.ietf.org References: <52E63702.20102@pi.nu> In-Reply-To: <52E63702.20102@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [mpls] wglc closed -- Re: working group last call on draft-ietf-mpls-psc-updates-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 07:11:30 -0000 Working Group, This wglc is closed. There has been comments, could the author please address them and post a new version of the document. /Loa for the mpls wg chairs On 2014-01-27 18:37, Loa Andersson wrote: > Working Group, > > This is to initiate a working group last call on > draft-ietf-mpls-psc-updates. > > One reason for the timing, other than that the author thinks is ready > for wglc, is that this document is normatively referenced in > draft-ietf-mpls-tp-psc-itu which also is in wglc. > > There are no IPR disclosures against this document. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > This working group last call ends Feb 190, 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 davis.dorian@aim.com Tue Feb 11 05:21:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364B31A02C6 for ; Tue, 11 Feb 2014 05:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwrRE5Yk7amK for ; Tue, 11 Feb 2014 05:21:27 -0800 (PST) Received: from omr-m08.mx.aol.com (omr-m08.mx.aol.com [64.12.222.129]) by ietfa.amsl.com (Postfix) with ESMTP id 5838F1A0144 for ; Tue, 11 Feb 2014 05:21:27 -0800 (PST) Received: from mtaomg-mbb02.mx.aol.com (mtaomg-mbb02.mx.aol.com [172.26.254.112]) by omr-m08.mx.aol.com (Outbound Mail Relay) with ESMTP id BB2B6701C57BA; Tue, 11 Feb 2014 08:21:26 -0500 (EST) Received: from core-aba06c.mail.aol.com (core-aba06.mail.aol.com [172.27.22.6]) by mtaomg-mbb02.mx.aol.com (OMAG/Core Interface) with ESMTP id 31D4638000087; Tue, 11 Feb 2014 08:21:26 -0500 (EST) References: <52F5F53A.9010107@pi.nu> <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EA04E@nkgeml506-mbx.china.huawei.com> To: lizhenbin@huawei.com, loa@pi.nu, mpls@ietf.org In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EA04E@nkgeml506-mbx.china.huawei.com> X-MB-Message-Source: WebUI Received: from 122.178.254.68 by webmail-d169.sysops.aol.com (205.188.252.84) with HTTP (WebMailUI); Tue, 11 Feb 2014 08:21:25 -0500 MIME-Version: 1.0 From: Dorian Davis X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D0F5434CD06EF9_1B98_7990E_webmail-d169.sysops.aol.com" X-Mailer: AOL Webmail 38366-STANDARD Message-Id: <8D0F5434CC48814-1B98-1F183@webmail-d169.sysops.aol.com> X-Originating-IP: [122.178.254.68] Date: Tue, 11 Feb 2014 08:21:26 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1392124886; bh=pZvxQQU/lQ171U1yOUPutOOihxOhvNTA9Xt/9YUZ8mI=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=nYZ8kYkTe1YNWYNsBHIsNiQp52iRtOO13tBTVWFPz8bfo7Frq3HtM2U+8gzLhytze aeWHJeuA0iV/sP9H63IgIi31WGFZ8qAhQZxhpdBXl6MtuzSGc8UqhYtbgAzSkwxGuh BOg8yzs15TWULsE70be+WxZq4h5zkUryRomPtJvI= x-aol-sid: 3039ac1afe7052fa23d6541f Cc: mpls-chairs@tools.ietf.org, draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org Subject: Re: [mpls] =?utf-8?b?562U5aSNOiAgcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25z?= =?utf-8?q?ensus_to_adopt_draft-rekhter-mpls-pim-sm-over-mldp_as_a_working?= =?utf-8?q?_group_document?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 13:21:34 -0000 This is a multi-part message in MIME format. ----------MB_8D0F5434CD06EF9_1B98_7990E_webmail-d169.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Support!=20 ------------------ Dorian Davis davis.dorian@aim.com -----Original Message----- From: Lizhenbin To: Loa Andersson ; mpls Cc: mpls-chairs ; draft-rekhter-mpls-pim-sm-ove= r-mldp Sent: Tue, Feb 11, 2014 8:30 am Subject: [mpls] =E7=AD=94=E5=A4=8D: poll to see if we have consensus to ad= opt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Support. -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bounces@ietf.org] =E4=BB=A3= =E8=A1=A8 Loa Andersson =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=888=E6=97=A5 17:= 14 =E6=94=B6=E4=BB=B6=E4=BA=BA: mpls@ietf.org =E6=8A=84=E9=80=81: mpls-chairs@tools.ietf.org; draft-rekhter-mpls-pim-sm-o= ver-mldp@tools.ietf.org =E4=B8=BB=E9=A2=98: [mpls] poll to see if we have consensus to adopt draft-= rekhter-mpls-pim-sm-over-mldp=20 as a working group document Working Group, This is to start a two week poll on adopting draft-rekhter-mpls-pim-sm-over= -mld=20 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group= =20 mailing list (mpls@ietf.org). Please give a technical motivation for your= =20 support/not support, especially if you think that the document should not b= e=20 adopted as a working group document. Please note that we have identified an overlap between this document and=20 draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document includes = text=20 to cover this. There are 1 IPR claim against this document. The authors has stated on the working group mailing list that they are not = aware=20 of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR=20 that relates to this draft, the time to disclose this is now. This poll ends February 22, 2014. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ----------MB_8D0F5434CD06EF9_1B98_7990E_webmail-d169.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Support! 

= ------------------
Doria= n Davis
davis.dorian@aim.com


-----= Original Message-----
From: Lizhenbin <lizhenbin@huawei.com>
To: Loa Andersson <loa@pi.nu>; mpls <mpls@ietf.org>
Cc: mpls-chairs <mpls-chairs@tools.ietf.org>; draft-rekhter-mpls-pim-= sm-over-mldp <draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org>
Sent: Tue, Feb 11, 2014 8:30 am
Subject: [mpls] =E7=AD=94=E5=A4=8D: poll to see if we have consensus to ad= opt draft-rekhter-mpls-pim-sm-over-mldp as a working group document

Support.



-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Loa Andersson
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=888=E6=97=A5 17:=
14
=E6=94=B6=E4=BB=B6=E4=BA=BA: mpls@ietf.org=

=E6=8A=84=E9=80=81: mpls-chai=
rs@tools.ietf.org; draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org
=E4=B8=BB=E9=A2=98: [mpls] poll to see if we have consensus to adopt draft-=
rekhter-mpls-pim-sm-over-mldp=20
as a working group document


Working Group,

This is to start a two week poll on adopting draft-rekhter-mpls-pim-sm-over=
-mld=20
as an MPLS working group document.

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

Please note that we have identified an overlap between this document and=20
draft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document includes =
text=20
to cover this.

There are 1 IPR claim against this document.

The authors has stated on the working group mailing list that they are not =
aware=20
of any other IPR claims against this draft.

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

This poll ends February 22, 2014.

/Loa
(mpls wg co-chair)
--=20


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          lo=
a@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/mpls
----------MB_8D0F5434CD06EF9_1B98_7990E_webmail-d169.sysops.aol.com-- From Boris.Zhang@telus.com Tue Feb 11 05:59: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 042D31A0310 for ; Tue, 11 Feb 2014 05:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 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_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 qTCFcA3eRplg for ; Tue, 11 Feb 2014 05:59:47 -0800 (PST) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD651A00BC for ; Tue, 11 Feb 2014 05:59:47 -0800 (PST) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ZVkCmJ7LuGPo0fWToK+H9804P/P++fJku4cMc80fZQr4lWgLF2ktkOsl VS5pAtxxy1t7rUu4gbgz/BurIdgoS4Y8QcJkGxc+zRgsmoT024qJWHi76 kTQkQcl/MDTlY3dko5HqxkFmI1HxfZh2jgW+azXJxX0kNNCCgZiEpgIiQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOwr+lKOP4Bp/2dsb2JhbABagmshOKUOmi6BDxZ0giUBAQEEAQEBNxkbBgUMBAIBCA0EBAEBHwkHJwsUCAEIAgQBDQUIh30BDMguEwSOFxACAR4xBwaDHoEUBIlIlVGLMYNL X-IronPort-AV: E=Sophos;i="4.95,825,1384300800"; d="scan'208";a="295087844" Received: from unknown (HELO WP40057.corp.ads) ([142.63.128.105]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 11 Feb 2014 13:59:46 +0000 Received: from wp40067.corp.ads ([::1]) by WP40057.corp.ads ([::1]) with mapi; Tue, 11 Feb 2014 08:59:45 -0500 From: Boris Zhang To: "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Date: Tue, 11 Feb 2014 08:59:44 -0500 Thread-Topic: Please Reply) FW: IPR Poll on draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHPJseCCycsis66GU+CCLlUcT/KBpqwFRaA Message-ID: <3CC752382EB88F48ADAC4AF9F478A153168D265AD1@WP40067.corp.ads> References: <5316A0AB3C851246A7CA5758973207D445C362F4@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C362F4@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Please Reply) FW: IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Feb 2014 13:59:50 -0000 I am not aware of any IPR associated with this draft. =20 Boris Zhang Telus Inc. -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Monday, February 10, 2014 3:51 PM To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection Working Group, The authors of draft-chen-mpls-p2mp-egress-protection have told the working= group chairs that the draft is ready to be adopted as a working group docu= ment. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protec= tion? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Tue Feb 11 12:09:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364311A0747 for ; Tue, 11 Feb 2014 12:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 B1UrZypgcBZy for ; Tue, 11 Feb 2014 12:09:28 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A44081A073D for ; Tue, 11 Feb 2014 12:09:26 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-dd-52fa8375fe8c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1F.8C.11484.5738AF25; Tue, 11 Feb 2014 21:09:26 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 15:09:24 -0500 From: Gregory Mirsky To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document Thread-Index: AQHPJK4cGe8GOjEH00S8Mj+RngnP75qwgN4w Date: Tue, 11 Feb 2014 20:09:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B761046@eusaamb103.ericsson.se> References: <52F5F53A.9010107@pi.nu> In-Reply-To: <52F5F53A.9010107@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXRPrG5Z868gg113+C2av3pb/Js7h9ni +6UlLBa3lq5kdWDxWLLkJ5PHrOltbB5fLn9mC2CO4rJJSc3JLEst0rdL4MqYs/0hW8Em3oov T34zNTDe5upi5OSQEDCR2Dl1JjOELSZx4d56ti5GLg4hgSOMEt2PT0E5yxklNl7qYwKpYhMw knixsYcdxBYRsJPY+OofI0gRs8AaRolF5w+ydDFycAgL1Et8358CEhcRaGCUeLT8GlSDkUTz krssIDaLgKrEs91zwOp5BXwlrhxlAzGFBFQkpm+TAKngBKp4eugLG4jNCHTc91NrwE5gFhCX uPVkPhPE0QISS/ach3pAVOLl43+sELaixL7+6ewQ9ToSC3Z/YoOwtSWWLXwNVs8rIChxcuYT lgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtzECIygYxJsjjsYF3yyPMQozcGiJM77 5a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGhe3ru22kNzK+8DrgPWmtodG58i/neZPS l+5U1o6dbxDdF3Fq6ef4neW3M00svwhFn/o7wauVr/ryqayy+zlb9ngXpfcfOZLu5rD5TLOM 5PLKGapKhZ8ecD5WXlfVkpl54xhXf/eKpZu2Tl1yjVH6/Or1bYxlix/IhQalbOxM6T7yxN1c 26VDiaU4I9FQi7moOBEAYP+nQ24CAAA= Cc: "mpls-chairs@tools.ietf.org" , "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 20:09:30 -0000 yes/support Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, February 08, 2014 1:14 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-rekhter-mpls-pim-sm-over-mldp@tools.i= etf.org Subject: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpl= s-pim-sm-over-mldp as a working group document Working Group, This is to start a two week poll on adopting draft-rekhter-mpls-pim-sm-over= -mld as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. Please note that we have identified an overlap between this document and dr= aft-wijnands-mpls-mldp-in-band-wildcard-encoding. This document includes te= xt to cover this. There are 1 IPR claim against this document. The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends February 22, 2014. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Tue Feb 11 19:42:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7901A081A for ; Tue, 11 Feb 2014 19:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Lu8_3nHv8PDi for ; Tue, 11 Feb 2014 19:42:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 729101A0803 for ; Tue, 11 Feb 2014 19:42:52 -0800 (PST) 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 BBA38571; Wed, 12 Feb 2014 03:42:50 +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; Wed, 12 Feb 2014 03:42:33 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 03:42:46 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 19:42:35 -0800 From: Huaimo Chen To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: IPR Poll on draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHPJqo4ypWXuvo0GkKTwKBGWrlxJ5qwyuOg Date: Wed, 12 Feb 2014 03:42:34 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C36ABA@SJCEML701-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Feb 2014 03:42:55 -0000 I am not aware of any related IPRs that have not been disclosed. There are = two IPRs that have been disclosed and being processed by the IETF disclosur= e system. The application numbers are 61883006 and 61841726. Best Regards, Huaimo -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 10, 2014 4:51 PM To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection Working Group, The authors of draft-chen-mpls-p2mp-egress-protection have told the working= group chairs that the draft is ready to be adopted as a working group docu= ment. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protec= tion? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From stephane.litkowski@orange.com Wed Feb 12 06:11: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 B6CF31A0990 for ; Wed, 12 Feb 2014 06:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3e_jAbgajcV for ; Wed, 12 Feb 2014 06:11:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 638591A02E3 for ; Wed, 12 Feb 2014 06:11:19 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A634A22C930; Wed, 12 Feb 2014 15:11:17 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7BBCE238082; Wed, 12 Feb 2014 15:11:17 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 12 Feb 2014 15:11:16 +0100 From: To: Sriganesh Kini Date: Wed, 12 Feb 2014 15:11:15 +0100 Thread-Topic: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Thread-Index: Ac8jh2c//SB3EGD8TJeS6r23l8d13gEcxLeg Message-ID: <4219_1392214277_52FB8105_4219_13676_1_EEE55384044474429A926C625D0FCC810C32CFB573@PUEXCB2F.nanterre.francetelecom.fr> References: <11094_1391177507_52EBAF23_11094_2718_1_EEE55384044474429A926C625D0FCC8109A301097D@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810C32CFB573PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714 Cc: "mpls@ietf.org" , "draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org" Subject: Re: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Feb 2014 14:11:26 -0000 --_000_EEE55384044474429A926C625D0FCC810C32CFB573PUEXCB2Fnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3JpLA0KDQpQbHMgZmluZCBtb3JlIGlubGluZQ0KDQpCZXN0IFJlZ2FyZHMsDQoNClN0ZXBo YW5lDQoNCg0KRGUgOiBzcmlnYW5lc2hraW5pQGdtYWlsLmNvbSBbbWFpbHRvOnNyaWdhbmVzaGtp bmlAZ21haWwuY29tXSBEZSBsYSBwYXJ0IGRlIFNyaWdhbmVzaCBLaW5pDQpFbnZvecOpIDogamV1 ZGkgNiBmw6l2cmllciAyMDE0IDIzOjA0DQrDgCA6IExJVEtPV1NLSSBTdGVwaGFuZSBEVEYvREVS WA0KQ2MgOiBkcmFmdC1raW5pLW1wbHMtZW50cm9weS1sYWJlbC1zcmMtc3RhY2tlZC10dW5uZWxz QHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnDQpPYmpldCA6IFJlOiBbbXBsc10gZHJhZnQt a2luaS1tcGxzLWVudHJvcHktbGFiZWwtc3JjLXN0YWNrZWQtdHVubmVscw0KDQpIaSBTdGVwaGFu ZSwNCg0KT24gRnJpLCBKYW4gMzEsIDIwMTQgYXQgNjoxMSBBTSwgPHN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3Rl Og0KSGkgQXV0aG9ycywNCg0KDQpJIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB5b3UgYXJlIHByb2dy ZXNzaW5nIG9uIHRoaXMgZHJhZnQgPw0KRW50cm9weSBsYWJlbCBzdXBwb3J0IGZvciBzdGFja2Vk IHR1bm5lbHMgd291bGQgYmUgbWFuZGF0b3J5IGZvciB1cywgc28gSSB3b3VsZCBsaWtlIHRvIHN1 cHBvcnQgdGhlIHdvcmsgb24gdGhpcyB0b3BpYyB0byBoYXZlIGEgd29ya2luZyBzb2x1dGlvbiBh cyBzb29uIGFzIHBvc3NpYmxlLg0KDQpZZXMsIHdlIGFyZSBwcm9ncmVzc2luZyBvbiB0aGlzIGRy YWZ0LiBUaGFua3MgZm9yIHN1cHBvcnRpbmcgdGhpcyB3b3JrLg0KDQoNCg0KUmVnYXJkaW5nIHRo ZSBzb2x1dGlvbnMgeW91IGFyZSBwcm9wb3NpbmcgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiwgdGhl cmUgaXMgbm9uZSBwZXJmZWN0IG9uZSwgYW5kIHVuZm9ydHVuYXRlbHkgYWxsIGhhdmUgZHJhd2Jh Y2tzLg0KDQpQcmVjaXNlbHkgd2h5IHdlIHdhbnRlZCB0byBwdXQgYWxsIHRoZSBvcHRpb25zIG9u IHRoZSB0YWJsZS4NCg0KVGhlIGNvbXBhdGliaWxpdHkgKG9uIExTUikgd2l0aCBjdXJyZW50IGdl bmVyYXRpb24gb2YgaGFyZHdhcmVzIG1heSBiZSDigJxnb29k4oCdIChtYW5kYXRvcnkgPykgZm9y IHRoZSB0YXJnZXQgc29sdXRpb24uDQoNCkluIHlvdXIgZG9jdW1lbnQgLCBzb2x1dGlvbiDCpzMu MyDigJxyZS11c2FibGUgRUwgZm9yIGEgc3RhY2sgb2YgdHVubmVsc+KAnSBzb3VuZHMgZm9yIG1l IHRvIGJlIHRoZSBiZXN0IGJhc2UgaWRlYS4gSeKAmW0ganVzdCB3b25kZXJpbmcgd2hhdCB3b3Vs ZCBiZSB0aGUgaGFyZHdhcmUgaW1wYWN0IG9mIGRvaW5nIHRoZSByZWluc2VydGlvbiBvZiBFTEkg YXQgdHVubmVsIGVuZCAuIENvdWxkIHRoaXMgYmUgZG9uZSBpbiBvbmUgcGFzcyA/IChJTUhPLCB0 aGlzIG1heSBiZSBwb3NzaWJsZSwgYXMgdG9kYXkgd2UgYXJlIGFibGUgdG8gcG9wIG9yIHN3YXAg KyBwdXNoIEZSUiBoZWFkZXJzKSBBcyB5b3UgYXJlIHRocmVlIGRpZmZlcmVudCB2ZW5kb3JzIGFz IGNvLWF1dGhvciwgZGlkIHlvdSBhbHJlYWR5IGV2YWx1YXRlIHN1Y2ggaW1wYWN0IG9uIHlvdXIg aGFyZHdhcmVzID8gKEnigJltIG5vdCBleHBlY3RpbmcgZGV0YWlscyBvbiB0aGUgbWFpbGluZyBs aXN0LCBidXQgSSB3b3VsZCBiZSBpbnRlcmVzdGVkIGJ5IGRldGFpbHMgdW5pY2FzdCB0byBtZSBh bmQganVzdCB5ZXMvbm8gb24gdGhlIHRoZSBsaXN0KQ0KDQpUaGlzIGlzIHZlbmRvcitwbGF0Zm9y bSBzcGVjaWZpYyBxdWVzdGlvbi4gSU1PIGl0IGlzIGJlc3QgaWYgdGhlIGRldGFpbHMgYXJlIHVu aWNhc3QuDQpbU0xJXSBZZXAg4pi6DQoNCg0KVG8gYmUgZXhoYXVzdGl2ZSBpbiBsaXN0aW5nIHNv bHV0aW9ucywgZGlkIHlvdSB0aGluayBhYm91dCBsZWF2aW5nIHRoZSBFTC9FTEkgYXQgdG9wIG9m IHRoZSBzdGFjayA/IEkgdGhpbmsgdGhlcmUgaXMgYWxyZWFkeSBhIGNhc2Ugd2hlcmUgYSBzcGVj aWFsIGxhYmVsIG1heQ0KDQpZZXMsIHdlIGhhZCBjb25zaWRlcmVkIHRoaXMuIFNpbmNlIGl0IHdh cyBub3QgaW5saW5lIHdpdGggUkZDNjc5MCBhbmQgaXQgaXMgYWxtb3N0IGV4YWN0bHkgdGhlIHNh bWUgYXMgdGhlIHJlLXVzYWJsZSBFTCBvcHRpb24sIHdlIGRpZCBub3QgaW5jbHVkZSBpdC4NCiBb U0xJXSBBZ3JlZSwgcHV0IGZvciBub3csIEkgZG9u4oCZdCByZWFsbHkgd2FudCB0byBzZWUgdGhp cyBvcHRpb24gZGlzY2FyZGVkDQpiZSBrZXB0IGF0IHRvcCBvZiB0aGUgc3RhY2sgKE1QTFMgUm91 dGVyIGFsZXJ0KS4NCldoYXQgd291bGQgYmUgbmVlZGVkIDoNCg0KLSAgICAgICAgICBlYWNoIGhv cCBuZWVkIHRvIGFkdmVydGlzZSBpcyBhYmlsaXR5IHRvIHByb2Nlc3MgRUwsIGlmIG5leHRob3Ag Y2Fubm90IHByb2Nlc3MgRUwsIGl0IHNob3VsZCBiZSByZW1vdmVkIHdoZW4gZm9yd2FyZGVkIHRv IG5leHRob3AgKHRoZXJlIHNob3VsZCBiZSB0aGUgc2FtZSByZXF1aXJlbWVudCBmb3IgcmUtdXNh YmxlIEVMKQ0KDQpFTCBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQgdmlhIElHUCBpcyBkZWZpbmVk IGluIGRyYWZ0LXh1LXtpc2lzfG9zcGZ9LW1wbHMtZWxjLiBSZS1pbnNlcnRpbmcgRUwgaXQgYXQg dGhlIG5leHQgcGxhY2UgaW4gdGhlIHN0YWNrIHdoZXJlIHRoZSBuZXh0IEVMIGNhcGFiaWxpdHkg TFNSIGFsb25nIHRoZSBwYXRoIGlzIHRoZXJlIGlzIGEgYmV0dGVyIG9wdGlvbiB0aGFuIGp1c3Qg cmVtb3ZpbmcgRUwgd2hlbiBuZXh0aG9wIGlzIG5vdCBFTCBjYXBhYmxlLiBCdXQgdGhpcyB1bm5l Y2Vzc2FyeSBidXJkZW4gb24gdHJhbnNpdCBMU1IuIEEgYmV0dGVyIGFsdGVybmF0aXZlIGNvdWxk IGJlIHRoZSBpbmdyZXNzIHNpbmNlIGl0IGNhbiBkZXRlcm1pbmUgbW9yZSBlYXNpbHkgYXMgdG8g d2hpY2ggTFNScyBhbG9uZyB0aGUgcGF0aCBhcmUgbm90IEVMIGNhcGFibGUgYW5kIHRoZW4gaW5z ZXJ0IG11bHRpcGxlIEVMcyBzdWNoIHRoYXQgZXZlbiBpZiBhbiBFTCBpcyBkcm9wcGVkIHdoZW4g bmV4dGhvcCBpcyBub3QgRUwgY2FwYWJsZSwgdGhlbiBhbm90aGVyIEVMIGlzIGF2YWlsYWJsZSBp biB0aGUgc3RhY2sgd2hlbiB0aGUgcGFja2V0IHJlYWNoZXMgTFNScyB0aGF0IGFyZSBFTCBjYXBh YmxlLiBUaGUgdHJhZGVvZmYgaXMgaW5jcmVhc2VkIHN0YWNrIHNpemUsIGJ1dCBzaXplIGluY3Jl YXNlcyBvbmx5IGJ5IHRoZSBudW1iZXIgb2Ygbm9uIEVMIGNhcGFibGUgTFNSIHNlZ21lbnRzIGFs b25nIHRoZSBwYXRoLg0KDQpbU0xJXSBSYXRoZXIgdGhhbiB1c2luZyBhIG5ldyBzdWJUTFYgZm9y IGFkdmVydGlzaW5nIEVMQyAsIGl0IHdvdWxkIGJlIGVhc2llciB0byBqdXN0IGFkZCBhIGJpdCBp biB0aGUg4oCcU3RhY2tlZCB0dW5uZWzigJ0gKGV4IHNlZ21lbnQgcm91dGluZykgY2FwYWJpbGl0 eSDigKYNCg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyByZWFsbHkgZGlmZmVyZW50IGZyb20g cmUtdXNhYmxlIEVMIGluIHRoZSBjb25jZXB0IDoNCg0KWWVzLiBCdXQgdGhlIGRpZmZlcmVuY2Vz IGFyZSBzdWJ0bGUuDQoNCi0gICAgICAgICAgcmV1c2FibGUgRUwgOiBwcm9jZXNzIHRvcCBsZXZl bCBmb3J3YXJkaW5nIGxhYmVsLCBpZiBwb3BwZWQgYW5kIG5leHQgbGFiZWwgaXMgRUwsIHBvcCBF TEkvRUwgYW5kIG5leHQgbGFiZWwgTCwgcHVzaCBwYWNrIEVMSS9FTCBhbmQgdGhlbiBMICh3ZSBu ZWVkIHRvIHN3YXAgcG9zaXRpb25zIGJldHdlZW4gRUxJL0VMIGFuZCBMKSBpZiBuZXh0aG9wIGlz IGFibGUgdG8gcHJvY2VzcyBFTC4NCk1vc3RseSBjb3JyZWN0LiBCdXQgbm90ZSB0aGF0IHdoZW4g YSB0dW5uZWwtc2VnbWVudCBpcyB0ZXJtaW5hdGVkIGF0IGEgTFNSLCB0aGUgbGFiZWwtb3BlcmF0 aW9uIGZvciBuZXh0IHR1bm5lbC1zZWdtZW50IGlzIHN3YXAuDQpbU0xJXSBZZXMsIGl0IG1heSBi ZSBzd2FwIG9yIHBvcCBkZXBlbmRpbmcgb2YgdGhlIHNlZ21lbnQgdHlwZS4NCg0KSW4geW91ciBl eGFtcGxlIHRoZSBvcGVyYXRpb24gZm9yIHRoZSBpbmNvbWluZyBsYWJlbCBMIHdvdWxkIGJlIHN3 YXAsIGhlbmNlIHRoZSBvdXRnb2luZyBsYWJlbCBtYXkgYmUgTCcuIFNvIHRoZSByZWNlaXZlZCBF TEkvRUwgbmVlZHMgdG8gYmUgcHVzaGVkIGR1cmluZyB0aGlzIG9wZXJhdGlvbi4gQWR2ZXJ0aXNp bmcgdGhpcyBjYXBhYmlsaXR5IGlzIHNpbXBsZSBzaW5jZSB0aGlzIGlzIHRoZSB0dW5uZWwgdGVy bWluYXRpb24gcG9pbnQuIFdoZW4gdGhlIG9wZXJhdGlvbiBpcyBzd2FwIHdpdGhvdXQgdGVybWlu YXRpbmcgdGhlIHR1bm5lbC1zZWdtZW50LCB0aGVuIEVMSS9FTCBpcyBub3QgYXQgdGhlIHRvcCBv ZiBzdGFjayBzbyB0aGUgdHJhbnNpdCBMU1Igb2YgdGhlIHR1bm5lbC1zZWdtZW50IGRvZXMgbm90 IG5lZWQgYW55IGFkZGl0aW9uYWwgY2FwYWJpbGl0eS4gU28gdGhlICJubyB0cmFuc2l0IExTUiBj aGFuZ2UiIHByb3BlcnR5IG9mIFJGQzY3OTAgaXMgcHJlc2VydmVkLiBPbmx5IHRoZSBMU1JzIHRo YXQgYXJlIHRlcm1pbmF0aW5nIHR1bm5lbC1zZWdtZW50cyBuZWVkIHRoZSBuZXcgY2FwYWJpbGl0 eS4NCg0KW1NMSV0gUmlnaHQsIGJ1dCBpbiBhIFNQUklORyBkb21haW4sIGFueSBub2RlIHdpbGwg cmVxdWlyZSB0aGlzLCBlc3BlY2lhbGx5IHdoZW4gVHJhZmZpYyBlbmdpbmVlcmluZyB1c2UgY2Fz ZSBpcyB1c2VkIGFuZCBjb21iaW5hdGlvbiBvZiBub2RlL2FkaiBzZWdtZW50IG1heSB1c2UgYW55 IG5vZGUuDQoNCg0KLSAgICAgICAgICB0b3AgbGV2ZWwgRUwgOiBwcm9jZXNzIHRvcCBsZXZlbCBF TEksIEVMSSBpcyByZWNvZ25pemVkLCBFTEkvRUwgaXMgcmVtb3ZlZCwgZm9yd2FyZGluZyBpcyBk b25lIG9uIGZvcndhcmRpbmcgbGFiZWwsIEVMSS9FTCBpcyBwdXNoZWQgYmFjayBpbiBuZXh0aG9w IGlzIGFibGUgdG8gcHJvY2VzcyBFTC4NClRoZSBiaWdnZXN0IGRyYXdiYWNrIGlzIHRoYXQgZXZl cnkgTFNSIGFsb25nIGV2ZXJ5IHR1bm5lbC1zZWdtZW50IHNob3VsZCBub3cgaGF2ZSB0aGUgbmV3 IGJlaGF2aW9yIG9mIHB1c2hpbmcgdGhlIHJlY2VpdmVkIEVMSS9FTCBhZnRlciB0aGUgZm9yd2Fy ZGluZyBsYWJlbCBzd2FwLg0KDQpbU0xJXSBOb3QgYSBiaWcgZGVhbCAsIGFzIHRoZSBub2RlIHdv dWxkIHJlcXVpcmUgdG8gYmUgdXBncmFkZWQgdG8gc3VwcG9ydCBzdGFja2VkIHR1bm5lbCBhbHNv IGFuZCBhbGwgbm9kZXMgaW4gdGhlIFNQUklORyBkb21haW4gd2lsbCByZXF1aXJlIGEgc29mdHdh cmUgdXBncmFkZSDigKYNCg0KSW4gdGVybSBvZiBvcGVyYXRpb25zLCBJIHRoaW5rIHRoYXQgdG9w IGxldmVsIEVMIG1heSBiZSBzaW1wbGVyICwgYnV0IGFzIEnigJltIG5vdCBoYXJkd2FyZSBjb2Rl ciwgbWF5IGJlIEnigJltIHdyb25nIOKApiBtb3Jlb3ZlciBpdCBtYXkgYmUgc2ltaWxhciB0byBN UExTIFJvdXRlciBhbGVydCBwcm9jZXNzaW5nLg0KDQpJdCBpcyBkaWZmZXJlbnQgZnJvbSBSb3V0 ZXItYWxlcnQgcHJvY2Vzc2luZy4gSGVyZSBldmVyeXRoaW5nIGlzIGluIHRoZSBmYXN0LXBhdGgg YW5kIHByb2Nlc3NpbmcgaGFzIHRvIGJlIGF0IGxpbmUtcmF0ZS4gSW4gY2FzZSBvZiBSb3V0ZXIt YWxlcnQgaXQgd2FzIGhhbmRvZmYgdG8gYSBzb2Z0d2FyZSBtb2R1bGUgZm9yIHNsb3dlci1wYXRo IHByb2Nlc3NpbmcuDQoNCltTTEldIEkgaG9wZSB0aGFuIHBvcCAmIHB1c2ggb2Ygcm91dGVyIGFs ZXJ0IGlzIGhhbmRsZWQgaW4gSFcsIGp1c3QgcGFja2V0IGluc3BlY3Rpb24gaXMgZG9uZSBpbiBz b2Z0d2FyZSAoYnV0IG1heWJlIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCkuIFdlIGNvdWxkIGtl ZXAgZmFzdCBwYXRoIGhlcmUsIGFzIHdlIGRvbuKAmXQgbmVlZCBwYWNrZXQgaW5zcGVjdGlvbiwg anVzdCBwb3AsIHB1c2guDQoNCg0KDQoNCllvdXIgdGhvdWdodHMgPw0KDQoNCkkgdGhpbmsgdG9w LWxldmVsIEVMIGlzIGhhcmRlciB0byBkZXBsb3kgYW5kIGxlc3MgaW4tbGluZSB3aXRoIFJGQzY3 OTAuDQoNCltTTEldIE5vdCBzdXJlIGl0IG1heSBiZSBoYXJkZXIgdG8gZGVwbG95LCBidXQgYWdy ZWUgdGhhdCBpdOKAmXMgbm90IGlubGluZSB3aXRoIFJDNjc5MC4NCkJ1dCBhbnl3YXksIEnigJlt IG5vdCBwdXNoaW5nIGFueSBzb2x1dGlvbiBub3csIGRpc2N1c3Npb25zIGFyZSBuZWVkZWQgdG8g Z2F0aGVyIG9waW5pb25zL2NvbnN0cmFpbnRzIG9mIG90aGVyIHBlb3BsZSB0byBkZWZpbmUgdGhl IGJlc3Qgb25lLg0KQXJlIHlvdSBwbGFubmluZyBhIHNlc3Npb24gb24gdGhpcyB0b3BpYyBpbiBM b25kb24gPw0KDQoNCg0KU3JpDQoNCg0KDQpTdGVwaGFuZQ0KDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0K DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_EEE55384044474429A926C625D0FCC810C32CFB573PUEXCB2Fnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOp Zm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkZSO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1GUiBs aW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGkgU3JpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlBscyBmaW5kIG1vcmUgaW5saW5lPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QmVzdCBSZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlN0ZXBoYW5lPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gc3JpZ2FuZXNoa2luaUBnbWFpbC5jb20gW21haWx0bzpzcmlnYW5lc2hraW5pQGdtYWlsLmNv bV0gPGI+RGUgbGEgcGFydCBkZTwvYj4gU3JpZ2FuZXNoIEtpbmk8YnI+PGI+RW52b3nDqSZuYnNw Ozo8L2I+IGpldWRpIDYgZsOpdnJpZXIgMjAxNCAyMzowNDxicj48Yj7DgCZuYnNwOzo8L2I+IExJ VEtPV1NLSSBTdGVwaGFuZSBEVEYvREVSWDxicj48Yj5DYyZuYnNwOzo8L2I+IGRyYWZ0LWtpbmkt bXBscy1lbnRyb3B5LWxhYmVsLXNyYy1zdGFja2VkLXR1bm5lbHNAdG9vbHMuaWV0Zi5vcmc7IG1w bHNAaWV0Zi5vcmc8YnI+PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW21wbHNdIGRyYWZ0LWtpbmkt bXBscy1lbnRyb3B5LWxhYmVsLXNyYy1zdGFja2VkLXR1bm5lbHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPkhpIFN0ZXBoYW5lLDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gRnJpLCBKYW4gMzEsIDIwMTQgYXQgNjoxMSBBTSwgJmx0 OzxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkhpIEF1dGhvcnMsPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gbGFuZz1FTi1VUz5JIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB5b3UgYXJlIHByb2dyZXNz aW5nIG9uIHRoaXMgZHJhZnQmbmJzcDs/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVM+RW50cm9weSBsYWJlbCBzdXBwb3J0IGZvciBzdGFj a2VkIHR1bm5lbHMgd291bGQgYmUgbWFuZGF0b3J5IGZvciB1cywgc28gSSB3b3VsZCBsaWtlIHRv IHN1cHBvcnQgdGhlIHdvcmsgb24gdGhpcyB0b3BpYyB0byBoYXZlIGEgd29ya2luZyBzb2x1dGlv biBhcyBzb29uIGFzIHBvc3NpYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5ZZXMsIHdlIGFyZSBwcm9ncmVzc2luZyBvbiB0aGlzIGRyYWZ0LiBU aGFua3MgZm9yIHN1cHBvcnRpbmcgdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3Rl IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVM+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxh bmc9RU4tVVM+UmVnYXJkaW5nIHRoZSBzb2x1dGlvbnMgeW91IGFyZSBwcm9wb3NpbmcgaW4gdGhl IGN1cnJlbnQgdmVyc2lvbiwgdGhlcmUgaXMgbm9uZSBwZXJmZWN0IG9uZSwgYW5kIHVuZm9ydHVu YXRlbHkgYWxsIGhhdmUgZHJhd2JhY2tzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UHJlY2lzZWx5IHdoeSB3ZSB3YW50ZWQg dG8gcHV0IGFsbCB0aGUgb3B0aW9ucyBvbiB0aGUgdGFibGUuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGJsb2Nr cXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtJz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1VUz5UaGUg Y29tcGF0aWJpbGl0eSAob24gTFNSKSB3aXRoIGN1cnJlbnQgZ2VuZXJhdGlvbiBvZiBoYXJkd2Fy ZXMgbWF5IGJlIOKAnGdvb2TigJ0gKG1hbmRhdG9yeSA/KSBmb3IgdGhlIHRhcmdldCBzb2x1dGlv bi48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1F Ti1VUz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gbGFuZz1FTi1VUz5JbiB5b3VyIGRvY3VtZW50ICwgc29sdXRpb24gwqczLjMg4oCccmUtdXNh YmxlIEVMIGZvciBhIHN0YWNrIG9mIHR1bm5lbHPigJ0gc291bmRzIGZvciBtZSB0byBiZSB0aGUg YmVzdCBiYXNlIGlkZWEuIEnigJltIGp1c3Qgd29uZGVyaW5nIHdoYXQgd291bGQgYmUgdGhlIGhh cmR3YXJlIGltcGFjdCBvZiBkb2luZyB0aGUgcmVpbnNlcnRpb24gb2YgRUxJIGF0IHR1bm5lbCBl bmQgLiBDb3VsZCB0aGlzIGJlIGRvbmUgaW4gb25lIHBhc3MgPyAoSU1ITywgdGhpcyBtYXkgYmUg cG9zc2libGUsIGFzIHRvZGF5IHdlIGFyZSBhYmxlIHRvIHBvcCBvciBzd2FwICsgcHVzaCBGUlIg aGVhZGVycykgQXMgeW91IGFyZSB0aHJlZSBkaWZmZXJlbnQgdmVuZG9ycyBhcyBjby1hdXRob3Is IGRpZCB5b3UgYWxyZWFkeSBldmFsdWF0ZSBzdWNoIGltcGFjdCBvbiB5b3VyIGhhcmR3YXJlcyA/ IChJ4oCZbSBub3QgZXhwZWN0aW5nIGRldGFpbHMgb24gdGhlIG1haWxpbmcgbGlzdCwgYnV0IEkg d291bGQgYmUgaW50ZXJlc3RlZCBieSBkZXRhaWxzIHVuaWNhc3QgdG8gbWUgYW5kIGp1c3QgeWVz L25vIG9uIHRoZSB0aGUgbGlzdCk8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9i bG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgaXMgdmVuZG9yK3BsYXRmb3JtIHNwZWNp ZmljIHF1ZXN0aW9uLiBJTU8gaXQgaXMgYmVzdCBpZiB0aGUgZGV0YWlscyBhcmUgdW5pY2FzdC48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5b U0xJXSBZZXAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QnPko8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1VUz5UbyBiZSBleGhhdXN0aXZlIGlu IGxpc3Rpbmcgc29sdXRpb25zLCBkaWQgeW91IHRoaW5rIGFib3V0IGxlYXZpbmcgdGhlIEVML0VM SSBhdCB0b3Agb2YgdGhlIHN0YWNrID8gSSB0aGluayB0aGVyZSBpcyBhbHJlYWR5IGEgY2FzZSB3 aGVyZSBhIHNwZWNpYWwgbGFiZWwgbWF5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5ZZXMsIHdlIGhhZCBjb25zaWRlcmVkIHRo aXMuIFNpbmNlIGl0IHdhcyBub3QgaW5saW5lIHdpdGggUkZDNjc5MCBhbmQgaXQgaXMgYWxtb3N0 IGV4YWN0bHkgdGhlIHNhbWUgYXMgdGhlIHJlLXVzYWJsZSBFTCBvcHRpb24sIHdlIGRpZCBub3Qg aW5jbHVkZSBpdC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5bU0xJXSBB Z3JlZSwgcHV0IGZvciBub3csIEkgZG9u4oCZdCByZWFsbHkgd2FudCB0byBzZWUgdGhpcyBvcHRp b24gZGlzY2FyZGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90 ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20n PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLVVTPmJlIGtlcHQg YXQgdG9wIG9mIHRoZSBzdGFjayAoTVBMUyBSb3V0ZXIgYWxlcnQpLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLVVTPldoYXQgd291bGQgYmUg bmVlZGVkIDogPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIGxhbmc9RU4tVVM+LTwvc3Bh bj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUz5lYWNoIGhvcCBuZWVkIHRvIGFkdmVydGlzZSBpcyBhYmlsaXR5IHRvIHByb2Nlc3Mg RUwsIGlmIG5leHRob3AgY2Fubm90IHByb2Nlc3MgRUwsIGl0IHNob3VsZCBiZSByZW1vdmVkIHdo ZW4gZm9yd2FyZGVkIHRvIG5leHRob3AgKHRoZXJlIHNob3VsZCBiZSB0aGUgc2FtZSByZXF1aXJl bWVudCBmb3IgcmUtdXNhYmxlIEVMKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RUwgY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50 IHZpYSBJR1AgaXMgZGVmaW5lZCBpbiZuYnNwO2RyYWZ0LXh1LXtpc2lzfG9zcGZ9LW1wbHMtZWxj LiBSZS1pbnNlcnRpbmcgRUwgaXQgYXQgdGhlIG5leHQgcGxhY2UgaW4gdGhlIHN0YWNrIHdoZXJl IHRoZSBuZXh0IEVMIGNhcGFiaWxpdHkgTFNSIGFsb25nIHRoZSBwYXRoIGlzIHRoZXJlIGlzIGEg YmV0dGVyIG9wdGlvbiB0aGFuIGp1c3QgcmVtb3ZpbmcgRUwgd2hlbiBuZXh0aG9wIGlzIG5vdCBF TCBjYXBhYmxlLiBCdXQgdGhpcyB1bm5lY2Vzc2FyeSBidXJkZW4gb24gdHJhbnNpdCBMU1IuIEEg YmV0dGVyIGFsdGVybmF0aXZlIGNvdWxkIGJlIHRoZSBpbmdyZXNzIHNpbmNlIGl0IGNhbiBkZXRl cm1pbmUgbW9yZSBlYXNpbHkgYXMgdG8gd2hpY2ggTFNScyBhbG9uZyB0aGUgcGF0aCBhcmUgbm90 IEVMIGNhcGFibGUgYW5kIHRoZW4gaW5zZXJ0IG11bHRpcGxlIEVMcyBzdWNoIHRoYXQgZXZlbiBp ZiBhbiBFTCBpcyBkcm9wcGVkIHdoZW4gbmV4dGhvcCBpcyBub3QgRUwgY2FwYWJsZSwgdGhlbiBh bm90aGVyIEVMIGlzIGF2YWlsYWJsZSBpbiB0aGUgc3RhY2sgd2hlbiB0aGUgcGFja2V0IHJlYWNo ZXMgTFNScyB0aGF0IGFyZSBFTCBjYXBhYmxlLiBUaGUgdHJhZGVvZmYgaXMgaW5jcmVhc2VkIHN0 YWNrIHNpemUsIGJ1dCBzaXplIGluY3JlYXNlcyBvbmx5IGJ5IHRoZSBudW1iZXIgb2Ygbm9uIEVM IGNhcGFibGUgTFNSIHNlZ21lbnRzIGFsb25nIHRoZSBwYXRoLjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5bU0xJXSBSYXRoZXIgdGhhbiB1c2luZyBhIG5ldyBzdWJUTFYg Zm9yIGFkdmVydGlzaW5nIEVMQyAsIGl0IHdvdWxkIGJlIGVhc2llciB0byBqdXN0IGFkZCBhIGJp dCBpbiB0aGUg4oCcU3RhY2tlZCB0dW5uZWzigJ0gKGV4IHNlZ21lbnQgcm91dGluZykgY2FwYWJp bGl0eSDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IGxhbmc9RU4tVVM+SSBkb27igJl0IHRoaW5rIHRoaXMgaXMgcmVhbGx5IGRpZmZlcmVudCBmcm9t IHJlLXVzYWJsZSBFTCBpbiB0aGUgY29uY2VwdCA6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5ZZXMuIEJ1dCB0aGUgZGlmZmVy ZW5jZXMgYXJlIHN1YnRsZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxkaXY+PGRp dj48cD48c3BhbiBsYW5nPUVOLVVTPi08L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjcuMHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+cmV1c2FibGUgRUwgOiBwcm9jZXNz IHRvcCBsZXZlbCBmb3J3YXJkaW5nIGxhYmVsLCBpZiBwb3BwZWQgYW5kIG5leHQgbGFiZWwgaXMg RUwsIHBvcCBFTEkvRUwgYW5kIG5leHQgbGFiZWwgTCwgcHVzaCBwYWNrIEVMSS9FTCBhbmQgdGhl biBMICh3ZSBuZWVkIHRvIHN3YXAgcG9zaXRpb25zIGJldHdlZW4gRUxJL0VMIGFuZCBMKSBpZiBu ZXh0aG9wIGlzIGFibGUgdG8gcHJvY2VzcyBFTC48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk1vc3RseSBjb3JyZWN0 LiBCdXQgbm90ZSB0aGF0IHdoZW4gYSB0dW5uZWwtc2VnbWVudCBpcyB0ZXJtaW5hdGVkIGF0IGEg TFNSLCB0aGUgbGFiZWwtb3BlcmF0aW9uIGZvciBuZXh0IHR1bm5lbC1zZWdtZW50IGlzIHN3YXAu IDxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bU0xJXSBZZXMs IGl0IG1heSBiZSBzd2FwIG9yIHBvcCBkZXBlbmRpbmcgb2YgdGhlIHNlZ21lbnQgdHlwZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVM+SW4geW91ciBleGFtcGxlIHRoZSBvcGVyYXRpb24gZm9yIHRo ZSBpbmNvbWluZyBsYWJlbCBMIHdvdWxkIGJlIHN3YXAsIGhlbmNlIHRoZSBvdXRnb2luZyBsYWJl bCBtYXkgYmUgTCcuIDwvc3Bhbj5TbyB0aGUgcmVjZWl2ZWQgRUxJL0VMIG5lZWRzIHRvIGJlIHB1 c2hlZCBkdXJpbmcgdGhpcyBvcGVyYXRpb24uIEFkdmVydGlzaW5nIHRoaXMgY2FwYWJpbGl0eSBp cyBzaW1wbGUgc2luY2UgdGhpcyBpcyB0aGUgdHVubmVsIHRlcm1pbmF0aW9uIHBvaW50LiBXaGVu IHRoZSBvcGVyYXRpb24gaXMgc3dhcCB3aXRob3V0IHRlcm1pbmF0aW5nIHRoZSB0dW5uZWwtc2Vn bWVudCwgdGhlbiBFTEkvRUwgaXMgbm90IGF0IHRoZSB0b3Agb2Ygc3RhY2sgc28gdGhlIHRyYW5z aXQgTFNSIG9mIHRoZSB0dW5uZWwtc2VnbWVudCBkb2VzIG5vdCBuZWVkIGFueSBhZGRpdGlvbmFs IGNhcGFiaWxpdHkuIFNvIHRoZSAmcXVvdDtubyB0cmFuc2l0IExTUiBjaGFuZ2UmcXVvdDsgcHJv cGVydHkgb2YgUkZDNjc5MCBpcyBwcmVzZXJ2ZWQuIE9ubHkgdGhlIExTUnMgdGhhdCBhcmUgdGVy bWluYXRpbmcgdHVubmVsLXNlZ21lbnRzIG5lZWQgdGhlIG5ldyBjYXBhYmlsaXR5LjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPltTTEldIFJpZ2h0LCBidXQgaW4gYSBTUFJJTkcgZG9tYWluLCBhbnkg bm9kZSB3aWxsIHJlcXVpcmUgdGhpcywgZXNwZWNpYWxseSB3aGVuIFRyYWZmaWMgZW5naW5lZXJp bmcgdXNlIGNhc2UgaXMgdXNlZCBhbmQgY29tYmluYXRpb24gb2Ygbm9kZS9hZGogc2VnbWVudCBt YXkgdXNlIGFueSBub2RlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtJz48ZGl2PjxkaXY+PHA+PHNwYW4gbGFuZz1FTi1VUz4tPC9zcGFuPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBsYW5nPUVO LVVTPnRvcCBsZXZlbCBFTCA6IHByb2Nlc3MgdG9wIGxldmVsIEVMSSwgRUxJIGlzIHJlY29nbml6 ZWQsIEVMSS9FTCBpcyByZW1vdmVkLCBmb3J3YXJkaW5nIGlzIGRvbmUgb24gZm9yd2FyZGluZyBs YWJlbCwgRUxJL0VMIGlzIHB1c2hlZCBiYWNrIGluIG5leHRob3AgaXMgYWJsZSB0byBwcm9jZXNz IEVMLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIGJpZ2dlc3QgZHJhd2JhY2sgaXMgdGhhdCBldmVyeSBMU1Ig YWxvbmcgZXZlcnkgdHVubmVsLXNlZ21lbnQgc2hvdWxkIG5vdyBoYXZlIHRoZSBuZXcgYmVoYXZp b3Igb2YgcHVzaGluZyB0aGUgcmVjZWl2ZWQgRUxJL0VMIGFmdGVyIHRoZSBmb3J3YXJkaW5nIGxh YmVsIHN3YXAuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5bU0xJXSBOb3QgYSBiaWcgZGVhbCAsIGFzIHRoZSBub2RlIHdvdWxkIHJl cXVpcmUgdG8gYmUgdXBncmFkZWQgdG8gc3VwcG9ydCBzdGFja2VkIHR1bm5lbCBhbHNvIGFuZCBh bGwgbm9kZXMgaW4gdGhlIFNQUklORyBkb21haW4gd2lsbCByZXF1aXJlIGEgc29mdHdhcmUgdXBn cmFkZSDigKYgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVM+SW4gdGVybSBv ZiBvcGVyYXRpb25zLCBJIHRoaW5rIHRoYXQgdG9wIGxldmVsIEVMIG1heSBiZSBzaW1wbGVyICwg YnV0IGFzIEnigJltIG5vdCBoYXJkd2FyZSBjb2RlciwgbWF5IGJlIEnigJltIHdyb25nIOKApiBt b3Jlb3ZlciBpdCBtYXkgYmUgc2ltaWxhciB0byBNUExTIFJvdXRlciBhbGVydCBwcm9jZXNzaW5n Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+SXQgaXMgZGlmZmVyZW50IGZyb20gUm91dGVyLWFsZXJ0IHByb2Nlc3NpbmcuIEhl cmUgZXZlcnl0aGluZyBpcyBpbiB0aGUgZmFzdC1wYXRoIGFuZCBwcm9jZXNzaW5nIGhhcyB0byBi ZSBhdCBsaW5lLXJhdGUuIEluIGNhc2Ugb2YgUm91dGVyLWFsZXJ0IGl0IHdhcyBoYW5kb2ZmIHRv IGEgc29mdHdhcmUgbW9kdWxlIGZvciBzbG93ZXItcGF0aCBwcm9jZXNzaW5nLjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bU0xJXSBJIGhvcGUgdGhhbiBwb3AgJmFtcDsg cHVzaCBvZiByb3V0ZXIgYWxlcnQgaXMgaGFuZGxlZCBpbiBIVywganVzdCBwYWNrZXQgaW5zcGVj dGlvbiBpcyBkb25lIGluIHNvZnR3YXJlIChidXQgbWF5YmUgaW1wbGVtZW50YXRpb24gZGVwZW5k ZW50KS4gV2UgY291bGQga2VlcCBmYXN0IHBhdGggaGVyZSwgYXMgd2UgZG9u4oCZdCBuZWVkIHBh Y2tldCBpbnNwZWN0aW9uLCBqdXN0IHBvcCwgcHVzaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVM+WW91 ciB0aG91Z2h0cyA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90 ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+SSB0aGluayB0b3AtbGV2ZWwgRUwgaXMgaGFyZGVyIHRvIGRlcGxveSBhbmQgbGVzcyBpbi1s aW5lIHdpdGggUkZDNjc5MC4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+W1NMSV0gTm90IHN1cmUgaXQgbWF5IGJlIGhhcmRlciB0byBkZXBsb3ksIGJ1dCBhZ3Jl ZSB0aGF0IGl04oCZcyBub3QgaW5saW5lIHdpdGggUkM2NzkwLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJ1 dCBhbnl3YXksIEnigJltIG5vdCBwdXNoaW5nIGFueSBzb2x1dGlvbiBub3csIGRpc2N1c3Npb25z IGFyZSBuZWVkZWQgdG8gZ2F0aGVyIG9waW5pb25zL2NvbnN0cmFpbnRzIG9mIG90aGVyIHBlb3Bs ZSB0byBkZWZpbmUgdGhlIGJlc3Qgb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFyZSB5b3UgcGxhbm5p bmcgYSBzZXNzaW9uIG9uIHRoaXMgdG9waWMgaW4gTG9uZG9uID88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U3JpPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtJz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1F Ti1VUz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gbGFuZz1FTi1VUz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gbGFuZz1FTi1VUz5TdGVwaGFuZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48cHJlPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+ PC9wcmU+PHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+PHByZT5hIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9w cmU+PHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9wcmU+PHByZT50 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3ByZT48cHJlPkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwv cHJlPjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPm1wbHMgbWFpbGluZyBsaXN0PGJyPjxhIGhy ZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PG86cD48L286 cD48L3A+PC9ibG9ja3F1b3RlPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48 L2JvZHk+PC9odG1sPg== --_000_EEE55384044474429A926C625D0FCC810C32CFB573PUEXCB2Fnante_-- From lizho.jin@gmail.com Wed Feb 12 07:46: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 6616A1A0412 for ; Wed, 12 Feb 2014 07:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocdE-t_d4eOc for ; Wed, 12 Feb 2014 07:46:16 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 665FC1A0928 for ; Wed, 12 Feb 2014 07:46:16 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp16so9404749pbb.34 for ; Wed, 12 Feb 2014 07:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=xcEzBdUbvnLZqf4jJeoGXL9afE8funrKKVsa16y930s=; b=mLCI2Pu1ChnThOo0KS5kUOQ/RJav48yeAPaoQGTJxtxZMEk4BoZsYilCLyXYA9+MNf el7hApjA1xIr04EtWycRRxHcSWSz9VzVVNUvrgL3YNpkuxjPB65+7tc2hZajWgA2ygTK RNTDlzmqldTIMWVEqvHdavLvBZ6GncW19ccev933MSb1xrJkRVIBu4lrqbMdcoKbO6rI Gkcf8hEsJfPLx0SwIlpvw2LBIQ5nZibXKY4dbROKeTVnlCU5wMoN94AvJX8d8VfSBCVM MFwrcjoWYBMc9hgjMqmI756rcvbYSnD8A0IyHsPXN7ubXCSf3Pkx5duj7kv/s64MjWYB O/gQ== X-Received: by 10.68.136.162 with SMTP id qb2mr52695597pbb.88.1392219975643; Wed, 12 Feb 2014 07:46:15 -0800 (PST) Received: from LizhongPC ([114.62.204.44]) by mx.google.com with ESMTPSA id ac7sm75514219pad.12.2014.02.12.07.46.12 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Feb 2014 07:46:15 -0800 (PST) From: "Lizhong Jin" To: "'Loa Andersson'" References: In-Reply-To: Date: Wed, 12 Feb 2014 23:46:07 +0800 Message-ID: <52fb9747.c7fd420a.0d5f.ffffeb80@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8iO57RyXUOPVrtQcWxqoE3JPzE1gFzXHaw Content-Language: zh-cn Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 15:46:18 -0000 Hi, all Yes, support. Lizhong > ------------------------------ > > Date: Wed, 05 Feb 2014 14:29:00 +0800 > From: Loa Andersson > To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" > , "VIGOUREUX, MARTIN (MARTIN)" > , > "draft-wijnands-mpls-mldp-in-band-wildcard- > encoding@tools.ietf.org" > encoding@tools.ietf.org> > Subject: [mpls] wg adoption poll on > draft-wijnands-mpls-mldp-in-band-wildcard-encoding > Message-ID: <52F1DA2C.2070007@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working Group, > > This is to start a two week poll on adopting > draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > Please note that we have identified an overlap between this document > and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this > document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp > to cover this. > > There are no IPR claims against this document. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends February 19, 2014. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > ------------------------------ > From ningso@yahoo.com Wed Feb 12 09:20: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 C70A71A08B8 for ; Wed, 12 Feb 2014 09:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTpd0W9eB6eo for ; Wed, 12 Feb 2014 09:20:37 -0800 (PST) Received: from nm12-vm6.bullet.mail.ne1.yahoo.com (nm12-vm6.bullet.mail.ne1.yahoo.com [98.138.91.105]) by ietfa.amsl.com (Postfix) with ESMTP id C5AE21A09A3 for ; Wed, 12 Feb 2014 09:20:25 -0800 (PST) Received: from [98.138.226.177] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 17:20:24 -0000 Received: from [98.138.87.8] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 17:20:24 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 17:20:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 702034.44861.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 96059 invoked by uid 60001); 12 Feb 2014 17:20:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392225624; bh=1F4aLSJXhJs++nG2m1T5DXvbsqYj0PpX4aTV2b+MPZA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=KDHexDVfHTiO/e+iUsEi+QQLvqeh79XHfou7NqsQADs+Yx5FDZNU34y6eh7PswaLTK4C1fqbUdOHK3WlqVXUEw4MXs03d8D/mVD6LLheITaHknJdasIbnQIwL9njPrMLHOGuBIUESMU0Hdm3WpiMkuXS1LxyPBRdAveGoWj+TpI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=mW60zqY/ODcbTeaSHTAzJYoMaRaLy6Fl0vhzdrrvJ52arSoXxP8+KQi74vB8mIdsUCKFFmhi4FzBC39wARqpWMEU7nbOYWGxmdQ1vEEp0YA+tn3q5NStZQNwCduAEMe6CTv11V+OeCArUcW/FreEiQQHBnFdS6PlhN3Q+75eF60=; X-YMail-OSG: Vc7Y1RgVM1nGZqpz5YX03gLzUdxCNkItk06mMZ7iZX2Bbpx ifd8dGw8BLtY8qsRIqd1Fy4smTPxoTa1pZwGJy63y4DV5qhx9WBkVuybkx8N D2LAqWi10h4NzisgKGmcpmmRfzJ9X_Gx_z4yNV9FJ8laUEDKYT2phLDfV8ib PlDzj.uBS8H1gVvAwzU3FWQ4vxclOfWOX9L769CBFHeM5QrFFJ8pCr7m87Hp roWSfg2fwyiE5KIS68eHR_mQ7sCi3cvclqJAE9YR43eUd._0dvUrC1Ol7l65 b_GttQ3N4Jdzodtlho6.qmIaTYvl4Uyfgnsj3qJ.g9rL3uKS6aDh..fsEjjB aDDl4C6v1EslQc8QmtHPwjNhnSCS1PipdvGGdEnt7yi7iUGWEomLzzGaicc1 O48aNP.Teex0n54KNdM7KIIImXH2ZHahdXaTAvyuhjy0gBLaR7_.udLU3__p OUVBO9xMaWEEwsUwVHI2vezSihucu1xsDD14NvmAeKvw4UCe4ZZc49CQn6k2 8t96.VOVqV62oJ0zeIPHSIkwO.lXpW_Jl0NzM7t98QrdPd5t2MMEUwKk4SlX grzXfny.sVA-- Received: from [71.170.227.188] by web121002.mail.ne1.yahoo.com via HTTP; Wed, 12 Feb 2014 09:20:24 PST X-Rocket-MIMEInfo: 002.001, U3VwcG9ydC4KCk5pbmcgU28KOTcyLTk1NS0wOTE0CgotLS0tLT8_Pz8tLS0tLQo_Pz86IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddID8_IExvYSBBbmRlcnNzb24KPz8_PzogMjAxND8yPzg_IDE3OjE0Cj8_PzogbXBsc0BpZXRmLm9yZwo_PzogbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LXJla2h0ZXItbXBscy1waW0tc20tb3Zlci1tbGRwQHRvb2xzLmlldGYub3JnCj8_OiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQtcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.176.634 References: Message-ID: <1392225624.93747.YahooMailNeo@web121002.mail.ne1.yahoo.com> Date: Wed, 12 Feb 2014 09:20:24 -0800 (PST) From: ningso@yahoo.com To: "mpls@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-599881721-634253128-1392225624=:93747" Subject: Re: [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm-over-mldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ningso@yahoo.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:20:40 -0000 ---599881721-634253128-1392225624=:93747 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Support.=0A=0ANing So=0A972-955-0914=0A=0A-----????-----=0A???: mpls [mailt= o:mpls-bounces@ietf.org] ?? Loa Andersson=0A????: 2014?2?8? 17:14=0A???: mp= ls@ietf.org=0A??: mpls-chairs@tools.ietf.org; draft-rekhter-mpls-pim-sm-ove= r-mldp@tools.ietf.org=0A??: [mpls] poll to see if we have consensus to adop= t draft-rekhter-mpls-pim-sm-over-mldp =0Aas a working group document=0A=0A= =0AWorking Group,=0A=0AThis is to start a two week poll on adopting draft-r= ekhter-mpls-pim-sm-over-mld =0Aas an MPLS working group document.=0A=0APlea= se send your comments (support/not support) to the mpls working group =0Ama= iling list (mpls@ietf.org). Please give a technical motivation for your =0A= support/not support, especially if you think that the document should not b= e =0Aadopted as a working group document.=0A=0APlease note that we have ide= ntified an overlap between this document and =0Adraft-wijnands-mpls-mldp-in= -band-wildcard-encoding. This document includes text =0Ato cover this.=0A= =0AThere are 1 IPR claim against this document.=0A=0AThe authors has stated= on the working group mailing list that they are not aware =0Aof any other = IPR claims against this draft.=0A=0AHowever if you are on the the mpls work= ing group mailing list and aware of IPR =0Athat relates to this draft, the = time to disclose this is now.=0A=0AThis poll ends February 22, 2014.=0A=0A/= Loa=0A(mpls wg co-chair)=0A-- =0A=0A=0ALoa Andersson=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 email: loa@mail01.huawei.com=0ASenior MPLS Expert= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 loa@pi.nu=0AHuawei Tech= nologies (consultant)=A0 =A0 phone: +46 739 81 21 64begin_of_the_skype_hig= hlighting=A0+46 739 81 21 64=A0FREE=A0=A0end_of_the_skype_highlighting=0A__= _____________________________________________=0Ampls mailing list=0Ampls@ie= tf.org=0Ahttps://www.ietf.org/mailman/listinfo/mpls=0A_____________________= __________________________=0Ampls mailing list=0Ampls@ietf.org=0Ahttps://ww= w.ietf.org/mailman/listinfo/mpls ---599881721-634253128-1392225624=:93747 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Support.

Ning So
972-955-0914
=
-----????-----
???: mpls [mailto:mpls-bounces@ietf.org] ?? Loa Andersson
????: 2014?2?8= ? 17:14
???: mpls@ietf.org
??: mpls-chairs@tools.ietf.org; draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org
??:= [mpls] poll to see if we have consensus to adopt draft-rekhter-mpls-pim-sm= -over-mldp
as a working group document


Working Group,

This is to start a= two week poll on adopting draft-rekhter-mpls-pim-sm-over-mld
as an MPL= S working group document.

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

Please note that we have identified= an overlap between this document and
draft-wijnands-mpls-mldp-in-band-= wildcard-encoding. This document includes text
to cover this.

Th= ere are 1 IPR claim against this document.

The authors has stated on= the working group mailing list that they are not aware
of any other IP= R claims against this draft.

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

This poll ends February 22, 2014= .

/Loa
(mpls wg co-chair)
--


Loa Andersson  &= nbsp;                    = email: loa@mail01.huawei.com
= Senior MPLS Expert                &= nbsp;         loa@pi.nu
Huawei Tec= hnologies (consultant)    phone: +46 739 81 21 64 begin_of_the_skyp= e_highlighting +46 739 81 21 64 FR= EE  end_of_the_skype= _highlighting
_____________________________________= __________
mpls mailing list
mpls@ietf.org<= br>https://www.ietf.org/mailman/listinfo/mpls_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.= ietf.org/mailman/listinfo/mpls


---599881721-634253128-1392225624=:93747-- From internet-drafts@ietf.org Wed Feb 12 09:46: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 5DA2A1A0676; Wed, 12 Feb 2014 09:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHlojVVA2-_A; Wed, 12 Feb 2014 09:46:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BA61A0659; Wed, 12 Feb 2014 09:46:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212174628.8923.57822.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 09:46:28 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-forwarding-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: Wed, 12 Feb 2014 17:46:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Forwarding Compliance and Performance Requirements Authors : Curtis Villamizar Kireeti Kompella Shane Amante Andrew Malis Carlos Pignataro Filename : draft-ietf-mpls-forwarding-07.txt Pages : 57 Date : 2014-02-12 Abstract: This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-forwarding/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-forwarding-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-forwarding-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 internet-drafts@ietf.org Wed Feb 12 10:32: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 30AD81A0678; Wed, 12 Feb 2014 10:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMKvHIFGBPx1; Wed, 12 Feb 2014 10:32:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E5C1A0602; Wed, 12 Feb 2014 10:32:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212183237.5211.32254.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 10:32:37 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-forwarding-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, 12 Feb 2014 18:32:42 -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 Forwarding Compliance and Performance Requirements Authors : Curtis Villamizar Kireeti Kompella Shane Amante Andrew Malis Carlos Pignataro Filename : draft-ietf-mpls-forwarding-08.txt Pages : 57 Date : 2014-02-12 Abstract: This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-forwarding/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-forwarding-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-forwarding-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 mkonstan@cisco.com Wed Feb 12 11:07: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 72B651A0678 for ; Wed, 12 Feb 2014 11:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.449 X-Spam-Level: X-Spam-Status: No, score=-14.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 rRu6MR6kauPG for ; Wed, 12 Feb 2014 11:07:04 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C1AFC1A0548 for ; Wed, 12 Feb 2014 11:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26653; q=dns/txt; s=iport; t=1392232023; x=1393441623; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:content-id:content-transfer-encoding: mime-version; bh=b/pDto3+0RSCkqBBsuIQq5G3KnyPvo5wVV0WroWyM0g=; b=OAwInb+jmFGkRMBFxZWzCrhXjBtrqgkdq7zeLts2PA3tJUy9pfOl5Ja0 c6/uB81PuZZWBkoJRFlT/Yw/h44PhUcyLADMh66QDZ+bstr8j4W3yilYf 25Zj8b6Cfqiy5+00PBBfb2lrHKNwW2LmAVfE2Ss06dpjFYhKNWlo69op4 k=; X-IronPort-AV: E=Sophos;i="4.95,833,1384300800"; d="scan'208";a="303632251" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 12 Feb 2014 19:07:03 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1CJ724a023490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 19:07:02 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.65]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 13:07:02 -0600 From: "Maciek Konstantynowicz (mkonstan)" To: Curtis Villamizar Thread-Topic: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls Thread-Index: AQHPGJCK96FhvLwL/kSFCUm8kANVwZqyfqaA Date: Wed, 12 Feb 2014 19:07:01 +0000 Message-ID: References: <201401232312.s0NNC08b010650@maildrop2.v6ds.occnc.com> In-Reply-To: <201401232312.s0NNC08b010650@maildrop2.v6ds.occnc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.101.174] Content-Type: text/plain; charset="us-ascii" Content-ID: <987AC3BE281CC84DAF423D91C69E64D4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-seamless-mpls.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "maciek@cisco.com" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 19:07:08 -0000 Curtis, Many thanks for thorough review and all your comments. Pls see in line. On 23 Jan 2014, at 23:12, Curtis Villamizar wrote: >=20 > In message > "Maciek Konstantynowicz (mkonstan)" writes: >=20 >> Curtis, >>=20 >> Pls see our comments inline, and let us know your thoughts. >> We have also posted updated ID. >=20 > There was very little change between the 04 version and the 05 > version. >=20 >> On 15 Oct 2013, at 18:09, Curtis Villamizar wrote: >>=20 >>>=20 >>> Loa, >>>=20 >>> No details are given in IPR #686 (applicable to RFC 5283) for the >>> "Reasonable and Non-Discriminatory License to All Implementers with >>> Possible Royalty/Fee." At the very least, some terms should be given. >>=20 >> Update from Bruno in addition to the email he sent on >> Date: 16 October 2013 08:43:46 GMT+01:00 >>=20 >> <...> >> Tried for more than 6 months, to have my IPR team to update the IPR 853 >> to make it clear that it _replaces/supersede _ 686. >> But they are not moving. It's all the more incredible that they have >> dropped the patent. So no, it's not even "No licence Required" it's even >> no IPR at all... >>=20 >> That being said, the above IPR was on RFC 5283, not on seamless MPLS >> draft. I had a discussion with Loa & Adrian on this, and there opinion >> is that no IPR declaration would be required for draft seamless mpls. So >> there is no real problem in the first place. >> <...> >>=20 >>>=20 >>> IPR #1920 and #2212 do provide details. >>>=20 >>> An alternate to the use of a prefix based LDP LSP is to use a prefix >>> based RSVP-TE LSP and carry the individual end-to-end LSP within it. >>> This is not mentioned in the draft. See below for details. >>=20 >> The use cases, proposed design and protocol choices have been driven by >> the actual SP deployments. >>=20 >> Design based on the hierarchy of RSVP-TE LSPs may address the listed use >> cases. However the labeled BGP design with LDP DoD has been chosen due >> to the higher degree of out-of-the-box automation and operational >> simplicity as well as compatibility with the existing backbone and >> backhaul designs & deployments which use LDP and not RSVP-TE. >>=20 >> It also assumes relatively simple MPLS implementations on access nodes - >> RFC 7032 goes into much more detail there. >=20 > Could you please simply mention that RSVP-TE might be an alternative > and then state the assumptions above in the document as reasons for > using this approach. Yes. Following text has been added in Section 4.4: Note that this document describes the design based on LDP, LDP Downstream-on-Demand and labeled BGP due to the higher degree of out-of-the-box automation and operational simplicity as well as compatibility with the existing backbone and backhaul designs & deployments which use LDP and not RSVP-TE. It also assumes relatively simple MPLS implementations on access nodes. The protocol choices for the design described in this document have been driven by the actual SP deployments. Design based on the hierarchy of RSVP-TE LSPs may be alternative but has not been considered in this document.=20 >=20 >=20 >>> Scaling numbers are given as: >>>=20 >>> Number of Aggregation Domains: 100 >>> Number of Backbone Nodes: 1.000 >>> Number of Aggregation Nodes: 10.000 >>> Number of Access Nodes: 100.000 >>>=20 >>> This section should state that very sparse connectivity among the set >>> of access nodes is expected. For exampls, you would not expect each >>> access node to have an LSP to every other access node. Is so, more >>> than 10 such access nodes aggregated prior to a prefix based LSP would >>> exceed the limits of the MPLS 20 bit label space. >>=20 >> The requirement was to cater for service connectivity over transport >> LSPs per scaling numbers provided for listed deployment use cases. The >> required design was not to restrict the LSP based connectivity between >> the access, aggregation and backbone nodes, catering equally well for >> sparse and dense connectivity, but not the full-mesh. Full-mesh >> connectivity between between all ANs will require each AN maintaining >> LSP that they initiate and terminate, complicating the AN >> implementation.=20 >> Luckily this is not the case in the listed use cases and the actual >> access deployments. >>=20 >> The result is the seamless MPLS design specified in this draft. And it >> does work for dense transport LSP connectivity between the access nodes >> without exhausting the MPLS 20-bit label space on any of the nodes by >> relying on LSP hierarchy provided by labeled BGP for inter-domain >> connectivity. >>=20 >> See section 5.2 for scalability analysis, and numerical examples for >> access node connectivity in section 5.2.1.5. >>=20 >>>=20 >>> On the other hand it would not be unreasonable to expect each of the >>> 10,000 aggregation nodes to be fully meshed or at least very densely >>> meshed. This can also create problems without some form of >>> aggregation as a worst case graph cut set with 5000 nodes on each side >>> would have 25,000,000 LSP. A cutset of 2-5 nodes (typical core) could >>> not support this (exceeds the 20 bit label space) without aggregation. >>=20 >> We read your comment "without some form of aggregation" as meaning >> "without some form of hierarchy". >> If so, indeed this is why specified design used LSP hierarchy per >> earlier comment. >=20 > OK. I reread parts of your draft and I understand how you are using > recursive LDP LFIB lookup to create a hierarchical label stack at the > ABR. Great. Thx. >=20 >>> Some indication of how dense or sparse the connectivity would be >>> useful in this section (2.1. Why Seamless MPLS). =20 >>=20 >> Indicative access node level connectivity has been described in section >> 5.2 Scalability Analysis, but we agree that it makes sense to give an >> indication in section 2.1 >=20 > Access node connectivity is not mentioned in 5.2 as far as I can tell. > What you do have in "5.2.1.4. Summary" is mention that "The main > limitation is the MPLS connectivity requirements on the AN, > i.e. mainly the number of LSP needed on the AN." At no point in this > section is there mention that this limit is less than #AN because in > the typical deployment there is a sparse mesh of connectivity among > access nodes. >=20 Just to clarify - I meant following text in 5.2, or more specifically in 5.= 2.1.1: o Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC which are outside of their routing domain. Those 100 remote FEC are the same for all Access Nodes of a given AGN. 1,000 LSPs per AN includes AN to AN LSPs, so it is captured. The numbers came from the EU operators, and AFAICT reflect their current an= d target access deployment models - both copper and fiber. And you're right, the sparse connectivity between ANs is indeed not there. Thanks for spotting, added following text for clarity: AN requirements are kept to a minimum. BGP is not required on ANs and the size of their FIB is driven only by their own connectivity requirements. In the FIB scale analysis described in sections 5.2.1.x, it was assumed that any single AN will need no more than 1,000 LSPs. This assumption is based on the expected AN access line capacity and LSPs required for connectivity to PE routers providing edge services as well as a sparse mesh of connectivity between ANs. > You would really solve this if in "5.2.1.1. Introduction" you added a > variable which is the number of access nodes that any one access node > is connected to. Perhaps call it #AMD for access mesh density and > explain what it is. You have a magical 1k and 100 under assumptions > that comes out of thin air. You can replace it with #AMD (or whatever > name you pick). Then when you do the worked examples in > "5.2.1.5. Numerical application for use case #1" and > "5.2.1.6. Numerical application for use case #2" you can include > values for #AMD. I do think that right now the 1k and 100 numbers are > reasonable values but I think in the future these may increase. >=20 > The reason that the 1k number looks to be out of thin air is because > sections 2.2.2 and 2.3.2 contain nothing but a table and no > explanation and there is desription of the assumption or connection to > the 1k number later on in section 5.2. See below on 2.2.2 and 2.3.2. >=20 Here I disagree. Adding a variable for #LSPs between ANs does not bring muc= h value here IMV. We already capture the total number of LSPs per AN as a constant 1,000 LSPs= . I have edited the following text in sec. 5.2.1.1 for improved clarity: Each Access Node needs to have up to 1,000 (1k) LSPs. This is driven by the expected AN access line capacity, and a sum of LSPs required for connectivity to PE routers providing edge services as well as a remote ANs. 100 LSPs per AN (10% of total) are FECs which are outside of their routing domain. Those 100 remote FEC are the same for all Access Nodes of a given AGN. > [OT and IMO - the access node connectivity due to legacy circuits is > expected to continue to drop even though actual TDM infrastructure is > disappearing and being replaced with IP and PW for remaining TDM, FR, > and ATM. OTOH - l3vpn connectivity is growing. Many potential l3vpn > customers know they can use plain old Internet and tunnel traffic > themselves and encrypt it. The value to them of l3vpn is mostly > preferred treatment of traffic. As cost of l3vpn service drops, that > value will out weigh the cost of the service until penetration > increases (in which case cost may drop more).] >=20 > btw- Are case #1 and case #2 the numbers that specific customers asked > you to use? A simple "yes/no" question - no need to name them. The numbers came from operators co-authoring the draft. >=20 >> Following text added in section 2.1: >>=20 >> Multiple Service Providers plan to deploy networks with 10k to 100k MPLS >> nodes, with varying levels of MPLS LSP connectivity between those nodes >> - sparse-mesh in access, partial-mesh in aggregation and full-mesh in >> core. This is typically at least one order of magnitude higher than >> typical deployments and may require a new architecture. >=20 > OK. Great. Thx. >=20 >>> It may be worth >>> creating a new subsection (2.2 Scaling Goals) and going into a little >>> more detail. >>=20 >> We believe this comment is addressed by above addition in section 2.1 >> and section 5.2. Scalability Analysis. Let us know if this does address >> your comment. >=20 > Please consider the comments I've made above. >=20 > I'm also not sure what "IGP Control Plane =3D 2" and "IP FIB =3D 2" mean > in table 1 and table 2. You also have "LDP Control Plane =3D 200" (or > 1000) and "LDP FIB =3D 200" (or 1000). It is not clear to me what it > means for an access node to have 200 control planes. If the access > node has only default routes I can see where "IP FIB =3D 2" would come > about but that assumption is not stated. It is unclear what "IGP > Control Plane =3D 2" means. Please explain in the document. You're right "IGP Control Plane =3D 2" is indeed confusing language. It should say RIB/FIB and LIB/LFIB Entries instead respectively, corrected. >=20 > It is also more common AFAIK to state how many VFRs the access node > needs and also how many routes per VRF on average. Since the access > nodes have a high fanout to CPE nodes, the number of IP fib entries > would be the two conditional default routes plus at least one route > per CPE attachment, plus VRF routes which should be counted > separately. If it is assumed that the aggregation nodes hold the VRF, > that should be stated. >=20 > If you are just counting core facing IP routes, then say so in the > document. >=20 > BTW- the correct MPLS term is ILM. IFIB is a vendor term and so far > does not appear in any RFCs. s/IFIB/ILM/g please. FIB is a commonly used term to denote the data plane that's in most cases i= s implemented in HW. And the document must distinguish between the ctrl pla= ne and data plane, as the latter is usually the limiting factor, hence RIB/= LIB and FIB/LFIB terms are used. I don't think me or other authors are married to these terms, so if you thi= nk they are not IETF terminology compliant, pls propose alternatives for: RIB for IP routing table (ctrl plane state) FIB for IP forwarding table (data plane state) LIB for label table (ctrl plane state) LFIB for label forwarding table (data plane state) >=20 >>> Then there is the question as to whether this draft should even go >>> forward at all. >>=20 >> Can you pls be more specific why you don't see this draft proceeding ? >>=20 >> There are production implementation by both vendors and providers of >> Seamless MPLS design as specified in this draft. >=20 > Now that I see how you are doing the core hierarchy I see how this > works. Great. Thx. >=20 >>> It is worth noting that a full mesh of 10.000 RSVP-TE LSP is feasible >>> using hierarch. Within the core of 100 nodes, PSC-4 can be used. >>> Each of the 1,000 backbone nodes can create a PSC-3 LSP to each other >>> backbone node (using above terminology, "edge" nodes in more common >>> core-edge-access or core-edge-aggregation-access terminology). If on >>> average there are 10 backbone nodes per core node pair, then each core >>> node has on the order of 10,000 ILM entries (about 20,000 if you >>> consider 50 pairs of core nodes, each serving 20 nodes). There are >>> only 100 LSP from each core node facing the core side, so FRR can be >>> very effectively deployed. The same holds for a full mesh of the >>> 10.000 aggregation nodes. If each of the 1,000 backbone nodes are >>> deployed in pairs serving on average 20 nodes per pair, then an ILM >>> siz on the order of 200,000 is needed. The PSC-3 LSP used to reach >>> the far side backbone node can be used, yielding only 1,000 LSP facing >>> the core per backbone node. Again, FRR can be used, with the protect >>> path using the alternate core node of the designated pair. >>>=20 >>> In this scenarion the access nodes may or may not be full meshed. If >>> they are full meshed, then they need to be able to support 100,000 DoD >>> mode LSP. If the are more sparsely meshed, they can support a lower >>> number of DoD mode LSP. >>=20 >> We do not disagree that alternative design approach based on RFC 4206 >> and related h-LSP RFCs may be applied to address the LSP connectivity in >> this environment. >>=20 >> However we believe the design specified in the Seamless MPLS draft >> better meets described requirements including better deployment >> flexibility, better scaling and easier troubleshooting. >=20 > As I said before, the draft would be greatly improved if you mentioned > that you have considered this alternative and why you took the > approach that you took. Ack. Added text per first comment. >=20 >>> If RSVP-TE is used in this way, there is no need for aggregating LDP >>> LSP. The LDP LSP are aggregated into RSVP-TE LSP and further >>> aggregated in PSC-3 LSP and PSC-4 LSP in tiers closer to the core. >>=20 >> The draft does not propose aggregating LDP LSPs. In fact the design >> enables the operator to choose the transport LSP signalling protocol, >> LDP or RSVP-TE, per domain, per section 4.4. Intra-Domain Routing. >=20 > OK. I missed that mention of RSVP. We may have been arguing for > similar solutions but your solution adding the recursive LDP route > lookup when only a prefix route is present and resulting in a label > stack. >=20 > This is a very key aspect of your proposal and it is not well > highlighted in section 4.5 where there is only the one word mention of > hierarchy. Perhaps you could add a forward reference from that point > such as a sentence saying "The mechanism for this hierarchy is defined > in Section 5.1.3" and then change the title of 5.1.3 from hierarchy to > "Hierarchy based on recursive LDP route lookup". This is AFAIK the first > RFC mention of this technique and it is quite well buried. Also in > this section please mention that router "I" could be an RSVP LSP or > LDP LSP that reaches a prefix at the other ABR. Thanks for the suggestion. Applied following changes: added to 4.5: The mechanism for the LSP forwarding hierarchy is defined in Section 5.3. Changed the section 5.1.3 title to:=20 Hierarchy based on recursive BGP labeled route lookup Re-reading section 5.1.3, we actually do need to add more comprehensive des= cription of how the LSP hierarchy is realised. Here is a proposed updated t= ext: Inline with the explanation in section 4.5, LSP hierarchy is key to a scalable seamless MPLS architecture.=20 The LSP hierarchy in this design is achieved by: - forming separate MPLS domains for aggregation and core areas - intra-domain LSP connectivity provided by combination of IS-IS (as the intra-domain link-state routing protocol) and LDP (used for MPLS label distribution for intra-domain LSPs) - inter-domain LSP connectivity provided by labeled BGP [RFC3107] (used for MPLS label distribution for inter-domain LSP FECs) and relying on IS-IS and LDP for intra-domain LSP connectivity between the LSR labeled BGP speakers (AGNs and ABRs). Note that the MPLS core notes are not carrying the labeled BGP routes. The aggregation and core MPLS domains are mapped to IS-IS areas as follows: Aggregation domains are mapped to IS-IS L1 areas. The core is configured as IS-IS L2. The border routers connecting aggregation and core are IS-IS L1L2 and are referred to as ABRs. From a technical and operational point of view these ABRs are part of the core, although they also belong to the respective aggregation domain purely from a routing protocol point of view. =20 >=20 >>> There are ultimate scaling limits to either approach, imposed by the >>> 20 bit label space. If a full mesh is needed at a given tier T with N >>> nodes, then the nodes in tier T-1 aggregating tier T needs an ILM size >>> of N times the number of T nodes the T-1 node serves. So for example, >>> with a full mesh of 100,000 tier T nodes if each tier T-1 node could >>> aggregate 8 tier T nodes without exceeding the 20 bit label space size >>> (ILM=3D800,000 in this case), but could not aggregate 20 tier T nodes >>> (ILM=3D2,000,000). If using RSVP-TE in the core, the core is limited b= y >>> the worst case cut set, but core sizes of on the order of hundreds are >>> OK (but smaller is better). >>=20 >> In line with your comments the scaling limits are imposed not only by >> MPLS 20-bit label space, but also by the number of supported LFIB >> entries on specific MPLS node. >>=20 >> Design in this draft relies on labeled BGP control plane to scale the >> MPLS label distribution and to optimize the MPLS data plane on ABR nodes >> by installing only the local labelled routes in its LFIB, as described >> in section 5.1.7. >=20 > Now that I see your LDP based hierarchy works I see how the scaling > works out. Great. Thx. >=20 >>> Using either RSVP-TE or LDP for aggregation the outermost T-max tier >>> could have a million nodes or more as long as they were sufficiently >>> sparsely connected. This limit is independent of whether aggregation >>> is via LDP or RSVP-TE. >>=20 >> Similarly, the scale of the design in this draft is restricted by the >> scale of AN at the outskirts of the MPLS network and their connectivity >> needs driving the scale of neighbouring AGNs. >=20 > We are in agreement. Your text was simply not clear to me. I'm not > usually known to be more clueless than the average reader (maybe > depends on who you ask, but OT) so it seems that some improvements in > document clarity wouldn't hurt. >=20 > I suspect that few people actually thoroughly read your document and > thought about where your numbers came from and that may have more to > do with lack of anyone else questioning your numbers (or maybe I *am* > just really dense - I hope not). Added following text in sec 3.4: The network must be highly scalable. Based on the use cases described in Se= ctions 2.2 and 2.3, as a minimum requirement the following scalability figu= res should be met: Combination of this add plus the other changes stimulated by your feedback = hopefully improve clarity now. >=20 >>> With RSVP-TE used for aggregation, T-LDP is used among the sparse mesh >>> in the outermost T-max tier. A T-LDP session is only needed if FEC >>> information needs to be exchanged via LDP to support an underlying >>> service, otherwise RSVP-TE alone could be used. Using T-LDP the >>> number of T-LDP TCP sessions could be a limiting factor for very >>> highly connected tier T-max nodes. Either TCB state or the 16 bit TCP >>> port limit could be the limit depending on how much RAM the T-max node >>> has. OTOH if a tier T-max node out on the fringes is supporting on >>> the order of 50K T-LDP sessions, it can use multiple IP addresses to >>> get around the 16 bit TCP port number issue. >>=20 >> In the draft, labeled BGP is used for labeled routes, providing excellen= t >> scaling properties in the control plane. >=20 > Yes. I agree. It was not clear to me at first how your hierarchy was > working in the core with the labeled BGP routes exchanged but not > installed in the core. >=20 > At some point in the document you should mention that the labeled BGP > routes are not installed in the core. I searched the document for the > word BGP (the word BGP is in a lot of places) and there does not seem > to be any mention that the BGP labeled routes are installed at the ABR > and carried across the core but are not installed in the core. Ack. Already captured in added text in 5.1.3. >=20 > Again, this is a key aspect of the proposal and it has gone unstated. >=20 >>> LDP could be extended to avoid the need for T-LDP sessions using LDP >>> distribution of labels that will make use of RSVP-TE LSP. A DoD >>> request would normally create a series of label bindings and swaps. >>> If a full mesh of RSVP-TE LSP is know to exist within a prefix (ie: >>> tier T), then the LSR can return a mapping of FEC,label,addr with its >>> address. This mapping can be passed back and at each hop that >>> actually does have a direct path to that address the mapping can be >>> installed and the RSVP-TE LSP used as an outer label, even if there is >>> no T-LDP session to that address. (btw- AFAIK no such extension >>> exists, I'd be happy to be wrong about that). >>>=20 >>> IMHO using RSPV-TE is a viable and IMHO better solution for the >>> problem posed in this draft. =20 >>=20 >> It is opinion of the authors of this draft and WG members supporting >> this draft that the design described in the draft is more optimal for >> scaling MPLS into large access and aggregation deployments compared to >> RSVP-TE with hierarchical LSPs. The draft also efficiently accommodates >> capabilities of access device and the operational aspects. >=20 > OK. Now I see how your approach works and I can see the benefits. > Prior to this discussion it was not clear from reading the draft. Great. Thx. >=20 >>> It is also not encumbered by IPR AFAIK. >>=20 >> IPRs are provided on non-discriminatory terms, per IETF standard. >=20 > Yes. I've seen that. Great. Thx. >=20 >>> I don't think the draft provides a good solution. >>=20 >> Per earlier note, the design specified by this draft has been accepted >> by number of operators for production deployments. >=20 > Now that I better understand how your proposal works, I withdraw my > "not a good solution" comment and replace it with "your draft is not a > clear description of your solution, but that can be easily fixed". >=20 > Please consider making the changes that I have suggested to improve > the document clarity. Great. Thx. Pls review the changes per this email, and ack or provide more comments and suggestions. thanks, /maciek >=20 >> /maciek >=20 > Regards, >=20 > Curtis >=20 >=20 >>> Curtis >>>=20 >>>=20 >>>=20 >>> In message <525CD992.2020800@pi.nu> >>> Loa Andersson writes: >>>=20 >>> Working Group, >>>=20 >>> I'll will keep this wglc open until October 21st, there are several >>> reasons. >>>=20 >>> - the subject line did not explicitly say that this was a working group >>> last call >>> - we had a very late IPR disclosure, and we are still looking into that= . >>> We should like to draw the attention to the expectation that IPRs >>> need to be disclosed in a timely fashion after your name appears on >>> on a document, we are talking days or weeks, rather than months; and >>> certainly not years >>> - we have not seen any comments on the list, we are therefore now also >>> asking if there is support to progress the draft. >>>=20 >>> /Loa >>>=20 >>>=20 >>>=20 >>> On 2013-09-26 13:37, Loa Andersson wrote: >>>> Working Group, >>>>=20 >>>> this is to start a two week+ working group last call on >>>> draft-ietf-mpls-seamless-mpls-05. >>>>=20 >>>> Please send your comment to working group mailing lists (mpls@ietf.org= ). >>>>=20 >>>> We did an IPR poll on this document prior to starting the wglc. >>>> All the authors responded to the IPR poll that they are not aware of >>>> any IPR's relating to this document other than the one already >>>> disclosed. >>>>=20 >>>> There are no IPRs disclosed directly against this document, disclosure >>>> #1920 was disclosed against an earlier individual version of the >>>> document. >>>>=20 >>>> It has also been pointed out that one of the components in the Seamles= s >>>> MPLS architecture is derived from RFC 5283 and that IPR disclosures >>>> # 686 and # 853 are applicable. >>>>=20 >>>> The working group last call will end Friday October 11, 2913. >>>>=20 >>>> /Loa >>>=20 >>> --=20 >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 From curtis@ipv6.occnc.com Wed Feb 12 12:52:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0341A06BC for ; Wed, 12 Feb 2014 12:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.548, 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 P55GrU6WjivX for ; Wed, 12 Feb 2014 12:52:44 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 37B6E1A06ED for ; Wed, 12 Feb 2014 12:52:44 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s1CKqXjP074635; Wed, 12 Feb 2014 15:52:33 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402122052.s1CKqXjP074635@maildrop2.v6ds.occnc.com> To: "maciek@cisco.com" From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Feb 2014 19:07:01 +0000." Date: Wed, 12 Feb 2014 15:52:33 -0500 Cc: "mpls@ietf.org" , "draft-ietf-mpls-seamless-mpls.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Still open: working group lst call on draft-ietf-mpls-seamless-mpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:52:49 -0000 Thanks for making the changes. Consider the WGLC comments to have been satisfied. There is still one request that I'd like to make that is not urgent. In keeping consistent with other MPLS documents, ILM should be used in place of LFIB. LFIB is used in 9 documents, in most cases incorrectly and in some cased ILM and LFIB are both used as if interchangeable. ILM is used in 58 documents. For example, see RFC 6383 Section 1.1.1 "What is a Cross-Connect?". In packet MPLS networks, this is often referred to as the Incoming Label Map (ILM) and Next Hop Label Forwarding Entry (NHLFE) [RFC3031] which are sometimes considered together as entries in the Label Forwarding Information Base (LFIB) [RFC4221]. The number of ILM (aka insegment) entries and the number of NHLFE (aka outsegment) entries differ. With platform label space the ILM size if fixed across all interfaces but only the outgoing interfaces need a NHLFE entry. Where the operation is POP and forward (ie: PHP POP), many ILM entries can share an NHLFE entry. So if LFIB refers to the set of hardware entries needed, including both ILM and NHLFE, then the number of LFEB is not correct. Curtis btw- I hated the terms ILM and NHLFE right from the start along with FEC and a few other MPLS framework terms but now we are stuck with them and we might as well use them consistently. In message "Maciek Konstantynowicz (mkonstan)" writes: Curtis, Many thanks for thorough review and all your comments. Pls see in line. On 23 Jan 2014, at 23:12, Curtis Villamizar wrote: > > In message > "Maciek Konstantynowicz (mkonstan)" writes: > >> Curtis, >> >> Pls see our comments inline, and let us know your thoughts. >> We have also posted updated ID. > > There was very little change between the 04 version and the 05 > version. > >> On 15 Oct 2013, at 18:09, Curtis Villamizar wrote: >> >>> >>> Loa, >>> >>> No details are given in IPR #686 (applicable to RFC 5283) for the >>> "Reasonable and Non-Discriminatory License to All Implementers with >>> Possible Royalty/Fee." At the very least, some terms should be given. >> >> Update from Bruno in addition to the email he sent on >> Date: 16 October 2013 08:43:46 GMT+01:00 >> >> <...> >> Tried for more than 6 months, to have my IPR team to update the IPR 853 >> to make it clear that it _replaces/supersede _ 686. >> But they are not moving. It's all the more incredible that they have >> dropped the patent. So no, it's not even "No licence Required" it's even >> no IPR at all... >> >> That being said, the above IPR was on RFC 5283, not on seamless MPLS >> draft. I had a discussion with Loa & Adrian on this, and there opinion >> is that no IPR declaration would be required for draft seamless mpls. So >> there is no real problem in the first place. >> <...> >> >>> >>> IPR #1920 and #2212 do provide details. >>> >>> An alternate to the use of a prefix based LDP LSP is to use a prefix >>> based RSVP-TE LSP and carry the individual end-to-end LSP within it. >>> This is not mentioned in the draft. See below for details. >> >> The use cases, proposed design and protocol choices have been driven by >> the actual SP deployments. >> >> Design based on the hierarchy of RSVP-TE LSPs may address the listed use >> cases. However the labeled BGP design with LDP DoD has been chosen due >> to the higher degree of out-of-the-box automation and operational >> simplicity as well as compatibility with the existing backbone and >> backhaul designs & deployments which use LDP and not RSVP-TE. >> >> It also assumes relatively simple MPLS implementations on access nodes - >> RFC 7032 goes into much more detail there. > > Could you please simply mention that RSVP-TE might be an alternative > and then state the assumptions above in the document as reasons for > using this approach. Yes. Following text has been added in Section 4.4: Note that this document describes the design based on LDP, LDP Downstream-on-Demand and labeled BGP due to the higher degree of out-of-the-box automation and operational simplicity as well as compatibility with the existing backbone and backhaul designs & deployments which use LDP and not RSVP-TE. It also assumes relatively simple MPLS implementations on access nodes. The protocol choices for the design described in this document have been driven by the actual SP deployments. Design based on the hierarchy of RSVP-TE LSPs may be alternative but has not been considered in this document. > > >>> Scaling numbers are given as: >>> >>> Number of Aggregation Domains: 100 >>> Number of Backbone Nodes: 1.000 >>> Number of Aggregation Nodes: 10.000 >>> Number of Access Nodes: 100.000 >>> >>> This section should state that very sparse connectivity among the set >>> of access nodes is expected. For exampls, you would not expect each >>> access node to have an LSP to every other access node. Is so, more >>> than 10 such access nodes aggregated prior to a prefix based LSP would >>> exceed the limits of the MPLS 20 bit label space. >> >> The requirement was to cater for service connectivity over transport >> LSPs per scaling numbers provided for listed deployment use cases. The >> required design was not to restrict the LSP based connectivity between >> the access, aggregation and backbone nodes, catering equally well for >> sparse and dense connectivity, but not the full-mesh. Full-mesh >> connectivity between between all ANs will require each AN maintaining >> LSP that they initiate and terminate, complicating the AN >> implementation. >> Luckily this is not the case in the listed use cases and the actual >> access deployments. >> >> The result is the seamless MPLS design specified in this draft. And it >> does work for dense transport LSP connectivity between the access nodes >> without exhausting the MPLS 20-bit label space on any of the nodes by >> relying on LSP hierarchy provided by labeled BGP for inter-domain >> connectivity. >> >> See section 5.2 for scalability analysis, and numerical examples for >> access node connectivity in section 5.2.1.5. >> >>> >>> On the other hand it would not be unreasonable to expect each of the >>> 10,000 aggregation nodes to be fully meshed or at least very densely >>> meshed. This can also create problems without some form of >>> aggregation as a worst case graph cut set with 5000 nodes on each side >>> would have 25,000,000 LSP. A cutset of 2-5 nodes (typical core) could >>> not support this (exceeds the 20 bit label space) without aggregation. >> >> We read your comment "without some form of aggregation" as meaning >> "without some form of hierarchy". >> If so, indeed this is why specified design used LSP hierarchy per >> earlier comment. > > OK. I reread parts of your draft and I understand how you are using > recursive LDP LFIB lookup to create a hierarchical label stack at the > ABR. Great. Thx. > >>> Some indication of how dense or sparse the connectivity would be >>> useful in this section (2.1. Why Seamless MPLS). >> >> Indicative access node level connectivity has been described in section >> 5.2 Scalability Analysis, but we agree that it makes sense to give an >> indication in section 2.1 > > Access node connectivity is not mentioned in 5.2 as far as I can tell. > What you do have in "5.2.1.4. Summary" is mention that "The main > limitation is the MPLS connectivity requirements on the AN, > i.e. mainly the number of LSP needed on the AN." At no point in this > section is there mention that this limit is less than #AN because in > the typical deployment there is a sparse mesh of connectivity among > access nodes. > Just to clarify - I meant following text in 5.2, or more specifically in 5.2.1.1: o Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC which are outside of their routing domain. Those 100 remote FEC are the same for all Access Nodes of a given AGN. 1,000 LSPs per AN includes AN to AN LSPs, so it is captured. The numbers came from the EU operators, and AFAICT reflect their current and target access deployment models - both copper and fiber. And you're right, the sparse connectivity between ANs is indeed not there. Thanks for spotting, added following text for clarity: AN requirements are kept to a minimum. BGP is not required on ANs and the size of their FIB is driven only by their own connectivity requirements. In the FIB scale analysis described in sections 5.2.1.x, it was assumed that any single AN will need no more than 1,000 LSPs. This assumption is based on the expected AN access line capacity and LSPs required for connectivity to PE routers providing edge services as well as a sparse mesh of connectivity between ANs. > You would really solve this if in "5.2.1.1. Introduction" you added a > variable which is the number of access nodes that any one access node > is connected to. Perhaps call it #AMD for access mesh density and > explain what it is. You have a magical 1k and 100 under assumptions > that comes out of thin air. You can replace it with #AMD (or whatever > name you pick). Then when you do the worked examples in > "5.2.1.5. Numerical application for use case #1" and > "5.2.1.6. Numerical application for use case #2" you can include > values for #AMD. I do think that right now the 1k and 100 numbers are > reasonable values but I think in the future these may increase. > > The reason that the 1k number looks to be out of thin air is because > sections 2.2.2 and 2.3.2 contain nothing but a table and no > explanation and there is desription of the assumption or connection to > the 1k number later on in section 5.2. See below on 2.2.2 and 2.3.2. > Here I disagree. Adding a variable for #LSPs between ANs does not bring much value here IMV. We already capture the total number of LSPs per AN as a constant 1,000 LSPs. I have edited the following text in sec. 5.2.1.1 for improved clarity: Each Access Node needs to have up to 1,000 (1k) LSPs. This is driven by the expected AN access line capacity, and a sum of LSPs required for connectivity to PE routers providing edge services as well as a remote ANs. 100 LSPs per AN (10% of total) are FECs which are outside of their routing domain. Those 100 remote FEC are the same for all Access Nodes of a given AGN. > [OT and IMO - the access node connectivity due to legacy circuits is > expected to continue to drop even though actual TDM infrastructure is > disappearing and being replaced with IP and PW for remaining TDM, FR, > and ATM. OTOH - l3vpn connectivity is growing. Many potential l3vpn > customers know they can use plain old Internet and tunnel traffic > themselves and encrypt it. The value to them of l3vpn is mostly > preferred treatment of traffic. As cost of l3vpn service drops, that > value will out weigh the cost of the service until penetration > increases (in which case cost may drop more).] > > btw- Are case #1 and case #2 the numbers that specific customers asked > you to use? A simple "yes/no" question - no need to name them. The numbers came from operators co-authoring the draft. > >> Following text added in section 2.1: >> >> Multiple Service Providers plan to deploy networks with 10k to 100k MPLS >> nodes, with varying levels of MPLS LSP connectivity between those nodes >> - sparse-mesh in access, partial-mesh in aggregation and full-mesh in >> core. This is typically at least one order of magnitude higher than >> typical deployments and may require a new architecture. > > OK. Great. Thx. > >>> It may be worth >>> creating a new subsection (2.2 Scaling Goals) and going into a little >>> more detail. >> >> We believe this comment is addressed by above addition in section 2.1 >> and section 5.2. Scalability Analysis. Let us know if this does address >> your comment. > > Please consider the comments I've made above. > > I'm also not sure what "IGP Control Plane = 2" and "IP FIB = 2" mean > in table 1 and table 2. You also have "LDP Control Plane = 200" (or > 1000) and "LDP FIB = 200" (or 1000). It is not clear to me what it > means for an access node to have 200 control planes. If the access > node has only default routes I can see where "IP FIB = 2" would come > about but that assumption is not stated. It is unclear what "IGP > Control Plane = 2" means. Please explain in the document. You're right "IGP Control Plane = 2" is indeed confusing language. It should say RIB/FIB and LIB/LFIB Entries instead respectively, corrected. > > It is also more common AFAIK to state how many VFRs the access node > needs and also how many routes per VRF on average. Since the access > nodes have a high fanout to CPE nodes, the number of IP fib entries > would be the two conditional default routes plus at least one route > per CPE attachment, plus VRF routes which should be counted > separately. If it is assumed that the aggregation nodes hold the VRF, > that should be stated. > > If you are just counting core facing IP routes, then say so in the > document. > > BTW- the correct MPLS term is ILM. IFIB is a vendor term and so far > does not appear in any RFCs. s/IFIB/ILM/g please. FIB is a commonly used term to denote the data plane that's in most cases is implemented in HW. And the document must distinguish between the ctrl plane and data plane, as the latter is usually the limiting factor, hence RIB/LIB and FIB/LFIB terms are used. I don't think me or other authors are married to these terms, so if you think they are not IETF terminology compliant, pls propose alternatives for: RIB for IP routing table (ctrl plane state) FIB for IP forwarding table (data plane state) LIB for label table (ctrl plane state) LFIB for label forwarding table (data plane state) > >>> Then there is the question as to whether this draft should even go >>> forward at all. >> >> Can you pls be more specific why you don't see this draft proceeding ? >> >> There are production implementation by both vendors and providers of >> Seamless MPLS design as specified in this draft. > > Now that I see how you are doing the core hierarchy I see how this > works. Great. Thx. > >>> It is worth noting that a full mesh of 10.000 RSVP-TE LSP is feasible >>> using hierarch. Within the core of 100 nodes, PSC-4 can be used. >>> Each of the 1,000 backbone nodes can create a PSC-3 LSP to each other >>> backbone node (using above terminology, "edge" nodes in more common >>> core-edge-access or core-edge-aggregation-access terminology). If on >>> average there are 10 backbone nodes per core node pair, then each core >>> node has on the order of 10,000 ILM entries (about 20,000 if you >>> consider 50 pairs of core nodes, each serving 20 nodes). There are >>> only 100 LSP from each core node facing the core side, so FRR can be >>> very effectively deployed. The same holds for a full mesh of the >>> 10.000 aggregation nodes. If each of the 1,000 backbone nodes are >>> deployed in pairs serving on average 20 nodes per pair, then an ILM >>> siz on the order of 200,000 is needed. The PSC-3 LSP used to reach >>> the far side backbone node can be used, yielding only 1,000 LSP facing >>> the core per backbone node. Again, FRR can be used, with the protect >>> path using the alternate core node of the designated pair. >>> >>> In this scenarion the access nodes may or may not be full meshed. If >>> they are full meshed, then they need to be able to support 100,000 DoD >>> mode LSP. If the are more sparsely meshed, they can support a lower >>> number of DoD mode LSP. >> >> We do not disagree that alternative design approach based on RFC 4206 >> and related h-LSP RFCs may be applied to address the LSP connectivity in >> this environment. >> >> However we believe the design specified in the Seamless MPLS draft >> better meets described requirements including better deployment >> flexibility, better scaling and easier troubleshooting. > > As I said before, the draft would be greatly improved if you mentioned > that you have considered this alternative and why you took the > approach that you took. Ack. Added text per first comment. > >>> If RSVP-TE is used in this way, there is no need for aggregating LDP >>> LSP. The LDP LSP are aggregated into RSVP-TE LSP and further >>> aggregated in PSC-3 LSP and PSC-4 LSP in tiers closer to the core. >> >> The draft does not propose aggregating LDP LSPs. In fact the design >> enables the operator to choose the transport LSP signalling protocol, >> LDP or RSVP-TE, per domain, per section 4.4. Intra-Domain Routing. > > OK. I missed that mention of RSVP. We may have been arguing for > similar solutions but your solution adding the recursive LDP route > lookup when only a prefix route is present and resulting in a label > stack. > > This is a very key aspect of your proposal and it is not well > highlighted in section 4.5 where there is only the one word mention of > hierarchy. Perhaps you could add a forward reference from that point > such as a sentence saying "The mechanism for this hierarchy is defined > in Section 5.1.3" and then change the title of 5.1.3 from hierarchy to > "Hierarchy based on recursive LDP route lookup". This is AFAIK the first > RFC mention of this technique and it is quite well buried. Also in > this section please mention that router "I" could be an RSVP LSP or > LDP LSP that reaches a prefix at the other ABR. Thanks for the suggestion. Applied following changes: added to 4.5: The mechanism for the LSP forwarding hierarchy is defined in Section 5.3. Changed the section 5.1.3 title to: Hierarchy based on recursive BGP labeled route lookup Re-reading section 5.1.3, we actually do need to add more comprehensive description of how the LSP hierarchy is realised. Here is a proposed updated text: Inline with the explanation in section 4.5, LSP hierarchy is key to a scalable seamless MPLS architecture. The LSP hierarchy in this design is achieved by: - forming separate MPLS domains for aggregation and core areas - intra-domain LSP connectivity provided by combination of IS-IS (as the intra-domain link-state routing protocol) and LDP (used for MPLS label distribution for intra-domain LSPs) - inter-domain LSP connectivity provided by labeled BGP [RFC3107] (used for MPLS label distribution for inter-domain LSP FECs) and relying on IS-IS and LDP for intra-domain LSP connectivity between the LSR labeled BGP speakers (AGNs and ABRs). Note that the MPLS core notes are not carrying the labeled BGP routes. The aggregation and core MPLS domains are mapped to IS-IS areas as follows: Aggregation domains are mapped to IS-IS L1 areas. The core is configured as IS-IS L2. The border routers connecting aggregation and core are IS-IS L1L2 and are referred to as ABRs. From a technical and operational point of view these ABRs are part of the core, although they also belong to the respective aggregation domain purely from a routing protocol point of view. > >>> There are ultimate scaling limits to either approach, imposed by the >>> 20 bit label space. If a full mesh is needed at a given tier T with N >>> nodes, then the nodes in tier T-1 aggregating tier T needs an ILM size >>> of N times the number of T nodes the T-1 node serves. So for example, >>> with a full mesh of 100,000 tier T nodes if each tier T-1 node could >>> aggregate 8 tier T nodes without exceeding the 20 bit label space size >>> (ILM=800,000 in this case), but could not aggregate 20 tier T nodes >>> (ILM=2,000,000). If using RSVP-TE in the core, the core is limited by >>> the worst case cut set, but core sizes of on the order of hundreds are >>> OK (but smaller is better). >> >> In line with your comments the scaling limits are imposed not only by >> MPLS 20-bit label space, but also by the number of supported LFIB >> entries on specific MPLS node. >> >> Design in this draft relies on labeled BGP control plane to scale the >> MPLS label distribution and to optimize the MPLS data plane on ABR nodes >> by installing only the local labelled routes in its LFIB, as described >> in section 5.1.7. > > Now that I see your LDP based hierarchy works I see how the scaling > works out. Great. Thx. > >>> Using either RSVP-TE or LDP for aggregation the outermost T-max tier >>> could have a million nodes or more as long as they were sufficiently >>> sparsely connected. This limit is independent of whether aggregation >>> is via LDP or RSVP-TE. >> >> Similarly, the scale of the design in this draft is restricted by the >> scale of AN at the outskirts of the MPLS network and their connectivity >> needs driving the scale of neighbouring AGNs. > > We are in agreement. Your text was simply not clear to me. I'm not > usually known to be more clueless than the average reader (maybe > depends on who you ask, but OT) so it seems that some improvements in > document clarity wouldn't hurt. > > I suspect that few people actually thoroughly read your document and > thought about where your numbers came from and that may have more to > do with lack of anyone else questioning your numbers (or maybe I *am* > just really dense - I hope not). Added following text in sec 3.4: The network must be highly scalable. Based on the use cases described in Sections 2.2 and 2.3, as a minimum requirement the following scalability figures should be met: Combination of this add plus the other changes stimulated by your feedback hopefully improve clarity now. > >>> With RSVP-TE used for aggregation, T-LDP is used among the sparse mesh >>> in the outermost T-max tier. A T-LDP session is only needed if FEC >>> information needs to be exchanged via LDP to support an underlying >>> service, otherwise RSVP-TE alone could be used. Using T-LDP the >>> number of T-LDP TCP sessions could be a limiting factor for very >>> highly connected tier T-max nodes. Either TCB state or the 16 bit TCP >>> port limit could be the limit depending on how much RAM the T-max node >>> has. OTOH if a tier T-max node out on the fringes is supporting on >>> the order of 50K T-LDP sessions, it can use multiple IP addresses to >>> get around the 16 bit TCP port number issue. >> >> In the draft, labeled BGP is used for labeled routes, providing excellent >> scaling properties in the control plane. > > Yes. I agree. It was not clear to me at first how your hierarchy was > working in the core with the labeled BGP routes exchanged but not > installed in the core. > > At some point in the document you should mention that the labeled BGP > routes are not installed in the core. I searched the document for the > word BGP (the word BGP is in a lot of places) and there does not seem > to be any mention that the BGP labeled routes are installed at the ABR > and carried across the core but are not installed in the core. Ack. Already captured in added text in 5.1.3. > > Again, this is a key aspect of the proposal and it has gone unstated. > >>> LDP could be extended to avoid the need for T-LDP sessions using LDP >>> distribution of labels that will make use of RSVP-TE LSP. A DoD >>> request would normally create a series of label bindings and swaps. >>> If a full mesh of RSVP-TE LSP is know to exist within a prefix (ie: >>> tier T), then the LSR can return a mapping of FEC,label,addr with its >>> address. This mapping can be passed back and at each hop that >>> actually does have a direct path to that address the mapping can be >>> installed and the RSVP-TE LSP used as an outer label, even if there is >>> no T-LDP session to that address. (btw- AFAIK no such extension >>> exists, I'd be happy to be wrong about that). >>> >>> IMHO using RSPV-TE is a viable and IMHO better solution for the >>> problem posed in this draft. >> >> It is opinion of the authors of this draft and WG members supporting >> this draft that the design described in the draft is more optimal for >> scaling MPLS into large access and aggregation deployments compared to >> RSVP-TE with hierarchical LSPs. The draft also efficiently accommodates >> capabilities of access device and the operational aspects. > > OK. Now I see how your approach works and I can see the benefits. > Prior to this discussion it was not clear from reading the draft. Great. Thx. > >>> It is also not encumbered by IPR AFAIK. >> >> IPRs are provided on non-discriminatory terms, per IETF standard. > > Yes. I've seen that. Great. Thx. > >>> I don't think the draft provides a good solution. >> >> Per earlier note, the design specified by this draft has been accepted >> by number of operators for production deployments. > > Now that I better understand how your proposal works, I withdraw my > "not a good solution" comment and replace it with "your draft is not a > clear description of your solution, but that can be easily fixed". > > Please consider making the changes that I have suggested to improve > the document clarity. Great. Thx. Pls review the changes per this email, and ack or provide more comments and suggestions. thanks, /maciek > >> /maciek > > Regards, > > Curtis > > >>> Curtis >>> >>> >>> >>> In message <525CD992.2020800@pi.nu> >>> Loa Andersson writes: >>> >>> Working Group, >>> >>> I'll will keep this wglc open until October 21st, there are several >>> reasons. >>> >>> - the subject line did not explicitly say that this was a working group >>> last call >>> - we had a very late IPR disclosure, and we are still looking into that. >>> We should like to draw the attention to the expectation that IPRs >>> need to be disclosed in a timely fashion after your name appears on >>> on a document, we are talking days or weeks, rather than months; and >>> certainly not years >>> - we have not seen any comments on the list, we are therefore now also >>> asking if there is support to progress the draft. >>> >>> /Loa >>> >>> >>> >>> On 2013-09-26 13:37, Loa Andersson wrote: >>>> Working Group, >>>> >>>> this is to start a two week+ working group last call on >>>> draft-ietf-mpls-seamless-mpls-05. >>>> >>>> Please send your comment to working group mailing lists (mpls@ietf.org). >>>> >>>> We did an IPR poll on this document prior to starting the wglc. >>>> All the authors responded to the IPR poll that they are not aware of >>>> any IPR's relating to this document other than the one already >>>> disclosed. >>>> >>>> There are no IPRs disclosed directly against this document, disclosure >>>> #1920 was disclosed against an earlier individual version of the >>>> document. >>>> >>>> It has also been pointed out that one of the components in the Seamless >>>> MPLS architecture is derived from RFC 5283 and that IPR disclosures >>>> # 686 and # 853 are applicable. >>>> >>>> The working group last call will end Friday October 11, 2913. >>>> >>>> /Loa >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 From gregory.mirsky@ericsson.com Wed Feb 12 15:26: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 82E9D1A0022 for ; Wed, 12 Feb 2014 15:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lPvyswoqII6j for ; Wed, 12 Feb 2014 15:26:15 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE751A002A for ; Wed, 12 Feb 2014 15:26:15 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-a8-52fc031225d4 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C4.9E.12743.2130CF25; Thu, 13 Feb 2014 00:26:10 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 18:26:13 -0500 From: Gregory Mirsky To: "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: Mail regarding draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac8oSA4xaJC4UUoKSO2rSotsniXi5w== Date: Wed, 12 Feb 2014 23:26:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7619A2@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7619A2eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXRPrK4Q858gg8t7tS16Z29ntLi1dCWr A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxbqZmwSvTiplvr7E0MDbrdzFyckgImEjs +nyLEcIWk7hwbz1bFyMXh5DAEUaJVQtPMkE4yxkllt8+xg5SxSZgJPFiYw+YLSJQKvFi/Srm LkYODmYBZYlTd2VAwsICdhLHTu9lgihxlvj3/woLhK0n8bD1INgyFgFViU1/pzCBtPIK+Epc mJYFEmYEuuH7qTVgrcwC4hK3nsxngrhNQGLJnvPMELaoxMvH/1ghbEWJff3T2SHq8yU2/d8J FucVEJQ4OfMJywRG4VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxchR WpxalptuZLCJERghxyTYdHcw7nlpeYhRmoNFSZz3y1vnICGB9MSS1OzU1ILUovii0pzU4kOM TBycUg2M2y1yypINijktOL+9mX6r/JrD0x9HVVmSt9syZ4noPLMr/NGxrU5ur7mVcqT1oqXP vkcYm5mwcm1WEJb06z2x/MJnhVkXK0p7xYzuxFzXeDJ93fHb17rD0lrjClZMWn+69XRi9MOw r6eNeM9Fm1kxqBx+JRmcZ6Xl+LBPRzPZobLl7be/DHJKLMUZiYZazEXFiQCDrMWpXgIAAA== Cc: "mpls@ietf.org" Subject: [mpls] Mail regarding draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Feb 2014 23:26:18 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7619A2eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, I have couple comments to changes made in version 11 of the document: * Introduction. A statement that e2e may "provide slow fault recove= ry" been added. Of course, if an operator to use slower fault detection and= opt for service restoration rather than protection, then fault recovery wi= ll be slow. But if we to compare apples to apples, then I find this assumpt= ion unsubstantiated and hence don't see enough motivation for the proposed = solution. * Section 1.1 "Exactly how the failure is detected is out of scope = for this document." I agree with this as long as you can demonstrate that e= gress failure can be detected and clearly identified specifically as egress= failure in reasonable time. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B7619A2eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

I have couple comments to changes made in version 11= of the document:

·       &= nbsp; Introduction. A statement that e2e ma= y “provide slow fault recovery” been add= ed. Of course, if an operator to use slower fault detection and opt for ser= vice restoration rather than protection, then fault recovery will be slow. But if we to compare apples to apples, then I= find this assumption unsubstantiated and hence don’t see enough moti= vation for the proposed solution.

·         Section 1.1 “Exactly how the failure i= s detected is out of scope for this document.” I agree with this as l= ong as you can demonstrate that egress failure can be detected and clearly = identified specifically as egress failure in reasonable time.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B7619A2eusaamb103erics_-- From huanglu@chinamobile.com Wed Feb 12 19:21: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 403891A00AF for ; Wed, 12 Feb 2014 19:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.475 X-Spam-Level: * X-Spam-Status: No, score=1.475 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 pCobbRXgZ37R for ; Wed, 12 Feb 2014 19:21:25 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id C18D71A0028 for ; Wed, 12 Feb 2014 19:21:24 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee252fc39aa7d4-e17d4; Thu, 13 Feb 2014 11:19:06 +0800 (CST) X-RM-TRANSID: 2ee252fc39aa7d4-e17d4 X-RM-SPAM-FLAG: 00000000 Received: from huanglu@chinamobile.com ( [114.245.39.89] ) by ajax-webmail-oa_rmapp03-11003 (RichMail) with HTTP; Thu, 13 Feb 2014 11:19:06 +0800 (CST) Date: Thu, 13 Feb 2014 11:19:06 +0800 (CST) From: =?utf-8?B?6buE55KQ?= To: mpls Message-ID: <2afb52fc39278db-00006.Richmail.00001040101188864585@chinamobile.com> References: <002b01cf26cd$b4f94560$1eebd020$@chinamobile.com> , <004001cf286a$4d29e770$e77db650$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_180009_2133958115.1392261546402" X-Priority: 3 X-RM-TRANSID: 2afb52fc39278db-00006 X-RM-OA-ENC-TYPE: 0 X-RM-FontColor: 0 X-Mailer: Richmail_Webapp(V1.4.9) Cc: mpls-chairs Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 03:21:29 -0000 ------=_Part_180009_2133958115.1392261546402 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am not aware of any IPR associated with this draft. =20 B.R. Lu Huang =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bounces@ietf.org] =E4=BB=A3= =E8=A1=A8 =E5=88=98=E5=BF=97=E6=81=92Vic Liu=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=8811=E6=97=A5, = =E6=98=9F=E6=9C=9F=E4=BA=8C 10:05=20 =E6=94=B6=E4=BB=B6=E4=BA=BA: mpls@ietf.org;=20 draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; rcallon@juniper.net= =20 =E6=8A=84=E9=80=81: mpls-chairs@tools.ietf.org=20 =E4=B8=BB=E9=A2=98: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-prot= ection=20 I am not aware of any IPR associated with this draft. =20 Vic Liu=20 Network Research Institute=20 China Mobile=20 LiuZhiheng@chinamobile.com=20 -----Original Message-----=20 From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Monday, February 10, 2014 3:51 PM=20 To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org=20 Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux=20 Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection=20 Working Group,=20 The authors of draft-chen-mpls-p2mp-egress-protection have told the working= =20 group chairs that the draft is ready to be adopted as a working group=20 document.=20 Before starting the the poll to see if we have consensus to make this a=20 working group document we need to do an IPR poll.=20 This mail starts that IPR poll.=20 Are you aware of any IPR that applies to=20 draft-chen-mpls-p2mp-egress-protection?=20 If so, has this IPR been disclosed in compliance with IETF IPR rules (see= =20 RFCs 3979, 4879, 3669 and 5378 for more details).=20 If you are listed as a document author or contributor please respond to thi= s=20 email regardless of whether or not you are aware of any relevant IPR. The= =20 response needs to be sent to the MPLS wg mailing list. The documents will= =20 not advance to the next stage until a response has been received from each= =20 author and each contributor.=20 If you are on the MPLS WG email list but are not listed as an author or=20 contributor, then please explicitly respond only if you are aware of any IP= R=20 that has not yet been disclosed in conformance with IETF rules.=20 Thanks, Ross=20 (as MPLS WG co-chair)=20 _______________________________________________=20 mpls mailing list=20 mpls@ietf.org=20 https://www.ietf.org/mailman/listinfo/mpls=20 _______________________________________________=20 mpls mailing list=20 mpls@ietf.org=20 https://www.ietf.org/mailman/listinfo/mpls=20 Subject=EF=BC=9A=E8=BD=AC=E5=8F=91: [mpls] IPR Poll on draft-chen-mpls-p2mp= -egress-protection -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=20 =E5=8F=91=E4=BB=B6=E4=BA=BA: =E5=88=98=E5=BF=97=E6=81=92Vic Liu [mailto:liu= zhiheng@chinamobile.com] =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=8811=E6=97=A5, = =E6=98=9F=E6=9C=9F=E4=BA=8C 11:41=20 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'HuangLu'=20 =E4=B8=BB=E9=A2=98: =E8=BD=AC=E5=8F=91: [mpls] IPR Poll on draft-chen-mpls-= p2mp-egress-protection=20 =E9=BB=84=E7=92=90=E6=82=A8=E5=A5=BD=20 MPLS=E5=B0=BE=E8=8A=82=E7=82=B9=E4=BF=9D=E6=8A=A4=E7=9A=84=E6=96=87=E7=A8= =BF=E8=BF=9B=E5=85=A5=E4=BA=86WG=E7=A8=8B=E5=BA=8F=E3=80=82=20 =E9=9C=80=E8=A6=81=E6=8C=89=E7=85=A7=E5=8F=91=E7=9A=84=E9=82=AE=E4=BB=B6=E6= =A0=BC=E5=BC=8F=E5=8F=91=E4=B8=80=E4=B8=8B=E9=82=AE=E4=BB=B6=E7=BB=99mail l= ist=E3=80=82=E8=B0=A2=E8=B0=A2=E5=95=A6=EF=BC=8C=E8=AF=B7=E6=8A=8A=E6=88=91= =E7=9A=84=E5=86=85=E5=AE=B9=E5=85=A8=E9=83=A8=E9=83=BD=E5=88=A0=E6=8E=89=E3= =80=82=20 =E7=9B=B8=E5=BD=93=E4=BA=8E=E7=9B=B4=E6=8E=A5=E5=9B=9E=E5=A4=8D=E9=82=AE=E4= =BB=B6=E3=80=82=20 =E5=88=98=E5=BF=97=E6=81=92=20 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=20 =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bounces@ietf.org] =E4=BB=A3= =E8=A1=A8 =E5=88=98=E5=BF=97=E6=81=92Vic Liu=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=8811=E6=97=A5, = =E6=98=9F=E6=9C=9F=E4=BA=8C 10:05=20 =E6=94=B6=E4=BB=B6=E4=BA=BA: mpls@ietf.org;=20 draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; rcallon@juniper.net= =20 =E6=8A=84=E9=80=81: mpls-chairs@tools.ietf.org=20 =E4=B8=BB=E9=A2=98: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-prot= ection=20 I am not aware of any IPR associated with this draft. =20 Vic Liu=20 Network Research Institute=20 China Mobile=20 LiuZhiheng@chinamobile.com=20 -----Original Message-----=20 From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Monday, February 10, 2014 3:51 PM=20 To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org=20 Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux=20 Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection=20 Working Group,=20 The authors of draft-chen-mpls-p2mp-egress-protection have told the working= =20 group chairs that the draft is ready to be adopted as a working group=20 document.=20 Before starting the the poll to see if we have consensus to make this a=20 working group document we need to do an IPR poll.=20 This mail starts that IPR poll.=20 Are you aware of any IPR that applies to=20 draft-chen-mpls-p2mp-egress-protection?=20 If so, has this IPR been disclosed in compliance with IETF IPR rules (see= =20 RFCs 3979, 4879, 3669 and 5378 for more details).=20 If you are listed as a document author or contributor please respond to thi= s=20 email regardless of whether or not you are aware of any relevant IPR. The= =20 response needs to be sent to the MPLS wg mailing list. The documents will= =20 not advance to the next stage until a response has been received from each= =20 author and each contributor.=20 If you are on the MPLS WG email list but are not listed as an author or=20 contributor, then please explicitly respond only if you are aware of any IP= R=20 that has not yet been disclosed in conformance with IETF rules.=20 Thanks, Ross=20 (as MPLS WG co-chair)=20 _______________________________________________=20 mpls mailing list=20 mpls@ietf.org=20 https://www.ietf.org/mailman/listinfo/mpls=20 _______________________________________________=20 mpls mailing list=20 mpls@ietf.org=20 https://www.ietf.org/mailman/listinfo/mpls=20 ------=_Part_180009_2133958115.1392261546402 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR associated&= nbsp;with this draft. 

B.R.

Lu Huang

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bo= unces@ietf.org] =E4=BB=A3=E8=A1=A8 =E5=88=98=E5=BF=97=E6=81=92Vic=  Liu
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6= =9C=8811=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=8C 10:05
=E6=94= =B6=E4=BB=B6=E4=BA=BA: mpls@ietf.org;
draft-chen-mpls-p2mp-egress-= protection@tools.ietf.org; rcallon@juniper.net
=E6=8A=84=E9=80=81:=  mpls-chairs@tools.ietf.org
=E4=B8=BB=E9=A2=98: Re: [mpl= s] IPR Poll on draft-chen-mpls-p2mp-egress-protection <= BR>
I am not aware of any IPR associa= ted with this draft. 

Vic Liu
Network&= nbsp;Research Institute
China Mobile
LiuZhiheng@chinamobi= le.com

-----Original Message-----
From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Monday, February&= nbsp;10, 2014 3:51 PM
To: mpls@ietf.org; draft= -chen-mpls-p2mp-egress-protection@tools.ietf.org
Cc: mpls-chairs@t= ools.ietf.org; Martin Vigoureux
Subject: IPR Poll&n= bsp;on draft-chen-mpls-p2mp-egress-protection

Working Gro= up,

The authors of draft-chen-mpls-p2mp-egress-prote= ction have told the working
group chairs = that the draft is ready to be adopted&nb= sp;as a working group
document.

Before star= ting the the poll to see if we have=  consensus to make this a
working group&n= bsp;document we need to do an IPR poll. =

This mail starts that IPR poll.

Ar= e you aware of any IPR that applies = ;to
draft-chen-mpls-p2mp-egress-protection?

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

If&= nbsp;you are listed as a document author = ;or contributor please respond to this
email&n= bsp;regardless of whether or not you are = ;aware of any relevant IPR. The
response = needs to be sent to the MPLS wg mai= ling list. The documents will
not advance = ;to the next stage until a response has&= nbsp;been received from each
author and each&n= bsp;contributor.

If you are on the MPLS&nb= sp;WG email list but are not listed as&n= bsp;an author or
contributor, then please expl= icitly respond only if you are aware of&= nbsp;any IPR
that has not yet been disclo= sed in conformance with IETF rules.

Thanks= , Ross
(as MPLS WG co-chair)


__________= _____________________________________
mpls mailing list
m= pls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


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

Subject=EF=BC=9A=E8=BD=AC=E5=8F=91: [mpls] IPR Poll&= nbsp;on draft-chen-mpls-p2mp-egress-protection



-----=E9= =82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA:&nbs= p;=E5=88=98=E5=BF=97=E6=81=92Vic Liu [mailto:liuzhiheng@chinamobi= le.com] 
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42= =E6=9C=8811=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=8C 11:41
=E6= =94=B6=E4=BB=B6=E4=BA=BA: 'HuangLu'
=E4=B8=BB=E9=A2=98: =E8= =BD=AC=E5=8F=91: [mpls] IPR Poll on draft-chen-mpl= s-p2mp-egress-protection

=E9=BB=84=E7=92=90=E6=82=A8=E5=A5=BD
<= BR>MPLS=E5=B0=BE=E8=8A=82=E7=82=B9=E4=BF=9D=E6=8A=A4=E7=9A=84=E6=96=87=E7= =A8=BF=E8=BF=9B=E5=85=A5=E4=BA=86WG=E7=A8=8B=E5=BA=8F=E3=80=82
=E9=9C= =80=E8=A6=81=E6=8C=89=E7=85=A7=E5=8F=91=E7=9A=84=E9=82=AE=E4=BB=B6=E6=A0=BC= =E5=BC=8F=E5=8F=91=E4=B8=80=E4=B8=8B=E9=82=AE=E4=BB=B6=E7=BB=99mail li= st=E3=80=82=E8=B0=A2=E8=B0=A2=E5=95=A6=EF=BC=8C=E8=AF=B7=E6=8A=8A=E6=88=91= =E7=9A=84=E5=86=85=E5=AE=B9=E5=85=A8=E9=83=A8=E9=83=BD=E5=88=A0=E6=8E=89=E3= =80=82
=E7=9B=B8=E5=BD=93=E4=BA=8E=E7=9B=B4=E6=8E=A5=E5=9B=9E=E5=A4=8D= =E9=82=AE=E4=BB=B6=E3=80=82


=E5=88=98=E5=BF=97=E6=81=92
-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4= =BA=BA: mpls [mailto:mpls-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 =E5=88=98=E5=BF=97=E6=81=92Vic Liu
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=8811=E6=97=A5, =E6=98=9F=E6= =9C=9F=E4=BA=8C 10:05
=E6=94=B6=E4=BB=B6=E4=BA=BA: mpls@ietf.= org;
draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; rcallo= n@juniper.net
=E6=8A=84=E9=80=81: mpls-chairs@tools.ietf.org
= =E4=B8=BB=E9=A2=98: Re: [mpls] IPR Poll on dr= aft-chen-mpls-p2mp-egress-protection

I am not aware&= nbsp;of any IPR associated with this draft.&n= bsp;

Vic Liu
Network Research Institute
Chin= a Mobile
LiuZhiheng@chinamobile.com

-----Original Mes= sage-----
From: Ross Callon [mailto:rcallon@juniper.net]=
Sent: Monday, February 10, 2014 3:51 PM =
To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@too= ls.ietf.org
Cc: mpls-chairs@tools.ietf.org; Martin Vigou= reux
Subject: IPR Poll on draft-chen-mpls-p2mp-egre= ss-protection

Working Group,

The authors of&= nbsp;draft-chen-mpls-p2mp-egress-protection have told the&nb= sp;working
group chairs that the draft is = ;ready to be adopted as a working group =
document.

Before starting the the poll = ;to see if we have consensus to make&nbs= p;this a
working group document we need t= o do an IPR poll.

This mail starts&nb= sp;that IPR poll.

Are you aware of an= y IPR that applies to
draft-chen-mpls-p2mp-egress-p= rotection?

If so, has this IPR been d= isclosed in compliance with IETF IPR rules&nb= sp;(see
RFCs 3979, 4879, 3669 and 5378 fo= r more details).

If you are listed as=  a document author or contributor please = ;respond to this
email regardless of whether&n= bsp;or not you are aware of any relevant=  IPR. The
response needs to be sent = to the MPLS wg mailing list. The documen= ts will
not advance to the next stage&nbs= p;until a response has been received from&nbs= p;each
author and each contributor.

If you&= nbsp;are on the MPLS WG email list but&n= bsp;are not listed as an author or
contri= butor, then please explicitly respond only if=  you are aware of any IPR
that has&n= bsp;not yet been disclosed in conformance wit= h IETF rules.

Thanks, Ross
(as MPLS WG=  co-chair)


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



____________________________________= ___________
mpls mailing list
mpls@ietf.org
https://w= ww.ietf.org/mailman/listinfo/mpls




------=_Part_180009_2133958115.1392261546402-- From stephane.litkowski@orange.com Thu Feb 13 08:01: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 A2C2E1A0306 for ; Thu, 13 Feb 2014 08:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T74SDQOsSGk for ; Thu, 13 Feb 2014 08:01:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D9C6A1A020D for ; Thu, 13 Feb 2014 08:01:46 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id CEDB4324560; Thu, 13 Feb 2014 17:01:44 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id AD2DA35C0A8; Thu, 13 Feb 2014 17:01:44 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 13 Feb 2014 17:01:44 +0100 From: To: "Nobo Akiya (nobo)" , "draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org" Date: Thu, 13 Feb 2014 17:01:43 +0100 Thread-Topic: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-mpls Thread-Index: Ac8o0o1+XpQwCtjuRh6vpvFWMgLyVg== Message-ID: <10973_1392307304_52FCEC68_10973_2075_1_EEE55384044474429A926C625D0FCC810C32CFBAFC@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810C32CFBAFCPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.13.101215 Cc: "mpls@ietf.org" , "draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org" Subject: Re: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-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, 13 Feb 2014 16:01:54 -0000 --_000_EEE55384044474429A926C625D0FCC810C32CFBAFCPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nobo and both draft Authors, Thanks for pointing this draft as reference also, I agree that solution nee= d to be consistent. Some inline comments as well as added comments on draft-ravisingh-mpls-el-f= or-seamless-mpls : =B7 Section 5.2.2.1 : b. Notional ingress behavior: When L1 does not intrinsically support ELC and L2 does, then the stitching point router must POP the incoming label, insert (ELI+EL) before PUSHing the label for the LSP segment L2. The label operations performed would be: POP(IncomingLabel), PUSH(EL), PUSH(ELI), PUSH(OutgoingLabel), or SWAP(EL), PUSH(ELI), PUSH(OutgoingLabel) The issue I see here, is that the stitching point acting as= notional ingress need to perform Deep Packet Inspection in order to comput= e EL value, but it has no knowledge of what is transported and moreover due= to usage of hierarchy the payload may be quite far ... IMHO, it may not be= a good idea to let a router not having the flow context computing an EL va= lue otherwise we are loosing some of the EL value added ... (Ingress that = have the flow context computing a good hash). Did I miss something ? For stitching , I would propose to keep consistent ELC across LSPs and othe= rwise break ELC (if some segments are not ELC) and in order to manage non E= LC domains/areas, I would encourage to use tunneling technics (so EL would = be safe) and not stitching ... Example : A ------ (S1) ----- B ----- (S2) ------ C ----- (S3) ----- D Consider S1,S2,S3 as LSPs being stiched , B does stitching between S1 and D= 2 and C between S2 and S3. if : - D is ELC for S3 - C is ELC for S3 and S2 - B is ELC for S2 BUT NOT for S1 - A is not ELC for S1 Only A has knowledge of the flow context and can perform a good hashing . I= f S1 is not ELC, I would propose to not use ELI/EL on the all stitched path= to D. But if A may be ELC2 for segment type of S2, we could imagine to start S2 o= n A rather than B and tunnel S2 over S1, so A would be able to use ELI/EL. Stephane De : Nobo Akiya (nobo) [mailto:nobo@cisco.com] Envoy=E9 : lundi 3 f=E9vrier 2014 16:44 =C0 : LITKOWSKI Stephane DTF/DERX; draft-kini-mpls-entropy-label-src-stacke= d-tunnels@tools.ietf.org Cc : mpls@ietf.org; draft-ravisingh-mpls-el-for-seaml= ess-mpls@tools.ietf.org Objet : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Taking the example from draft-ravisingh-mpls-el-for-seamless-mpls ... S1 D1 \ --------- / A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE / --------- \ S2 D2 In the above topology, let there be the following LSPs: L1: B->D L2: A->E, tunneled through LSP L1 L3: S1->D1, tunneled through LSP L2 L4: S2->D2, tunneled through LSP L2 Let's say: (1) S1 does not push ELI/EL. (2) A pushes ELI/EL. (3) B does not push ELI/EL, since label stack already contains ELI/EL. Behavior so far aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless-m= pls (snippet above). Ideally what should happen is: (4) D pops ELI/EL, and pushes (or carries over) ELI/EL below exposed top= label. [SLI] Why D pops ELI/EL ? ELI/EL was pushed by A and D is egress of tunnel = from B, so when D receives traffic originally sent by S1, D would pop tunne= l label from C (end of L1), and switch tunnel L2 label to E, and only E wou= ld see the ELI/EL (5) E pops ELI/EL, and _does not_ push ELI/EL below exposed top label. [SLI] Right (6) D1 receives data without any ELI/EL (as expected). How does nodes D and E determine the right behavior? [SLI] I don't see what's the issue there ... If A pushed ELI, E has signall= ed that it was ELC, so E is prepared to receive a packet with ELI/EL. >From what I've read in the two drafts, I don't see how this behavior is det= ermined. If we can address this issue, I think solution is applicable to Segment Rou= ting label stack with ELI/EL, meaning behavior can apply to solution 3.3 of= draft-kini-mpls-entropy-label-src-stacked-tunnels. One possibility is to make use of TC or TTL of EL to keep track of carry-ov= er number. Meaning: When ELI/EL is not inserted in a new tunnel because ELI/EL exists in the la= bel stack, then: - Increment carry-over number. - Move ELI/EL to below top label. [SLI] You can do it only if the new tunnel endpoint is ELC otherwise the ro= uter should not do it. When data terminates a tunnel, then: - Decrement carry-over number. - If (carry-over !=3D 0) re-insert ELI/EL to below exposed top lab= el. I'm no hardware expert either, and not sure if something like above can be = implemented. But if possible, then ELI/EL pushed in SR network can pre-set = carry-over number to certain value to ensure it is carried over below top l= abel all the way though, and there is only one ELI/EL at any given time. All this to say, I think there's a benefit in discussing this topic further= , with both drafts in mind. -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@o= range.com Sent: Friday, January 31, 2014 9:12 AM To: draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Hi Authors, I would like to know if you are progressing on this draft ? Entropy label support for stacked tunnels would be mandatory for us, so I w= ould like to support the work on this topic to have a working solution as s= oon as possible. Regarding the solutions you are proposing in the current version, there is = none perfect one, and unfortunately all have drawbacks. The compatibility (on LSR) with current generation of hardwares may be "goo= d" (mandatory ?) for the target solution. In your document , solution =A73.3 "re-usable EL for a stack of tunnels" so= unds for me to be the best base idea. I'm just wondering what would be the = hardware impact of doing the reinsertion of ELI at tunnel end . Could this = be done in one pass ? (IMHO, this may be possible, as today we are able to = pop or swap + push FRR headers) As you are three different vendors as co-au= thor, did you already evaluate such impact on your hardwares ? (I'm not exp= ecting details on the mailing list, but I would be interested by details un= icast to me and just yes/no on the the list) To be exhaustive in listing solutions, did you think about leaving the EL/E= LI at top of the stack ? I think there is already a case where a special la= bel may be kept at top of the stack (MPLS Router alert). What would be needed : - each hop need to advertise is ability to process EL, if nexthop = cannot process EL, it should be removed when forwarded to nexthop (there sh= ould be the same requirement for re-usable EL) I don't think this is really different from re-usable EL in the concept : - reusable EL : process top level forwarding label, if popped and = next label is EL, pop ELI/EL and next label L, push pack ELI/EL and then L = (we need to swap positions between ELI/EL and L) if nexthop is able to proc= ess EL. - top level EL : process top level ELI, ELI is recognized, ELI/EL = is removed, forwarding is done on forwarding label, ELI/EL is pushed back i= n nexthop is able to process EL. In term of operations, I think that top level EL may be simpler , but as I'= m not hardware coder, may be I'm wrong ... moreover it may be similar to MP= LS Router alert processing. Your thoughts ? Stephane ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810C32CFBAFCPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nobo and both draft Authors,<= /p>

&nb= sp;

Thanks for pointing this draft as reference also, I agree that sol= ution need to be consistent.

 

Some inline comment= s as well as added comments on draft-ravisingh-mpls-el-for-seamless-mpls :

 

=B7       &nb= sp; Section 5.2.2.1 :

 

=A0=A0=A0=A0=A0=A0=A0 b. Notional ingress b= ehavior:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 When L1 does no= t intrinsically support ELC and L2 does, then the

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 stitching point router must POP the incoming la= bel, insert

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (ELI+EL) bef= ore PUSHing the label for the LSP segment L2.

&nbs= p;

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The label operations perfo= rmed would be:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 POP(In= comingLabel), PUSH(EL), PUSH(ELI), PUSH(OutgoingLabel),

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 or

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SWAP(EL), PUSH(ELI), P= USH(OutgoingLabel)

 

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 The issue I see here, is that the stitching point acting as no= tional ingress need to perform Deep Packet Inspection in order to compute E= L value, but it has no knowledge of what is transported and moreover due to= usage of hierarchy the payload may be quite far … IMHO, it may not b= e a good idea to let a router not having the flow context computing an EL v= alue otherwise we are loosing some of the EL =A0value added … (Ingres= s that have the flow context computing a good hash). Did I miss something ?=

 

 

For stitching , I would propose to keep= consistent ELC across LSPs and otherwise break ELC (if some segments are n= ot ELC) and in order to manage non ELC domains/areas, I would encourage to = use tunneling technics (so EL would be safe) and not stitching …=

 

Example :

 

 <= /p>

A ------ (S= 1) ----- B ----- (S2) ------ C ----- (S3) ----- D

 <= /span>

Cons= ider S1,S2,S3 as LSPs being stiched , B does stitching between S1 and D2 an= d C between S2 and S3.

if :

-    = ;      D is ELC for S3

<= ![if !supportLists]>-  =         <= span lang=3DEN style=3D'color:#1F497D'>C is ELC for S3 and S2

-          B is ELC for S2 BUT = NOT for S1

-        = ;  A is not ELC for S1

 

Only A has knowledge of the fl= ow context and can perform a good hashing . If S1 is not ELC, I would propo= se to not use ELI/EL on the all stitched path to D.

But if A may be = ELC2 for segment type of S2, we could imagine to start S2 on A rather than = B and tunnel S2 over S1, so A would be able to use ELI/EL.

&nbs= p;

 

 

Stephane

 =

=  

De : Nobo = Akiya (nobo) [mailto:nobo@cisco.com]
Envoy=E9 : lundi 3 f=E9vrier 2014 16:44
=C0=  : LITKOWSKI Stephane DTF/DERX; draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ie= tf.org
Cc : <= /span>m= pls@ietf.org; draft-ravisingh-mpls-el-for-seamless-mpls@tool= s.ietf.org
Objet = : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels

 = ;

 

Tak= ing the example from draft-ravisingh-mpls-el-for-seamless-mpls …=

 

   &nb= sp;            S1&nb= sp;            =      D1

     =              \&= nbsp;   ---------    /

 &nbs= p;            &= nbsp;    A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE

           &= nbsp;      /    --------- &nbs= p;  \

        = ;        S2     = ;             D= 2

 

   In the above topo= logy, let there be the following LSPs:

 

        L1: B->D

        L3: S1-&= gt;D1, tunneled through LSP L2

    &nb= sp;   L4: S2->D2, tunneled through LSP L2

 

Let’s say:

(1)=     S1 does not push ELI/EL.

(2)    A pushes ELI/EL.

(3)    B does not push ELI/EL, since label stack already contains ELI/EL.

 

Beh= avior so far aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless-mpls= (snippet above). Ideally what should happen is:

 

(4)  &= nbsp; D pops ELI/EL, and pushes (or carries over) EL= I/EL below exposed top label.

[SLI] Why D= pops ELI/EL ? ELI/EL was pushed by A and D is egress of tunnel from B, so = when D receives traffic originally sent by S1, D would pop tunnel label fro= m C (end of L1), and switch tunnel L2 label to E, and only E would see the = ELI/EL

(5)    E pops ELI/EL, and _does not_ push ELI/EL below = exposed top label.

[SLI] Right=

(6)    D1 receives data without any ELI/EL (as expected).

=

 

How does nodes D and = E determine the right behavior?

<= span lang=3DEN-CA style=3D'color:#1F497D;mso-fareast-language:JA'>[SLI] I d= on’t see what’s the issue there … If A pushed ELI, E has = signalled that it was ELC, so E is prepared to receive a packet with ELI/EL= .

 

 

From what I’ve read in = the two drafts, I don’t see how this behavior is determined.

 

= If we ca= n address this issue, I think solution is applicable to Segment Routing lab= el stack with ELI/EL, meaning behavior can apply to solution 3.3 of draft-k= ini-mpls-entropy-label-src-stacked-tunnels.

 

One possibility is to make us= e of TC or TTL of EL to keep track of carry-over number. Meaning:

 

<= span lang=3DEN-CA style=3D'color:#1F497D;mso-fareast-language:JA'>When ELI/= EL is not inserted in a new tunnel because ELI/EL exists in the label stack= , then:

-&nbs= p;         I= ncrement carry-over number.

= -          Move ELI/EL to below top label.

[SLI] You can do it only if the new tunnel endpoint is ELC otherw= ise the router should not do it.

 

When data term= inates a tunnel, then:

-          Decrement carry-over number.

-       &n= bsp;  If (carry-over !=3D 0) re-insert ELI/EL t= o below exposed top label.

 

I’m no hardware expert either, and not sur= e if something like above can be implemented. But if possible, then ELI/EL = pushed in SR network can pre-set carry-over number to certain value to ensu= re it is carried over below top label all the way though, and there is only= one ELI/EL at any given time.

 = ;

All this to say, I think there’s a ben= efit in discussing this topic further, with both drafts in mind.=

 

-Nobo=

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com=
Sent: Friday, January 31, 2014 = 9:12 AM
To: draft-ki= ni-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] draft-kini-mpls-entropy-label-src-stacke= d-tunnels

 

Hi Authors,

=  

&n= bsp;

I would like t= o know if you are progressing on this draft ?

Entropy label support for stacked tunn= els would be mandatory for us, so I would like to support the work on this = topic to have a working solution as soon as possible.

=

 

 

Regarding the solutions you are proposing in the = current version, there is none perfect one, and unfortunately all have draw= backs.

The com= patibility (on LSR) with current generation of hardwares may be “good= ” (mandatory ?) for the target solution.

 

In your document , solution =A73.3 “re-usab= le EL for a stack of tunnels” sounds for me to be the best base idea.= I’m just wondering what would be the hardware impact of doing the re= insertion of ELI at tunnel end . Could this be done in one pass ? (IMHO, th= is may be possible, as today we are able to pop or swap + push FRR headers)= As you are three different vendors as co-author, did you already evaluate = such impact on your hardwares ? (I’m not expecting details on the mai= ling list, but I would be interested by details unicast to me and just yes/= no on the the list)

 

T= o be exhaustive in listing solutions, did you think about leaving the EL/EL= I at top of the stack ? I think there is already a case where a special lab= el may be kept at top of the stack (MPLS Router alert).

What would be needed :

-  &= nbsp;       each hop need to advertise is ability to process EL, if ne= xthop cannot process EL, it should be removed when forwarded to nexthop (th= ere should be the same requirement for re-usable EL)

<= p class=3DMsoNormal>I don’t think this is really d= ifferent from re-usable EL in the concept :

<= ![if !supportLists]>-     &nb= sp;    reu= sable EL : process top level forwarding label, if popped and next label is = EL, pop ELI/EL and next label L, push pack ELI/EL and then L (we need to sw= ap positions between ELI/EL and L) if nexthop is able to process EL.

- &n= bsp;        top level EL : process top level ELI, ELI is recogniz= ed, ELI/EL is removed, forwarding is done on forwarding label, ELI/EL is pu= shed back in nexthop is able to process EL.

 

In term of operations, I think that top level EL m= ay be simpler , but as I’m not hardware coder, may be I’m wrong= … moreover it may be similar to MPLS Router alert processing.

 

 

Your thoughts ?

 

 

Stephane

 

 =

 

_________________=
___________________________________________________________________________=
_____________________________
 
<= pre>Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc
pas etr=
e diffuses, exploites ou copies sans autorisation. Si vous avez recu ce mes=
sage par erreur, veuillez le signaler
a l'expediteur e=
t le detruire ainsi que les pieces jointes. Les messages electroniques etan=
t susceptibles d'alteration,
Orange decline toute resp=
onsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 =

This message and its attachments may c=
ontain confidential or privileged information that may be protected by law;=

they should not be distribu=
ted, used or copied without authorisation.
If you have received this email in error, please notify the =
sender and delete this message and its attachments.
= 
As emails may be altered, Orange is not liable for =
messages that have been modified, changed or falsified.
Thank you.
______________________=
___________________________________________________________________________=
________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810C32CFBAFCPUEXCB2Fnante_-- From huaimo.chen@huawei.com Thu Feb 13 08:33: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 37E061A033E for ; Thu, 13 Feb 2014 08:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 QzHMBxn-PnIY for ; Thu, 13 Feb 2014 08:33:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 10D101A032B for ; Thu, 13 Feb 2014 08:33:25 -0800 (PST) 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 BDO26853; Thu, 13 Feb 2014 16:33:22 +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; Thu, 13 Feb 2014 16:31:53 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 16:32:10 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 08:31:57 -0800 From: Huaimo Chen To: Gregory Mirsky , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: Mail regarding draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac8oSA4xaJC4UUoKSO2rSotsniXi5wAIcZ1A Date: Thu, 13 Feb 2014 16:31:56 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C36EA8@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B7619A2@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7619A2@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.140] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C36EA8SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Mail regarding draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 16:33:30 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C36EA8SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Wednesday, February 12, 2014 6:26 PM To: draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Mail regarding draft-chen-mpls-p2mp-egress-protection Dear Authors, I have couple comments to changes made in version 11 of the document: * Introduction. A statement that e2e may "provide slow fault recove= ry" been added. Of course, if an operator to use slower fault detection and= opt for service restoration rather than protection, then fault recovery wi= ll be slow. But if we to compare apples to apples, then I find this assumpt= ion unsubstantiated and hence don't see enough motivation for the proposed = solution. [Huaimo:] We just compare two types of methods for protecting an egress of = an LSP in section "Introduction". One type of methods is the existing meth= ods that are used for protecting the egress of the LSP. The other is the me= thods proposed in the draft for protecting the egress of the LSP. In your = comment above, you said "But if we to compare apples to apples, then I find= this assumption unsubstantiated and hence don't see enough motivation for = the proposed solution." . Did you want to say "But if you compare apples t= o oranges, then I find this assumption unsubstantiated and hence don't see = enough motivation for the proposed solution."? * Section 1.1 "Exactly how the failure is detected is out of scope = for this document." I agree with this as long as you can demonstrate that e= gress failure can be detected and clearly identified specifically as egress= failure in reasonable time. [Huaimo:] It seems that a similar question is asked and answered in the MPL= S mailing list. Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D445C36EA8SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments!

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Wednesday, February 12, 2014 6:26 PM
To: draft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] Mail regarding draft-chen-mpls-p2mp-egress-protectio= n

 

Dear Authors,

I have couple comments to changes made in version 11= of the document:

·       &= nbsp; Introduction. A statement that e2e ma= y “provide slow fault recovery” been add= ed. Of course, if an operator to use slower fault detection and opt for ser= vice restoration rather than protection, then fault recovery will be slow. But if we to compare apples to apples, then I= find this assumption unsubstantiated and hence don’t see enough moti= vation for the proposed solution.

[H= uaimo:] We just compare two types of methods for protecting an egress of an= LSP in section “Introduction”.  One type of methods is th= e existing methods that are used for protecting the egress of the LSP. The other is the methods proposed in the draft for protecting = the egress of the LSP.  In your comment above, you said “= But if we to compare apples to apples, then I find this assumption unsubstantiated and hence don’t= see enough motivation for the proposed solution.” .  Did you want to say “But if you compar= e apples to oranges, then I find this assumption unsubstantiated and hence don̵= 7;t see enough motivation for the proposed solution.”?<= /p>

 

·         Section 1.1 “Exactly how the failure i= s detected is out of scope for this document.” I agree with this as l= ong as you can demonstrate that egress failure can be detected and clearly = identified specifically as egress failure in reasonable time.

[H= uaimo:] It seems that a similar question is asked and answered in the MPLS = mailing list.  

Ba= sically, the objective of egress protection is to make sure that the data t= raffic flows to its destination in the case that the egress fails. It is ni= ce to have a method to detect the egress failure and clearly identify the failure as egress failure. It seems that = it is not a MUST for us to have this kind of method. As long as the data tr= affic flows to its destination through the use of egress protection when th= e egress fails or some related failures occur, it should be OK.

 

Regards,

    =     Greg

--_000_5316A0AB3C851246A7CA5758973207D445C36EA8SJCEML701CHMchi_-- From nobody Thu Feb 13 11:43: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 C80A31A0415 for ; Thu, 13 Feb 2014 11:43:28 -0800 (PST) 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 afUfnVUaEiVS for ; Thu, 13 Feb 2014 11:43:26 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4F91A03FA for ; Thu, 13 Feb 2014 11:43:26 -0800 (PST) Received: from mail52-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 19:43:24 +0000 Received: from mail52-am1 (localhost [127.0.0.1]) by mail52-am1-R.bigfish.com (Postfix) with ESMTP id 7F721E0CBF for ; Thu, 13 Feb 2014 19:43:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zzc85fh4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz18c673hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail52-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(199002)(189002)(63696002)(76482001)(79102001)(74876001)(76796001)(80022001)(66066001)(65816001)(74706001)(76176001)(76786001)(59766001)(83072002)(56776001)(94316002)(81816001)(81686001)(31966008)(74662001)(51856001)(33646001)(575784001)(47446002)(74502001)(86362001)(95666001)(94946001)(93516002)(46102001)(93136001)(53806001)(77982001)(92566001)(54356001)(54316002)(4396001)(95416001)(15975445006)(47976001)(69226001)(74366001)(49866001)(19580395003)(83322001)(80976001)(47736001)(87266001)(15202345003)(85306002)(74316001)(87936001)(2656002)(81342001)(85852003)(81542001)(50986001)(76576001)(56816005)(90146001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:761AD90E.8CF2D980.B9DD6197.15C48E51.208E9; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail52-am1 (localhost.localdomain [127.0.0.1]) by mail52-am1 (MessageSwitch) id 139232060247539_21919; Thu, 13 Feb 2014 19:43:22 +0000 (UTC) Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.233]) by mail52-am1.bigfish.com (Postfix) with ESMTP id F25384600BC for ; Thu, 13 Feb 2014 19:43:21 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS020.bigfish.com (10.3.207.158) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 19:43:21 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 19:43:18 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 13 Feb 2014 19:43:15 +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.0868.013; Thu, 13 Feb 2014 19:43:15 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Heads-up regarding draft names Thread-Index: Ac8o89PnwKAc4+dfRO+e+/KQBQP4PQ== Date: Thu, 13 Feb 2014 19:43:14 +0000 Message-ID: <75246335303d49cabf5f6c9686ef45c2@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0121F24F22 Content-Type: multipart/alternative; boundary="_000_75246335303d49cabf5f6c9686ef45c2CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rRq61s0L560BkV3825Vh8syKGGc Subject: [mpls] Heads-up regarding draft names X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 19:43:29 -0000 --_000_75246335303d49cabf5f6c9686ef45c2CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Over the next month or so we expect to be polling two documents for WG adop= tion which have very similar names (and some but not all authors and contri= butors in common). The two drafts are: draft-chen-mpls-p2mp-egress-protection draft-chen-mpls-p2mp-ingress-protection The two drafts will be polled separately, although the time frame of the po= lls might overlap. Thus I just thought that I would give a heads-up to take= a close look at the draft name and keep the two separate when reading and = responding to the polls. Thanks, Ross --_000_75246335303d49cabf5f6c9686ef45c2CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Over the next month or so we expect to be polling two documents for WG= adoption which have very similar names (and some but not all authors and c= ontributors in common). The two drafts are:
 
  draft-chen-mpls-p2mp-egress-protection
  draft-chen-mpls-p2mp-ingress-protection
 
The two drafts will be polled separately, although the time frame of t= he polls might overlap. Thus I just thought that I would give a heads-up to= take a close look at the draft name and keep the two separate when reading= and responding to the polls.
 
Thanks, Ross
 
 
 --_000_75246335303d49cabf5f6c9686ef45c2CO2PR05MB636namprd05pro_-- From nobody Thu Feb 13 11:46: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 0AC881A0420 for ; Thu, 13 Feb 2014 11:46:37 -0800 (PST) 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 V586dgcWtWPz for ; Thu, 13 Feb 2014 11:46:33 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 285251A041B for ; Thu, 13 Feb 2014 11:46:33 -0800 (PST) Received: from mail195-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 19:46:31 +0000 Received: from mail195-va3 (localhost [127.0.0.1]) by mail195-va3-R.bigfish.com (Postfix) with ESMTP id CC8943E0210; Thu, 13 Feb 2014 19:46:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zzc85fh4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail195-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(164054003)(199002)(189002)(63696002)(76482001)(79102001)(74876001)(76796001)(80022001)(66066001)(65816001)(74706001)(76176001)(18717965001)(76786001)(59766001)(83072002)(56776001)(94316002)(81816001)(81686001)(31966008)(74662001)(51856001)(33646001)(47446002)(74502001)(86362001)(95666001)(94946001)(93516002)(46102001)(93136001)(53806001)(16236675002)(77982001)(92566001)(54356001)(54316002)(4396001)(95416001)(15975445006)(47976001)(69226001)(74366001)(49866001)(19580395003)(83322001)(19580405001)(80976001)(47736001)(87266001)(15202345003)(85306002)(74316001)(19300405004)(87936001)(2656002)(81342001)(85852003)(81542001)(50986001)(76576001)(56816005)(90146001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:38F27495.9CF29FE1.38D9BDD4.4EEFFE8.2014B; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail195-va3 (localhost.localdomain [127.0.0.1]) by mail195-va3 (MessageSwitch) id 1392320790329105_3965; Thu, 13 Feb 2014 19:46:30 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.249]) by mail195-va3.bigfish.com (Postfix) with ESMTP id 4054030004C; Thu, 13 Feb 2014 19:46:30 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 19:46:29 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 19:46:29 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 13 Feb 2014 19:46:27 +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.0868.013; Thu, 13 Feb 2014 19:46:27 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPRIpPUShY7IUEKfeXCXoUCU4A== Date: Thu, 13 Feb 2014 19:46:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0121F24F22 Content-Type: multipart/alternative; boundary="_000_fb21d3965cc049839cc56ad405a9542bCO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LYv9Hd60cbzg-Rq3wzR-J2H2TIU Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 19:46:37 -0000 --_000_fb21d3965cc049839cc56ad405a9542bCO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_fb21d3965cc049839cc56ad405a9542bCO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_fb21d3965cc049839cc56ad405a9542bCO2PR05MB636namprd05pro_-- From nobody Thu Feb 13 11:59: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 7803F1A040C for ; Thu, 13 Feb 2014 11:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 6SwaTELPKLGP for ; Thu, 13 Feb 2014 11:58:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 072201A0424 for ; Thu, 13 Feb 2014 11:58:55 -0800 (PST) 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 BDO37689; Thu, 13 Feb 2014 19:58:54 +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, 13 Feb 2014 19:57:51 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 19:58:53 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 11:58:40 -0800 From: Huaimo Chen To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPRIpPUShY7IUEKfeXCXoUCU4JqzmThw Date: Thu, 13 Feb 2014 19:58:40 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C36FBE@SJCEML701-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.140] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C36FBESJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Q1ZiF4ga_O4-fjhzRJAXntx17xk Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 19:58:59 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C36FBESJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support! (as an author) Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C36FBESJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support!

(as an author)=

 <= /p>

Best Regards,<= /span>

Huaimo

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 2:46 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C36FBESJCEML701CHMchi_-- From nobody Thu Feb 13 12:34: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 802551A046C for ; Thu, 13 Feb 2014 12:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 lYTr7Y2vR50Q for ; Thu, 13 Feb 2014 12:34:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 082D01A0448 for ; Thu, 13 Feb 2014 12:34:46 -0800 (PST) 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 BBC16922; Thu, 13 Feb 2014 20:34:44 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 20:33:40 +0000 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; Thu, 13 Feb 2014 20:34:42 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 12:34:31 -0800 From: Quintin zhao To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPr+X+P2gAjnWkenXc3Ii5IRsA== Date: Thu, 13 Feb 2014 20:34:30 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C03071CE16@SJCEML701-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.200] 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/OGypCnzG0RfhI5fFmVz0SE7zIrg Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 20:34:49 -0000 Support. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one wee= k (so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and r= esponse around our travel plans and IETF activities. Thanks, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =09 ------------------------------ End of mpls Digest, Vol 118, Issue 37 ************************************* From nobody Thu Feb 13 13:00:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302A81A0283 for ; Thu, 13 Feb 2014 13:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrBzWH61GvT8 for ; Thu, 13 Feb 2014 13:00:54 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5325F1A045B for ; Thu, 13 Feb 2014 13:00:54 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id e16so18776775qcx.35 for ; Thu, 13 Feb 2014 13:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hshTcq+e/M79eP1ogDxjAjLeIcaP46j/LgovNsKw3L0=; b=R/vakzPOLl2mIVeNnBi6/ebi0CeD3j8p+rmRV1ZVmrzDc8U578OOlqd2P7klM6YhAk YpeUZ75O8/LSgcm3YAeS/8U8PoWG/X3AL2EGCffrLljaCjTjHJv3RC7rKbeHcPJQYUyF erQzWclWB/hdrcldWrEmRDXHGO6l1J6yxQwaNO/e6Xs7/B4Opht23+heLe/2IFNQzyQg Hzo7qxuuNLOsMrzAdaD1wai6l84l/+VAPaepTQnA7RP46gp08fqoNc4mLf3JFyUnMvhZ LoLOp7QDdI/v6/sWnJFhDgN7UTjVvA50vFUwXhjbs77AY9hWJbUrIsxlSPMKi/l+Q6p9 9vLw== X-Received: by 10.229.46.70 with SMTP id i6mr6534071qcf.10.1392325252978; Thu, 13 Feb 2014 13:00:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Thu, 13 Feb 2014 13:00:32 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Thu, 13 Feb 2014 16:00:32 -0500 Message-ID: To: Ross Callon Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ttALFVzlt3pMBEKMJURCAfNr3v4 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 21:00:56 -0000 Ross, This draft is already pretty well baked, with 12 revisions, lots of discussion, and an RT review already. It's also very useful functionality. It's long overdue for becoming a WG draft. Cheers, Andy On Thu, Feb 13, 2014 at 2:46 PM, Ross Callon wrote: > This is to start a poll on adopting > draft-chen-mpls-p2mp-egress-protection-11 > > as an MPLS working group document. Since many of us will be in transit to > the > > IETF approximately two weeks from now, I will extent the poll by one week > (so > > that it will be a three week poll). > > > > Please send your comments (support/not support) to the mpls working group > > mailing list (mpls@ietf.org). > > > > This poll will end Friday March 7, 2014. Note that this is the Friday of the > IETF, > > and thus we will each need to plan our review of the document and response > > around our travel plans and IETF activities. > > > > Thanks, Ross > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Thu Feb 13 13:10: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 D35531A0407 for ; Thu, 13 Feb 2014 13:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6LrMh84htf7J for ; Thu, 13 Feb 2014 13:10:47 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 75C6F1A04BF for ; Thu, 13 Feb 2014 13:10:47 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-46-52fd34d224fa Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EE.85.12743.2D43DF25; Thu, 13 Feb 2014 22:10:42 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 16:10:45 -0500 From: Gregory Mirsky To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPRIpPUShY7IUEKfeXCXoUCU4Jqzq88Q Date: Thu, 13 Feb 2014 21:10:45 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B762063eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXSPn+4lk79BBpt22Vh8v7SExeLW0pWs Fn9XXGFxYPZYsuQnk8f1pqvsHl8uf2YLYI7isklJzcksSy3St0vgyujtv8leMMGz4tkElwbG KY5djJwcEgImEi8eHmKHsMUkLtxbz9bFyMUhJHCEUWJyxzRWCGc5o8TnbdvYQKrYBIwkXmzs AesQEXCTmNN/ggnEZhawlbjz5BojiC0s4CHxY/IpJogaT4n9tz5C2UYSD+6tAbNZBFQlJhxp A6vnFfCVmD73CpgtJBAq8aHtPJjNKRAm8X7jMhYQmxHouu+n1kDtEpe49WQ+E8TVAhJL9pxn hrBFJV4+/scKYStK7Oufzg5Rny9xaNkzdohdghInZz5hmcAoOgvJqFlIymYhKYOI60gs2P2J DcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDYxAiPtmASb7g7GPS8tDzFKc7AoifN+ eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoEx79hG5ddGH3IMTJb8a2V7rbdoi7ZcWDvT 1K8nmfeyfqhu6VgdJLTqykd2j+bo0z2cN21LNE5ZbboSbrT3v8dz3g7/znqBw8KTHz1JWRpS qSDAWTDxQ9gE54r9VvtPHt74zTFoV9j+rkOr+UMuLimTf+TvIXFl+T+bvMVXn28OnZIjMmth Q+VaJZbijERDLeai4kQANeCrDIICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/GKHjn3oWd1M_okqF8HAAUGv10hg Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 21:10:50 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B762063eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B762063eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B762063eusaamb103erics_-- From nobody Thu Feb 13 13:38: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 5DC0E1A051C for ; Thu, 13 Feb 2014 13:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 AP8VovT1oro9 for ; Thu, 13 Feb 2014 13:38:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 63F9A1A050A for ; Thu, 13 Feb 2014 13:38:23 -0800 (PST) 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 BBC19619; Thu, 13 Feb 2014 21:38:21 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 21:38:02 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 21:38:20 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 13:38:15 -0800 From: Katherine Zhao To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPRIOj+NdR7l0Ea36ZoqqAu9epqztYNA Date: Thu, 13 Feb 2014 21:38:13 +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.213.50.28] Content-Type: multipart/alternative; boundary="_000_C96C811C9BFA5C4F91E913DA69932F8224761391SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7jCCqXmSpvNnGn-WC-1ml7teNRo Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 21:38:28 -0000 --_000_C96C811C9BFA5C4F91E913DA69932F8224761391SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards, Katherine From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_C96C811C9BFA5C4F91E913DA69932F8224761391SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

Regards,

Katherine

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_C96C811C9BFA5C4F91E913DA69932F8224761391SJCEML701CHMchi_-- From nobody Thu Feb 13 13:39: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 8BBDA1A0564 for ; Thu, 13 Feb 2014 13:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 0cD5BGi_OZpP for ; Thu, 13 Feb 2014 13:39:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C437E1A0563 for ; Thu, 13 Feb 2014 13:39:04 -0800 (PST) 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 BBC19653; Thu, 13 Feb 2014 21:39:02 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 21:37:58 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 21:39:00 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 13:38:50 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQAa29QMy3TZQUa/WtY1/4nJhZqzrkuA Date: Thu, 13 Feb 2014 21:38:49 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.140] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C37048SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HWpEDENymGZOBG707lLLu-DuiVg Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 21:39:10 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C37048SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C37048SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C37048SJCEML701CHMchi_-- From nobody Thu Feb 13 13:48: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 0C4961A0055 for ; Thu, 13 Feb 2014 13:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PmGb2M8m3UD6 for ; Thu, 13 Feb 2014 13:48:33 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id BF03A1A0029 for ; Thu, 13 Feb 2014 13:48:32 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-0c-52fd3db051fc Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D3.EB.11484.0BD3DF25; Thu, 13 Feb 2014 22:48:32 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 16:48:30 -0500 From: Gregory Mirsky To: Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQQErWTRsEe5IUeaVctZClaFmpqztzjw Date: Thu, 13 Feb 2014 21:48:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B762122eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXSPn+4G279BBr+uyVpsfXqF0eL7pSUs FreWrmS1+LviCosDi0fLkbesHkuW/GTyuN50ld3jy+XPbAEsUVw2Kak5mWWpRfp2CVwZL5dM Zyw43stY0X7rIUsD483aLkZODgkBE4k9pxYwQdhiEhfurWfrYuTiEBI4wiixecoeVpCEkMBy Romvnz1AbDYBI4kXG3vYQWwRgTyJ5uf7GUFsZgFbiTtProHZwgKBEtNbr7FB1ARJLLnxgKWL kQPINpL48DsHJMwioCrReeAuWAmvgK/Ev78nmSD2PmWUmDP7AdheToEwiaXLusFsRqDjvp9a wwSxS1zi1pP5UEcLSCzZc54ZwhaVePn4HyuErSixr386O8heZoF8ifOdGRC7BCVOznzCMoFR dBaSSbMQqmYhqYIo0ZFYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGW5iBMbe MQk2xx2MCz5ZHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj2pw3LrvN VpXrHmEOyXxzNtJ65oRrGzmkH3vfSVxyvyKGW6cz70f11Q5zkcOFW402LmOLPbJVelW2CMfF c2aB1jXlC/hevjafsM5hseuxzuxDbI5+y9lEWhNv/HMLtpjy8MGm0y1O2p9K7msIX+iZ/Ku5 PMa8QOZ+9ZQv07ze/H292NTeY9MHJZbijERDLeai4kQA68zy2osCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/DEQ48g1dei7YUrjlVeG-TS509Z0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 21:48:37 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B762122eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B762122eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B762122eusaamb103erics_-- From nobody Thu Feb 13 13:59: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 38AE81A027D for ; Thu, 13 Feb 2014 13:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 qtxBkv2Dxpiq for ; Thu, 13 Feb 2014 13:59:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9C1A0124 for ; Thu, 13 Feb 2014 13:59:45 -0800 (PST) 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 BDO42814; Thu, 13 Feb 2014 21:59:42 +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; Thu, 13 Feb 2014 21:59:22 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 21:59:40 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 13:59:29 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQAa29QMy3TZQUa/WtY1/4nJhZqzrkuAgACQewD//3ofgA== Date: Thu, 13 Feb 2014 21:59:28 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.140] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C37096SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hwBP-aHz-w-orXPqdioU4jw6TDA Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 21:59:50 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C37096SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C37096SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C37096SJCEML701CHMchi_-- From nobody Thu Feb 13 14:09: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 4F4611A020F for ; Thu, 13 Feb 2014 14:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 sPzZ-gtZ7vW1 for ; Thu, 13 Feb 2014 14:09:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E105F1A02B7 for ; Thu, 13 Feb 2014 14:09:50 -0800 (PST) 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 BDO43234; Thu, 13 Feb 2014 22:09:48 +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; Thu, 13 Feb 2014 22:09:29 +0000 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; Thu, 13 Feb 2014 22:09:47 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 14:09:42 -0800 From: Richard Li To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPRIpPUShY7IUEKfeXCXoUCU4JqzvRXA Date: Thu, 13 Feb 2014 22:09:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.72] Content-Type: multipart/alternative; boundary="_000_F061CEB6876F904F8EA6D6B92877731C305BCDEESJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dEtkc9VJ4OC6gVVB5WRg3QVvrog Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 22:09:56 -0000 --_000_F061CEB6876F904F8EA6D6B92877731C305BCDEESJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, This draft documents the result of some elaborated work jointly by people f= rom vendors, operators and academia. In view of its usefulness, its importance and its technical integrity, I su= pport its adoption. Regards, Renwei From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_F061CEB6876F904F8EA6D6B92877731C305BCDEESJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 <= /p>

This draft documents the = result of some elaborated work jointly by people from vendors, operators an= d academia.

 <= /p>

In view of its usefulness= , its importance and its technical integrity, I support its adoption.<= /o:p>

 <= /p>

Regards,

 <= /p>

Renwei<= /p>

 <= /p>

 <= /p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_F061CEB6876F904F8EA6D6B92877731C305BCDEESJCEML701CHMchi_-- From nobody Thu Feb 13 14:38: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 37D1F1A0389; Thu, 13 Feb 2014 14:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6ZT1xguTw29; Thu, 13 Feb 2014 14:38:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D067D1A0006; Thu, 13 Feb 2014 14:38:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213223847.13307.40416.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 14:38:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_nf_xitXnBisQFlg4sZOfvymaXY Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 22:38:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Gap Analysis for Operating IPv6-only MPLS Networks Authors : Wesley George Carlos Pignataro Filename : draft-george-mpls-ipv6-only-gap-04.txt Pages : 25 Date : 2014-02-13 Abstract: This document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS- related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-george-mpls-ipv6-only-gap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-george-mpls-ipv6-only-gap-04 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 Feb 13 15:31: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 B92681A0016 for ; Thu, 13 Feb 2014 15:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gZqV1ai3OacX for ; Thu, 13 Feb 2014 15:31:44 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C50201A007F for ; Thu, 13 Feb 2014 15:31:43 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-6e-52fd55da3f8a Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BE.BB.12743.AD55DF25; Fri, 14 Feb 2014 00:31:38 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 18:31:41 -0500 From: Gregory Mirsky To: Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQQErWTRsEe5IUeaVctZClaFmpqztzjwgABYTAD//8I4UA== Date: Thu, 13 Feb 2014 23:31:41 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7621B6eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPrO6t0L9BBq17jS22Pr3CaPH90hIW i1tLV7Ja/F1xhcWBxaPlyFtWjyVLfjJ5XG+6yu7x5fJntgCWKC6blNSczLLUIn27BK6My2c2 shV8usZYceZfQQPjxv2MXYycHBICJhIrrz1ggbDFJC7cW8/WxcjFISRwhFFidctUdghnOaPE xauv2UGq2ASMJF5s7AGzRQTyJJqfQ0xiFrCVuPPkGpgtLBAoMb31GhtETZDEkhsQG0QEnCQa Oh+A9bIIqEq0vLsMFucV8JU4un49M8Syr0wS+2YcBSviFAiTuL39EjOIzQh03vdTa5gglolL 3HoynwnibAGJJXvOM0PYohIvH/9jhbAVJfb1T2eHqM+XePJjLtQyQYmTM5+wTGAUnYVk1Cwk ZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGBpsYgTF4TIJNdwfj npeWhxilOViUxHm/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBYwG7VEFoSwXvgicLE /mWbDkj8Sto2sdBef3piVGJB2KPgSKU/L/sNTkrH1PRxbJKfc+fWEm5L6ZYMra5Yj42rXUse 3z3rzdS0du1Wuf/bZoX8MX9rt+6hIEd0tcm70Hksh9/pPA+2va9f9md+zFbP4pNljGmW0/6s vW+d5vrzG/eWPy3+NcFKLMUZiYZazEXFiQBVv5LejwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FmpUqwRyY1xuKVih5CmWT1HrZkE Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 13 Feb 2014 23:31:48 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7621B6eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B7621B6eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B7621B6eusaamb103erics_-- From nobody Thu Feb 13 16:04: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 CF0E61A04D8 for ; Thu, 13 Feb 2014 16:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 83OiI1hUEuPU for ; Thu, 13 Feb 2014 16:04:31 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6214C1A04B1 for ; Thu, 13 Feb 2014 16:04:31 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-11-52fd5d89c293 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C5.AC.12743.98D5DF25; Fri, 14 Feb 2014 01:04:25 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 19:04:28 -0500 From: Gregory Mirsky To: Gregory Mirsky , Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQQErWTRsEe5IUeaVctZClaFmpqztzjwgABYTAD//8I4UIAACzHw Date: Fri, 14 Feb 2014 00:04:28 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B762218@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B762218eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPlG5n7N8gg3nvbCy2Pr3CaPH90hIW i1tLV7Ja/F1xhcWBxaPlyFtWjyVLfjJ5XG+6yu7x5fJntgCWKC6blNSczLLUIn27BK6MFWc+ sRe8+8dY0fTuIHMD4+rHjF2MnBwSAiYSW840skPYYhIX7q1nA7GFBI4wSsz4ng5hL2eU6Doh C2KzCRhJvNjYA1TPxSEiMI9R4tTbr2DNzAK2EneeXAMbKiwQKDG99RrYIBGBIIklNx6wQNhu EstXPwSrZxFQlbh49jYriM0r4Ctx9vxBRpChQgI7mSUe75rKDJLgFPCTOPTmAdhQRqDrvp9a wwSxTFzi1pP5TBBXC0gs2XOeGcIWlXj5+B8rhK0osa9/OtRx+RL75n5gglgmKHFy5hOWCYyi s5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0OLUsN93IYBMjMAaP SbDp7mDc89LyEKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhg39RkKzPQz Vapq801cdk3mg9pL85UiS59tWK8uvSO5c2N6eBWTMIfHhakG94JKNE9/PXnIa9kcX613S6et cIwLy+p+LDdzSsGaiiy2U7JC7PrBb7b/kNK2uXp00eEbJmoTfviYu1rrPV1aZfag9dspBleJ hS8+rmJYXJXBPDH5p6vDKXZn0dVKLMUZiYZazEXFiQDoX2u/jwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eFlj6tLivNUgCpkrqoBq1iYxKXs Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 00:04:36 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B762218eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, another question in connection to our discussion: * in authors opinion, is it possible for FRR protection of link bet= ween R3 and L1 (Fig.1) and L1 egress node protection to coexist. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 3:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B762218eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

another question in conne= ction to our discussion:

·      = ;   in authors opinio= n, is it possible for FRR protection of link between R3 and L1 (Fig.1) and = L1 egress node protection to coexist.

 <= /p>

Regards,

        Greg

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 3:32 PM
To: Huaimo Chen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B762218eusaamb103erics_-- From nobody Thu Feb 13 17:11: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 8E2551A0045; Thu, 13 Feb 2014 17:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkZMsqb8mtaT; Thu, 13 Feb 2014 17:11:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7F21A0017; Thu, 13 Feb 2014 17:11:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214011146.27105.98561.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 17:11:46 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/X3pPtMaUFq8P7qFMThDAY3IVRlg Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-node-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 01:11:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : mLDP Node Protection Authors : IJsbrand Wijnands Eric Rosen Kamran Raza Jeff Tantsura Alia Atlas Quintin Zhao Filename : draft-ietf-mpls-mldp-node-protection-01.txt Pages : 16 Date : 2014-02-13 Abstract: This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (MP LSPs) built by LDP ("Label Distribution Protocol"), or simply mLDP. In order to protect a node N, the Point of Local Repair (PLR) LSR of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing P2P LSPs originated from the PLR LSR to the MPT LSRs while bypassing LSR node N. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-node-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-mldp-node-protection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-mldp-node-protection-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 13 19:14: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 5F5FF1A00AF for ; Thu, 13 Feb 2014 19:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, 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 h9l5dFcyYd3D for ; Thu, 13 Feb 2014 19:14:40 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD9E1A003A for ; Thu, 13 Feb 2014 19:14:40 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.83250505; Thu, 13 Feb 2014 22:14:35 -0500 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.36]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 22:14:35 -0500 From: "Toy, Mehmet" To: "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: Ac8pMoGLi9VipXq2Q3SEIpx59uPl/g== Date: Fri, 14 Feb 2014 03:14:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.249] Content-Type: multipart/alternative; boundary="_000_E0CCE9D2B396674BABDD84B7C422BE1C6F5E7B86PACDCEXMB13cabl_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LjzesCFgKNdfuaC3kNhODaHN5ro Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 03:14:42 -0000 --_000_E0CCE9D2B396674BABDD84B7C422BE1C6F5E7B86PACDCEXMB13cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As one of the co-authors, I do support adoption of draft-chen-mpls-p2mp-egr= ess-protection-11. Thanks Mehmet From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_E0CCE9D2B396674BABDD84B7C422BE1C6F5E7B86PACDCEXMB13cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As one of the co-authors,= I do support adoption of draft-chen-mpls-p2mp-egress-protection-11.

Thanks<= /p>

Mehmet<= /p>

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 2:46 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_E0CCE9D2B396674BABDD84B7C422BE1C6F5E7B86PACDCEXMB13cabl_-- From nobody Thu Feb 13 19:55:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4111A002E for ; Thu, 13 Feb 2014 19:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrB5ptbaSEY2 for ; Thu, 13 Feb 2014 19:55:42 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CA1B61A002C for ; Thu, 13 Feb 2014 19:55:42 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id to1so7153700ieb.0 for ; Thu, 13 Feb 2014 19:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WSC9U+3qp+R21ejjvu0zZ2fCXq5Nfd6sTkQuvNiCsnk=; b=GVJUSVYNp/MMlN27mlw5p3ME0zDSn+wiCCKwNlvwaNXk/nrpaskk82Eezala+DyAh9 rBP1qwg9SYhhLkFyovuMIGVkRUanuJvP+3zbtfXi6gZlGX58m09OuTnn4+6VzMfL62Yg gFWit41a2whTEvhIlhOCsOqnUZ2AVmQYu765PKgw5igNb9IDjuF3ae/dMmNHUi+3M0W9 Wv70q4j27A+RQiVDRBVaT40V+32L491BJ96eO616G3liHVZCXxwa/uHrSkkWFzYYbU7O kYc+B1ro3wwcUgyNvUolvRLap8pKQb54WdmoSI+XHVNNcfkt/QAFgdf/sCegl/rG5+PM it3w== MIME-Version: 1.0 X-Received: by 10.50.122.8 with SMTP id lo8mr459206igb.31.1392350141416; Thu, 13 Feb 2014 19:55:41 -0800 (PST) Received: by 10.50.160.231 with HTTP; Thu, 13 Feb 2014 19:55:41 -0800 (PST) Received: by 10.50.160.231 with HTTP; Thu, 13 Feb 2014 19:55:41 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Feb 2014 09:25:41 +0530 Message-ID: From: Dhruv Dhody To: Ross Callon Content-Type: multipart/alternative; boundary=089e015384fe95705e04f255c7f2 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4EEh5FOVUjyelcCNeBVgEIlZ_zw Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 03:55:45 -0000 --089e015384fe95705e04f255c7f2 Content-Type: text/plain; charset=ISO-8859-1 Support!! This I.D. is in good place to be a adopted by the working group. Regards, Dhruv On Feb 14, 2014 1:16 AM, "Ross Callon" wrote: > This is to start a poll on adopting > draft-chen-mpls-p2mp-egress-protection-11 > > as an MPLS working group document. Since many of us will be in transit to > the > > IETF approximately two weeks from now, I will extent the poll by one week > (so > > that it will be a three week poll). > > > > Please send your comments (support/not support) to the mpls working group > > mailing list (mpls@ietf.org). > > > > This poll will end Friday March 7, 2014. Note that this is the Friday of > the IETF, > > and thus we will each need to plan our review of the document and response > > around our travel plans and IETF activities. > > > > Thanks, Ross > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --089e015384fe95705e04f255c7f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Support!!

This I.D. is in good place to be a adopted by the working gr= oup.

Regards,
Dhruv

On Feb 14, 2014 1:16 AM, "Ross Callon"= <rcallon@juniper.net> wro= te:

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

=A0

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

mailing list (mpls@ietf.org).

=A0

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

=A0

Thanks, Ross

=A0


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

--089e015384fe95705e04f255c7f2-- From nobody Thu Feb 13 22:44: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 1C34A1A0116 for ; Thu, 13 Feb 2014 22:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 f0kGMgGdaAAL for ; Thu, 13 Feb 2014 22:44:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 236761A0111 for ; Thu, 13 Feb 2014 22:44:26 -0800 (PST) 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 BBC46751; Fri, 14 Feb 2014 06:44:25 +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; Fri, 14 Feb 2014 06:44:02 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 06:44:21 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 14:44:14 +0800 From: Lizhenbin To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPRIpPUShY7IUEKfeXCXoUCU4Jq0SZfg Date: Fri, 14 Feb 2014 06:44:14 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EB0AA@nkgeml506-mbx.china.huawei.com> References: 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.76.77] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081EB0AAnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0a4BUd2rNT4agBFhod4Ho3nHGqY Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogUG9sbCBmb3IgQWRvcHRpb24gZHJhZnQtY2hl?= =?gb2312?b?bi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb24tMTE=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 06:44:30 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081EB0AAnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyB0aGUgY29udHJpYnV0b3IuDQoNClRoZSBkcmFmdCBpcyBtYXR1cmUgYWZ0ZXIg YSBsb25nLXRlcm0gd29yay4gV2UgYWxzbyBpbXBsZW1lbnRlZCB0aGUgcHJvdG90eXBlIHRvIHZl cmlmeSB0aGUgc29sdXRpb24uIEluIFAyTVAgTVBMUyBhbmQgQkdQLWJhc2VkIE1WUE4gc29sdXRp b25zLCByZWxpYWJpbGl0eSBpcyBhbiBpbXBvcnRhbnQgcmVxdWlyZW1lbnQuIElmIHRoZSBlbmQt dG8tZW5kIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBhcmUgYWRvcHRlZCwgdGhhdCBpcywgdHdvIFAy TVAgdHVubmVsIGFyZSBzZXQgdXAgZm9yIDE6MSBvciAxKzEgcHJvdGVjdGlvbiwgc29tZSB1c2Vy cyBhbHdheXMgY29uY2VybnMgdGhhdCB0aGVyZSB3aWxsIGJlIGR1cGxpY2F0ZWQgdHJhZmZpYyBz cGFubmluZyB0aGUgd2hvbGUgbmV0d29yayBhbmQgaXQgd2lsbCBjYXVzZSB0aGUgYmFuZHdpZHRo IHdhc3RlLiBTbyB0aGUgbG9jYWwgcHJvdGVjdGlvbiBtZWNoYW5pc20gaXMgb2YgbXVjaCBpbXBv cnRhbmNlIHRvIGNvcGUgd2l0aCBzdWNoIGNvbmNlcm5zIGluIHRoZSBhY3R1YWwgZGVwbG95bWVu dC4gSSBzaW5jZXJlbHkgaG9wZSB0aGUgZHJhZnQgY2FuIGJlIGFkb3B0ZWQgYnkgV0cuDQoNCg0K QmVzdCBSZWdhcmRzLA0KUm9iaW4NCg0KDQq3orz+yMs6IG1wbHMgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gUm9zcyBDYWxsb24NCreiy83KsbzkOiAyMDE0xOoy1MIxNMjVIDM6 NDYNCsrVvP7IyzogbXBsc0BpZXRmLm9yZw0Ks63LzTogbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmcNCtb3zOI6IFttcGxzXSBQb2xsIGZvciBBZG9wdGlvbiBkcmFmdC1jaGVuLW1wbHMtcDJtcC1l Z3Jlc3MtcHJvdGVjdGlvbi0xMQ0KDQpUaGlzIGlzIHRvIHN0YXJ0IGEgcG9sbCBvbiBhZG9wdGlu ZyBkcmFmdC1jaGVuLW1wbHMtcDJtcC1lZ3Jlc3MtcHJvdGVjdGlvbi0xMQ0KYXMgYW4gTVBMUyB3 b3JraW5nIGdyb3VwIGRvY3VtZW50LiBTaW5jZSBtYW55IG9mIHVzIHdpbGwgYmUgaW4gdHJhbnNp dCB0byB0aGUNCklFVEYgYXBwcm94aW1hdGVseSB0d28gd2Vla3MgZnJvbSBub3csIEkgd2lsbCBl eHRlbnQgdGhlIHBvbGwgYnkgb25lIHdlZWsgKHNvDQp0aGF0IGl0IHdpbGwgYmUgYSB0aHJlZSB3 ZWVrIHBvbGwpLg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBw b3J0KSB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwDQptYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+KS4NCg0KVGhpcyBwb2xsIHdpbGwgZW5kIEZyaWRheSBN YXJjaCA3LCAyMDE0LiBOb3RlIHRoYXQgdGhpcyBpcyB0aGUgRnJpZGF5IG9mIHRoZSBJRVRGLA0K YW5kIHRodXMgd2Ugd2lsbCBlYWNoIG5lZWQgdG8gcGxhbiBvdXIgcmV2aWV3IG9mIHRoZSBkb2N1 bWVudCBhbmQgcmVzcG9uc2UNCmFyb3VuZCBvdXIgdHJhdmVsIHBsYW5zIGFuZCBJRVRGIGFjdGl2 aXRpZXMuDQoNClRoYW5rcywgUm9zcw0KDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081EB0AAnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support as= the contributor.

 = ;

The draft = is mature after a long-term work. We also implemented the prototype to veri= fy the solution. In P2MP MPLS and BGP-based MVPN solutions, reliability is an important requirement. If the end-to-end protection mech= anisms are adopted, that is, two P2MP tunnel are set up for 1:1 or 1+1 = protection, some users always concerns that there will be duplicated traffi= c spanning the whole network and it will cause the bandwidth waste. So the local protection mechanism is of mu= ch importance to cope with such concerns in the actual deployment. I sincer= ely hope the draft can be adopted by WG.

 = ;

 = ;

Best Regar= ds,

Robin=

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: mpls [m= ailto:mpls-bounces@ietf.org] =B4=FA= =B1=ED Ross Callon
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C214=C8=D5 3:46
=CA=D5=BC=FE=C8=CB: mpls@ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

 

This is to start a poll = on adopting draft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group= document. Since many of us will be in transit to the

IETF approximately two w= eeks from now, I will extent the poll by one week (so

that it will be a three = week poll).

 =

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

mailing list (mpls@ietf.org).

 =

This poll will end Frida= y March 7, 2014. Note that this is the Friday of the IETF,

and thus we will each ne= ed to plan our review of the document and response

around our travel plans = and IETF activities.

 =

Thanks, Ross<= /span>

 =

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081EB0AAnkgeml506mbxchi_-- From nobody Fri Feb 14 03:21:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DF21A01ED for ; Fri, 14 Feb 2014 03:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZaG4l2ND5HX for ; Fri, 14 Feb 2014 03:21:00 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0360E1A01BB for ; Fri, 14 Feb 2014 03:20:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1WEGp6-0000LI-J6 for mpls@ietf.org; Fri, 14 Feb 2014 13:20:48 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Fri, 14 Feb 2014 13:20:44 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140213223847.13307.40416.idtracker@ietfa.amsl.com> In-Reply-To: <20140213223847.13307.40416.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart16388875.CYhk7hAKTA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201402141320.47691.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CXG-MvbGOvxLH7w16op9IgEjH98 Subject: Re: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 11:21:03 -0000 --nextPart16388875.CYhk7hAKTA Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glad to see this work getting a lot more attention, as it is=20 one concern of mine as an operator. Just a few comments, for my own clarity: 1. This document focuses on a single-stack IPv6 backbone, but for practical operations as well, I think it might be necessary to look at dual - stack scenarios as well, where a an operator would like to transport both IPv4 and IPv6 over an MPLS network, but natively for each protocol. I concede that this may have to be done in another document. 2. Section 3.2.3.1 (IGP) speaks to OSPFv2. Not sure why given OSPFv2 does not support IPv6. 3. Curious why section 3.3.2.4.3 (PE-PE Multicast Routing Protocol) out of scope for this gap analysis. 4. While work is still ongoing for Segment Routing, perhaps it might be good to make a reference to it like you did for EVPN. Cheers, Mark. On Friday, February 14, 2014 12:38:47 AM internet- drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item > of the Multiprotocol Label Switching Working Group of > the IETF. >=20 > Title : Gap Analysis for Operating > IPv6-only MPLS Networks Authors : Wesley George > Carlos Pignataro > Filename : draft-george-mpls-ipv6-only- gap-04.txt > Pages : 25 > Date : 2014-02-13 >=20 > Abstract: > This document reviews the MPLS protocol suite in the > context of IPv6 and identifies gaps that must be > addressed in order to allow MPLS- related protocols and > applications to be used with IPv6-only networks. This > document is not intended to highlight a particular > vendor's implementation (or lack thereof) in the context > of IPv6-only MPLS functionality, but rather to focus on > gaps in the standards defining the MPLS suite. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-george-mpls-ipv6-o > nly-gap/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-george-mpls-ipv6-only-ga > p-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-george-mpls-ipv6-o > nly-gap-04 >=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 --nextPart16388875.CYhk7hAKTA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJS/fwPAAoJEGcZuYTeKm+GfY0P/R4Db2YOv42aIemJq00L4LFH 3Wd7GGprXS1ZnnHXKgcN9L//QnWAvlMjMoqNHumHMaLM3zFrI/padA7BVja4Ivx4 0a1Lw8yaKTT2gwmhiBsbnzKNS7ohNlCAndhKJ6amnNyywyA7n97z1sx4Xg3rc+Ml qjIoc5wp5LTr9NZ5PiHGo0PEt216mhGgrSK6WySoaO3QnOv3teA+0oeyqNGfqYpo lhdIk1T+hFNFkHmVP0kHhwy7US80wypR24yC3UnvPFycpmDdTj3SRM8aVj4j4/oF h3uswMBC3QCke4Ztj/kykbOK7aK1SVKAtCBFAyrgoMaSsrjfJuwrndXXmTaNwYkm JzOINQBawls8obEsVRDqG4kZ5u99LRjucC2WhXIhDrFxKf54yVoZd59nPq6ORr6R uc0dbGq8LxDBNC90D/M1Fqq0Qa4NuK0qy2DyH0VogHkr33H9DMwsKEOZInbEpeNT WbxtyJ6XdVndKCPfgKiLUJaM0ZdqVAbYDxHIOtsPw2dBRQdWUI96F3/PpQ3brtUG CXDYlrEKHpYmII3/fMU4Dsq2CHhD7HGwnYsqwhzc5GDvr4hKaF8eHjTVGHTh2iyK HVNLkxaumW1Spt9NRE2JK6u/qsNPbyLFPmJmxfg74XeaTcLuLAo8gMHoYa5skZSR 0kUqOei1117lA49+bqsV =xPpP -----END PGP SIGNATURE----- --nextPart16388875.CYhk7hAKTA-- From nobody Fri Feb 14 03:41: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 83D501A01AD for ; Fri, 14 Feb 2014 03:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.548, 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 7l2TcInGVKEE for ; Fri, 14 Feb 2014 03:41:09 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 461C21A00FB for ; Fri, 14 Feb 2014 03:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77853; q=dns/txt; s=iport; t=1392378067; x=1393587667; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Hcbhuqj/p/I6SdoB8+z5SRWCennus10Ci+BFp7aXAu0=; b=AZ5iexfNYDa9ZFvdfFGweMCC0jydAPajTbzffhbdUgegE4DMTcD47omN yq08PNrSyBuF1fARtYn1zdJAqimxJbOQ6c5Ah1nEV6s/t/g8m6FPLhvVr eUszOMJpG16c8MW+G5EsI4u2H4S2RmI+7fMZupEjwfu3apMJ2WPqQUJaY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAGAA/lKtJV2d/2dsb2JhbABZgkIjIThXvzKBFxZ0giUBAQEEGg0GOgQDCxACAQgRBAEBCxYBAgQHMhQJCAEBBA4FCBOHagHJABeOFgERAR8GByQGAQIEgx6BFASJEIszlgyBb4E+gXE5 X-IronPort-AV: E=Sophos; i="4.95,844,1384300800"; d="scan'208,217"; a="20449151" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 14 Feb 2014 11:41:05 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1EBf5iS008641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 11:41:05 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 05:41:04 -0600 From: "Nobo Akiya (nobo)" To: "stephane.litkowski@orange.com" , "draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org" Thread-Topic: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-mpls Thread-Index: Ac8o0o1+XpQwCtjuRh6vpvFWMgLyVgAo4LTQ Date: Fri, 14 Feb 2014 11:41:04 +0000 Message-ID: References: <10973_1392307304_52FCEC68_10973_2075_1_EEE55384044474429A926C625D0FCC810C32CFBAFC@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <10973_1392307304_52FCEC68_10973_2075_1_EEE55384044474429A926C625D0FCC810C32CFBAFC@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.232.3] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DF6A73Fxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7Hw0L_1NxhM5zsoYrt1Cne5oI1M Cc: "mpls@ietf.org" , "draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org" Subject: Re: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-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: Fri, 14 Feb 2014 11:41:15 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DF6A73Fxmbalnx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephane, Authors, et al, Please see in-line with [NOBO]. From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Thursday, February 13, 2014 11:02 AM To: Nobo Akiya (nobo); draft-kini-mpls-entropy-label-src-stacked-tunnels@to= ols.ietf.org Cc: mpls@ietf.org; draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org Subject: RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & dra= ft-ravisingh-mpls-el-for-seamless-mpls Hi Nobo and both draft Authors, Thanks for pointing this draft as reference also, I agree that solution nee= d to be consistent. [NOBO] Yeah, this is a very tricky topic and can benefit from more discussi= ons. Some inline comments as well as added comments on draft-ravisingh-mpls-el-f= or-seamless-mpls : =B7 Section 5.2.2.1 : b. Notional ingress behavior: When L1 does not intrinsically support ELC and L2 does, then the stitching point router must POP the incoming label, insert (ELI+EL) before PUSHing the label for the LSP segment L2. The label operations performed would be: POP(IncomingLabel), PUSH(EL), PUSH(ELI), PUSH(OutgoingLabel), or SWAP(EL), PUSH(ELI), PUSH(OutgoingLabel) The issue I see here, is that the stitching point acting as= notional ingress need to perform Deep Packet Inspection in order to comput= e EL value, but it has no knowledge of what is transported and moreover due= to usage of hierarchy the payload may be quite far ... IMHO, it may not be= a good idea to let a router not having the flow context computing an EL va= lue otherwise we are loosing some of the EL value added ... (Ingress that = have the flow context computing a good hash). Did I miss something ? For stitching , I would propose to keep consistent ELC across LSPs and othe= rwise break ELC (if some segments are not ELC) and in order to manage non E= LC domains/areas, I would encourage to use tunneling technics (so EL would = be safe) and not stitching ... Example : A ------ (S1) ----- B ----- (S2) ------ C ----- (S3) ----- D Consider S1,S2,S3 as LSPs being stiched , B does stitching between S1 and D= 2 and C between S2 and S3. if : - D is ELC for S3 - C is ELC for S3 and S2 - B is ELC for S2 BUT NOT for S1 - A is not ELC for S1 Only A has knowledge of the flow context and can perform a good hashing . I= f S1 is not ELC, I would propose to not use ELI/EL on the all stitched path= to D. But if A may be ELC2 for segment type of S2, we could imagine to start S2 o= n A rather than B and tunnel S2 over S1, so A would be able to use ELI/EL. [NOBO] I agree that EL benefit is best achieved with what you described. Ul= timately, I think things will depend on the intelligence at B. Is S2 only b= eing used as a stitching LSP with S1? If yes, then it is possible to do no-= op as far as ELI/EL imposition is concerned. If no, then B would need to de= termine if traffic came out from S1 or from elsewhere, in order to determin= e whether to take no-op approach or impose ELI/EL. Stephane De : Nobo Akiya (nobo) [mailto:nobo@cisco.com] Envoy=E9 : lundi 3 f=E9vrier 2014 16:44 =C0 : LITKOWSKI Stephane DTF/DERX; draft-kini-mpls-entropy-label-src-stacke= d-tunnels@tools.ietf.org Cc : mpls@ietf.org; draft-ravisingh-mpls-el-for-seaml= ess-mpls@tools.ietf.org Objet : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Taking the example from draft-ravisingh-mpls-el-for-seamless-mpls ... S1 D1 \ --------- / A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE / --------- \ S2 D2 In the above topology, let there be the following LSPs: L1: B->D L2: A->E, tunneled through LSP L1 L3: S1->D1, tunneled through LSP L2 L4: S2->D2, tunneled through LSP L2 Let's say: (1) S1 does not push ELI/EL. (2) A pushes ELI/EL. (3) B does not push ELI/EL, since label stack already contains ELI/EL. Behavior so far aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless-m= pls (snippet above). Ideally what should happen is: (4) D pops ELI/EL, and pushes (or carries over) ELI/EL below exposed top= label. [SLI] Why D pops ELI/EL ? ELI/EL was pushed by A and D is egress of tunnel = from B, so when D receives traffic originally sent by S1, D would pop tunne= l label from C (end of L1), and switch tunnel L2 label to E, and only E wou= ld see the ELI/EL (5) E pops ELI/EL, and _does not_ push ELI/EL below exposed top label. [SLI] Right (6) D1 receives data without any ELI/EL (as expected). How does nodes D and E determine the right behavior? [SLI] I don't see what's the issue there ... If A pushed ELI, E has signall= ed that it was ELC, so E is prepared to receive a packet with ELI/EL. [NOBO] Sorry, I sort of skipped few explanations. What I meant to say was t= hat, if label stack of can get "popped" to (3.= 3 from draft-kini-mpls-entropy-label-src-stacked-tunnels), then two behavio= rs are possible. 1. gets "popped" to - 3.3 from draft-kini= -mpls-entropy-label-src-stacked-tunnels. 2. gets "popped" to - more traditional way. What is ambiguous is, how does an LSR determine whether to apply (1) or (2)= . What I also meant to say was, if we are going to discuss behavior of (1),= then similar push behavior of (1) should be discussed. Meaning, if LSP1 is= tunneled over LSP2, then: 3. becomes - opposite of 3.3 fro= m draft-kini-mpls-entropy-label-src-stacked-tunnels. 4. becomes< LSP2, LSP1, ELI, EL> - more traditional wa= y. Now applying the example from above: a) S1 does not push ELI/EL: label stack =3D b) A pushes ELI, EL: label stack =3D c) B does not push ELI, EL, since label stack already contains ELI/EL = but moves ELI/EL to below top label: label stack =3D d) D pops B, ELI, EL and moves ELI/EL below exposed top label: label s= tack =3D e) E pops A, ELI, EL and _somehow knows_ not to move ELI/EL to below t= op label: f) D1 receives data without any ELI/EL. In this example, node D needs to know that it needs to apply behavior (1) a= nd node E needs to know that it needs to apply behavior (2) ... but how!? T= here may be ways for node D/E to know ELC for further upstreams/downstreams= , but ELC doesn't necessary mean ELI/EL is always pushed. -Nobo >From what I've read in the two drafts, I don't see how this behavior is det= ermined. If we can address this issue, I think solution is applicable to Segment Rou= ting label stack with ELI/EL, meaning behavior can apply to solution 3.3 of= draft-kini-mpls-entropy-label-src-stacked-tunnels. One possibility is to make use of TC or TTL of EL to keep track of carry-ov= er number. Meaning: When ELI/EL is not inserted in a new tunnel because ELI/EL exists in the la= bel stack, then: - Increment carry-over number. - Move ELI/EL to below top label. [SLI] You can do it only if the new tunnel endpoint is ELC otherwise the ro= uter should not do it. When data terminates a tunnel, then: - Decrement carry-over number. - If (carry-over !=3D 0) re-insert ELI/EL to below exposed top label= . I'm no hardware expert either, and not sure if something like above can be = implemented. But if possible, then ELI/EL pushed in SR network can pre-set = carry-over number to certain value to ensure it is carried over below top l= abel all the way though, and there is only one ELI/EL at any given time. All this to say, I think there's a benefit in discussing this topic further= , with both drafts in mind. -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@o= range.com Sent: Friday, January 31, 2014 9:12 AM To: draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Hi Authors, I would like to know if you are progressing on this draft ? Entropy label support for stacked tunnels would be mandatory for us, so I w= ould like to support the work on this topic to have a working solution as s= oon as possible. Regarding the solutions you are proposing in the current version, there is = none perfect one, and unfortunately all have drawbacks. The compatibility (on LSR) with current generation of hardwares may be "goo= d" (mandatory ?) for the target solution. In your document , solution =A73.3 "re-usable EL for a stack of tunnels" so= unds for me to be the best base idea. I'm just wondering what would be the = hardware impact of doing the reinsertion of ELI at tunnel end . Could this = be done in one pass ? (IMHO, this may be possible, as today we are able to = pop or swap + push FRR headers) As you are three different vendors as co-au= thor, did you already evaluate such impact on your hardwares ? (I'm not exp= ecting details on the mailing list, but I would be interested by details un= icast to me and just yes/no on the the list) To be exhaustive in listing solutions, did you think about leaving the EL/E= LI at top of the stack ? I think there is already a case where a special la= bel may be kept at top of the stack (MPLS Router alert). What would be needed : - each hop need to advertise is ability to process EL, if nexthop ca= nnot process EL, it should be removed when forwarded to nexthop (there shou= ld be the same requirement for re-usable EL) I don't think this is really different from re-usable EL in the concept : - reusable EL : process top level forwarding label, if popped and ne= xt label is EL, pop ELI/EL and next label L, push pack ELI/EL and then L (w= e need to swap positions between ELI/EL and L) if nexthop is able to proces= s EL. - top level EL : process top level ELI, ELI is recognized, ELI/EL is= removed, forwarding is done on forwarding label, ELI/EL is pushed back in = nexthop is able to process EL. In term of operations, I think that top level EL may be simpler , but as I'= m not hardware coder, may be I'm wrong ... moreover it may be similar to MP= LS Router alert processing. Your thoughts ? Stephane ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CECE764681BE964CBE1DFF78F3CDD3941DF6A73Fxmbalnx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stephane,= Authors, et al,

 <= /o:p>

Please see i= n-line with [NOBO].

 

steph= ane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Thursday, February 13, 2014 11:02 AM
To: Nobo Akiya (nobo); draft-kini-mpls-entropy-label-src-stacked-tun= nels@tools.ietf.org
Cc: mpls@ietf.org; draft-ravisingh-mpls-el-for-seamless-mpls@tools.i= etf.org
Subject: RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnel= s & draft-ravisingh-mpls-el-for-seamless-mpls

 

Hi Nobo= and both draft Authors,

&n= bsp;

Thanks = for pointing this draft as reference also, I agree that solution need to be= consistent.

 

[NOBO] Yeah, this is a very tricky topic and can benefit from more discu= ssions.

 

Some in= line comments as well as added comments on draft-ravising= h-mpls-el-for-seamless-mpls :

 

=B7     &= nbsp;  Section 5.2.2.1 :

 

        b. Notional ingress= behavior:

           W= hen L1 does not intrinsically support ELC and L2 does, then the<= /span>

           s= titching point router must POP the incoming label, insert=

           (= ELI+EL) before PUSHing the label for the LSP segment L2.

 

           T= he label operations performed would be:

          &n= bsp; POP(IncomingLabel), PUSH(EL), PUSH(ELI), PUSH(OutgoingLabel),

          &n= bsp;            = ; or

          &n= bsp; SWAP(EL), PUSH(ELI), PUSH(OutgoingLabel)

 = ;

 &nbs= p;            &= nbsp; The issue I see here, is that the stitching point acting as notional = ingress need to perform Deep Packet Inspection in order to compute EL value= , but it has no knowledge of what is transported and moreover due to usage of hierarchy the payload may be quite far …= ; IMHO, it may not be a good idea to let a router not having the flow conte= xt computing an EL value otherwise we are loosing some of the EL  valu= e added … (Ingress that have the flow context computing a good hash). Did I miss something ?

 = ;

 = ;

For stitch= ing , I would propose to keep consistent ELC across LSPs and otherwise brea= k ELC (if some segments are not ELC) and in order to manage non ELC domains= /areas, I would encourage to use tunneling technics (so EL would be safe) and not stitching …=

 = ;

Example :<= o:p>

 = ;

 = ;

A ------ (= S1) ----- B ----- (S2) ------ C ----- (S3) ----- D

 = ;

Consider S= 1,S2,S3 as LSPs being stiched , B does stitching between S1 and D2 and C be= tween S2 and S3.

if :<= /o:p>

-        D = is ELC for S3

-        C = is ELC for S3 and S2

-        B = is ELC for S2 BUT NOT for S1

-        A = is not ELC for S1

 = ;

Only A has= knowledge of the flow context and can perform a good hashing . If S1 is no= t ELC, I would propose to not use ELI/EL on the all stitched path to D.

But if A m= ay be ELC2 for segment type of S2, we could imagine to start S2 on A rather= than B and tunnel S2 over S1, so A would be able to use ELI/EL.=

 = ;

= [NOBO] I agree that EL benefit is best achieved with what you described. Ul= timately, I think things will depend on the intelligence at B. Is S2 only b= eing used as a stitching LSP with S1? If yes, then it is possible to do no-op as far as ELI/EL imposition is con= cerned. If no, then B would need to determine if traffic came out from S1 o= r from elsewhere, in order to determine whether to take no-op approach or i= mpose ELI/EL.

&n= bsp;

Stephan= e

&n= bsp;

&n= bsp;

N= obo Akiya (nobo) [mailto:nobo@cisco.com]
Envoy=E9 : lundi 3 f=E9vrier 2014 16:44
=C0 : LITKOWSKI Stephane DTF/DERX; draft-kini-mpls-en= tropy-label-src-stacked-tunnels@tools.ietf.org
Cc : mpls@ietf.org= ; draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org
Objet : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tu= nnels

 

 

Taking the example from draft-ravisingh-mpls-el-for-seamless-mpls …=

 

 = ;            &n= bsp;  S1          &n= bsp;       D1

 = ;            &n= bsp;    \    ---------    /

 = ;            &n= bsp;     A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=

 = ;            &n= bsp;    /    ---------    \

 = ;            &n= bsp;  S2          &n= bsp;       D2

=  

 = ;  In the above topology, let there be the following LSPs:<= /span>

=  

 = ;       L1: B->D

 = ;       L2: A->E, tunneled through LSP L1<= o:p>

 = ;       L3: S1->D1, tunneled through LSP L= 2

 = ;       L4: S2->D2, tunneled through LSP L= 2

 

Let’s say:

(1)    S1 does not push ELI/EL.

(2)    A pushes ELI/EL.

(3)    B does not push ELI/EL, since label stack already contains ELI/EL= .

 

Behavior so far aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless= -mpls (snippet above). Ideally what should happen is:

 

(4)    D pops ELI/EL, and pushes (or carries over) ELI/EL below exposed = top label.

[SLI] Why D pops ELI/EL ? ELI/EL was pushed by A and D is egress of tunne= l from B, so when D receives traffic originally sent by S1, D would pop tun= nel label from C (end of L1), and switch tunnel L2 label to E, and only E would see the ELI/EL

(5)    E pops ELI/EL, and _does not_ push ELI/EL below exposed to= p label.

[SLI] Right

(6)    D1 receives data without any ELI/EL (as expected).

 

How does nodes D and E determine the right behavior?

[SLI] I don’t see what’s the issue there … If A pushed = ELI, E has signalled that it was ELC, so E is prepared to receive a packet = with ELI/EL.

 

[NOBO] Sorry= , I sort of skipped few explanations. What I meant to say was that, if labe= l stack of <x, ELI, EL, y> can get “popped” to <y, ELI= , EL> (3.3 from draft-kini-mpls-entropy-label-src-stacked-tunnels), then two behaviors are possible.

1.      <= x, ELI, EL, y> gets “popped” to <y, ELI, EL> - 3.3 fro= m draft-kini-mpls-entropy-label-src-stacked-tunnels.

2.      <= x, ELI, EL, y> gets “popped” to <y> - more traditional= way.

What is ambi= guous is, how does an LSR determine whether to apply (1) or (2). What I als= o meant to say was, if we are going to discuss behavior of (1), then simila= r push behavior of (1) should be discussed. Meaning, if LSP1 is tunneled over LSP2, then:

3.      <= LSP1, ELI, EL> becomes <LSP2, ELI, EL, LSP1> - opposite of 3.3 fro= m draft-kini-mpls-entropy-label-src-stacked-tunnels.

4.      <= LSP1, ELI, EL> becomes< LSP2, LSP1, ELI, EL> - more traditional wa= y.

Now applying= the example from above:

 <= /o:p>

a)      S1 d= oes not push ELI/EL: label stack =3D <S1>

b)      A pu= shes ELI, EL: label stack =3D <A, ELI, EL, S1>

c)      B do= es not push ELI, EL, since label stack already contains ELI/EL but moves EL= I/EL to below top label: label stack =3D <B, ELI, EL, A, S1>

d)      D po= ps B, ELI, EL and moves ELI/EL below exposed top label: label stack =3D <= ;A, ELI, EL, S1>

e)      E po= ps A, ELI, EL and _somehow knows_ not to move ELI/EL to below top la= bel: <S1>

f)       D1 r= eceives data without any ELI/EL.

 <= /o:p>

In this exam= ple, node D needs to know that it needs to apply behavior (1) and node E ne= eds to know that it needs to apply behavior (2) … but how!? There may= be ways for node D/E to know ELC for further upstreams/downstreams, but ELC doesn’t necessary mean ELI/EL is alwa= ys pushed.

 <= /o:p>

-Nobo

 <= /o:p>

 

From what I’ve read in the two drafts, I don’t see how this b= ehavior is determined.

 

If we can address this issue, I think solution is applicable to Segment R= outing label stack with ELI/EL, meaning behavior can apply to solution 3.3 = of draft-kini-mpls-entropy-label-src-stacked-tunnels.

 

One possibility is to make use of TC or TTL of EL to keep track of carry-= over number. Meaning:

 

When ELI/EL is not inserted in a new tunnel because ELI/EL exists in the = label stack, then:

= -        Increment carry-over number.

= -        Move ELI/EL to below top label.

[SLI] You can do it only if the new tunnel endpoint is ELC otherwise the = router should not do it.

 

When data terminates a tunnel, then:

= -        Decrement carry-over number.

= -        If (carry-over !=3D 0) re-insert ELI/EL to below exposed top labe= l.

 

I’m no hardware expert either, and not sure if something like above= can be implemented. But if possible, then ELI/EL pushed in SR network can = pre-set carry-over number to certain value to ensure it is carried over below top label all the way though, and there= is only one ELI/EL at any given time.

 

All this to say, I think there’s a benefit in discussing this topic= further, with both drafts in mind.

 

-Nobo

 

mpls = [mailto:mpls-bounces@ietf.org] On Behalf Of steph= ane.litkowski@orange.com
Sent: Friday, January 31, 2014 9:12 AM
To: draft-kini-mpls-entropy-label-src-stacked-tunnels@tool= s.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels

 

Hi Authors,

 

 

I would like to know if you are= progressing on this draft ?

Entropy label support for stack= ed tunnels would be mandatory for us, so I would like to support the work o= n this topic to have a working solution as soon as possible.

 

 

Regarding the solutions you are= proposing in the current version, there is none perfect one, and unfortuna= tely all have drawbacks.

The compatibility (on LSR) with= current generation of hardwares may be “good” (mandatory ?) fo= r the target solution.

 

In your document , solution =A7= 3.3 “re-usable EL for a stack of tunnels” sounds for me to be t= he best base idea. I’m just wondering what would be the hardware impa= ct of doing the reinsertion of ELI at tunnel end . Could this be done in one pass ? (IMHO, this may be possible, as today we are ab= le to pop or swap + push FRR headers) As you are three different vendor= s as co-author, did you already evaluate such impact on your hardwares ? (I= ’m not expecting details on the mailing list, but I would be interested by details unicast to me and just yes/no o= n the the list)

 

To be exhaustive in listing sol= utions, did you think about leaving the EL/ELI at top of the stack ? I thin= k there is already a case where a special label may be kept at top of the s= tack (MPLS Router alert).

What would be needed :

-  = ;      each hop need to advert= ise is ability to process EL, if nexthop cannot process EL, it should be re= moved when forwarded to nexthop (there should be the same requirement for r= e-usable EL)

I don’t think this is rea= lly different from re-usable EL in the concept :

-  = ;      reusable EL : process t= op level forwarding label, if popped and next label is EL, pop ELI/EL and n= ext label L, push pack ELI/EL and then L (we need to swap positions between= ELI/EL and L) if nexthop is able to process EL.

-  = ;      top level EL : process = top level ELI, ELI is recognized, ELI/EL is removed, forwarding is done on = forwarding label, ELI/EL is pushed back in nexthop is able to process EL.

 

In term of operations, I think = that top level EL may be simpler , but as I’m not hardware coder, may= be I’m wrong … moreover it may be similar to MPLS Router alert= processing.

 

 

Your thoughts ?<= /p>

 

 

Stephane

 

=  

 

________________________________________=
___________________________________________________________________________=
______
 
Ce message et ses pieces jointes peuvent=
 contenir des informations confidentielles ou privilegiees et ne doivent do=
nc
pas etre diffuses, exploites ou copies s=
ans autorisation. Si vous avez recu ce message par erreur, veuillez le sign=
aler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion,
Orange decline toute responsabilite si c=
e message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;
they should not be distributed, used =
or copied without authorisation.
If you have received this email in er=
ror, please notify the sender and delete this message and its attachments.<=
o:p>
As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.<=
/o:p>
Thank you.
________________________________________=
___________________________________________________________________________=
______
 
Ce message et ses pieces jointes peuvent=
 contenir des informations confidentielles ou privilegiees et ne doivent do=
nc
pas etre diffuses, exploites ou copies s=
ans autorisation. Si vous avez recu ce message par erreur, veuillez le sign=
aler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion,
Orange decline toute responsabilite si c=
e message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may con=
tain confidential or privileged information that may be protected by law;
they should not be distributed, used or =
copied without authorisation.
If you have received this email in error=
, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not =
liable for messages that have been modified, changed or falsified.
Thank you.
--_000_CECE764681BE964CBE1DFF78F3CDD3941DF6A73Fxmbalnx01ciscoc_-- From nobody Fri Feb 14 05:17:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80161A0214 for ; Fri, 14 Feb 2014 05:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BThAg2W0VNdS for ; Fri, 14 Feb 2014 05:17:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0651A0209 for ; Fri, 14 Feb 2014 05:17:45 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id B1F992AC176; Fri, 14 Feb 2014 14:17:43 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 949B63840D1; Fri, 14 Feb 2014 14:17:43 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 14 Feb 2014 14:17:43 +0100 From: To: "Nobo Akiya (nobo)" , "draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org" Date: Fri, 14 Feb 2014 14:17:41 +0100 Thread-Topic: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-mpls Thread-Index: Ac8o0o1+XpQwCtjuRh6vpvFWMgLyVgAo4LTQAAQ6BFA= Message-ID: <27868_1392383863_52FE1777_27868_11123_1_EEE55384044474429A926C625D0FCC810C335F0297@PUEXCB2F.nanterre.francetelecom.fr> References: <10973_1392307304_52FCEC68_10973_2075_1_EEE55384044474429A926C625D0FCC810C32CFBAFC@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810C335F0297PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.14.113015 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/AyXJzOJfy7MyxutFQ60jkqwiHPw Cc: "mpls@ietf.org" , "draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org" Subject: Re: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-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: Fri, 14 Feb 2014 13:17:55 -0000 --_000_EEE55384044474429A926C625D0FCC810C335F0297PUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, [NOBO] I agree that EL benefit is best achieved with what you described. Ul= timately, I think things will depend on the intelligence at B. Is S2 only b= eing used as a stitching LSP with S1? If yes, then it is possible to do no-= op as far as ELI/EL imposition is concerned. If no, then B would need to de= termine if traffic came out from S1 or from elsewhere, in order to determin= e whether to take no-op approach or impose ELI/EL. [SLI] If all routers have been smart enough, IMHO there would have been no = need for entropy label. Intelligence of LSR (for deep packet inspection) is= implementation depend. Stephane De : Nobo Akiya (nobo) [mailto:nobo@cisco.com] Envoy=E9 : vendredi 14 f=E9vrier 2014 12:41 =C0 : LITKOWSKI Stephane DTF/DERX; draft-kini-mpls-entropy-label-src-stacke= d-tunnels@tools.ietf.org Cc : mpls@ietf.org; draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org Objet : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draf= t-ravisingh-mpls-el-for-seamless-mpls Hi Stephane, Authors, et al, Please see in-line with [NOBO]. From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Thursday, February 13, 2014 11:02 AM To: Nobo Akiya (nobo); draft-kini-mpls-entropy-label-src-stacked-tunnels@to= ols.ietf.org Cc: mpls@ietf.org; draft-ravisingh-mpls-el-for-seamle= ss-mpls@tools.ietf.org Subject: RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & dra= ft-ravisingh-mpls-el-for-seamless-mpls Hi Nobo and both draft Authors, Thanks for pointing this draft as reference also, I agree that solution nee= d to be consistent. [NOBO] Yeah, this is a very tricky topic and can benefit from more discussi= ons. Some inline comments as well as added comments on draft-ravisingh-mpls-el-f= or-seamless-mpls : =B7 Section 5.2.2.1 : b. Notional ingress behavior: When L1 does not intrinsically support ELC and L2 does, then the stitching point router must POP the incoming label, insert (ELI+EL) before PUSHing the label for the LSP segment L2. The label operations performed would be: POP(IncomingLabel), PUSH(EL), PUSH(ELI), PUSH(OutgoingLabel), or SWAP(EL), PUSH(ELI), PUSH(OutgoingLabel) The issue I see here, is that the stitching point acting as= notional ingress need to perform Deep Packet Inspection in order to comput= e EL value, but it has no knowledge of what is transported and moreover due= to usage of hierarchy the payload may be quite far ... IMHO, it may not be= a good idea to let a router not having the flow context computing an EL va= lue otherwise we are loosing some of the EL value added ... (Ingress that = have the flow context computing a good hash). Did I miss something ? For stitching , I would propose to keep consistent ELC across LSPs and othe= rwise break ELC (if some segments are not ELC) and in order to manage non E= LC domains/areas, I would encourage to use tunneling technics (so EL would = be safe) and not stitching ... Example : A ------ (S1) ----- B ----- (S2) ------ C ----- (S3) ----- D Consider S1,S2,S3 as LSPs being stiched , B does stitching between S1 and D= 2 and C between S2 and S3. if : - D is ELC for S3 - C is ELC for S3 and S2 - B is ELC for S2 BUT NOT for S1 - A is not ELC for S1 Only A has knowledge of the flow context and can perform a good hashing . I= f S1 is not ELC, I would propose to not use ELI/EL on the all stitched path= to D. But if A may be ELC2 for segment type of S2, we could imagine to start S2 o= n A rather than B and tunnel S2 over S1, so A would be able to use ELI/EL. [NOBO] I agree that EL benefit is best achieved with what you described. Ul= timately, I think things will depend on the intelligence at B. Is S2 only b= eing used as a stitching LSP with S1? If yes, then it is possible to do no-= op as far as ELI/EL imposition is concerned. If no, then B would need to de= termine if traffic came out from S1 or from elsewhere, in order to determin= e whether to take no-op approach or impose ELI/EL. Stephane De : Nobo Akiya (nobo) [mailto:nobo@cisco.com] Envoy=E9 : lundi 3 f=E9vrier 2014 16:44 =C0 : LITKOWSKI Stephane DTF/DERX; draft-kini-mpls-entropy-label-src-stacke= d-tunnels@tools.ietf.org Cc : mpls@ietf.org; draft-ravisingh-mpls-el-for-seaml= ess-mpls@tools.ietf.org Objet : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Taking the example from draft-ravisingh-mpls-el-for-seamless-mpls ... S1 D1 \ --------- / A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE / --------- \ S2 D2 In the above topology, let there be the following LSPs: L1: B->D L2: A->E, tunneled through LSP L1 L3: S1->D1, tunneled through LSP L2 L4: S2->D2, tunneled through LSP L2 Let's say: (1) S1 does not push ELI/EL. (2) A pushes ELI/EL. (3) B does not push ELI/EL, since label stack already contains ELI/EL. Behavior so far aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless-m= pls (snippet above). Ideally what should happen is: (4) D pops ELI/EL, and pushes (or carries over) ELI/EL below exposed top= label. [SLI] Why D pops ELI/EL ? ELI/EL was pushed by A and D is egress of tunnel = from B, so when D receives traffic originally sent by S1, D would pop tunne= l label from C (end of L1), and switch tunnel L2 label to E, and only E wou= ld see the ELI/EL (5) E pops ELI/EL, and _does not_ push ELI/EL below exposed top label. [SLI] Right (6) D1 receives data without any ELI/EL (as expected). How does nodes D and E determine the right behavior? [SLI] I don't see what's the issue there ... If A pushed ELI, E has signall= ed that it was ELC, so E is prepared to receive a packet with ELI/EL. [NOBO] Sorry, I sort of skipped few explanations. What I meant to say was t= hat, if label stack of can get "popped" to (3.= 3 from draft-kini-mpls-entropy-label-src-stacked-tunnels), then two behavio= rs are possible. 1. gets "popped" to - 3.3 from draft-kin= i-mpls-entropy-label-src-stacked-tunnels. 2. gets "popped" to - more traditional way. What is ambiguous is, how does an LSR determine whether to apply (1) or (2)= . What I also meant to say was, if we are going to discuss behavior of (1),= then similar push behavior of (1) should be discussed. Meaning, if LSP1 is= tunneled over LSP2, then: 3. becomes - opposite of 3.3 fr= om draft-kini-mpls-entropy-label-src-stacked-tunnels. 4. becomes< LSP2, LSP1, ELI, EL> - more traditional w= ay. Now applying the example from above: a) S1 does not push ELI/EL: label stack =3D b) A pushes ELI, EL: label stack =3D c) B does not push ELI, EL, since label stack already contains ELI/EL= but moves ELI/EL to below top label: label stack =3D d) D pops B, ELI, EL and moves ELI/EL below exposed top label: label s= tack =3D e) E pops A, ELI, EL and _somehow knows_ not to move ELI/EL to below t= op label: f) D1 receives data without any ELI/EL. In this example, node D needs to know that it needs to apply behavior (1) a= nd node E needs to know that it needs to apply behavior (2) ... but how!? T= here may be ways for node D/E to know ELC for further upstreams/downstreams= , but ELC doesn't necessary mean ELI/EL is always pushed. -Nobo >From what I've read in the two drafts, I don't see how this behavior is det= ermined. If we can address this issue, I think solution is applicable to Segment Rou= ting label stack with ELI/EL, meaning behavior can apply to solution 3.3 of= draft-kini-mpls-entropy-label-src-stacked-tunnels. One possibility is to make use of TC or TTL of EL to keep track of carry-ov= er number. Meaning: When ELI/EL is not inserted in a new tunnel because ELI/EL exists in the la= bel stack, then: - Increment carry-over number. - Move ELI/EL to below top label. [SLI] You can do it only if the new tunnel endpoint is ELC otherwise the ro= uter should not do it. When data terminates a tunnel, then: - Decrement carry-over number. - If (carry-over !=3D 0) re-insert ELI/EL to below exposed top lab= el. I'm no hardware expert either, and not sure if something like above can be = implemented. But if possible, then ELI/EL pushed in SR network can pre-set = carry-over number to certain value to ensure it is carried over below top l= abel all the way though, and there is only one ELI/EL at any given time. All this to say, I think there's a benefit in discussing this topic further= , with both drafts in mind. -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of stephane.litkowski@o= range.com Sent: Friday, January 31, 2014 9:12 AM To: draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels Hi Authors, I would like to know if you are progressing on this draft ? Entropy label support for stacked tunnels would be mandatory for us, so I w= ould like to support the work on this topic to have a working solution as s= oon as possible. Regarding the solutions you are proposing in the current version, there is = none perfect one, and unfortunately all have drawbacks. The compatibility (on LSR) with current generation of hardwares may be "goo= d" (mandatory ?) for the target solution. In your document , solution =A73.3 "re-usable EL for a stack of tunnels" so= unds for me to be the best base idea. I'm just wondering what would be the = hardware impact of doing the reinsertion of ELI at tunnel end . Could this = be done in one pass ? (IMHO, this may be possible, as today we are able to = pop or swap + push FRR headers) As you are three different vendors as co-au= thor, did you already evaluate such impact on your hardwares ? (I'm not exp= ecting details on the mailing list, but I would be interested by details un= icast to me and just yes/no on the the list) To be exhaustive in listing solutions, did you think about leaving the EL/E= LI at top of the stack ? I think there is already a case where a special la= bel may be kept at top of the stack (MPLS Router alert). What would be needed : - each hop need to advertise is ability to process EL, if nexthop = cannot process EL, it should be removed when forwarded to nexthop (there sh= ould be the same requirement for re-usable EL) I don't think this is really different from re-usable EL in the concept : - reusable EL : process top level forwarding label, if popped and = next label is EL, pop ELI/EL and next label L, push pack ELI/EL and then L = (we need to swap positions between ELI/EL and L) if nexthop is able to proc= ess EL. - top level EL : process top level ELI, ELI is recognized, ELI/EL = is removed, forwarding is done on forwarding label, ELI/EL is pushed back i= n nexthop is able to process EL. In term of operations, I think that top level EL may be simpler , but as I'= m not hardware coder, may be I'm wrong ... moreover it may be similar to MP= LS Router alert processing. Your thoughts ? Stephane ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810C335F0297PUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

[NOBO] I agree that EL benefit is best achieved with what you described. = Ultimately, I think things will depend on the intelligence at B. Is S2 only= being used as a stitching LSP with S1? If yes, then it is possible to do n= o-op as far as ELI/EL imposition is concerned. If no, then B would need to = determine if traffic came out from S1 or from elsewhere, in order to determ= ine whether to take no-op approach or impose ELI/EL.

<= p class=3DMsoNormal> 

[= SLI] If all routers have been smart enough, IMHO there would have been no n= eed for entropy label. Intelligence of LSR (for deep packet inspection) is = implementation depend.

 

Stephane

<= p class=3DMsoNormal> 

 

De : Nobo Akiya (nobo) [mailto:nob= o@cisco.com]
Envoy=E9 : vendredi 14 f=E9vrier 2014 12:41=C0 : LITKOWSKI Stephane DTF/DERX; draft-kini-mpls-entropy-lab= el-src-stacked-tunnels@tools.ietf.org
Cc : mpls@ietf.org; dr= aft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org
Objet : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft= -ravisingh-mpls-el-for-seamless-mpls

 

Hi Stephane, Authors, et al,=

 

Please see in-line with [NOBO].

 

<= b>From: stephane.litkowski@orang= e.com [mailto:stephane= .litkowski@orange.com]
Sent: Thursday, February 13, 2014 11:= 02 AM
To: Nobo Akiya (nobo); draft-kini-mpls-entropy-lab= el-src-stacked-tunnels@tools.ietf.org
Cc: mpls@ietf.org; draft-ravisingh-mpls-el-for-seamless-mpls= @tools.ietf.org
Subject: RE: [mpls] draft-kini-mpls-entropy-l= abel-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-mpls

 

Hi Nobo and both draft Authors,

 

Th= anks for pointing this draft as reference also, I agree that solution need = to be consistent.

 

[NOBO] Yeah, this is a very tricky topic and can benefit from more disc= ussions.

 

Some inline comments as well = as added comments on draft-ravisingh-mpls-el-for-seamless-mpls :<= /span>

 

=B7         Section 5.2.2.1 :

&= nbsp;

        b. Notional= ingress behavior:

      =      When L1 does not intrinsically support ELC and L2 = does, then the

      &nbs= p;    stitching point router must POP the incoming label, in= sert

        &n= bsp;  (ELI+EL) before PUSHing the label for the LSP segment L2.

 

     &nbs= p;     The label operations performed would be:

          &n= bsp; POP(IncomingLabel), PUSH(EL), PUSH(ELI), PUSH(OutgoingLabel),

          &nb= sp;            = or

        &nb= sp;   SWAP(EL), PUSH(ELI), PUSH(OutgoingLabel)<= /p>

 =

            =     The issue I see here, is that the stitching point acting= as notional ingress need to perform Deep Packet Inspection in order to com= pute EL value, but it has no knowledge of what is transported and moreover = due to usage of hierarchy the payload may be quite far … IMHO, it may= not be a good idea to let a router not having the flow context computing a= n EL value otherwise we are loosing some of the EL  value added …= ; (Ingress that have the flow context computing a good hash). Did I miss so= mething ?

 

 

For stitching , I would prop= ose to keep consistent ELC across LSPs and otherwise break ELC (if some seg= ments are not ELC) and in order to manage non ELC domains/areas, I would en= courage to use tunneling technics (so EL would be safe) and not stitching &= #8230;

 

Example :

 

=

 

= A ------ (S1) ----- B ----- (S2) ------ C ----- (S3) ----- D

&n= bsp;

Consider S1,S2,S3 as LSPs being stiched , B does stitching between S= 1 and D2 and C between S2 and S3.

if :

<= ![if !supportLists]>-  =         <= span lang=3DEN style=3D'color:#1F497D'>D is ELC for S3

-&nb= sp;         C is ELC for S3 and S2=

-          = B is ELC fo= r S2 BUT NOT for S1

-      &= nbsp;   A is not ELC for S1

 

Only A has knowledge= of the flow context and can perform a good hashing . If S1 is not ELC, I w= ould propose to not use ELI/EL on the all stitched path to D.

But if= A may be ELC2 for segment type of S2, we could imagine to start S2 on A ra= ther than B and tunnel S2 over S1, so A would be able to use ELI/EL.

 

[NOBO] I agree that EL benefit is best achieved wi= th what you described. Ultimately, I think things will depend on the intell= igence at B. Is S2 only being used as a stitching LSP with S1? If yes, then= it is possible to do no-op as far as ELI/EL imposition is concerned. If no= , then B would need to determine if traffic came out from S1 or from elsewh= ere, in order to determine whether to take no-op approach or impose ELI/EL.=

 

Stephane

 

=

 =

De : Nobo Akiya (nobo= ) [mailto:nobo@cisco.com] <= br>Envoy=E9 : lundi 3 f=E9vrier 2014 16:44
=C0 := LITKOWSKI Stephane DTF/DERX; draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.ietf.org
Cc : mpls@ietf.or= g; <= span lang=3DEN-US>draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org<= /span>
Objet : RE: [= mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels

 

 

Taking the exa= mple from draft-ravisingh-mpls-el-for-seamless-mpls …

 

     =            S1  =             &nb= sp;   D1

      &nb= sp;           \ &nbs= p;  ---------    /

   &= nbsp;           &nbs= p;   A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE<= /p>

&= nbsp;           &nbs= p;     /    ---------    = \

         &n= bsp;      S2      &n= bsp;           D2

 

   In the above topology, let = there be the following LSPs:

 

<= p class=3DMsoNormal style=3D'line-height:14.4pt'>&nb= sp;       L1: B->D

 =        L2: A->E, tunneled through LSP L1

        L3: S1->D1, t= unneled through LSP L2

      = ;  L4: S2->D2, tunneled through LSP L2

 

Let’s say:<= /span>

(1)    = S1 does not push ELI/EL.

(2)&n= bsp;   A pushes ELI/EL.<= /p>

(3)    B doe= s not push ELI/EL, since label stack already contains ELI/EL.

 

Behavior so f= ar aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless-mpls (snippet = above). Ideally what should happen is:

 

(4)    D pops ELI/EL, and pushes (or carries over) ELI/EL below = exposed top label.

[SLI] Why D pops ELI/E= L ? ELI/EL was pushed by A and D is egress of tunnel from B, so when D rece= ives traffic originally sent by S1, D would pop tunnel label from C (end of= L1), and switch tunnel L2 label to E, and only E would see the ELI/EL=

(5)    = E pops ELI/EL, and _does not_ push ELI/EL below exposed top= label.

[SLI] Right

(6)    D1 rece= ives data without any ELI/EL (as expected).

 

How does nodes D and E determ= ine the right behavior?

[SLI] I don’= ;t see what’s the issue there … If A pushed ELI, E has signalle= d that it was ELC, so E is prepared to receive a packet with ELI/EL. <= /o:p>

 

[NOBO] Sorry, I sor= t of skipped few explanations. What I meant to say was that, if label stack= of <x, ELI, EL, y> can get “popped” to <y, ELI, EL>= ; (3.3 from draft-kini-mpls-entropy-label-src-stacked-tunnels), then two be= haviors are possible.

1.   &nbs= p;   <x, ELI, EL, y> gets “popped” to = <y, ELI, EL> - 3.3 from draft-kini-mpls-entropy-label-src-stacked-tun= nels.

2.       <= /span><x, ELI, EL, y> gets “popped” to <y> - more= traditional way.

What is ambiguous is, how does an LSR= determine whether to apply (1) or (2). What I also meant to say was, if we= are going to discuss behavior of (1), then similar push behavior of (1) sh= ould be discussed. Meaning, if LSP1 is tunneled over LSP2, then:=

3.       <LSP1= , ELI, EL> becomes <LSP2, ELI, EL, LSP1> - opposite of 3.3 from dr= aft-kini-mpls-entropy-label-src-stacked-tunnels.

4.       <LSP1, ELI, EL> be= comes< LSP2, LSP1, ELI, EL> - more traditional way.=

Now applying the example from above:

 

a)      S1 does not= push ELI/EL: label stack =3D <S1>

b)&n= bsp;     A pushes ELI, EL: label stack =3D <= ;A, ELI, EL, S1>

c)   &nbs= p;   B does not push ELI, EL, since label stack already = contains ELI/EL but moves ELI/EL to below top label: label stack =3D <B,= ELI, EL, A, S1>

d)   &nbs= p;  D pops B, ELI, EL and moves ELI/EL below exposed top labe= l: label stack =3D <A, ELI, EL, S1>

e)&= nbsp;     E pops A, ELI, EL and _somehow kn= ows_ not to move ELI/EL to below top label: <S1>

f)       <= ![endif]>D1 receives d= ata without any ELI/EL.

 

In t= his example, node D needs to know that it needs to apply behavior (1) and n= ode E needs to know that it needs to apply behavior (2) … but how!? T= here may be ways for node D/E to know ELC for further upstreams/downstreams= , but ELC doesn’t necessary mean ELI/EL is always pushed.<= /span>

 

-Nobo

 

 

From w= hat I’ve read in the two drafts, I don’t see how this behavior = is determined.

 

If we can address this issue, I think solution is applicable= to Segment Routing label stack with ELI/EL, meaning behavior can apply to = solution 3.3 of draft-kini-mpls-entropy-label-src-stacked-tunnels.

 

= One poss= ibility is to make use of TC or TTL of EL to keep track of carry-over numbe= r. Meaning:

 

<= p class=3DMsoNormal>When ELI/EL is not inserted in a new tunnel because ELI/EL exis= ts in the label stack, then:

-          Increment carry-over number.

-      =     Move ELI/EL to below top label.<= o:p>

[SLI] You can do it only if the new tunne= l endpoint is ELC otherwise the router should not do it.<= /p>

 

When data terminates a tunnel, then:

-      &nb= sp;   Decrement carry-over number.

-   =        If (carry-over = !=3D 0) re-insert ELI/EL to below exposed top label.

<= p class=3DMsoNormal> 

I’m no hardware = expert either, and not sure if something like above can be implemented. But= if possible, then ELI/EL pushed in SR network can pre-set carry-over numbe= r to certain value to ensure it is carried over below top label all the way= though, and there is only one ELI/EL at any given time.<= /p>

 

All this to say, I= think there’s a benefit in discussing this topic further, with both = drafts in mind.

 <= /p>

-Nobo

 

From: mpls [mailto:mpls-bounces@ietf.org<= /a>] On Behalf Of stephane.li= tkowski@orange.com
Sent: = Friday, January 31, 2014 9:12 AM
To: draft-kini-mpls-entropy-label-src-stacked-tunnels@tools.= ietf.org
Cc: mpls@ietf.org
Subject: [mpls] draft-kini-mp= ls-entropy-label-src-stacked-tunnels

 

Hi Authors,

 

=  

I would like to know if you are progressing on this draft = ?

Entropy labe= l support for stacked tunnels would be mandatory for us, so I would like to= support the work on this topic to have a working solution as soon as possi= ble.

&nbs= p;

 

Regarding the solutions= you are proposing in the current version, there is none perfect one, and u= nfortunately all have drawbacks.

= The compatibility (on LSR) with current generation of ha= rdwares may be “good” (mandatory ?) for the target solution.

 

In your document , solu= tion =A73.3 “re-usable EL for a stack of tunnels” sounds for me= to be the best base idea. I’m just wondering what would be the hardw= are impact of doing the reinsertion of ELI at tunnel end . Could this be do= ne in one pass ? (IMHO, this may be possible, as today we are able to pop o= r swap + push FRR headers) As you are three different vendors as co-author,= did you already evaluate such impact on your hardwares ? (I’m not ex= pecting details on the mailing list, but I would be interested by details u= nicast to me and just yes/no on the the list)

 

To be exhaustive in listing solutions, did you thi= nk about leaving the EL/ELI at top of the stack ? I think there is already = a case where a special label may be kept at top of the stack (MPLS Router a= lert).

What wo= uld be needed :

-          each hop need to advertise is a= bility to process EL, if nexthop cannot process EL, it should be removed wh= en forwarded to nexthop (there should be the same requirement for re-usable= EL)

I donR= 17;t think this is really different from re-usable EL in the concept :=

- &= nbsp;        reusable EL : process top level forwarding label, if= popped and next label is EL, pop ELI/EL and next label L, push pack ELI/EL= and then L (we need to swap positions between ELI/EL and L) if nexthop is = able to process EL.

-          top level EL : process top = level ELI, ELI is recognized, ELI/EL is removed, forwarding is done on forw= arding label, ELI/EL is pushed back in nexthop is able to process EL.<= /o:p>

 

In term of operations, I t= hink that top level EL may be simpler , but as I’m not hardware coder= , may be I’m wrong … moreover it may be similar to MPLS Router = alert processing.

 

 

Your thoughts ?

 

 =

Stephane

=  

 

 

____________________________________________________________=
_____________________________________________________________
 
Ce messag=
e et ses pieces jointes peuvent contenir des informations confidentielles o=
u privilegiees et ne doivent donc
pas=
 etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce=
 message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages=
 electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, de= forme ou falsifie. Merci.
 
This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;
they should not be distributed, used or copied with= out authorisation.
If you =
have received this email in error, please notify the sender and delete this=
 message and its attachments.
As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
Tha=
nk you.
_________________________=
___________________________________________________________________________=
_____________________
 =

Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans a=
utorisation. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion,
Orange decline toute responsabili=
te si ce message a ete altere, deforme ou falsifie. Merci.
 
This message=
 and its attachments may contain confidential or privileged information tha=
t may be protected by law;
they should =
not be distributed, used or copied without authorisation.=

If you have received this email in error, please notify =
the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
______________=
___________________________________________________________________________=
________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810C335F0297PUEXCB2Fnante_-- From nobody Fri Feb 14 06:38:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1C31A0284 for ; Fri, 14 Feb 2014 06:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz4g9SIQBLD4 for ; Fri, 14 Feb 2014 06:38:05 -0800 (PST) Received: from nm26-vm5.bullet.mail.ne1.yahoo.com (nm26-vm5.bullet.mail.ne1.yahoo.com [98.138.91.248]) by ietfa.amsl.com (Postfix) with ESMTP id 29BDA1A0281 for ; Fri, 14 Feb 2014 06:38:00 -0800 (PST) Received: from [98.138.100.117] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 14:37:58 -0000 Received: from [98.138.88.239] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 14:37:58 -0000 Received: from [127.0.0.1] by omp1039.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 14:37:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 523047.48082.bm@omp1039.mail.ne1.yahoo.com Received: (qmail 27675 invoked by uid 60001); 14 Feb 2014 14:37:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392388678; bh=8+9GXyD0Y5vfdR1skfQIHv75jL64JLGvzHPBAEa2v8w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=1H4M+qG4L7jzqhrwSYcroOKuZSSpdL6QVQE1CDqVPiISJKQk0jU+cAd/zRUuWq5z/hbgEBaCZiPxBvKVGytbqStAQ2znYwGEczsEVRIJmDGpGGJF1CuNacNpUUArs/ctPstcTxqVF1L9ttcuD0gKj0jjbpN0AL/xkt84rUDDZ7g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=PZQnZ1/6EvP09/wYX50/KkHEtaMnNNerIVXbkUXA2mjgiBnr9GAkPhcv5z0jtXwzvs0dbVkSg6SiGwNq6OYJcgrdY3Et746gAGTtWQVtQtJkw7I/iIO4j/EsoZ+n6YAISKuhayCsqRO9PU7RBWl3JfIa89aA67/yjxwTvaFbwBw=; X-YMail-OSG: n66.JZsVM1ngNqFq_kVYlqX.CV7fCO.zU_zw5jxtwEVfnBt ndjBBqD2lcOZeZD23CBBi9EkSlwqNL_lcK4zC0Lm_MUMnSERKCLAx8jfvkcl jZzLe57PmvEOqHLIl8.PDiryq0HjCbDBSN4gHmAUdEBnz5uSzFG21nAogybA mB4PCOLqJfGRe1_fnww.HCXvOF.s1zgmxXRWOYITNVnDF.iTcTLqKo413Uvg xoqvUKKH2SbwOQBqwjAm16oA.UpXSofEuOzKLnlV1ISBZGyxDrCEvcV04E9C fGTLlNN7pNb2_GhfHLiXuV1WVokiprlCTwnRCBcoF0E_yBY.827x6hglI5Lh BrWEgP9dnTqzYOfv1MYg_b_bgRfRKzB4LJkVZAQLApkgCUplU.GNrSZhdL_y JjvVOggiBMzZoXAIjzIeRQhncACEHTieUnTCjZnyXschzFEV8Gt4AR5iY9OW 7.gk3b8RyRQRgkvDMlEy1zg76GI3z0.dmbdrzfsj2tXLPZ5wbLO2DPfrIhLP vTHRfbkbg6aFFJg12e1YMFlYaffV13tdew.yxWHCkJdOROV1LN5BZq1s5JsY - Received: from [71.170.227.188] by web121004.mail.ne1.yahoo.com via HTTP; Fri, 14 Feb 2014 06:37:58 PST X-Rocket-MIMEInfo: 002.001, U3VwcG9ydCBhcyBjby1hdXRob3IuCgpOaW5nIFNvCjk3Mi05NTUtMDkxNAEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.177.636 References: Message-ID: <1392388678.26158.YahooMailNeo@web121004.mail.ne1.yahoo.com> Date: Fri, 14 Feb 2014 06:37:58 -0800 (PST) From: ningso@yahoo.com To: "mpls@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1562933420-1261991099-1392388678=:26158" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hReWIhM8wammH-K0P_-mXEk-5KA Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ningso@yahoo.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:38:12 -0000 ---1562933420-1261991099-1392388678=:26158 Content-Type: text/plain; charset=us-ascii Support as co-author. Ning So 972-955-0914 ---1562933420-1261991099-1392388678=:26158 Content-Type: text/html; charset=us-ascii
Support as co-author.
 
Ning So
972-955-0914
---1562933420-1261991099-1392388678=:26158-- From nobody Fri Feb 14 07:52: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 6F2E61A02DF for ; Fri, 14 Feb 2014 07:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMefCpVHeU9Y for ; Fri, 14 Feb 2014 07:52:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E61861A02BA for ; Fri, 14 Feb 2014 07:51:59 -0800 (PST) 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 BDP14038; Fri, 14 Feb 2014 15:51:58 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 15:49:04 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 15:49:25 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 07:49:18 -0800 From: Lucy yong To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKZJai9VipXq2Q3SEIpx59uPl/pq05Zew Date: Fri, 14 Feb 2014 15:49:17 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4532F1D6@dfweml701-chm.china.huawei.com> References: <1392388678.26158.YahooMailNeo@web121004.mail.ne1.yahoo.com> In-Reply-To: <1392388678.26158.YahooMailNeo@web121004.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.108] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4532F1D6dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IFMldGUekfjv29bEHNFL4oKfTeE Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 15:52:07 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4532F1D6dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support! Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D4532F1D6dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support!

Lucy

 

--_000_2691CE0099834E4A9C5044EEC662BB9D4532F1D6dfweml701chmchi_-- From nobody Fri Feb 14 08:28: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 159EA1A02DE for ; Fri, 14 Feb 2014 08:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 XhRGPalggPTp for ; Fri, 14 Feb 2014 08:28:32 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A387F1A02A3 for ; Fri, 14 Feb 2014 08:28:31 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1EGSSI9008578 for ; Fri, 14 Feb 2014 16:28:28 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1EGSNdh008490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 14 Feb 2014 16:28:25 GMT From: "Adrian Farrel" To: References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> In-Reply-To: <52FE2E14.3010903@cisco.com> Date: Fri, 14 Feb 2014 16:28:17 -0000 Message-ID: <002d01cf29a1$c9c1f9c0$5d45ed40$@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: AQHZAbpQEHKtxixh1gWDHsjupsHBAwFVBBIXAfST0/2ahvLrgA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/x4OPQq0etB6nUzF7bAtaJOjSuJY Subject: [mpls] FW: Mail regarding draft-ietf-mpls-special-purpose-labels 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, 14 Feb 2014 16:28:36 -0000 FYI > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: 14 February 2014 14:54 > To: adrian@olddog.co.uk; draft-ietf-mpls-special-purpose-labels@tools.ietf.org > Cc: Alia Atlas > Subject: Re: Mail regarding draft-ietf-mpls-special-purpose-labels > > On 11/02/2014 20:07, Adrian Farrel wrote: > > Hi Stewart, > > > > Thanks for this. Can we copy the thread to the WG mailing list? > > Sure. Doing that. > > > >> I have reviewed this draft and have a few comments that I would > >> like to discuss before it goes to IETF LC. > >> > >> It is possible that Alia may have some additional comments > >> and since it will fall to her to take this through the IESG > >> you should give priority to any comments that she makes. > > So I cc'ed her here. > > > >> XL The Extension Label that indicates that an extended special > >> purpose label follows. > >> > >> ESPL An Extended Special Purpose Label. > >> > >> Something that I think would be worthwhile clarifying right at the > >> front is that a label is an ESPL IFF it is preceded by an XL. > >> It might even be worth noting that really we have a new label type: > >> a label couple in which the first label defines the type of the > >> second label and neither are of any use as individual labels. > > I can see how you would see this as a new label type. Maybe "compound" > rather > > than "couple". > > However, I am not convinced that it is new that one label leads to the semantics > > of the next (for example the entropy label). > > What is more, I am not sure that there will be more than this instance of this > > type of tight coupling. > > So I would rather leave this point out. > I can foresee other cases where we might use label pairs to mitigate the > 20bit limit. I am sure it has been discussed, so creating the reference > might > be useful. Just because this was not done in EL, does not mean that > we should not set down the concept here. > > However I agree compound would be a better term. > > > > > But as to clarifying ESPL: yes. > > The XP definition is, I think, clear. > > How about... > > > > ESPL An Extended Special Purpose Label. A Special Purpose Label that > > is placed in the label stack after the Extension Label. > Yes. Indeed it MUST be placed be placed there, however the definition > above is fine. > > > >> ====== > >> > >> I think that the draft will need to provide some guidance > >> on when to allocate a 0..15 and when to allocate an ESPL. > >> > >> I imagine that a 0..15 should only be used when it can be shown > >> that the extra stack space of forwarding time is burdensome > >> but that is a question that the WG should explicitly consider. > > We discussed this at some point on the MPLS list (many centuries ago, I think) > > and reached no conclusion. > > The primary purpose of the XL is to handle the time when 0..15 is depleted. > > You're right that we could encourage people to start using ESPLs now before > > 0..15 is depleted. But it is hard to make the case for requiring it when there > > is still some of 0..15 available and the rate of burn is not so high. > > > > We could put in some text like... > > > > When allocating a new Special Purpose Label, protocol designers should > consider > > whether they could, instead, use an Extended Special Purpose Label. Doing so > > would help to preserve the scarce resources of Special Purpose Labels for use > in > > cases where minimizing the label stack size is particularly important. > That would be useful text. > >> ====== > >> > >> 2. A Standards Track RFC must accompany a request for allocation of > >> Standards Action special purpose labels, as per [RFC5226]. > >> > >> You need to clarify whether this is a 0..15 SPL, an ESPL or both. > > Section 3, answer 2 (which you quote) is answering Section 2 question 2. > > Both explicitly state "special purpose label". > > It is not until question 5 and its answer that extended special purpose labels > > come in. > > The IANA considerations section describes the allocation policies for ESPLs. > OK > > > >> ====== > >> > >> 6. [RFC6790] says that special purpose labels MUST NOT be used for > >> load balancing. The same logic applies to extended special > >> purpose labels (ESPLs). Thus, this document specifies that ESPLs > >> MUST NOT be used for load balancing. It is noted that existing > >> implementations may violate this, as they do not look for the XL > >> and thus for ESPLs. The consequence is that if ESPLs are used in > >> some packets of a flow, these packets may be delivered on > >> different paths and so could be re-ordered. However, it is > >> important to specify the correct behavior for future > >> implementations, hence the use of "MUST NOT". > >> > >> I would suggest that most implementations do violate this. I would > >> also suggest that it seems unlikely that you will get to the point > >> where it is not violated in the foreseeable future. > > I can't tell whether there is an action here for us. > > There are two "violations" that exist: > > 1. Some implementations violate 6790. Not sure what we can do about > > that in this document. Note that the entropy label can help with this > > but only to a limited extent since the implementations that violate 6790 > > probably also fail to recognise the entropy label. > > 2. Implementations that conform to 6790 will understand that the XL is > > a special purpose label and will not use it to load balance. But they will > > not necessarily understand that the next label is an ESPL that must be > > skipped as well. Again, there is nothing we can do about this except to > > note it (done) and possibly to use the EL further up the stack. > > My point was that the may in "It is noted that existing implementations may > violate this" was a little soft. Most implementations, except the latest > designs > of maybe as few as a single vendor, would certainly violate this. > > Also of course you are making a statement of fact and not of permission > so I think it may be more precise to say: > > It is noted that most existing > implementations currently violate this, as they do not look for the XL > and thus for ESPLs. > > > > > >> ===== > >> > >> A further question to be settled in this regard is whether a > >> "regular" special purpose label retains its meaning if it follows the > >> XL; see Section 3.1. > >> > >> The way that you start the para it looks like this is an open question > >> could I suggest rewording so that it is clear that this is a resolved > >> matter. > > OLD > > A further question to be settled in this regard is whether a > > "regular" special purpose label retains its meaning if it follows the > > XL; see Section 3.1. > > NEW > > A further question that needed to be settled in this regard was > > whether a "regular" special purpose label retains its meaning if it > > follows the XL. This answer to this question is provided in Section > > 3.1. > > END > yes. > > >> ======= > >> > >> Label 7 (when received) retains its meaning as ELI whether a regular > >> special purpose label or an ESPL; this simplifies a transit LSR's > >> task of looking for entropy labels since it may just look for label 7 > >> and need not verify that the previous label in the stack is not the > >> XL 15. However, an LSR wishing to insert an entropy label SHOULD > >> insert label 7 as a regular special purpose label, not as an ESPL. > >> > >> Why is this not a MUST! There is no ESPL in the wild running an > >> alternate behaviour, so why not simply mandate this? > > If this was a MUST then there would be no case for handling Label 7 after XL. > > There was some concern I believe that implementations might have a path that > > puts them on to XL insertion processing and then consider what to do next. At > > that point they might decide that label 7 is needed. > > > > It seems esoteric, but I couldn't see a reason to prohibit it. > > > > Maybe "MUST NOT include" and "SHOULD process when received" are > compatible. > > > > Part of me hates the idea of this change just because I don't want another > > working group last call before we can move forward. How important is it? > The reason to be stricter at the TX is that the forwarding path can be > simpler at the > RX. I cannot see how you would get to the point of putting in L15 and then > saying "you know I need to put in L7" particularly as no other 0..15 is > allowed. > Normally I would think that you would put in the compound label as a pair > and that is a good reason to use the compound label concept. > > Also I see no reason for the inconsistency between L7 and all of the > other L0..L15 cases. > > So I think that it's OK, but probably silly to allow L0..L15, but to allow > the exception of just L7 just complicates things without good cause. > > > >> ======== > >> > >> 3.2. Process for Retiring Special Purpose Labels > >> > >> While the following process is defined for the sake of completeness, > >> note that retiring special purpose labels is difficult. It is > >> recommended that this process be used sparingly. > >> > >> a. A label value that has been assigned from the "Special Purpose > >> MPLS Label Values" may be deprecated by IETF consensus with > >> review by the MPLS working group (or designated experts if the > >> working group or a successor does not exist). An RFC with at > >> least Informational status is required. > >> > >> The RFC will direct the IANA to mark the label value as > >> "deprecated" in the registry, but will not release it at this > >> stage. > >> > >> Deprecating means that no further specifications using the > >> deprecated value will be documented. > >> > >> At the same time this is an indication to vendors not to include > >> the deprecated value in new implementations, and to operators to > >> avoid including it in new deployments. > >> > >> b. 12 months after the RFC deprecating the label value is published, > >> an IETF-wide survey may be conducted to determine if the > >> deprecated label value is still in use. If the survey indicates > >> that the deprecated label value is in use, the survey may be > >> repeated after a further 6 months. > >> > >> c. 24 months after the RFC that deprecated the label value was > >> published and if the survey indicates that deprecated label value > >> is not in use, publication may be requested of an IETF Standards > >> Track Internet-Draft that retires the deprecated the label value. > >> This document will request IANA to release the label value for > >> for future use and assignment. > >> > >> I have two comments on this. Firstly why is it necessary to specify the > >> MPLS WG. If the action is IETF consensus, then this will get picked but > >> my MPLS WG then IETF LC and then ADs. There are enough checks and > >> balances in the system that there is no need to call up a specific > >> WG that may or may not be in existence. > > I think the wording is very fine in terms of setting expectations. > > The expectation is that there will be IETF consensus and that, along the way, > > the MPLS WG will review the decision. > > I think this is almost certainly business as usual, but writing it down doesn't > > seem to hurt. > OK > > > > >> Secondly I think the timescales are ridiculously optimistic. To get > >> a label out of circulation in 24 months seems most unlikely. Also > >> 6 month checks is a lot of work. > >> > >> A more realistic schedule would be to poll at 12month intervals until > >> such time as it is determined that reallocation would do not harm and > >> then give a further 12 months notice. > > Erm, that's what the text says, I think... > > > > 12 months after the RFC deprecating the label value is published, > > an IETF-wide survey may be conducted to determine if the > > deprecated label value is still in use. > > > > The "may" in that means that the earliest you can "poll" is 12 months after the > > deprecation RFC is published (noting that the RFC won't even get published > until > > lots of discussion and consensus to deprecate). > > Then, *if* the poll response is OK, and then not earlier than 24 months after > > the deprecation RFC is published, publication can be requested for a new RFC > > (which means that the WG has already reached consensus, and that a > subsequent > > IETF last call will be held). > > > > Frankly, I think that this process is only likely to be executed for SPLs that > > are allocated "in error", because other stuff will probably be in the field. Can > > you think of a label that was allocated in error? I can :-) > > This seems like a lot of text to specify in detail something we would never > run. In protocols, including this type of protocol, the fewer words used to > describe the rarely executed exception path the better. > > > > > >> =========== > >> > >> | 7 | Allocated; meaning is ELI [RFC6790] | > >> > >> I do not understand why you need the complexity of this exception. > > So you said above. > > Is there a problem? > > Does it break something badly, or is it just not what you would have done? > I can like with the complexity, but as I noted above complexity rarely > executed leads to interesting bugs. > > > > >> ============ > >> > >> 6. Security Considerations > >> > >> This document does not make a large change to the operation of the > >> MPLS data plane > >> > >> That is an incorrect statement! This memo explicitly makes changes > >> to the MPLS DP! > > The text does not say that the document makes no changes to the data plane. > It > > says no large change to the operation of the data plane. > > > > What text would you prefer in the context of the Security Considerations? > > Sorry I misread it and missed the word "large". The text is fine. > > > >> =========== > >> > >> This document provides a protocol-legal way to > >> arbitrarily increase the label stack and so might provide a way to > >> attack some nodes in a network without violating the protocol rules. > >> > >> I think that this already exists with the ELI doesn't it? > > To a different order of magnitude (different arbitrariness?). > > One could argue that a large number of {ELI, EL} pairs could be inserted, where > > this I-D doesn't really change anything that already exists. > > > > Actually, I think this text dates from when XL was a legal ESPL. That was > > nonsense we managed to squash despite the "architects" who thought it was > > beautiful. > > > > It might be better to say... > > > > This document provides a protocol-legal way to > > increase the label stack through the insertion of additional {XL,ESPL} > > pairs at a greater rate than insertion of single "rogue" labels. This > > might provide a way to attack some nodes in a network that can only > > process label stacks of a certain size without violating the protocol > > rules. > Yes, that is better. > > > > >> =========== > >> > >> This document also describes events that may cause an LSR to issue > >> event logs at a per-packet rate. It is critically important that > >> implementations rate-limit such logs. > >> > >> I do not see any text on this at all! However that brings me to > >> suggest that you probably need to write an OPs section and > >> you might want to think about the PM implications of the extra > >> metatdata in the packets. > > Section 3.1.1 has > > If an LSR encounters the XL at the top of stack and it doesn't > > understand extension labels, it SHOULD drop the packet as specified > > for the handling of any unknown lable according to [RFC3031]. If an > > LSR encounters an ESPL at the top of stack (after the XL) and does > > not understand the ESPL, it SHOULD drop the packet, again following > > the procedures for unknown labels as set out in [RFC3031]. In either > > case, the LSR MAY log the event, but such logging MUST be rate- > > limited. > > Without rate limiting on the logging, this is an attack vector. > OK and I agree that if the section is null it should not be included. > I imagine that there will be concerns about how you know that you > can introduce the feature, and what you do in the event of re-routing > etc. > > If you do not think there are other considerations we can leave the > text and get the Ops folks to comment later in the process. > > > > What OPS issues had you in mind that need to be addressed? I am a fan of OPS > > sections, but not a fan of empty OPS sections, and when we looked through > RFC > > 6123 (which is my favourite crib for what to describe wrt manageability) we > > didn't see anything that has changed from pre-existing MPLS. > > > > What metadata are you talking about? Is an existing special purpose label > > metadata? If so, the PM issues are pre-existing. Is there something special > > introduced by this I-D that constitutes metadata? > Well what follows an XL is certainly metadata, and one application is > certainly to introduce tags that would alert the PM devices to take an > interest. > > > > >> How do you know if the target can accept ESPLs? Do you need to specify > >> some sort if ICMP response given that there could be a lot more > >> SPLs as a result of this. > > How do you know if the target can accept a new SPL? > > I don't think that prevents us from assigning them, and each I-D that assigns a > > new one has to worry about backward compatibility. Note that the default > > backward compatibility is covered by "drop packets with unrecognised labels". > > In this respect XL is just another SPL that might be unrecognised. > > Below XL, each ESPL is just another ESPL that might be unrecognised and will > > also cause the packet to be dropped (see 3.1.1) > > Any I-D that defines a new ESPL will have to worry about backward > compatibility > > for that ESPL. This I-D does not have that problem. > > OK > > Stewart > > Cheers, > > Adrian > > > > . > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Fri Feb 14 08:44: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 2B28E1A02CC; Fri, 14 Feb 2014 08:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o3LwG6WVgfk; Fri, 14 Feb 2014 08:44:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1F51A012E; Fri, 14 Feb 2014 08:44:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214164405.8044.35182.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 08:44:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0caj6b5jA9v2QE_tLJEDJNKoFio Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-relay-reply-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:44:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Relayed Echo Reply mechanism for LSP Ping Authors : Jian Luo Lizhong Jin Thomas Nadeau George Swallow Filename : draft-ietf-mpls-lsp-ping-relay-reply-02.txt Pages : 14 Date : 2014-02-14 Abstract: In some inter autonomous system (AS) and inter-area deployment scenarios for Label Switched Path (LSP) Ping and Traceroute, a replying LSR may not have the available route to the initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying Label Switching Router (LSR) to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-relay-reply-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 08:46: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 D64781A02EA for ; Fri, 14 Feb 2014 08:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 B7xnGx2q9g69 for ; Fri, 14 Feb 2014 08:46:09 -0800 (PST) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id D64CF1A0270 for ; Fri, 14 Feb 2014 08:46:08 -0800 (PST) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:MIME-Version; b=JBvvivrnCEDbg3nOfWD1dhiqbdr3FeJczXd4olOVsm8Hv0ZuEh/Jmw8C ZSxOIHr370ra8Ob/NksTwL8Y5OT9XtZHw+2vtHmrguFGd8s4gzC8VE5wG UDaVMgmh551atLrWmdIT0UmqBDXa+CsUayoUZ44rlDSDVJ4cHXUwymgSJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFACtH/lKOP4Bp/2dsb2JhbABZgkIjITilM5pWgRQWdIIlAQEFLSYbCxIBCA0EBAEBKDkUCQkBBA4FCId9AcgmF45IMQaDJYEUBIlIlVOLNINL X-IronPort-AV: E=Sophos;i="4.95,845,1384300800"; d="scan'208,217";a="297856688" Received: from unknown (HELO WP40057.corp.ads) ([142.63.128.105]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 14 Feb 2014 16:46:06 +0000 Received: from wp40067.corp.ads ([::1]) by WP40057.corp.ads ([::1]) with mapi; Fri, 14 Feb 2014 11:46:05 -0500 From: Boris Zhang To: "mpls@ietf.org" Date: Fri, 14 Feb 2014 11:46:04 -0500 Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: Ac8ppBbrB5zQAw+ATSy6rc3FqLiHuA== Message-ID: <3CC752382EB88F48ADAC4AF9F478A153168D3597DA@WP40067.corp.ads> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: multipart/alternative; boundary="_000_3CC752382EB88F48ADAC4AF9F478A153168D3597DAWP40067corpad_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rvsTQZCGkf2mFahs8xUbvQ14gB4 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 16:46:13 -0000 --_000_3CC752382EB88F48ADAC4AF9F478A153168D3597DAWP40067corpad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Cheers Boris Zhang Telus Inc. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_3CC752382EB88F48ADAC4AF9F478A153168D3597DAWP40067corpad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Cheers

Boris Zhang

Telus Inc.

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf= Of Ross Callon
Sent: Thursday, February 13, 2014 2:46 PM
= To: mpls@ietf.org
Cc:= mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-= protection-11


Subject= : [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

 

<= div>

as an MPLS working group document. Since man= y of us will be in transit to the

IETF approximately two weeks from now, I will extent the poll by on= e week (so

that it will be= a three week poll).

 

This poll will end Frid= ay March 7, 2014. Note that this is the Friday of the IETF,

and thus we will each need to plan our re= view of the document and response

around our travel plans and IETF activities.

=

 

Thanks, Ross

<= p class=3DMsoNormal> 

= --_000_3CC752382EB88F48ADAC4AF9F478A153168D3597DAWP40067corpad_-- From nobody Fri Feb 14 08:47: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 067861A025A for ; Fri, 14 Feb 2014 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 i84nTd3OJIcq for ; Fri, 14 Feb 2014 08:47:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D61A02C0 for ; Fri, 14 Feb 2014 08:47:06 -0800 (PST) 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 BDP17675; Fri, 14 Feb 2014 16:47:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 16:45:41 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 16:46:01 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 08:45:53 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQAa29QMy3TZQUa/WtY1/4nJhZqzrkuAgACQewD//3ofgIAAorWAgACRYBA= Date: Fri, 14 Feb 2014 16:45:51 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.162] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C37563SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8Fym4WFsQK2tmfi5xa7Wn1Nq_cs Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 16:47:12 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C37563SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C37563SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C37563SJCEML701CHMchi_-- From nobody Fri Feb 14 08:58: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 268231A031F for ; Fri, 14 Feb 2014 08:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 9I3NZa-y4U42 for ; Fri, 14 Feb 2014 08:58:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1F41A0270 for ; Fri, 14 Feb 2014 08:58:16 -0800 (PST) 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 BBD36972; Fri, 14 Feb 2014 16:58:14 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 16:56:24 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 16:56:44 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 08:56:38 -0800 From: Linda Dunbar To: "mpls@ietf.org" , Ross Callon Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKaW5RiEcl68KRE6z6PbuTjifvw== Date: Fri, 14 Feb 2014 16:56:37 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C801ED@dfweml701-chm.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D445C372E6@SJCEML701-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.192.11.98] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C801EDdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_suLSB_vJFQIvZi4v7u28Q178t0 Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 16:58:24 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C801EDdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Linda From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_4A95BA014132FF49AE685FAB4B9F17F645C801EDdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.  

 <= /p>

Linda

 <= /p>

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 2:46 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645C801EDdfweml701chmchi_-- From nobody Fri Feb 14 08:58: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 BEB641A0329 for ; Fri, 14 Feb 2014 08:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 5ZGbAvRmibqi for ; Fri, 14 Feb 2014 08:58:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2F621A031D for ; Fri, 14 Feb 2014 08:58:22 -0800 (PST) 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 BDP18389; Fri, 14 Feb 2014 16:58:19 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 16:57:15 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 16:57:35 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 08:57:22 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQAa29QMy3TZQUa/WtY1/4nJhZqzrkuAgACQewD//3ofgIAAorWAgAAJKQCAAJJjoA== Date: Fri, 14 Feb 2014 16:57:21 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C3758E@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B762218@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B762218@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.162] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C3758ESJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rMFRxGKCd_eLy-Y_IdNAavDxzBM Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 16:58:35 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C3758ESJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Why not? It seems that section 1.2 "Egress Local Protection with FRR" of the draft i= ndicates that that is the way it should go. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 7:04 PM To: Gregory Mirsky; Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, another question in connection to our discussion: * in authors opinion, is it possible for FRR protection of link bet= ween R3 and L1 (Fig.1) and L1 egress node protection to coexist. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 3:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C3758ESJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

Why not?

It seems that section 1.2 “Egres= s Local Protection with FRR” of the draft indicates t= hat that is the way it should go.

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Thursday, February 13, 2014 7:04 PM
To: Gregory Mirsky; Huaimo Chen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

another question in conne= ction to our discussion:

·      = ;   in authors opinio= n, is it possible for FRR protection of link between R3 and L1 (Fig.1) and = L1 egress node protection to coexist.

 <= /p>

Regards,

        Greg

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 3:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C3758ESJCEML701CHMchi_-- From nobody Fri Feb 14 09:03: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 6CDE51A0352; Fri, 14 Feb 2014 09:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-6S7frQOnoI; Fri, 14 Feb 2014 09:03:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1FD1A012E; Fri, 14 Feb 2014 09:03:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214170306.10570.89781.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 09:03:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dAI-QTDEooklfUWNuc0j-oVPQr0 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-chen-mpls-p2mp-ingress-protection-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:03:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Ingress Local Protection Authors : Huaimo Chen Raveendra Torvi Filename : draft-chen-mpls-p2mp-ingress-protection-11.txt Pages : 28 Date : 2014-02-13 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-mpls-p2mp-ingress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-mpls-p2mp-ingress-protection-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-chen-mpls-p2mp-ingress-protection-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 09:04:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47621A0353 for ; Fri, 14 Feb 2014 09:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ka7dSX4k2dW0 for ; Fri, 14 Feb 2014 09:04:22 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB29E1A0354 for ; Fri, 14 Feb 2014 09:04:21 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-b3-52fe4c8fec9c Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.26.12743.F8C4EF25; Fri, 14 Feb 2014 18:04:16 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 12:04:18 -0500 From: Gregory Mirsky To: Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQQErWTRsEe5IUeaVctZClaFmpqztzjwgABYTAD//8I4UIABeH2A//+s7mA= Date: Fri, 14 Feb 2014 17:04:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B762774eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt+4En39BBqu38FtsfXqF0eL7pSUs FreWrmS1+LviCosDi0fLkbesHkuW/GTyuN50ld3jy+XPbAEsUVw2Kak5mWWpRfp2CVwZGy/M ZCro2sBU0Th7OmMD49Y+pi5GTg4JAROJfbN+sEDYYhIX7q1nA7GFBI4wSjRNs4OwlzNKzFlU DWKzCRhJvNjYww5iiwjkSTQ/388IYjML2ErceXINzBYWCJSY3nqNDaImSGLJjQcsELafxNXl S8HiLAKqEjf2fwGzeQV8JfZtWgx0DxfQrlYWibfbe8EaOAXCJF783QtWxAh03PdTa5gglolL 3HoyH+oBAYkle84zQ9iiEi8f/2OFsJUkJi09xwpRny9xaNI2RohlghInZz5hmcAoOgvJqFlI ymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDYxAiPwmASb7g7G PS8tDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRQfrhqqJL/qEH8mKy QlImPuq9opscfXem0Mk0zT/Pvykuv9b5bueVCvdYi6ajBVpx3oori8svZjNU/WFv9ei+8fTF Em6d3HC1xXKH31yxOTbRrS8/pbVDafJ+o0T1dKP3XMeuHLlVuvtbU8IcJ8dqkQWM+56UsO3l NWJlEtSy3OIwK6bCvk+JpTgj0VCLuag4EQCWui/0jgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ulSETyJEzYX90fghAyVIwS9Tydc Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 17:04:27 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B762774eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B762774eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B762774eusaamb103erics_-- From nobody Fri Feb 14 09:16: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 4211C1A02E1 for ; Fri, 14 Feb 2014 09:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Eb4OlW6wikhW for ; Fri, 14 Feb 2014 09:16:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 402F21A01F3 for ; Fri, 14 Feb 2014 09:16:38 -0800 (PST) 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 BDP19463; Fri, 14 Feb 2014 17:16:35 +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; Fri, 14 Feb 2014 17:15:46 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 17:16:07 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 09:15:56 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQAa29QMy3TZQUa/WtY1/4nJhZqzrkuAgACQewD//3ofgIAAorWAgACRYBCAAJS4gP//efAQ Date: Fri, 14 Feb 2014 17:15:55 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.162] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C375EFSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OetpLkKkowp1nuf12UwYUeqIVME Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 17:16:45 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C375EFSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, For a transit node of an LSP and the link between the transit node and = the upstream node of the transit node, can we use both the link protection = define in RFC 4090 for protecting the link and the node protection defined = in RFC 4090 for protecting the transit node? If so, will this kind of deplo= yment lead to unpredictable results? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:04 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C375EFSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

    For a = transit node of an LSP and the link between the transit node and the upstre= am node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC= 4090 for protecting the transit node? If so, will this kind of deployment lead to unpredictable results?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C375EFSJCEML701CHMchi_-- From nobody Fri Feb 14 09:36: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 044F41A0346 for ; Fri, 14 Feb 2014 09:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 9WbGhoCE7RdD for ; Fri, 14 Feb 2014 09:35:58 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4E98E1A0338 for ; Fri, 14 Feb 2014 09:35:58 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1EHZpXh012471; Fri, 14 Feb 2014 17:35:51 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1EHZmqq012443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 17:35:50 GMT From: "Adrian Farrel" To: , References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> In-Reply-To: <52FE2E14.3010903@cisco.com> Date: Fri, 14 Feb 2014 17:35:47 -0000 Message-ID: <007001cf29ab$335bbbb0$9a133310$@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: AQHZAbpQEHKtxixh1gWDHsjupsHBAwFVBBIXAfST0/2ahvSAYA== Content-Language: en-gb X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1VwMQL3PfITAo36uQtAmZ4OQER0 Cc: mpls@ietf.org, 'Alia Atlas' Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels 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, 14 Feb 2014 17:36:03 -0000 [snip] > >> XL The Extension Label that indicates that an extended special > >> purpose label follows. > >> > >> ESPL An Extended Special Purpose Label. > >> > >> Something that I think would be worthwhile clarifying right at the > >> front is that a label is an ESPL IFF it is preceded by an XL. > >> It might even be worth noting that really we have a new label type: > >> a label couple in which the first label defines the type of the > >> second label and neither are of any use as individual labels. > > I can see how you would see this as a new label type. Maybe "compound" > > rather than "couple". > > However, I am not convinced that it is new that one label leads to the semantics > > of the next (for example the entropy label). > > What is more, I am not sure that there will be more than this instance of this > > type of tight coupling. > > So I would rather leave this point out. > I can foresee other cases where we might use label pairs to mitigate the > 20bit limit. I am sure it has been discussed, so creating the reference > might be useful. Just because this was not done in EL, does not mean that > we should not set down the concept here. > > However I agree compound would be a better term. > > > > > But as to clarifying ESPL: yes. > > The XP definition is, I think, clear. > > How about... > > > > ESPL An Extended Special Purpose Label. A Special Purpose Label that > > is placed in the label stack after the Extension Label. > > Yes. Indeed it MUST be placed be placed there, however the definition > above is fine. OK, I updated to... ESPL An Extended Special Purpose Label. A Special Purpose Label that is placed in the label stack after the Extension Label. The combination of XL and ESPL might be regarded as a new form of "compound label" comprising more than one consecutive entry in the label stack. ..to cover your other point as well. > >> ====== > >> > >> I think that the draft will need to provide some guidance > >> on when to allocate a 0..15 and when to allocate an ESPL. > >> > >> I imagine that a 0..15 should only be used when it can be shown > >> that the extra stack space of forwarding time is burdensome > >> but that is a question that the WG should explicitly consider. > > We discussed this at some point on the MPLS list (many centuries ago, I think) > > and reached no conclusion. > > The primary purpose of the XL is to handle the time when 0..15 is depleted. > > You're right that we could encourage people to start using ESPLs now before > > 0..15 is depleted. But it is hard to make the case for requiring it when there > > is still some of 0..15 available and the rate of burn is not so high. > > > > We could put in some text like... > > > > When allocating a new Special Purpose Label, protocol designers should > > consider whether they could, instead, use an Extended Special Purpose > > Label. Doing so would help to preserve the scarce resources of Special > > Purpose Labels for use in cases where minimizing the label stack size is > > particularly important. > > That would be useful text. Added as new section 3.1.2 with slight tweak to wording. [snip] > >> 6. [RFC6790] says that special purpose labels MUST NOT be used for > >> load balancing. The same logic applies to extended special > >> purpose labels (ESPLs). Thus, this document specifies that ESPLs > >> MUST NOT be used for load balancing. It is noted that existing > >> implementations may violate this, as they do not look for the XL > >> and thus for ESPLs. The consequence is that if ESPLs are used in > >> some packets of a flow, these packets may be delivered on > >> different paths and so could be re-ordered. However, it is > >> important to specify the correct behavior for future > >> implementations, hence the use of "MUST NOT". > >> > >> I would suggest that most implementations do violate this. I would > >> also suggest that it seems unlikely that you will get to the point > >> where it is not violated in the foreseeable future. > > I can't tell whether there is an action here for us. > > There are two "violations" that exist: > > 1. Some implementations violate 6790. Not sure what we can do about > > that in this document. Note that the entropy label can help with this > > but only to a limited extent since the implementations that violate 6790 > > probably also fail to recognise the entropy label. > > 2. Implementations that conform to 6790 will understand that the XL is > > a special purpose label and will not use it to load balance. But they will > > not necessarily understand that the next label is an ESPL that must be > > skipped as well. Again, there is nothing we can do about this except to > > note it (done) and possibly to use the EL further up the stack. > > My point was that the may in "It is noted that existing implementations may > violate this" was a little soft. Most implementations, except the latest > designs of maybe as few as a single vendor, would certainly violate this. > > Also of course you are making a statement of fact and not of permission > so I think it may be more precise to say: > > It is noted that most existing > implementations currently violate this, as they do not look for the XL > and thus for ESPLs. OK. I've gone with... It is noted that existing implementations would violate this, as they do not recognise XL as anything other than a single Special Purpose Label and will not expect an ESPL to follow. [snip] > >> Label 7 (when received) retains its meaning as ELI whether a regular > >> special purpose label or an ESPL; this simplifies a transit LSR's > >> task of looking for entropy labels since it may just look for label 7 > >> and need not verify that the previous label in the stack is not the > >> XL 15. However, an LSR wishing to insert an entropy label SHOULD > >> insert label 7 as a regular special purpose label, not as an ESPL. > >> > >> Why is this not a MUST! There is no ESPL in the wild running an > >> alternate behaviour, so why not simply mandate this? > > If this was a MUST then there would be no case for handling Label 7 after XL. > > There was some concern I believe that implementations might have a path that > > puts them on to XL insertion processing and then consider what to do next. At > > that point they might decide that label 7 is needed. > > > > It seems esoteric, but I couldn't see a reason to prohibit it. > > > > Maybe "MUST NOT include" and "SHOULD process when received" are > > compatible. > > > > Part of me hates the idea of this change just because I don't want another > > working group last call before we can move forward. How important is it? > > The reason to be stricter at the TX is that the forwarding path can be > simpler at the RX. I cannot see how you would get to the point of putting > in L15 and then saying "you know I need to put in L7" particularly as no > other 0..15 is allowed. > Normally I would think that you would put in the compound label as a pair > and that is a good reason to use the compound label concept. > > Also I see no reason for the inconsistency between L7 and all of the > other L0..L15 cases. > > So I think that it's OK, but probably silly to allow L0..L15, but to allow > the exception of just L7 just complicates things without good cause. I'm not in a position to argue on this one as the debate and text were driven by others. I believe that the claim was that allowing L7 to be inserted anywhere made processing it easier not harder at the receiver. Note that {XL,7} would be an error case in your way of looking at things so the receiver should (must?) not process it. But the claim was that h/w will simply search the stack for L7 so that allowing {L7} and {XL, L7} to be treated in the same way made life easier for the h/w. Bottom line, however, seems to be that you have a preference for doing it one way, and the WG has a preference for doing it a different way. How to resolve that? Given the posting deadline, I've not made any change for this. We can continue to discuss. > >> ======== > >> > >> 3.2. Process for Retiring Special Purpose Labels [snip] > >> Secondly I think the timescales are ridiculously optimistic. To get > >> a label out of circulation in 24 months seems most unlikely. Also > >> 6 month checks is a lot of work. > >> > >> A more realistic schedule would be to poll at 12month intervals until > >> such time as it is determined that reallocation would do not harm and > >> then give a further 12 months notice. > > Erm, that's what the text says, I think... > > > > 12 months after the RFC deprecating the label value is published, > > an IETF-wide survey may be conducted to determine if the > > deprecated label value is still in use. > > > > The "may" in that means that the earliest you can "poll" is 12 months after the > > deprecation RFC is published (noting that the RFC won't even get published > > until lots of discussion and consensus to deprecate). > > Then, *if* the poll response is OK, and then not earlier than 24 months after > > the deprecation RFC is published, publication can be requested for a new RFC > > (which means that the WG has already reached consensus, and that a > > subsequent IETF last call will be held). > > > > Frankly, I think that this process is only likely to be executed for SPLs that > > are allocated "in error", because other stuff will probably be in the field. Can > > you think of a label that was allocated in error? I can :-) > > This seems like a lot of text to specify in detail something we would never > run. In protocols, including this type of protocol, the fewer words used to > describe the rarely executed exception path the better. The case was considered worthy of inclusion because the SPL range is so small. If any SPL can be reclaimed at some future time it will be very valuable and so a mechanism needs to be documented against that happy day. [snip] > >> =========== [snip] > >> However that brings me to > >> suggest that you probably need to write an OPs section and > >> you might want to think about the PM implications of the extra > >> metatdata in the packets. > > > > What OPS issues had you in mind that need to be addressed? I am a fan of OPS > > sections, but not a fan of empty OPS sections, and when we looked through > > RFC 6123 (which is my favourite crib for what to describe wrt manageability) we > > didn't see anything that has changed from pre-existing MPLS. > > > > What metadata are you talking about? Is an existing special purpose label > > metadata? If so, the PM issues are pre-existing. Is there something special > > introduced by this I-D that constitutes metadata? > > Well what follows an XL is certainly metadata, and one application is > certainly to introduce tags that would alert the PM devices to take an > interest. OK it is a form of metadata as existing SPLs are metadata. The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI that the SPL is there. What has changed? We could certainly sit down and write an I-D about the implications of using MPLS in an environment where PM might be present (BTW, I assume this is Pervasive Monitoring. Would be embarrassing to find you meant something else :-). I think such an I-D would discuss SPLs as indicative metadata and would then note that ESPLs are in the same category. Is *this* the I-D in which to have that discussion? [snip] I'll post the revised I-D in a few minutes and others can throw vegetables (rotten or otherwise). Adrian From nobody Fri Feb 14 09:42: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 B02B71A032E for ; Fri, 14 Feb 2014 09:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qpheD3X8oO9X for ; Fri, 14 Feb 2014 09:42:13 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id CD1721A0214 for ; Fri, 14 Feb 2014 09:42:08 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-d6-52fe556fc782 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 38.FA.11484.F655EF25; Fri, 14 Feb 2014 18:42:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 12:41:52 -0500 From: Gregory Mirsky To: Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQQErWTRsEe5IUeaVctZClaFmpqztzjwgABYTAD//8I4UIABeH2A//+s7mCAAFt5gP//srUQ Date: Fri, 14 Feb 2014 17:41:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7627DE@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7627DEeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPlG5+6L8ggx8vRS22Pr3CaPH90hIW i1tLV7Ja/F1xhcWBxaPlyFtWjyVLfjJ5XG+6yu7x5fJntgCWKC6blNSczLLUIn27BK6M+3/P MxdMu8dUMff7DKYGxjvbmboYOTkkBEwkdpx7yQhhi0lcuLeerYuRi0NI4AijxOJlD1ggnOWM EhPn3WAHqWITMJJ4sbEHzBYRyJNofr4frJtZwFbizpNrYLawQKDE9NZrbBA1QRJLboAMArGj JB49W87cxcjBwSKgKnHtbChImFfAV2LBobdg5UICU1klTmypBrE5BcIkJr7/xgpiMwId9/3U GiaIVeISt57Mh3pAQGLJnvPMELaoxMvH/1ghbCWJSUvPsULU50us75zFCLFLUOLkzCcsExhF ZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR4SZGYAQe k2Bz3MG44JPlIUZpDhYlcd4vb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDGNEyYzTJ/ hxn7qiSXiLjVrBdjbFdGb5Rnv3hiry/LYoMFgUkPo18a9frdOiNo43+rhHWOos7Ja6udhPYp u0Z3Gbz6vnj16eQnDSoLUhVX6eZ9fbn0taDo26dhC8unpytJbMswz2Oqrtj/zM79VtkXAbW6 6yL7br4okL/0vZgt6/8Sv0wGG2ElluKMREMt5qLiRAAHMVWEjgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mOVHcUawRgOhL82Tpxv87pQwvck Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 17:42:19 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7627DEeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, AFAIK, you can use either link or node protection, not both at the same PLR= . If you believe otherwise, please illustrate with RSVP signaling scenario. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 9:16 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, For a transit node of an LSP and the link between the transit node and = the upstream node of the transit node, can we use both the link protection = define in RFC 4090 for protecting the link and the node protection defined = in RFC 4090 for protecting the transit node? If so, will this kind of deplo= yment lead to unpredictable results? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:04 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B7627DEeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

AFAIK, you can use either= link or node protection, not both at the same PLR. If you believe otherwis= e, please illustrate with RSVP signaling scenario.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Friday, February 14, 2014 9:16 AM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    For a = transit node of an LSP and the link between the transit node and the upstre= am node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC= 4090 for protecting the transit node? If so, will this kind of deployment = lead to unpredictable results?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B7627DEeusaamb103erics_-- From nobody Fri Feb 14 09:51: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 A4DB71A0331; Fri, 14 Feb 2014 09:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQursnXlhAdu; Fri, 14 Feb 2014 09:51:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB5C1A032F; Fri, 14 Feb 2014 09:51:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214175135.20443.67641.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 09:51:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CtdKSnW5xUKJBsC4H2D7__ihlXw Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-special-purpose-labels-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, 14 Feb 2014 17:51:42 -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 : Allocating and Retiring Special Purpose MPLS Labels Authors : Kireeti Kompella Loa Andersson Adrian Farrel Filename : draft-ietf-mpls-special-purpose-labels-05.txt Pages : 13 Date : 2014-02-14 Abstract: Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these special purpose labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines new procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. This document updates a number of previous RFCs that used the term "reserved label". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-special-purpose-labels-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 Feb 14 10:54: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 B7D561A038C; Fri, 14 Feb 2014 10:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EzpjJ05HPkx; Fri, 14 Feb 2014 10:54:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2E01A02D0; Fri, 14 Feb 2014 10:54:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214185400.3376.12133.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 10:54:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KiPMXx9Ccc71npZdR_hFffy-L6A Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:54:05 -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 : Seamless MPLS Architecture Authors : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-06.txt Pages : 40 Date : 2014-02-14 Abstract: This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mpls-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 12:05: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 86F2F1A0338; Fri, 14 Feb 2014 12:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naKs1_8w3Yli; Fri, 14 Feb 2014 12:05:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEA11A02BE; Fri, 14 Feb 2014 12:05:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214200507.12199.95584.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 12:05:07 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/a1bxURg7ABcfw-icdObN6YqvlyQ Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-10.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:05: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 : LDP Extensions for Multi Topology Authors : Quintin Zhao Kamran Raza Chao Zhou Luyuan Fang Lianyuan Li Daniel King Filename : draft-ietf-mpls-ldp-multi-topology-10.txt Pages : 17 Date : 2014-02-14 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-multi-topology-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 12:49:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360661A0372; Fri, 14 Feb 2014 12:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuf7vPQtmNaT; Fri, 14 Feb 2014 12:49:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358D1A03C6; Fri, 14 Feb 2014 12:49:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214204926.6260.62683.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 12:49:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kG-rXADVRt__CgDd0QMlMJCSDDc Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:49:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Extensions for Multi Topology Authors : Quintin Zhao Kamran Raza Chao Zhou Luyuan Fang Lianyuan Li Daniel King Filename : draft-ietf-mpls-ldp-multi-topology-11.txt Pages : 18 Date : 2014-02-14 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-multi-topology-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 14:08: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 1B8741A015E for ; Fri, 14 Feb 2014 14:08:07 -0800 (PST) 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 yofUPIJOb3eO for ; Fri, 14 Feb 2014 14:08:01 -0800 (PST) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id CA14A1A00BB for ; Fri, 14 Feb 2014 14:07:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe01.verizonbusiness.com with ESMTP; 14 Feb 2014 22:07:53 +0000 From: "Xu, Fengman" X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208,217";a="653942765" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 14 Feb 2014 22:07:52 +0000 Received: from FHDP1LUMXC7V33.us.one.verizon.com ([166.68.125.34]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Fri, 14 Feb 2014 17:07:52 -0500 To: "mpls@ietf.org" Date: Fri, 14 Feb 2014 17:07:51 -0500 Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: Ac8pvjUC1sQYghaBRGCmTnPmYHjxdQ== Message-ID: <65017ED8D0F1E343AF27F9E2F24859F216B6A6385C@FHDP1LUMXC7V33.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_65017ED8D0F1E343AF27F9E2F24859F216B6A6385CFHDP1LUMXC7V3_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aX0ALRa7EzNieuJr4q6zxlXAT2g Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 14 Feb 2014 22:08:07 -0000 --_000_65017ED8D0F1E343AF27F9E2F24859F216B6A6385CFHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as co-author Fengman From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_65017ED8D0F1E343AF27F9E2F24859F216B6A6385CFHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=  

Support as co-author=

 

Fengman

 

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behal= f Of Ross Callon
Sent: Thursday, February 13, 2014 2:46 PMTo: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org<= /a>
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress= -protection-11

 <= /p>

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014. Note that this is the Friday of t= he IETF,

and thus we will each need to = plan our review of the document and response

around our travel plans and IETF activities.

 

Thanks, Ross

 

= --_000_65017ED8D0F1E343AF27F9E2F24859F216B6A6385CFHDP1LUMXC7V3_-- From fengman.xu@verizon.com Mon Feb 10 14:38: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 845F91A0488 for ; Mon, 10 Feb 2014 14:38:31 -0800 (PST) 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 NDvBWbkgA4UE for ; Mon, 10 Feb 2014 14:38:28 -0800 (PST) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id BC0411A05F2 for ; Mon, 10 Feb 2014 14:38:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe02.verizonbusiness.com with ESMTP; 10 Feb 2014 22:38:26 +0000 From: "Xu, Fengman" X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208,217";a="668531456" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 10 Feb 2014 22:38:26 +0000 Received: from FHDP1LUMXC7V33.us.one.verizon.com ([169.254.3.214]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Mon, 10 Feb 2014 17:38:26 -0500 To: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Date: Mon, 10 Feb 2014 17:38:24 -0500 Thread-Topic: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac8mr/26/aVSVGaGSPqM75YjUTXalQAADaXg Message-ID: <65017ED8D0F1E343AF27F9E2F24859F216B530D498@FHDP1LUMXC7V33.us.one.verizon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_65017ED8D0F1E343AF27F9E2F24859F216B530D498FHDP1LUMXC7V3_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 14 Feb 2014 18:11:44 -0800 Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 10 Feb 2014 22:38:31 -0000 --_000_65017ED8D0F1E343AF27F9E2F24859F216B530D498FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR associated with this draft. Best regards, Fengman Xu From: LEI LIU [mailto:liulei.kddi@gmail.com] Sent: Monday, February 10, 2014 4:32 PM To: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls= -p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-chen-mpls-p2mp-egress-protection I am not aware of any IPR associated with this draft. Best regards, Lei Liu 2014-02-10 13:53 GMT-08:00 Ning So >: I am not aware of any IPR associated with this draft. Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications (Cell) 972-955-0914 -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net] Sent: Monday, February 10, 2014 3:51 PM To: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protec= tion@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin V= igoureux Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection Working Group, The authors of draft-chen-mpls-p2mp-egress-protection have told the working= group chairs that the draft is ready to be adopted as a working group docu= ment. Before starting the the poll to see if we have consensus to make this a wor= king group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-p2mp-egress-protec= tion? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and each contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- -- __________________________________ Best Regards, Sincerely Yours, Lei Liu, Ph.D -------------------- Photonic Transport Network Laboratory, KDDI R&D Laboratories Inc., 2-1-15 Ohara Fujimino-shi, Saitama, Japan TELE: +81-49-278-7536 FAX: +81-49-278-7510 ZIP: 356-8502 E-mail: le-liu@kddilabs.jp / liulei@ieee.org --_000_65017ED8D0F1E343AF27F9E2F24859F216B530D498FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR= associated with this draft.

Best regards,

 

Fengman = Xu

 

From: LEI LIU [mailto:liulei.kddi@gmail.com]
Sent: Monday, February 10, 2014 4:32 PM
To: Ross Callon; mpl= s@ietf.org; mpls-chairs@tools.ietf.org; draft-chen-mpls-p2mp-egress-protect= ion@tools.ietf.org
Subject: Re: [mpls] IPR Poll on draft-chen-mpl= s-p2mp-egress-protection

&nb= sp;

I am not aware of any IPR associated with thi= s draft.

Best regards,

Le= i Liu

 

2014-02-10 13:53 GM= T-08:00 Ning So <Ning.So@tatacommunications.com>:

I am not aware of any IPR associated with this draft.

B= est regards,

Ning So
Head of Network Architecture
Mobile Broad= band Services
Tata Communications
(Cell) 972-955-0914


-----Ori= ginal Message-----
From: Ross Callon [mailto:rcallon@juniper.net]
Sent: Monday, February 10, 2014 3:5= 1 PM
To: mpls@ietf.org; draft-chen-mp= ls-p2mp-egress-protection@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux
= Subject: IPR Poll on draft-chen-mpls-p2mp-egress-protection

Working = Group,

The authors of draft-chen-mpls-p2mp-egress-protection have to= ld the working group chairs that the draft is ready to be adopted as a work= ing group document.

Before starting the the poll to see if we have c= onsensus to make this a working group document we need to do an IPR poll.
This mail starts that IPR poll.

Are you aware of any IPR that = applies to draft-chen-mpls-p2mp-egress-protection?

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

If you are listed as a document auth= or 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 MP= LS wg mailing list. The documents will not advance to the next stage until = a response has been received from each author and each contributor.

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

Thank= s, Ross
(as MPLS WG co-chair)


_______________________________= ________________
mpls mailing list
m= pls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls=



<= /p>

 

--

-- 

=

__________________________________

=

Best Regards,

 

Since= rely Yours,

Lei Liu, Ph.D

--------------------<= /p>

Photonic Transport Network Laboratory,

KDDI R&D Laboratories Inc.= ,

2-1-15 Ohara Fujimino-shi, = Saitama, Japan 

TELE: +8= 1-49-278-7536

FAX: +81-49-278= -7510

ZIP: 356-8502

=
= --_000_65017ED8D0F1E343AF27F9E2F24859F216B530D498FHDP1LUMXC7V3_-- From nobody Fri Feb 14 18:11:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EA11A0254 for ; Fri, 14 Feb 2014 06:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.704 X-Spam-Level: X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 OqBPoWiHh1mf for ; Fri, 14 Feb 2014 06:54:20 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id B6FDD1A022E for ; Fri, 14 Feb 2014 06:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17677; q=dns/txt; s=iport; t=1392389658; x=1393599258; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uou43iojBPcPsLdwaQd4Lo3tub9io9eijkasu/DX2Go=; b=K6IWTkg9tACc2kOt1fkYfXgHQoUdALhL2B4P11G9KqiM7Bk9a1XsmqV9 3gzJ7FF7rgLBeOr8ffyzSIkRLxEm6Ifr/T1dETihgq1O+OgbSmFcmGI7d KNU0tMiEs/3fFaCs9cRAB4rupy8SrW0Qxj5rK7GKMMMhSbXI6WSGTSUGR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAJ0t/lKQ/khM/2dsb2JhbABZgwY4wAmBFBZ0giUBAQEDAQ4KIC0GAwYEARALGAkWDwkDAgECAUUHDAEHAQGHeQgNySEXjiEBBgEBHDMHhDgElEODaZIjgy2BaAEIFw X-IronPort-AV: E=Sophos;i="4.95,845,1384300800"; d="scan'208";a="338930" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-4.cisco.com with ESMTP; 14 Feb 2014 14:54:17 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1EEsGKQ016787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 14:54:16 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1EEsCoX018618; Fri, 14 Feb 2014 14:54:13 GMT Message-ID: <52FE2E14.3010903@cisco.com> Date: Fri, 14 Feb 2014 14:54:12 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-mpls-special-purpose-labels@tools.ietf.org References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> In-Reply-To: <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hdTGNlop5MRJhVCySyqesLsiPL8 X-Mailman-Approved-At: Fri, 14 Feb 2014 18:11:44 -0800 Cc: Alia Atlas Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels 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, 14 Feb 2014 14:54:24 -0000 On 11/02/2014 20:07, Adrian Farrel wrote: > Hi Stewart, > > Thanks for this. Can we copy the thread to the WG mailing list? Sure. Doing that. > >> I have reviewed this draft and have a few comments that I would >> like to discuss before it goes to IETF LC. >> >> It is possible that Alia may have some additional comments >> and since it will fall to her to take this through the IESG >> you should give priority to any comments that she makes. > So I cc'ed her here. > >> XL The Extension Label that indicates that an extended special >> purpose label follows. >> >> ESPL An Extended Special Purpose Label. >> >> Something that I think would be worthwhile clarifying right at the >> front is that a label is an ESPL IFF it is preceded by an XL. >> It might even be worth noting that really we have a new label type: >> a label couple in which the first label defines the type of the >> second label and neither are of any use as individual labels. > I can see how you would see this as a new label type. Maybe "compound" rather > than "couple". > However, I am not convinced that it is new that one label leads to the semantics > of the next (for example the entropy label). > What is more, I am not sure that there will be more than this instance of this > type of tight coupling. > So I would rather leave this point out. I can foresee other cases where we might use label pairs to mitigate the 20bit limit. I am sure it has been discussed, so creating the reference might be useful. Just because this was not done in EL, does not mean that we should not set down the concept here. However I agree compound would be a better term. > > But as to clarifying ESPL: yes. > The XP definition is, I think, clear. > How about... > > ESPL An Extended Special Purpose Label. A Special Purpose Label that > is placed in the label stack after the Extension Label. Yes. Indeed it MUST be placed be placed there, however the definition above is fine. > >> ====== >> >> I think that the draft will need to provide some guidance >> on when to allocate a 0..15 and when to allocate an ESPL. >> >> I imagine that a 0..15 should only be used when it can be shown >> that the extra stack space of forwarding time is burdensome >> but that is a question that the WG should explicitly consider. > We discussed this at some point on the MPLS list (many centuries ago, I think) > and reached no conclusion. > The primary purpose of the XL is to handle the time when 0..15 is depleted. > You're right that we could encourage people to start using ESPLs now before > 0..15 is depleted. But it is hard to make the case for requiring it when there > is still some of 0..15 available and the rate of burn is not so high. > > We could put in some text like... > > When allocating a new Special Purpose Label, protocol designers should consider > whether they could, instead, use an Extended Special Purpose Label. Doing so > would help to preserve the scarce resources of Special Purpose Labels for use in > cases where minimizing the label stack size is particularly important. That would be useful text. >> ====== >> >> 2. A Standards Track RFC must accompany a request for allocation of >> Standards Action special purpose labels, as per [RFC5226]. >> >> You need to clarify whether this is a 0..15 SPL, an ESPL or both. > Section 3, answer 2 (which you quote) is answering Section 2 question 2. > Both explicitly state "special purpose label". > It is not until question 5 and its answer that extended special purpose labels > come in. > The IANA considerations section describes the allocation policies for ESPLs. OK > >> ====== >> >> 6. [RFC6790] says that special purpose labels MUST NOT be used for >> load balancing. The same logic applies to extended special >> purpose labels (ESPLs). Thus, this document specifies that ESPLs >> MUST NOT be used for load balancing. It is noted that existing >> implementations may violate this, as they do not look for the XL >> and thus for ESPLs. The consequence is that if ESPLs are used in >> some packets of a flow, these packets may be delivered on >> different paths and so could be re-ordered. However, it is >> important to specify the correct behavior for future >> implementations, hence the use of "MUST NOT". >> >> I would suggest that most implementations do violate this. I would >> also suggest that it seems unlikely that you will get to the point >> where it is not violated in the foreseeable future. > I can't tell whether there is an action here for us. > There are two "violations" that exist: > 1. Some implementations violate 6790. Not sure what we can do about > that in this document. Note that the entropy label can help with this > but only to a limited extent since the implementations that violate 6790 > probably also fail to recognise the entropy label. > 2. Implementations that conform to 6790 will understand that the XL is > a special purpose label and will not use it to load balance. But they will > not necessarily understand that the next label is an ESPL that must be > skipped as well. Again, there is nothing we can do about this except to > note it (done) and possibly to use the EL further up the stack. My point was that the may in "It is noted that existing implementations may violate this" was a little soft. Most implementations, except the latest designs of maybe as few as a single vendor, would certainly violate this. Also of course you are making a statement of fact and not of permission so I think it may be more precise to say: It is noted that most existing implementations currently violate this, as they do not look for the XL and thus for ESPLs. > >> ===== >> >> A further question to be settled in this regard is whether a >> "regular" special purpose label retains its meaning if it follows the >> XL; see Section 3.1. >> >> The way that you start the para it looks like this is an open question >> could I suggest rewording so that it is clear that this is a resolved >> matter. > OLD > A further question to be settled in this regard is whether a > "regular" special purpose label retains its meaning if it follows the > XL; see Section 3.1. > NEW > A further question that needed to be settled in this regard was > whether a "regular" special purpose label retains its meaning if it > follows the XL. This answer to this question is provided in Section > 3.1. > END yes. >> ======= >> >> Label 7 (when received) retains its meaning as ELI whether a regular >> special purpose label or an ESPL; this simplifies a transit LSR's >> task of looking for entropy labels since it may just look for label 7 >> and need not verify that the previous label in the stack is not the >> XL 15. However, an LSR wishing to insert an entropy label SHOULD >> insert label 7 as a regular special purpose label, not as an ESPL. >> >> Why is this not a MUST! There is no ESPL in the wild running an >> alternate behaviour, so why not simply mandate this? > If this was a MUST then there would be no case for handling Label 7 after XL. > There was some concern I believe that implementations might have a path that > puts them on to XL insertion processing and then consider what to do next. At > that point they might decide that label 7 is needed. > > It seems esoteric, but I couldn't see a reason to prohibit it. > > Maybe "MUST NOT include" and "SHOULD process when received" are compatible. > > Part of me hates the idea of this change just because I don't want another > working group last call before we can move forward. How important is it? The reason to be stricter at the TX is that the forwarding path can be simpler at the RX. I cannot see how you would get to the point of putting in L15 and then saying "you know I need to put in L7" particularly as no other 0..15 is allowed. Normally I would think that you would put in the compound label as a pair and that is a good reason to use the compound label concept. Also I see no reason for the inconsistency between L7 and all of the other L0..L15 cases. So I think that it's OK, but probably silly to allow L0..L15, but to allow the exception of just L7 just complicates things without good cause. > >> ======== >> >> 3.2. Process for Retiring Special Purpose Labels >> >> While the following process is defined for the sake of completeness, >> note that retiring special purpose labels is difficult. It is >> recommended that this process be used sparingly. >> >> a. A label value that has been assigned from the "Special Purpose >> MPLS Label Values" may be deprecated by IETF consensus with >> review by the MPLS working group (or designated experts if the >> working group or a successor does not exist). An RFC with at >> least Informational status is required. >> >> The RFC will direct the IANA to mark the label value as >> "deprecated" in the registry, but will not release it at this >> stage. >> >> Deprecating means that no further specifications using the >> deprecated value will be documented. >> >> At the same time this is an indication to vendors not to include >> the deprecated value in new implementations, and to operators to >> avoid including it in new deployments. >> >> b. 12 months after the RFC deprecating the label value is published, >> an IETF-wide survey may be conducted to determine if the >> deprecated label value is still in use. If the survey indicates >> that the deprecated label value is in use, the survey may be >> repeated after a further 6 months. >> >> c. 24 months after the RFC that deprecated the label value was >> published and if the survey indicates that deprecated label value >> is not in use, publication may be requested of an IETF Standards >> Track Internet-Draft that retires the deprecated the label value. >> This document will request IANA to release the label value for >> for future use and assignment. >> >> I have two comments on this. Firstly why is it necessary to specify the >> MPLS WG. If the action is IETF consensus, then this will get picked but >> my MPLS WG then IETF LC and then ADs. There are enough checks and >> balances in the system that there is no need to call up a specific >> WG that may or may not be in existence. > I think the wording is very fine in terms of setting expectations. > The expectation is that there will be IETF consensus and that, along the way, > the MPLS WG will review the decision. > I think this is almost certainly business as usual, but writing it down doesn't > seem to hurt. OK > >> Secondly I think the timescales are ridiculously optimistic. To get >> a label out of circulation in 24 months seems most unlikely. Also >> 6 month checks is a lot of work. >> >> A more realistic schedule would be to poll at 12month intervals until >> such time as it is determined that reallocation would do not harm and >> then give a further 12 months notice. > Erm, that's what the text says, I think... > > 12 months after the RFC deprecating the label value is published, > an IETF-wide survey may be conducted to determine if the > deprecated label value is still in use. > > The "may" in that means that the earliest you can "poll" is 12 months after the > deprecation RFC is published (noting that the RFC won't even get published until > lots of discussion and consensus to deprecate). > Then, *if* the poll response is OK, and then not earlier than 24 months after > the deprecation RFC is published, publication can be requested for a new RFC > (which means that the WG has already reached consensus, and that a subsequent > IETF last call will be held). > > Frankly, I think that this process is only likely to be executed for SPLs that > are allocated "in error", because other stuff will probably be in the field. Can > you think of a label that was allocated in error? I can :-) This seems like a lot of text to specify in detail something we would never run. In protocols, including this type of protocol, the fewer words used to describe the rarely executed exception path the better. > >> =========== >> >> | 7 | Allocated; meaning is ELI [RFC6790] | >> >> I do not understand why you need the complexity of this exception. > So you said above. > Is there a problem? > Does it break something badly, or is it just not what you would have done? I can like with the complexity, but as I noted above complexity rarely executed leads to interesting bugs. > >> ============ >> >> 6. Security Considerations >> >> This document does not make a large change to the operation of the >> MPLS data plane >> >> That is an incorrect statement! This memo explicitly makes changes >> to the MPLS DP! > The text does not say that the document makes no changes to the data plane. It > says no large change to the operation of the data plane. > > What text would you prefer in the context of the Security Considerations? Sorry I misread it and missed the word "large". The text is fine. > >> =========== >> >> This document provides a protocol-legal way to >> arbitrarily increase the label stack and so might provide a way to >> attack some nodes in a network without violating the protocol rules. >> >> I think that this already exists with the ELI doesn't it? > To a different order of magnitude (different arbitrariness?). > One could argue that a large number of {ELI, EL} pairs could be inserted, where > this I-D doesn't really change anything that already exists. > > Actually, I think this text dates from when XL was a legal ESPL. That was > nonsense we managed to squash despite the "architects" who thought it was > beautiful. > > It might be better to say... > > This document provides a protocol-legal way to > increase the label stack through the insertion of additional {XL,ESPL} > pairs at a greater rate than insertion of single "rogue" labels. This > might provide a way to attack some nodes in a network that can only > process label stacks of a certain size without violating the protocol > rules. Yes, that is better. > >> =========== >> >> This document also describes events that may cause an LSR to issue >> event logs at a per-packet rate. It is critically important that >> implementations rate-limit such logs. >> >> I do not see any text on this at all! However that brings me to >> suggest that you probably need to write an OPs section and >> you might want to think about the PM implications of the extra >> metatdata in the packets. > Section 3.1.1 has > If an LSR encounters the XL at the top of stack and it doesn't > understand extension labels, it SHOULD drop the packet as specified > for the handling of any unknown lable according to [RFC3031]. If an > LSR encounters an ESPL at the top of stack (after the XL) and does > not understand the ESPL, it SHOULD drop the packet, again following > the procedures for unknown labels as set out in [RFC3031]. In either > case, the LSR MAY log the event, but such logging MUST be rate- > limited. > Without rate limiting on the logging, this is an attack vector. OK and I agree that if the section is null it should not be included. I imagine that there will be concerns about how you know that you can introduce the feature, and what you do in the event of re-routing etc. If you do not think there are other considerations we can leave the text and get the Ops folks to comment later in the process. > > What OPS issues had you in mind that need to be addressed? I am a fan of OPS > sections, but not a fan of empty OPS sections, and when we looked through RFC > 6123 (which is my favourite crib for what to describe wrt manageability) we > didn't see anything that has changed from pre-existing MPLS. > > What metadata are you talking about? Is an existing special purpose label > metadata? If so, the PM issues are pre-existing. Is there something special > introduced by this I-D that constitutes metadata? Well what follows an XL is certainly metadata, and one application is certainly to introduce tags that would alert the PM devices to take an interest. > >> How do you know if the target can accept ESPLs? Do you need to specify >> some sort if ICMP response given that there could be a lot more >> SPLs as a result of this. > How do you know if the target can accept a new SPL? > I don't think that prevents us from assigning them, and each I-D that assigns a > new one has to worry about backward compatibility. Note that the default > backward compatibility is covered by "drop packets with unrecognised labels". > In this respect XL is just another SPL that might be unrecognised. > Below XL, each ESPL is just another ESPL that might be unrecognised and will > also cause the packet to be dropped (see 3.1.1) > Any I-D that defines a new ESPL will have to worry about backward compatibility > for that ESPL. This I-D does not have that problem. OK Stewart > Cheers, > Adrian > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Fri Feb 14 18:52: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 2972C1A002B for ; Fri, 14 Feb 2014 18:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwMOruVnXG_a for ; Fri, 14 Feb 2014 18:52:47 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBFA1A0026 for ; Fri, 14 Feb 2014 18:52:46 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id z6so12654307yhz.27 for ; Fri, 14 Feb 2014 18:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/pC6peO5u48tAKooyT33aK2FaL622WxUFrrkJdYqjJk=; b=sU7nlv/3huDlHKiG9t7F/DA/JLajx+Ur/eEAAhtHEn7kY3s+/cmMpEmqIS0bYOfAST /5mirGBw1EUYSHROFbKTlrsaN9Az1hWo2vzS2oYtQajUX72mXFCS++ipgZOkxP3h1OzO US1kkkONXKp77e7L0ZvzMBNAkcDMm3vj9IMpecByqGoIuo1y/khtJcoDC085JGsMz3BX n67A+JHwyEeJBATkP58QERaM03pFIHehYMdXtbSH+kHqDsyGoMsDZseql4SWcv3kW2DC npFf5zwtar7d6syP2y7D/6MCvA/6n77pEC4NUFu99TKAXTShypm5uDU5TNKDOICWmPsl IvGA== MIME-Version: 1.0 X-Received: by 10.236.7.231 with SMTP id 67mr6304060yhp.30.1392432765182; Fri, 14 Feb 2014 18:52:45 -0800 (PST) Received: by 10.170.185.212 with HTTP; Fri, 14 Feb 2014 18:52:45 -0800 (PST) In-Reply-To: <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> Date: Fri, 14 Feb 2014 21:52:45 -0500 Message-ID: From: Alia Atlas To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a11c1fd2457a65804f2690451 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/41FHvOskenGHGPrKABIA_0Aw6Fk Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 15 Feb 2014 02:52:53 -0000 --001a11c1fd2457a65804f2690451 Content-Type: text/plain; charset=ISO-8859-1 Adrian and others, Having reviewed the 05 of this draft and this thread, I have the following suggestions. Other than these, I'm quite happy with how this draft has improved. a) In Sec 3.1, the following paragraph could be updated from: " Label 7 (when received) retains its meaning as ELI whether a regular special purpose label or an ESPL; this simplifies a transit LSR's task of looking for entropy labels since it may just look for label 7 and need not verify that the previous label in the stack is not the XL 15. However, an LSR wishing to insert an entropy label SHOULD insert label 7 as a regular special purpose label, not as an ESPL." to: "An LSR wishing to insert an entropy label MUST insert label value 7 (meaning ELI) as a regular special purpose label and not as an ESPL. Value 7 MUST NOT be sent as an ESPL in the data plane. However, to simplify the data plane implementation for Entropy Labels, an implementation MAY interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, an implementation MAY choose to not treat the packet as malformed and thus discard it. The data plane simplification thus enabled is the ability to determine if any label value is 7 without needing to verify that the previous label in the stack is not the XL value of 15." b) In Sec 3.2: "An RFC with at least Informational status is required." How is this different from IETF Review in RFC 5226? Do BCPs count? What is "at least Informational status"? On the concern about Pervasive Monitoring, the only advantage that (XL, ESPL) offers is that the labels wouldn't (eventually) be hashed for load-balancing. Otherwise, the label stack offers the ability for meta-data already where only the receiver would need to understand it. Consistent paths are very useful, but there are other ways of doing this already - with the most trivial being just using label 15. I have a hard time seeing this as a new attack vector (but I'm not professionally paranoid yet). Alia On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel wrote: > [snip] > > > >> XL The Extension Label that indicates that an extended special > > >> purpose label follows. > > >> > > >> ESPL An Extended Special Purpose Label. > > >> > > >> Something that I think would be worthwhile clarifying right at the > > >> front is that a label is an ESPL IFF it is preceded by an XL. > > >> It might even be worth noting that really we have a new label type: > > >> a label couple in which the first label defines the type of the > > >> second label and neither are of any use as individual labels. > > > I can see how you would see this as a new label type. Maybe "compound" > > > rather than "couple". > > > However, I am not convinced that it is new that one label leads to the > semantics > > > of the next (for example the entropy label). > > > What is more, I am not sure that there will be more than this instance > of > this > > > type of tight coupling. > > > So I would rather leave this point out. > > I can foresee other cases where we might use label pairs to mitigate the > > 20bit limit. I am sure it has been discussed, so creating the reference > > might be useful. Just because this was not done in EL, does not mean that > > we should not set down the concept here. > > > > However I agree compound would be a better term. > > > > > > > > But as to clarifying ESPL: yes. > > > The XP definition is, I think, clear. > > > How about... > > > > > > ESPL An Extended Special Purpose Label. A Special Purpose Label that > > > is placed in the label stack after the Extension Label. > > > > Yes. Indeed it MUST be placed be placed there, however the definition > > above is fine. > > OK, I updated to... > > ESPL An Extended Special Purpose Label. A Special Purpose Label that > is placed in the label stack after the Extension Label. The > combination of XL and ESPL might be regarded as a new form of > "compound label" comprising more than one consecutive entry in > the label stack. > > ..to cover your other point as well. > > > >> ====== > > >> > > >> I think that the draft will need to provide some guidance > > >> on when to allocate a 0..15 and when to allocate an ESPL. > > >> > > >> I imagine that a 0..15 should only be used when it can be shown > > >> that the extra stack space of forwarding time is burdensome > > >> but that is a question that the WG should explicitly consider. > > > We discussed this at some point on the MPLS list (many centuries ago, I > think) > > > and reached no conclusion. > > > The primary purpose of the XL is to handle the time when 0..15 is > depleted. > > > You're right that we could encourage people to start using ESPLs now > before > > > 0..15 is depleted. But it is hard to make the case for requiring it > when > there > > > is still some of 0..15 available and the rate of burn is not so high. > > > > > > We could put in some text like... > > > > > > When allocating a new Special Purpose Label, protocol designers should > > > consider whether they could, instead, use an Extended Special Purpose > > > Label. Doing so would help to preserve the scarce resources of Special > > > Purpose Labels for use in cases where minimizing the label stack size > is > > > particularly important. > > > > That would be useful text. > > Added as new section 3.1.2 with slight tweak to wording. > > [snip] > > > >> 6. [RFC6790] says that special purpose labels MUST NOT be used > for > > >> load balancing. The same logic applies to extended special > > >> purpose labels (ESPLs). Thus, this document specifies that > ESPLs > > >> MUST NOT be used for load balancing. It is noted that existing > > >> implementations may violate this, as they do not look for the > XL > > >> and thus for ESPLs. The consequence is that if ESPLs are used > in > > >> some packets of a flow, these packets may be delivered on > > >> different paths and so could be re-ordered. However, it is > > >> important to specify the correct behavior for future > > >> implementations, hence the use of "MUST NOT". > > >> > > >> I would suggest that most implementations do violate this. I would > > >> also suggest that it seems unlikely that you will get to the point > > >> where it is not violated in the foreseeable future. > > > I can't tell whether there is an action here for us. > > > There are two "violations" that exist: > > > 1. Some implementations violate 6790. Not sure what we can do about > > > that in this document. Note that the entropy label can help with this > > > but only to a limited extent since the implementations that violate > 6790 > > > probably also fail to recognise the entropy label. > > > 2. Implementations that conform to 6790 will understand that the XL is > > > a special purpose label and will not use it to load balance. But they > will > > > not necessarily understand that the next label is an ESPL that must be > > > skipped as well. Again, there is nothing we can do about this except to > > > note it (done) and possibly to use the EL further up the stack. > > > > My point was that the may in "It is noted that existing implementations > may > > violate this" was a little soft. Most implementations, except the latest > > designs of maybe as few as a single vendor, would certainly violate this. > > > > Also of course you are making a statement of fact and not of permission > > so I think it may be more precise to say: > > > > It is noted that most existing > > implementations currently violate this, as they do not look for the XL > > and thus for ESPLs. > > OK. > > I've gone with... > > It is noted that existing > implementations would violate this, as they do not recognise XL > as anything other than a single Special Purpose Label and will > not expect an ESPL to follow. > > [snip] > > > >> Label 7 (when received) retains its meaning as ELI whether a > regular > > >> special purpose label or an ESPL; this simplifies a transit LSR's > > >> task of looking for entropy labels since it may just look for > label 7 > > >> and need not verify that the previous label in the stack is not the > > >> XL 15. However, an LSR wishing to insert an entropy label SHOULD > > >> insert label 7 as a regular special purpose label, not as an ESPL. > > >> > > >> Why is this not a MUST! There is no ESPL in the wild running an > > >> alternate behaviour, so why not simply mandate this? > > > If this was a MUST then there would be no case for handling Label 7 > after > XL. > > > There was some concern I believe that implementations might have a > path that > > > puts them on to XL insertion processing and then consider what to do > next. > At > > > that point they might decide that label 7 is needed. > > > > > > It seems esoteric, but I couldn't see a reason to prohibit it. > > > > > > Maybe "MUST NOT include" and "SHOULD process when received" are > > > compatible. > > > > > > Part of me hates the idea of this change just because I don't want > another > > > working group last call before we can move forward. How important is > it? > > > > The reason to be stricter at the TX is that the forwarding path can be > > simpler at the RX. I cannot see how you would get to the point of putting > > in L15 and then saying "you know I need to put in L7" particularly as no > > other 0..15 is allowed. > > Normally I would think that you would put in the compound label as a pair > > and that is a good reason to use the compound label concept. > > > > Also I see no reason for the inconsistency between L7 and all of the > > other L0..L15 cases. > > > > So I think that it's OK, but probably silly to allow L0..L15, but to > allow > > the exception of just L7 just complicates things without good cause. > > I'm not in a position to argue on this one as the debate and text were > driven by > others. > > I believe that the claim was that allowing L7 to be inserted anywhere made > processing it easier not harder at the receiver. > Note that {XL,7} would be an error case in your way of looking at things > so the > receiver should (must?) not process it. > But the claim was that h/w will simply search the stack for L7 so that > allowing > {L7} and {XL, L7} to be treated in the same way made life easier for the > h/w. > > Bottom line, however, seems to be that you have a preference for doing it > one > way, and the WG has a preference for doing it a different way. How to > resolve > that? > > Given the posting deadline, I've not made any change for this. We can > continue > to discuss. > > > >> ======== > > >> > > >> 3.2. Process for Retiring Special Purpose Labels > > [snip] > > > >> Secondly I think the timescales are ridiculously optimistic. To get > > >> a label out of circulation in 24 months seems most unlikely. Also > > >> 6 month checks is a lot of work. > > >> > > >> A more realistic schedule would be to poll at 12month intervals until > > >> such time as it is determined that reallocation would do not harm and > > >> then give a further 12 months notice. > > > Erm, that's what the text says, I think... > > > > > > 12 months after the RFC deprecating the label value is > published, > > > an IETF-wide survey may be conducted to determine if the > > > deprecated label value is still in use. > > > > > > The "may" in that means that the earliest you can "poll" is 12 months > after > the > > > deprecation RFC is published (noting that the RFC won't even get > published > > > until lots of discussion and consensus to deprecate). > > > Then, *if* the poll response is OK, and then not earlier than 24 months > after > > > the deprecation RFC is published, publication can be requested for a > new RFC > > > (which means that the WG has already reached consensus, and that a > > > subsequent IETF last call will be held). > > > > > > Frankly, I think that this process is only likely to be executed for > SPLs > that > > > are allocated "in error", because other stuff will probably be in the > field. > Can > > > you think of a label that was allocated in error? I can :-) > > > > This seems like a lot of text to specify in detail something we would > never > > run. In protocols, including this type of protocol, the fewer words used > to > > describe the rarely executed exception path the better. > > The case was considered worthy of inclusion because the SPL range is so > small. > If any SPL can be reclaimed at some future time it will be very valuable > and so > a mechanism needs to be documented against that happy day. > > [snip] > > >> =========== > [snip] > > >> However that brings me to > > >> suggest that you probably need to write an OPs section and > > >> you might want to think about the PM implications of the extra > > >> metatdata in the packets. > > > > > > What OPS issues had you in mind that need to be addressed? I am a fan > of OPS > > > sections, but not a fan of empty OPS sections, and when we looked > through > > > RFC 6123 (which is my favourite crib for what to describe wrt > manageability) > we > > > didn't see anything that has changed from pre-existing MPLS. > > > > > > What metadata are you talking about? Is an existing special purpose > label > > > metadata? If so, the PM issues are pre-existing. Is there something > special > > > introduced by this I-D that constitutes metadata? > > > > Well what follows an XL is certainly metadata, and one application is > > certainly to introduce tags that would alert the PM devices to take an > > interest. > > OK it is a form of metadata as existing SPLs are metadata. > The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI that > the SPL > is there. > What has changed? > We could certainly sit down and write an I-D about the implications of > using > MPLS in an environment where PM might be present (BTW, I assume this is > Pervasive Monitoring. Would be embarrassing to find you meant something > else > :-). I think such an I-D would discuss SPLs as indicative metadata and > would > then note that ESPLs are in the same category. > Is *this* the I-D in which to have that discussion? > > [snip] > > I'll post the revised I-D in a few minutes and others can throw vegetables > (rotten or otherwise). > > Adrian > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c1fd2457a65804f2690451 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrian and others,

Having reviewed the = 05 of this draft and this thread, I have the following suggestions. =A0Othe= r than these, I'm quite happy with how this draft has improved.

a) In Sec 3.1, the following paragraph could be updated from= :

" Label 7 (when received) retains its meaning as E= LI whether a regular=A0special purpose label or an ESPL; this simplifies a tr= ansit LSR's=A0task of looking for entropy labels since it may just look f= or label 7=A0 and need not verify that the previous label in the stack is not= the=A0XL 15. However, an LSR wishing to insert an entropy label SHOULD=A0inse= rt label 7 as a regular special purpose label, not as an ESPL."= 

to:

"An LSR wishing to insert an entropy =
label MUST insert label value 7 (meaning ELI) as a regular special purpose<=
/pre>

label and not as an ESPL.  Value 7 MUST NOT be sent as an ESPL in the data =
plane.  However, to simplify


the data plane implementation for Entropy Labels, an=
 implementation MAY
interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, =
an implementation=A0
MAY choose to not treat th=
e packet as malformed a=
nd thus discard it.  The data plane simplification thus enabled

=
is the ability to determine if any label value is 7 without needing to veri=
fy that the previous label in the stack is not the XL value of 15."


=

b) In Sec 3.2: "An RFC with at least Informational status is req=
uired."   How is this different from IETF Review in RFC 5226?  Do BCPs=
 count? What is "at least Informational status"?



On the concern =
about Pervasive Monitoring, the only advantage that (XL, ESPL) offers is th=
at the labels wouldn't (eventually) be hashed for load-balancing. =A0Ot=
herwise, the label stack offers the ability for meta-data already where onl=
y the receiver would need to understand it. =A0Consistent paths are very us=
eful, but there are other ways of doing this already - with the most trivia=
l being just using label 15. =A0I have a hard time seeing this as a new att=
ack vector (but I'm not professionally paranoid yet).



Alia
On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel=
 <adrian@olddog.co.uk> wrote:


[snip]




> >> XL =A0 The Extension Label that indicates that an extended sp=
ecial

> >> =A0 =A0 =A0 =A0 purpose label follows.

> >>

> >> ESPL An Extended Special Purpose Label.

> >>

> >> Something that I think would be worthwhile clarifying right a=
t the

> >> front is that a label is an ESPL IFF it is preceded by an XL.=


> >> It might even be worth noting that really we have a new label=
 type:

> >> a label couple in which the first label defines the type of t=
he

> >> second label and neither are of any use as individual labels.=


> > I can see how you would see this as a new label type. Maybe "=
;compound"

> > rather than "couple".

> > However, I am not convinced that it is new that one label leads t=
o the

semantics

> > of the next (for example the entropy label).

> > What is more, I am not sure that there will be more than this ins=
tance of

this

> > type of tight coupling.

> > So I would rather leave this point out.

> I can foresee other cases where we might use label pairs to mitigate t=
he

> 20bit limit. I am sure it has been discussed, so creating the referenc=
e

> might be useful. Just because this was not done in EL, does not mean t=
hat

> we should not set down the concept here.

>

> However I agree compound would be a better term.

>

> >

> > But as to clarifying ESPL: yes.

> > The XP definition is, I think, clear.

> > How about...

> >

> > ESPL An Extended Special Purpose Label. A Special Purpose Label t=
hat

> > =A0 =A0 =A0 is placed in the label stack after the Extension Labe=
l.

>

> Yes. Indeed it MUST be placed be placed there, however the definition<=
br>
> above is fine.




OK, I updated to...




=A0 =A0ESPL An Extended Special Purpose Label. A Special Purpose Label that=



=A0 =A0 =A0 =A0 is placed in the label stack after the Extension Labe=
l. =A0The

=A0 =A0 =A0 =A0 combination of XL and ESPL might be regarded as a new form =
of

=A0 =A0 =A0 =A0 "compound label" comprising more than one consecu=
tive entry in

=A0 =A0 =A0 =A0 the label stack.



..to cover your other point as well.




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

> >>

> >> I think that the draft will need to provide some guidance

> >> on when to allocate a 0..15 and when to allocate an ESPL.

> >>

> >> I imagine that a 0..15 should only be used when it can be sho=
wn

> >> that the extra stack space of forwarding time is burdensome
> >> but that is a question that the WG should explicitly consider=
.

> > We discussed this at some point on the MPLS list (many centuries =
ago, I

think)

> > and reached no conclusion.

> > The primary purpose of the XL is to handle the time when 0..15 is=
 depleted.

> > You're right that we could encourage people to start using ES=
PLs now before

> > 0..15 is depleted. But it is hard to make the case for requiring =
it when

there

> > is still some of 0..15 available and the rate of burn is not so h=
igh.

> >

> > We could put in some text like...

> >

> > When allocating a new Special Purpose Label, protocol designers s=
hould

> > consider whether they could, instead, use an Extended Special Pur=
pose

> > Label. Doing so would help to preserve the scarce resources of Sp=
ecial

> > Purpose Labels for use in cases where minimizing the label stack =
size is

> > particularly important.

>

> That would be useful text.




Added as new section 3.1.2 with slight tweak to wording.



[snip]




> >> =A0 =A0 6. =A0[RFC6790] says that special purpose labels MUST=
 NOT be used for

> >> =A0 =A0 =A0 =A0load balancing. =A0The same logic applies to e=
xtended special

> >> =A0 =A0 =A0 =A0purpose labels (ESPLs). =A0Thus, this document=
 specifies that ESPLs

> >> =A0 =A0 =A0 =A0MUST NOT be used for load balancing. =A0It is =
noted that existing

> >> =A0 =A0 =A0 =A0implementations may violate this, as they do n=
ot look for the XL

> >> =A0 =A0 =A0 =A0and thus for ESPLs. =A0The consequence is that=
 if ESPLs are used in

> >> =A0 =A0 =A0 =A0some packets of a flow, these packets may be d=
elivered on

> >> =A0 =A0 =A0 =A0different paths and so could be re-ordered. =
=A0However, it is

> >> =A0 =A0 =A0 =A0important to specify the correct behavior for =
future

> >> =A0 =A0 =A0 =A0implementations, hence the use of "MUST N=
OT".

> >>

> >> I would suggest that most implementations do violate this. I =
would

> >> also suggest that it seems unlikely that you will get to the =
point

> >> where it is not violated in the foreseeable future.

> > I can't tell whether there is an action here for us.

> > There are two "violations" that exist:

> > 1. Some implementations violate 6790. Not sure what we can do abo=
ut

> > that in this document. Note that the entropy label can help with =
this

> > but only to a limited extent since the implementations that viola=
te 6790

> > probably also fail to recognise the entropy label.

> > 2. Implementations that conform to 6790 will understand that the =
XL is

> > a special purpose label and will not use it to load balance. But =
they will

> > not necessarily understand that the next label is an ESPL that mu=
st be

> > skipped as well. Again, there is nothing we can do about this exc=
ept to

> > note it (done) and possibly to use the EL further up the stack.
>

> My point was that the may in "It is noted that existing implement=
ations may

> violate this" was a little soft. Most implementations, except the=
 latest

> designs of maybe as few as a single vendor, would certainly violate th=
is.

>

> Also of course you are making a statement of fact and not of permissio=
n

> so I think it may be more precise to say:

>

> It is noted that most existing

> implementations currently violate this, as they do not look for the XL=


> and thus for ESPLs.




OK.



I've gone with...




=A0 =A0 =A0 =A0It is noted that existing


=A0 =A0 =A0 =A0implementations would violate this, as they do not rec=
ognise XL

=A0 =A0 =A0 =A0as anything other than a single Special Purpose Label and wi=
ll

=A0 =A0 =A0 =A0not expect an ESPL to follow.



[snip]




> >> =A0 =A0Label 7 (when received) retains its meaning as ELI whe=
ther a regular

> >> =A0 =A0special purpose label or an ESPL; this simplifies a tr=
ansit LSR's

> >> =A0 =A0task of looking for entropy labels since it may just l=
ook for label 7

> >> =A0 =A0and need not verify that the previous label in the sta=
ck is not the

> >> =A0 =A0XL 15. =A0However, an LSR wishing to insert an entropy=
 label SHOULD

> >> =A0 =A0insert label 7 as a regular special purpose label, not=
 as an ESPL.

> >>

> >> Why is this not a MUST! There is no ESPL in the wild running =
an

> >> alternate behaviour, so why not simply mandate this?

> > If this was a MUST then there would be no case for handling Label=
 7 after

XL.

> > There was some concern I believe that implementations might have =
a path that

> > puts them on to XL insertion processing and then consider what to=
 do next.

At

> > that point they might decide that label 7 is needed.

> >

> > It seems esoteric, but I couldn't see a reason to prohibit it=
.

> >

> > Maybe "MUST NOT include" and "SHOULD process when =
received" are

> > compatible.

> >

> > Part of me hates the idea of this change just because I don't=
 want another

> > working group last call before we can move forward. How important=
 is it?

>

> The reason to be stricter at the TX is that the forwarding path can be=


> simpler at the RX. I cannot see how you would get to the point of putt=
ing

> in L15 and then saying "you know I need to put in L7" partic=
ularly as no

> other 0..15 is allowed.

> Normally I would think that you would put in the compound label as a p=
air

> and that is a good reason to use the compound label concept.

>

> Also I see no reason for the inconsistency between L7 and all of the
> other L0..L15 cases.

>

> So I think that it's OK, but probably silly to allow L0..L15, but =
to allow

> the exception of just L7 just complicates things without good cause.



I'm not in a position to argue on this one as the debate an=
d text were driven by

others.



I believe that the claim was that allowing L7 to be inserted anywhere made<=
br>
processing it easier not harder at the receiver.

Note that {XL,7} would be an error case in your way of looking at things so=
 the

receiver should (must?) not process it.

But the claim was that h/w will simply search the stack for L7 so that allo=
wing

{L7} and {XL, L7} to be treated in the same way made life easier for the h/=
w.



Bottom line, however, seems to be that you have a preference for doing it o=
ne

way, and the WG has a preference for doing it a different way. How to resol=
ve

that?



Given the posting deadline, I've not made any change for this. We can c=
ontinue

to discuss.




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

> >>

> >> 3.2. =A0Process for Retiring Special Purpose Labels




[snip]




> >> Secondly I think the timescales are ridiculously optimistic. =
To get

> >> a label out of circulation in 24 months seems most unlikely. =
Also

> >> 6 month checks is a lot of work.

> >>

> >> A more realistic schedule would be to poll at 12month interva=
ls until

> >> such time as it is determined that reallocation would do not =
harm and

> >> then give a further 12 months notice.

> > Erm, that's what the text says, I think...

> >

> > =A0 =A0 =A0 =A0 12 months after the RFC deprecating the label val=
ue is published,

> > =A0 =A0 =A0 =A0 an IETF-wide survey may be conducted to determine=
 if the

> > =A0 =A0 =A0 =A0 deprecated label value is still in use.

> >

> > The "may" in that means that the earliest you can "=
;poll" is 12 months after

the

> > deprecation RFC is published (noting that the RFC won't even =
get published

> > until lots of discussion and consensus to deprecate).

> > Then, *if* the poll response is OK, and then not earlier than 24 =
months

after

> > the deprecation RFC is published, publication can be requested fo=
r a new RFC

> > (which means that the WG has already reached consensus, and that =
a

> > subsequent IETF last call will be held).

> >

> > Frankly, I think that this process is only likely to be executed =
for SPLs

that

> > are allocated "in error", because other stuff will prob=
ably be in the field.

Can

> > you think of a label that was allocated in error? I can :-)

>

> This seems like a lot of text to specify in detail something we would =
never

> run. In protocols, including this type of protocol, the fewer words us=
ed to

> describe the rarely executed exception path the better.




The case was considered worthy of inclusion because the SPL ran=
ge is so small.

If any SPL can be reclaimed at some future time it will be very valuable an=
d so

a mechanism needs to be documented against that happy day.



[snip]

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

[snip]


> >> However that brings me to

> >> suggest that you probably need to write an OPs section and
> >> you might want to think about the PM implications of the extr=
a

> >> metatdata in the packets.

> >


> > What OPS issues had you in mind that need t=
o be addressed? I am a fan of OPS

> > sections, but not a fan of empty OPS sections, and when we looked=
 through

> > RFC 6123 (which is my favourite crib for what to describe wrt man=
ageability)

we

> > didn't see anything that has changed from pre-existing MPLS.<=
br>
> >

> > What metadata are you talking about? Is an existing special purpo=
se label

> > metadata? If so, the PM issues are pre-existing. Is there somethi=
ng special

> > introduced by this I-D that constitutes metadata?

>

> Well what follows an XL is certainly metadata, and one application is<=
br>
> certainly to introduce tags that would alert the PM devices to take an=


> interest.




OK it is a form of metadata as existing SPLs are metadata.

The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI that th=
e SPL

is there.

What has changed?

We could certainly sit down and write an I-D about the implications of usin=
g

MPLS in an environment where PM might be present (BTW, I assume this is

Pervasive Monitoring. Would be embarrassing to find you meant something els=
e

:-). I think such an I-D would discuss SPLs as indicative metadata and woul=
d

then note that ESPLs are in the same category.

Is *this* the I-D in which to have that discussion?



[snip]



I'll post the revised I-D in a few minutes and others can throw vegetab=
les

(rotten or otherwise).



Adrian




_______________________________________________

mpls mailing list

mpls@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/mpls

--001a11c1fd2457a65804f2690451-- From nobody Fri Feb 14 20:09: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 AB86B1A0006 for ; Fri, 14 Feb 2014 20:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 2vc9LJqU5ml1 for ; Fri, 14 Feb 2014 20:09:30 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDA1A0005 for ; Fri, 14 Feb 2014 20:09:29 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so13148212pbc.38 for ; Fri, 14 Feb 2014 20:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=fuvb+9f/wezMtXKICstLZVD8Lcg7VPzTFWFVtmRFTcI=; b=fAlbY503qw3mtb3Gc4kUO8jk6AdDR7Vk2D2D46VhfHFR9bab2XIfb5uNbexpIZcRU4 a4p7OjGp5vphab89PosJzLC9JLphtnDHOBK31ppmZJs8h1+T9tH3UHwyfJ35nX6Vwomf G+MjZY2EjBqeDK7NxWJ7Hf/Cekhj5ZKkBCHz+UIuPAON6vhEdPSxEbakGlQrcjulMUql io4e7egGFsBnNqHN8nNVPExxag8GpSJeAK5txGSKLJsCy1pE1PWwaXnFAJfIjE1AaTNH oi4gu9hr4mTqm5UFxAIoXmBnD6TdTQDEJ0N6ja0ILC5BHd+WI6ZNBOjxVbOrw8t4HZtR 4JgQ== X-Received: by 10.68.178.229 with SMTP id db5mr13009299pbc.97.1392437368408; Fri, 14 Feb 2014 20:09:28 -0800 (PST) Received: from [192.168.1.2] ([59.57.162.86]) by mx.google.com with ESMTPSA id zc6sm56263256pab.18.2014.02.14.20.09.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 20:09:26 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-CEF35BFF-32CC-45C7-913C-11B590B2D6DF Content-Transfer-Encoding: 7bit Message-Id: <4AA4663F-E6E7-449E-97FC-EA0F56F1118C@gmail.com> X-Mailer: iPhone Mail (10B142) From: Emily Date: Sat, 15 Feb 2014 12:09:18 +0800 To: Ross Callon Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3JQtVpjwUdKdCSHR1byIhGpZwDQ Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 15 Feb 2014 04:09:32 -0000 --Apple-Mail-CEF35BFF-32CC-45C7-913C-11B590B2D6DF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Support. Best regards, Emily On Feb 14, 2014, at 3:46, Ross Callon wrote: > This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection= -11 > as an MPLS working group document. Since many of us will be in transit to t= he > IETF approximately two weeks from now, I will extent the poll by one week (= so > that it will be a three week poll). > =20 > Please send your comments (support/not support) to the mpls working group > mailing list (mpls@ietf.org). > =20 > This poll will end Friday March 7, 2014. Note that this is the Friday of t= he IETF, > and thus we will each need to plan our review of the document and response= > around our travel plans and IETF activities. > =20 > Thanks, Ross > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-CEF35BFF-32CC-45C7-913C-11B590B2D6DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Support.


Best regards,
Emily

On Feb 14, 2014, at 3:46, Ross Callon <rcallon@juniper.net> wrote:

This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Since many of us will be in transit to the

IETF approximately two weeks from now, I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014. Note that this is the Friday of the IETF,

and thus we will each need to plan our review of the document and response

around our travel plans and IETF activities.

 

Thanks, Ross

 

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--Apple-Mail-CEF35BFF-32CC-45C7-913C-11B590B2D6DF-- From nobody Fri Feb 14 20:58: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 00DC41A0019 for ; Fri, 14 Feb 2014 20:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ih5l8tlBjTOT for ; Fri, 14 Feb 2014 20:58:13 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 504631A0010 for ; Fri, 14 Feb 2014 20:58:13 -0800 (PST) Received: from [192.168.1.4] (unknown [112.208.78.190]) (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 5A81E1802AAD; Sat, 15 Feb 2014 05:58:09 +0100 (CET) Message-ID: <52FEF3DC.2000105@pi.nu> Date: Sat, 15 Feb 2014 12:58:04 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alia Atlas , Adrian Farrel References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/y1m1Mth6ZYZtnLk5D3wiqMl1w74 Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 15 Feb 2014 04:58:18 -0000 Alia, Two comments on this. First a nit "An LSR wishing to insert an ...", LSR are boxes and can't wish anything for themselves, a Simple change would be "When an LSR insert..." Actually the same is true for the current text and should be changed the same way. Second, and this is maybe more tricky - the reason given "simplify the data plane implementation" is not true and might even be wrong. The reason put always using the ELI as a "regular special purpose label" is backwards compatibility. I would claim that the treatment of the ELI is an (well motivated) exception, but exceptions always mean that things get more complicated. I don't want to propose a final text,but something along these lines: "Label 7 (when received) retains its meaning as ELI whether a regular special purpose label or an ESPL; this is because of backwards compatibility with existing implemented and deployed code and hardware that looks for the ELI without verifying if the previous label is XL or not. However, when an LSR insert an entropy label it SHOULD insert the ELI as a regular special purpose label, not as an ESPL." /Loa On 2014-02-15 10:52, Alia Atlas wrote: > Adrian and others, > > Having reviewed the 05 of this draft and this thread, I have the > following suggestions. Other than these, I'm quite happy with how this > draft has improved. > > a) In Sec 3.1, the following paragraph could be updated from: > > "Label 7 (when received) retains its meaning as ELI whether a > regular special purpose label or an ESPL; this simplifies a transit > LSR's task of looking for entropy labels since it may just look for > label 7 and need not verify that the previous label in the stack is not > the XL 15. However, an LSR wishing to insert an entropy label SHOULD > insert label 7 as a regular special purpose label, not as an ESPL." > > > to: > > > "An LSR wishing to insert an entropy label MUST insert label value 7 (meaning ELI) as a regular special purpose > > label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data plane. However, to simplify > > the data plane implementation for Entropy Labels, an implementation MAY > > interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, an implementation > > MAY choose to not treat the packet as malformedand thus discard it. The data plane simplification thus enabled > > is the ability to determine if any label value is 7 without needing to verify that the previous label in the stack is not the XL value of 15." > > > b)In Sec 3.2: "An RFC with at least Informational status is required." How is this different from IETF Review in RFC 5226? Do BCPs count? What is "at least Informational status"? > > > On the concern about Pervasive Monitoring, the only advantage that (XL, > ESPL) offers is that the labels wouldn't (eventually) be hashed for > load-balancing. Otherwise, the label stack offers the ability for > meta-data already where only the receiver would need to understand it. > Consistent paths are very useful, but there are other ways of doing > this already - with the most trivial being just using label 15. I have > a hard time seeing this as a new attack vector (but I'm not > professionally paranoid yet). > > Alia > > On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel > wrote: > > [snip] > > > >> XL The Extension Label that indicates that an extended special > > >> purpose label follows. > > >> > > >> ESPL An Extended Special Purpose Label. > > >> > > >> Something that I think would be worthwhile clarifying right at the > > >> front is that a label is an ESPL IFF it is preceded by an XL. > > >> It might even be worth noting that really we have a new label > type: > > >> a label couple in which the first label defines the type of the > > >> second label and neither are of any use as individual labels. > > > I can see how you would see this as a new label type. Maybe > "compound" > > > rather than "couple". > > > However, I am not convinced that it is new that one label leads > to the > semantics > > > of the next (for example the entropy label). > > > What is more, I am not sure that there will be more than this > instance of > this > > > type of tight coupling. > > > So I would rather leave this point out. > > I can foresee other cases where we might use label pairs to > mitigate the > > 20bit limit. I am sure it has been discussed, so creating the > reference > > might be useful. Just because this was not done in EL, does not > mean that > > we should not set down the concept here. > > > > However I agree compound would be a better term. > > > > > > > > But as to clarifying ESPL: yes. > > > The XP definition is, I think, clear. > > > How about... > > > > > > ESPL An Extended Special Purpose Label. A Special Purpose Label > that > > > is placed in the label stack after the Extension Label. > > > > Yes. Indeed it MUST be placed be placed there, however the definition > > above is fine. > > OK, I updated to... > > ESPL An Extended Special Purpose Label. A Special Purpose Label that > is placed in the label stack after the Extension Label. The > combination of XL and ESPL might be regarded as a new form of > "compound label" comprising more than one consecutive entry in > the label stack. > > ..to cover your other point as well. > > > >> ====== > > >> > > >> I think that the draft will need to provide some guidance > > >> on when to allocate a 0..15 and when to allocate an ESPL. > > >> > > >> I imagine that a 0..15 should only be used when it can be shown > > >> that the extra stack space of forwarding time is burdensome > > >> but that is a question that the WG should explicitly consider. > > > We discussed this at some point on the MPLS list (many > centuries ago, I > think) > > > and reached no conclusion. > > > The primary purpose of the XL is to handle the time when 0..15 > is depleted. > > > You're right that we could encourage people to start using > ESPLs now before > > > 0..15 is depleted. But it is hard to make the case for > requiring it when > there > > > is still some of 0..15 available and the rate of burn is not so > high. > > > > > > We could put in some text like... > > > > > > When allocating a new Special Purpose Label, protocol designers > should > > > consider whether they could, instead, use an Extended Special > Purpose > > > Label. Doing so would help to preserve the scarce resources of > Special > > > Purpose Labels for use in cases where minimizing the label > stack size is > > > particularly important. > > > > That would be useful text. > > Added as new section 3.1.2 with slight tweak to wording. > > [snip] > > > >> 6. [RFC6790] says that special purpose labels MUST NOT be > used for > > >> load balancing. The same logic applies to extended special > > >> purpose labels (ESPLs). Thus, this document specifies > that ESPLs > > >> MUST NOT be used for load balancing. It is noted that > existing > > >> implementations may violate this, as they do not look > for the XL > > >> and thus for ESPLs. The consequence is that if ESPLs > are used in > > >> some packets of a flow, these packets may be delivered on > > >> different paths and so could be re-ordered. However, it is > > >> important to specify the correct behavior for future > > >> implementations, hence the use of "MUST NOT". > > >> > > >> I would suggest that most implementations do violate this. I would > > >> also suggest that it seems unlikely that you will get to the point > > >> where it is not violated in the foreseeable future. > > > I can't tell whether there is an action here for us. > > > There are two "violations" that exist: > > > 1. Some implementations violate 6790. Not sure what we can do about > > > that in this document. Note that the entropy label can help > with this > > > but only to a limited extent since the implementations that > violate 6790 > > > probably also fail to recognise the entropy label. > > > 2. Implementations that conform to 6790 will understand that > the XL is > > > a special purpose label and will not use it to load balance. > But they will > > > not necessarily understand that the next label is an ESPL that > must be > > > skipped as well. Again, there is nothing we can do about this > except to > > > note it (done) and possibly to use the EL further up the stack. > > > > My point was that the may in "It is noted that existing > implementations may > > violate this" was a little soft. Most implementations, except the > latest > > designs of maybe as few as a single vendor, would certainly > violate this. > > > > Also of course you are making a statement of fact and not of > permission > > so I think it may be more precise to say: > > > > It is noted that most existing > > implementations currently violate this, as they do not look for > the XL > > and thus for ESPLs. > > OK. > > I've gone with... > > It is noted that existing > implementations would violate this, as they do not recognise XL > as anything other than a single Special Purpose Label and will > not expect an ESPL to follow. > > [snip] > > > >> Label 7 (when received) retains its meaning as ELI whether > a regular > > >> special purpose label or an ESPL; this simplifies a transit > LSR's > > >> task of looking for entropy labels since it may just look > for label 7 > > >> and need not verify that the previous label in the stack is > not the > > >> XL 15. However, an LSR wishing to insert an entropy label > SHOULD > > >> insert label 7 as a regular special purpose label, not as > an ESPL. > > >> > > >> Why is this not a MUST! There is no ESPL in the wild running an > > >> alternate behaviour, so why not simply mandate this? > > > If this was a MUST then there would be no case for handling > Label 7 after > XL. > > > There was some concern I believe that implementations might > have a path that > > > puts them on to XL insertion processing and then consider what > to do next. > At > > > that point they might decide that label 7 is needed. > > > > > > It seems esoteric, but I couldn't see a reason to prohibit it. > > > > > > Maybe "MUST NOT include" and "SHOULD process when received" are > > > compatible. > > > > > > Part of me hates the idea of this change just because I don't > want another > > > working group last call before we can move forward. How > important is it? > > > > The reason to be stricter at the TX is that the forwarding path > can be > > simpler at the RX. I cannot see how you would get to the point of > putting > > in L15 and then saying "you know I need to put in L7" > particularly as no > > other 0..15 is allowed. > > Normally I would think that you would put in the compound label > as a pair > > and that is a good reason to use the compound label concept. > > > > Also I see no reason for the inconsistency between L7 and all of the > > other L0..L15 cases. > > > > So I think that it's OK, but probably silly to allow L0..L15, but > to allow > > the exception of just L7 just complicates things without good cause. > > I'm not in a position to argue on this one as the debate and text > were driven by > others. > > I believe that the claim was that allowing L7 to be inserted > anywhere made > processing it easier not harder at the receiver. > Note that {XL,7} would be an error case in your way of looking at > things so the > receiver should (must?) not process it. > But the claim was that h/w will simply search the stack for L7 so > that allowing > {L7} and {XL, L7} to be treated in the same way made life easier for > the h/w. > > Bottom line, however, seems to be that you have a preference for > doing it one > way, and the WG has a preference for doing it a different way. How > to resolve > that? > > Given the posting deadline, I've not made any change for this. We > can continue > to discuss. > > > >> ======== > > >> > > >> 3.2. Process for Retiring Special Purpose Labels > > [snip] > > > >> Secondly I think the timescales are ridiculously optimistic. > To get > > >> a label out of circulation in 24 months seems most unlikely. Also > > >> 6 month checks is a lot of work. > > >> > > >> A more realistic schedule would be to poll at 12month > intervals until > > >> such time as it is determined that reallocation would do not > harm and > > >> then give a further 12 months notice. > > > Erm, that's what the text says, I think... > > > > > > 12 months after the RFC deprecating the label value is > published, > > > an IETF-wide survey may be conducted to determine if the > > > deprecated label value is still in use. > > > > > > The "may" in that means that the earliest you can "poll" is 12 > months after > the > > > deprecation RFC is published (noting that the RFC won't even > get published > > > until lots of discussion and consensus to deprecate). > > > Then, *if* the poll response is OK, and then not earlier than > 24 months > after > > > the deprecation RFC is published, publication can be requested > for a new RFC > > > (which means that the WG has already reached consensus, and that a > > > subsequent IETF last call will be held). > > > > > > Frankly, I think that this process is only likely to be > executed for SPLs > that > > > are allocated "in error", because other stuff will probably be > in the field. > Can > > > you think of a label that was allocated in error? I can :-) > > > > This seems like a lot of text to specify in detail something we > would never > > run. In protocols, including this type of protocol, the fewer > words used to > > describe the rarely executed exception path the better. > > The case was considered worthy of inclusion because the SPL range is > so small. > If any SPL can be reclaimed at some future time it will be very > valuable and so > a mechanism needs to be documented against that happy day. > > [snip] > > >> =========== > [snip] > > >> However that brings me to > > >> suggest that you probably need to write an OPs section and > > >> you might want to think about the PM implications of the extra > > >> metatdata in the packets. > > > > > > What OPS issues had you in mind that need to be addressed? I am > a fan of OPS > > > sections, but not a fan of empty OPS sections, and when we > looked through > > > RFC 6123 (which is my favourite crib for what to describe wrt > manageability) > we > > > didn't see anything that has changed from pre-existing MPLS. > > > > > > What metadata are you talking about? Is an existing special > purpose label > > > metadata? If so, the PM issues are pre-existing. Is there > something special > > > introduced by this I-D that constitutes metadata? > > > > Well what follows an XL is certainly metadata, and one application is > > certainly to introduce tags that would alert the PM devices to > take an > > interest. > > OK it is a form of metadata as existing SPLs are metadata. > The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI > that the SPL > is there. > What has changed? > We could certainly sit down and write an I-D about the implications > of using > MPLS in an environment where PM might be present (BTW, I assume this is > Pervasive Monitoring. Would be embarrassing to find you meant > something else > :-). I think such an I-D would discuss SPLs as indicative metadata > and would > then note that ESPLs are in the same category. > Is *this* the I-D in which to have that discussion? > > [snip] > > I'll post the revised I-D in a few minutes and others can throw > vegetables > (rotten or otherwise). > > Adrian > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Feb 14 21:24: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 452E31A0021 for ; Fri, 14 Feb 2014 21:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 5HlcNpU2dG8z for ; Fri, 14 Feb 2014 21:24:28 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) by ietfa.amsl.com (Postfix) with ESMTP id 50D4E1A001F for ; Fri, 14 Feb 2014 21:24:28 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id 142so25589243ykq.0 for ; Fri, 14 Feb 2014 21:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5/6dJHfndGv+BP3PdHDRTWOJEJNr92iUFhqjt36jEUI=; b=ui1pr3REPSM/5eMG7j8SGNQEaYmiGxrtrPUiWDlDhzgmX5GfzC26/NHkpfF2scq0+Q igzfdegljB9pQVwDEZxqCh3V8c5n7aF3jTMlaEV6th+cs0e/XyeUEutXej6HUa/zkb1D X60xTrG2lfa6g66zRAg0eH95EYe/POWaiRp7laqf5FKs8VHum5sgh4VJbgN7u5+vIE0E kqJyAF4NdAy/E6Vz3OwUQrWSslRu2Cnqw5Wt+iTk5Uf6ggoB7orsznxsLexJOsay1k1e DvMlo5K0MMKmyYLM4uEk0wPuFPliWZ4tECzVEKAMjeC+d5m0uoV9bW9sp7Els1wpGPEq +Dcg== MIME-Version: 1.0 X-Received: by 10.236.170.3 with SMTP id o3mr102201yhl.143.1392441866420; Fri, 14 Feb 2014 21:24:26 -0800 (PST) Received: by 10.170.185.212 with HTTP; Fri, 14 Feb 2014 21:24:26 -0800 (PST) In-Reply-To: <52FEF3DC.2000105@pi.nu> References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> Date: Sat, 15 Feb 2014 00:24:26 -0500 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf3040e372d1862104f26b2259 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2qwaIScqUwREHkSXK6-f8hgREZQ Cc: "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 15 Feb 2014 05:24:35 -0000 --20cf3040e372d1862104f26b2259 Content-Type: text/plain; charset=ISO-8859-1 Loa, On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson wrote: > Alia, > > Two comments on this. > > First a nit "An LSR wishing to insert an ...", LSR are boxes and can't > wish anything for themselves, a Simple change would be "When an LSR > insert..." > > Actually the same is true for the current text and should be changed the > same way. > [Alia] Sure - I took the original text and modified it. Second, and this is maybe more tricky - the reason given "simplify the > data plane implementation" is not true and might even be wrong. > The reason put always using the ELI as a "regular special purpose label" > is backwards compatibility. > I would claim that the treatment of the ELI is an (well motivated) > exception, but exceptions always mean that things get more complicated. > [Alia] There were three purposes to my suggested text change. First, to specify that an LSR MUST NOT insert the ELI as an ESPL. Second, to say that a receiving LSR MAY choose to not discard a packet with the ELI as an ESPL. Third, I wanted to see a clearer justification for why this exception is worth making. [Alia] Since the whole draft is about a data-plane change, what we've been putting in doesn't really articulate the full problem. Prelim text would around that would be better as: "ELI is an exception because each LSR examines the whole label stack to see if the ELI appears; pre-existing implementations of [Entropy-Label] do this examination without verifying that the label above the ELI is not XL. If a packet used an ESPL of 7 and that did not mean ELI, then when that packet transited deployed LSRs, which implement [Entropy-Label] and not this document, the meaning of the ESPL would be misinterpreted. Such a misinterpretation could result in poor traffic behavior (large flows, reordered flows, etc.) depending on the label after the ESPL of 7. It is to avoid such issues that ELI is defined as an exception that can appear as an regular special label or as an ESPL with the same value of 7." What do you think? Alia I don't want to propose a final text,but something along these lines: > > > "Label 7 (when received) retains its meaning as ELI whether a > regular special purpose label or an ESPL; this is because of backwards > compatibility with existing implemented and deployed code and hardware > that looks for the ELI without verifying if the previous label > is XL or not. However, when an LSR insert an entropy label it SHOULD > insert the ELI as a regular special purpose label, not as an ESPL." > > /Loa > > > On 2014-02-15 10:52, Alia Atlas wrote: > >> Adrian and others, >> >> Having reviewed the 05 of this draft and this thread, I have the >> following suggestions. Other than these, I'm quite happy with how this >> draft has improved. >> >> a) In Sec 3.1, the following paragraph could be updated from: >> >> "Label 7 (when received) retains its meaning as ELI whether a >> regular special purpose label or an ESPL; this simplifies a transit >> LSR's task of looking for entropy labels since it may just look for >> label 7 and need not verify that the previous label in the stack is not >> the XL 15. However, an LSR wishing to insert an entropy label SHOULD >> insert label 7 as a regular special purpose label, not as an ESPL." >> >> >> to: >> >> >> "An LSR wishing to insert an entropy label MUST insert label value 7 >> (meaning ELI) as a regular special purpose >> >> label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data >> plane. However, to simplify >> >> >> the data plane implementation for Entropy Labels, an implementation MAY >> >> interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and >> 8-15, an implementation >> >> MAY choose to not treat the packet as malformedand thus discard it. The >> data plane simplification thus enabled >> >> >> is the ability to determine if any label value is 7 without needing to >> verify that the previous label in the stack is not the XL value of 15." >> >> >> b)In Sec 3.2: "An RFC with at least Informational status is required." >> How is this different from IETF Review in RFC 5226? Do BCPs count? What is >> "at least Informational status"? >> >> >> >> On the concern about Pervasive Monitoring, the only advantage that (XL, >> ESPL) offers is that the labels wouldn't (eventually) be hashed for >> load-balancing. Otherwise, the label stack offers the ability for >> meta-data already where only the receiver would need to understand it. >> Consistent paths are very useful, but there are other ways of doing >> this already - with the most trivial being just using label 15. I have >> a hard time seeing this as a new attack vector (but I'm not >> professionally paranoid yet). >> >> Alia >> >> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel > > wrote: >> >> [snip] >> >> > >> XL The Extension Label that indicates that an extended special >> > >> purpose label follows. >> > >> >> > >> ESPL An Extended Special Purpose Label. >> > >> >> > >> Something that I think would be worthwhile clarifying right at >> the >> > >> front is that a label is an ESPL IFF it is preceded by an XL. >> > >> It might even be worth noting that really we have a new label >> type: >> > >> a label couple in which the first label defines the type of the >> > >> second label and neither are of any use as individual labels. >> > > I can see how you would see this as a new label type. Maybe >> "compound" >> > > rather than "couple". >> > > However, I am not convinced that it is new that one label leads >> to the >> semantics >> > > of the next (for example the entropy label). >> > > What is more, I am not sure that there will be more than this >> instance of >> this >> > > type of tight coupling. >> > > So I would rather leave this point out. >> > I can foresee other cases where we might use label pairs to >> mitigate the >> > 20bit limit. I am sure it has been discussed, so creating the >> reference >> > might be useful. Just because this was not done in EL, does not >> mean that >> > we should not set down the concept here. >> > >> > However I agree compound would be a better term. >> > >> > > >> > > But as to clarifying ESPL: yes. >> > > The XP definition is, I think, clear. >> > > How about... >> > > >> > > ESPL An Extended Special Purpose Label. A Special Purpose Label >> that >> > > is placed in the label stack after the Extension Label. >> > >> > Yes. Indeed it MUST be placed be placed there, however the >> definition >> > above is fine. >> >> OK, I updated to... >> >> ESPL An Extended Special Purpose Label. A Special Purpose Label >> that >> is placed in the label stack after the Extension Label. The >> combination of XL and ESPL might be regarded as a new form of >> "compound label" comprising more than one consecutive entry >> in >> the label stack. >> >> ..to cover your other point as well. >> >> > >> ====== >> > >> >> > >> I think that the draft will need to provide some guidance >> > >> on when to allocate a 0..15 and when to allocate an ESPL. >> > >> >> > >> I imagine that a 0..15 should only be used when it can be shown >> > >> that the extra stack space of forwarding time is burdensome >> > >> but that is a question that the WG should explicitly consider. >> > > We discussed this at some point on the MPLS list (many >> centuries ago, I >> think) >> > > and reached no conclusion. >> > > The primary purpose of the XL is to handle the time when 0..15 >> is depleted. >> > > You're right that we could encourage people to start using >> ESPLs now before >> > > 0..15 is depleted. But it is hard to make the case for >> requiring it when >> there >> > > is still some of 0..15 available and the rate of burn is not so >> high. >> > > >> > > We could put in some text like... >> > > >> > > When allocating a new Special Purpose Label, protocol designers >> should >> > > consider whether they could, instead, use an Extended Special >> Purpose >> > > Label. Doing so would help to preserve the scarce resources of >> Special >> > > Purpose Labels for use in cases where minimizing the label >> stack size is >> > > particularly important. >> > >> > That would be useful text. >> >> Added as new section 3.1.2 with slight tweak to wording. >> >> [snip] >> >> > >> 6. [RFC6790] says that special purpose labels MUST NOT be >> used for >> > >> load balancing. The same logic applies to extended >> special >> > >> purpose labels (ESPLs). Thus, this document specifies >> that ESPLs >> > >> MUST NOT be used for load balancing. It is noted that >> existing >> > >> implementations may violate this, as they do not look >> for the XL >> > >> and thus for ESPLs. The consequence is that if ESPLs >> are used in >> > >> some packets of a flow, these packets may be delivered on >> > >> different paths and so could be re-ordered. However, it >> is >> > >> important to specify the correct behavior for future >> > >> implementations, hence the use of "MUST NOT". >> > >> >> > >> I would suggest that most implementations do violate this. I >> would >> > >> also suggest that it seems unlikely that you will get to the >> point >> > >> where it is not violated in the foreseeable future. >> > > I can't tell whether there is an action here for us. >> > > There are two "violations" that exist: >> > > 1. Some implementations violate 6790. Not sure what we can do >> about >> > > that in this document. Note that the entropy label can help >> with this >> > > but only to a limited extent since the implementations that >> violate 6790 >> > > probably also fail to recognise the entropy label. >> > > 2. Implementations that conform to 6790 will understand that >> the XL is >> > > a special purpose label and will not use it to load balance. >> But they will >> > > not necessarily understand that the next label is an ESPL that >> must be >> > > skipped as well. Again, there is nothing we can do about this >> except to >> > > note it (done) and possibly to use the EL further up the stack. >> > >> > My point was that the may in "It is noted that existing >> implementations may >> > violate this" was a little soft. Most implementations, except the >> latest >> > designs of maybe as few as a single vendor, would certainly >> violate this. >> > >> > Also of course you are making a statement of fact and not of >> permission >> > so I think it may be more precise to say: >> > >> > It is noted that most existing >> > implementations currently violate this, as they do not look for >> the XL >> > and thus for ESPLs. >> >> OK. >> >> I've gone with... >> >> It is noted that existing >> implementations would violate this, as they do not recognise >> XL >> as anything other than a single Special Purpose Label and will >> not expect an ESPL to follow. >> >> [snip] >> >> > >> Label 7 (when received) retains its meaning as ELI whether >> a regular >> > >> special purpose label or an ESPL; this simplifies a transit >> LSR's >> > >> task of looking for entropy labels since it may just look >> for label 7 >> > >> and need not verify that the previous label in the stack is >> not the >> > >> XL 15. However, an LSR wishing to insert an entropy label >> SHOULD >> > >> insert label 7 as a regular special purpose label, not as >> an ESPL. >> > >> >> > >> Why is this not a MUST! There is no ESPL in the wild running an >> > >> alternate behaviour, so why not simply mandate this? >> > > If this was a MUST then there would be no case for handling >> Label 7 after >> XL. >> > > There was some concern I believe that implementations might >> have a path that >> > > puts them on to XL insertion processing and then consider what >> to do next. >> At >> > > that point they might decide that label 7 is needed. >> > > >> > > It seems esoteric, but I couldn't see a reason to prohibit it. >> > > >> > > Maybe "MUST NOT include" and "SHOULD process when received" are >> > > compatible. >> > > >> > > Part of me hates the idea of this change just because I don't >> want another >> > > working group last call before we can move forward. How >> important is it? >> > >> > The reason to be stricter at the TX is that the forwarding path >> can be >> > simpler at the RX. I cannot see how you would get to the point of >> putting >> > in L15 and then saying "you know I need to put in L7" >> particularly as no >> > other 0..15 is allowed. >> > Normally I would think that you would put in the compound label >> as a pair >> > and that is a good reason to use the compound label concept. >> > >> > Also I see no reason for the inconsistency between L7 and all of >> the >> > other L0..L15 cases. >> > >> > So I think that it's OK, but probably silly to allow L0..L15, but >> to allow >> > the exception of just L7 just complicates things without good >> cause. >> >> I'm not in a position to argue on this one as the debate and text >> were driven by >> others. >> >> I believe that the claim was that allowing L7 to be inserted >> anywhere made >> processing it easier not harder at the receiver. >> Note that {XL,7} would be an error case in your way of looking at >> things so the >> receiver should (must?) not process it. >> But the claim was that h/w will simply search the stack for L7 so >> that allowing >> {L7} and {XL, L7} to be treated in the same way made life easier for >> the h/w. >> >> Bottom line, however, seems to be that you have a preference for >> doing it one >> way, and the WG has a preference for doing it a different way. How >> to resolve >> that? >> >> Given the posting deadline, I've not made any change for this. We >> can continue >> to discuss. >> >> > >> ======== >> > >> >> > >> 3.2. Process for Retiring Special Purpose Labels >> >> [snip] >> >> > >> Secondly I think the timescales are ridiculously optimistic. >> To get >> > >> a label out of circulation in 24 months seems most unlikely. >> Also >> > >> 6 month checks is a lot of work. >> > >> >> > >> A more realistic schedule would be to poll at 12month >> intervals until >> > >> such time as it is determined that reallocation would do not >> harm and >> > >> then give a further 12 months notice. >> > > Erm, that's what the text says, I think... >> > > >> > > 12 months after the RFC deprecating the label value is >> published, >> > > an IETF-wide survey may be conducted to determine if the >> > > deprecated label value is still in use. >> > > >> > > The "may" in that means that the earliest you can "poll" is 12 >> months after >> the >> > > deprecation RFC is published (noting that the RFC won't even >> get published >> > > until lots of discussion and consensus to deprecate). >> > > Then, *if* the poll response is OK, and then not earlier than >> 24 months >> after >> > > the deprecation RFC is published, publication can be requested >> for a new RFC >> > > (which means that the WG has already reached consensus, and that >> a >> > > subsequent IETF last call will be held). >> > > >> > > Frankly, I think that this process is only likely to be >> executed for SPLs >> that >> > > are allocated "in error", because other stuff will probably be >> in the field. >> Can >> > > you think of a label that was allocated in error? I can :-) >> > >> > This seems like a lot of text to specify in detail something we >> would never >> > run. In protocols, including this type of protocol, the fewer >> words used to >> > describe the rarely executed exception path the better. >> >> The case was considered worthy of inclusion because the SPL range is >> so small. >> If any SPL can be reclaimed at some future time it will be very >> valuable and so >> a mechanism needs to be documented against that happy day. >> >> [snip] >> > >> =========== >> [snip] >> > >> However that brings me to >> > >> suggest that you probably need to write an OPs section and >> > >> you might want to think about the PM implications of the extra >> > >> metatdata in the packets. >> > > >> > > What OPS issues had you in mind that need to be addressed? I am >> a fan of OPS >> > > sections, but not a fan of empty OPS sections, and when we >> looked through >> > > RFC 6123 (which is my favourite crib for what to describe wrt >> manageability) >> we >> > > didn't see anything that has changed from pre-existing MPLS. >> > > >> > > What metadata are you talking about? Is an existing special >> purpose label >> > > metadata? If so, the PM issues are pre-existing. Is there >> something special >> > > introduced by this I-D that constitutes metadata? >> > >> > Well what follows an XL is certainly metadata, and one application >> is >> > certainly to introduce tags that would alert the PM devices to >> take an >> > interest. >> >> OK it is a form of metadata as existing SPLs are metadata. >> The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI >> that the SPL >> is there. >> What has changed? >> We could certainly sit down and write an I-D about the implications >> of using >> MPLS in an environment where PM might be present (BTW, I assume this >> is >> Pervasive Monitoring. Would be embarrassing to find you meant >> something else >> :-). I think such an I-D would discuss SPLs as indicative metadata >> and would >> then note that ESPLs are in the same category. >> Is *this* the I-D in which to have that discussion? >> >> [snip] >> >> I'll post the revised I-D in a few minutes and others can throw >> vegetables >> (rotten or otherwise). >> >> Adrian >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --20cf3040e372d1862104f26b2259 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Loa,

On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson &= lt;loa@pi.nu> = wrote:
Alia,

Two comments on this.

First a nit "An LSR wishing to insert an ...", LSR are boxes and = can't
wish anything for themselves, a Simple change would be "When an LSR insert..."

Actually the same is true for the current text and should be changed the same way.

[Alia] Sure - I took the orig= inal text and modified it.=A0

Second, and this is maybe more tricky - the reason given "simplify the=
data plane implementation" is not true and might even be wrong.
The reason put always using the ELI as a "regular special purpose labe= l"
is backwards compatibility.
I would claim that the treatment of the ELI is an (well motivated)
exception, but exceptions always mean that things get more complicated.
=

[Alia] There were three purposes to my sug= gested text change. =A0First, to specify that
an LSR MUST NOT ins= ert the ELI as an ESPL. =A0 Second, to say that a receiving LSR
MAY choose to not discard a packet with the ELI as an ESPL. =A0Third, = I wanted to see
a clearer justification for why this exception is= worth making.

[Alia] Since the whole draft is abo= ut a data-plane change, what we've been putting in doesn't
really articulate the full problem. =A0Prelim text would around that w= ould be better as:

"ELI is an exception becau= se each LSR examines the whole label stack to see if the ELI
appe= ars; pre-existing implementations of [Entropy-Label] do this examination wi= thout verifying
that the label above the ELI is not XL. =A0If a packet used an ESPL of= 7 and that did not mean
ELI, then when that packet transited dep= loyed LSRs, which implement [Entropy-Label] and not this document,=A0
the meaning of the ESPL would be misinterpreted. =A0Such a misinterpre= tation could result in poor traffic behavior (large flows,
reorde= red flows, etc.) depending on the label after the ESPL of 7. =A0It is to av= oid such issues that ELI is defined as an exception
that can appear as an regular special label or as an ESPL with the sam= e value of 7."
=A0
What do you think?
Alia

I don't want to propose a final text,but something along these lines:

"Label 7 (when received) retains its meaning as ELI whether a
=A0regular special purpose label or an ESPL; this is because of backwards =A0compatibility with existing implemented and deployed code and hardware =A0that looks for the ELI without verifying if the previous label
=A0is XL or not. However, when an LSR insert an entropy label it SHOULD
=A0insert the ELI as a regular special purpose label, not as an ESPL."=

/Loa


On 2014-02-15 10:52, Alia Atlas wrote:
Adrian and others,

Having reviewed the 05 of this draft and this thread, I have the
following suggestions. =A0Other than these, I'm quite happy with how th= is
draft has improved.

a) In Sec 3.1, the following paragraph could be updated from:

"Label 7 (when received) retains its meaning as ELI whether a
regular special purpose label or an ESPL; this simplifies a transit
LSR's task of looking for entropy labels since it may just look for
label 7 =A0and need not verify that the previous label in the stack is not<= br> the XL 15. However, an LSR wishing to insert an entropy label SHOULD
insert label 7 as a regular special purpose label, not as an ESPL."

to:


"An LSR wishing to insert an entropy label MUST insert label value 7 (= meaning ELI) as a regular special purpose

label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data pl= ane. =A0However, to simplify


the data plane implementation for Entropy Labels, an implementation MAY

interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, = an implementation

MAY choose to not treat the packet as malformedand thus discard it. =A0The = data plane simplification thus enabled


is the ability to determine if any label value is 7 without needing to veri= fy that the previous label in the stack is not the XL value of 15."

b)In Sec 3.2: "An RFC with at =A0least Informational status is require= d." =A0 How is this different from IETF Review in RFC 5226? =A0Do BCPs= count? What is "at least Informational status"?
<= br>

On the concern about Pervasive Monitoring, the only advantage that (XL,
ESPL) offers is that the labels wouldn't (eventually) be hashed for
load-balancing. =A0Otherwise, the label stack offers the ability for
meta-data already where only the receiver would need to understand it.
=A0 Consistent paths are very useful, but there are other ways of doing
this already - with the most trivial being just using label 15. =A0I have a hard time seeing this as a new attack vector (but I'm not
professionally paranoid yet).

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <adrian@olddog.co.uk
<mailto:adrian@= olddog.co.uk>> wrote:

=A0 =A0 [snip]

=A0 =A0 =A0> >> XL =A0 The Extension Label that indicates that an = extended special
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0 purpose label follows.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> ESPL An Extended Special Purpose Label.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> Something that I think would be worthwhile clarify= ing right at the
=A0 =A0 =A0> >> front is that a label is an ESPL IFF it is precede= d by an XL.
=A0 =A0 =A0> >> It might even be worth noting that really we have = a new label
=A0 =A0 type:
=A0 =A0 =A0> >> a label couple in which the first label defines th= e type of the
=A0 =A0 =A0> >> second label and neither are of any use as individ= ual labels.
=A0 =A0 =A0> > I can see how you would see this as a new label type. = Maybe
=A0 =A0 "compound"
=A0 =A0 =A0> > rather than "couple".
=A0 =A0 =A0> > However, I am not convinced that it is new that one la= bel leads
=A0 =A0 to the
=A0 =A0 semantics
=A0 =A0 =A0> > of the next (for example the entropy label).
=A0 =A0 =A0> > What is more, I am not sure that there will be more th= an this
=A0 =A0 instance of
=A0 =A0 this
=A0 =A0 =A0> > type of tight coupling.
=A0 =A0 =A0> > So I would rather leave this point out.
=A0 =A0 =A0> I can foresee other cases where we might use label pairs to=
=A0 =A0 mitigate the
=A0 =A0 =A0> 20bit limit. I am sure it has been discussed, so creating t= he
=A0 =A0 reference
=A0 =A0 =A0> might be useful. Just because this was not done in EL, does= not
=A0 =A0 mean that
=A0 =A0 =A0> we should not set down the concept here.
=A0 =A0 =A0>
=A0 =A0 =A0> However I agree compound would be a better term.
=A0 =A0 =A0>
=A0 =A0 =A0> >
=A0 =A0 =A0> > But as to clarifying ESPL: yes.
=A0 =A0 =A0> > The XP definition is, I think, clear.
=A0 =A0 =A0> > How about...
=A0 =A0 =A0> >
=A0 =A0 =A0> > ESPL An Extended Special Purpose Label. A Special Purp= ose Label
=A0 =A0 that
=A0 =A0 =A0> > =A0 =A0 =A0 is placed in the label stack after the Ext= ension Label.
=A0 =A0 =A0>
=A0 =A0 =A0> Yes. Indeed it MUST be placed be placed there, however the = definition
=A0 =A0 =A0> above is fine.

=A0 =A0 OK, I updated to...

=A0 =A0 =A0 =A0 ESPL An Extended Special Purpose Label. A Special Purpose L= abel that
=A0 =A0 =A0 =A0 =A0 =A0 =A0is placed in the label stack after the Extension= Label. =A0The
=A0 =A0 =A0 =A0 =A0 =A0 =A0combination of XL and ESPL might be regarded as = a new form of
=A0 =A0 =A0 =A0 =A0 =A0 =A0"compound label" comprising more than = one consecutive entry in
=A0 =A0 =A0 =A0 =A0 =A0 =A0the label stack.

=A0 =A0 ..to cover your other point as well.

=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I think that the draft will need to provide some g= uidance
=A0 =A0 =A0> >> on when to allocate a 0..15 and when to allocate a= n ESPL.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I imagine that a 0..15 should only be used when it= can be shown
=A0 =A0 =A0> >> that the extra stack space of forwarding time is b= urdensome
=A0 =A0 =A0> >> but that is a question that the WG should explicit= ly consider.
=A0 =A0 =A0> > We discussed this at some point on the MPLS list (many=
=A0 =A0 centuries ago, I
=A0 =A0 think)
=A0 =A0 =A0> > and reached no conclusion.
=A0 =A0 =A0> > The primary purpose of the XL is to handle the time wh= en 0..15
=A0 =A0 is depleted.
=A0 =A0 =A0> > You're right that we could encourage people to sta= rt using
=A0 =A0 ESPLs now before
=A0 =A0 =A0> > 0..15 is depleted. But it is hard to make the case for=
=A0 =A0 requiring it when
=A0 =A0 there
=A0 =A0 =A0> > is still some of 0..15 available and the rate of burn = is not so
=A0 =A0 high.
=A0 =A0 =A0> >
=A0 =A0 =A0> > We could put in some text like...
=A0 =A0 =A0> >
=A0 =A0 =A0> > When allocating a new Special Purpose Label, protocol = designers
=A0 =A0 should
=A0 =A0 =A0> > consider whether they could, instead, use an Extended = Special
=A0 =A0 Purpose
=A0 =A0 =A0> > Label. Doing so would help to preserve the scarce reso= urces of
=A0 =A0 Special
=A0 =A0 =A0> > Purpose Labels for use in cases where minimizing the l= abel
=A0 =A0 stack size is
=A0 =A0 =A0> > particularly important.
=A0 =A0 =A0>
=A0 =A0 =A0> That would be useful text.

=A0 =A0 Added as new section 3.1.2 with slight tweak to wording.

=A0 =A0 [snip]

=A0 =A0 =A0> >> =A0 =A0 6. =A0[RFC6790] says that special purpose = labels MUST NOT be
=A0 =A0 used for
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0load balancing. =A0The same logic a= pplies to extended special
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0purpose labels (ESPLs). =A0Thus, th= is document specifies
=A0 =A0 that ESPLs
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0MUST NOT be used for load balancing= . =A0It is noted that
=A0 =A0 existing
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0implementations may violate this, a= s they do not look
=A0 =A0 for the XL
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0and thus for ESPLs. =A0The conseque= nce is that if ESPLs
=A0 =A0 are used in
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0some packets of a flow, these packe= ts may be delivered on
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0different paths and so could be re-= ordered. =A0However, it is
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0important to specify the correct be= havior for future
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0implementations, hence the use of &= quot;MUST NOT".
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I would suggest that most implementations do viola= te this. I would
=A0 =A0 =A0> >> also suggest that it seems unlikely that you will = get to the point
=A0 =A0 =A0> >> where it is not violated in the foreseeable future= .
=A0 =A0 =A0> > I can't tell whether there is an action here for u= s.
=A0 =A0 =A0> > There are two "violations" that exist:
=A0 =A0 =A0> > 1. Some implementations violate 6790. Not sure what we= can do about
=A0 =A0 =A0> > that in this document. Note that the entropy label can= help
=A0 =A0 with this
=A0 =A0 =A0> > but only to a limited extent since the implementations= that
=A0 =A0 violate 6790
=A0 =A0 =A0> > probably also fail to recognise the entropy label.
=A0 =A0 =A0> > 2. Implementations that conform to 6790 will understan= d that
=A0 =A0 the XL is
=A0 =A0 =A0> > a special purpose label and will not use it to load ba= lance.
=A0 =A0 But they will
=A0 =A0 =A0> > not necessarily understand that the next label is an E= SPL that
=A0 =A0 must be
=A0 =A0 =A0> > skipped as well. Again, there is nothing we can do abo= ut this
=A0 =A0 except to
=A0 =A0 =A0> > note it (done) and possibly to use the EL further up t= he stack.
=A0 =A0 =A0>
=A0 =A0 =A0> My point was that the may in "It is noted that existin= g
=A0 =A0 implementations may
=A0 =A0 =A0> violate this" was a little soft. Most implementations,= except the
=A0 =A0 latest
=A0 =A0 =A0> designs of maybe as few as a single vendor, would certainly=
=A0 =A0 violate this.
=A0 =A0 =A0>
=A0 =A0 =A0> Also of course you are making a statement of fact and not o= f
=A0 =A0 permission
=A0 =A0 =A0> so I think it may be more precise to say:
=A0 =A0 =A0>
=A0 =A0 =A0> It is noted that most existing
=A0 =A0 =A0> implementations currently violate this, as they do not look= for
=A0 =A0 the XL
=A0 =A0 =A0> and thus for ESPLs.

=A0 =A0 OK.

=A0 =A0 I've gone with...

=A0 =A0 =A0 =A0 =A0 =A0 It is noted that existing
=A0 =A0 =A0 =A0 =A0 =A0 implementations would violate this, as they do not = recognise XL
=A0 =A0 =A0 =A0 =A0 =A0 as anything other than a single Special Purpose Lab= el and will
=A0 =A0 =A0 =A0 =A0 =A0 not expect an ESPL to follow.

=A0 =A0 [snip]

=A0 =A0 =A0> >> =A0 =A0Label 7 (when received) retains its meaning= as ELI whether
=A0 =A0 a regular
=A0 =A0 =A0> >> =A0 =A0special purpose label or an ESPL; this simp= lifies a transit
=A0 =A0 LSR's
=A0 =A0 =A0> >> =A0 =A0task of looking for entropy labels since it= may just look
=A0 =A0 for label 7
=A0 =A0 =A0> >> =A0 =A0and need not verify that the previous label= in the stack is
=A0 =A0 not the
=A0 =A0 =A0> >> =A0 =A0XL 15. =A0However, an LSR wishing to insert= an entropy label
=A0 =A0 SHOULD
=A0 =A0 =A0> >> =A0 =A0insert label 7 as a regular special purpose= label, not as
=A0 =A0 an ESPL.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> Why is this not a MUST! There is no ESPL in the wi= ld running an
=A0 =A0 =A0> >> alternate behaviour, so why not simply mandate thi= s?
=A0 =A0 =A0> > If this was a MUST then there would be no case for han= dling
=A0 =A0 Label 7 after
=A0 =A0 XL.
=A0 =A0 =A0> > There was some concern I believe that implementations = might
=A0 =A0 have a path that
=A0 =A0 =A0> > puts them on to XL insertion processing and then consi= der what
=A0 =A0 to do next.
=A0 =A0 At
=A0 =A0 =A0> > that point they might decide that label 7 is needed. =A0 =A0 =A0> >
=A0 =A0 =A0> > It seems esoteric, but I couldn't see a reason to = prohibit it.
=A0 =A0 =A0> >
=A0 =A0 =A0> > Maybe "MUST NOT include" and "SHOULD pr= ocess when received" are
=A0 =A0 =A0> > compatible.
=A0 =A0 =A0> >
=A0 =A0 =A0> > Part of me hates the idea of this change just because = I don't
=A0 =A0 want another
=A0 =A0 =A0> > working group last call before we can move forward. Ho= w
=A0 =A0 important is it?
=A0 =A0 =A0>
=A0 =A0 =A0> The reason to be stricter at the TX is that the forwarding = path
=A0 =A0 can be
=A0 =A0 =A0> simpler at the RX. I cannot see how you would get to the po= int of
=A0 =A0 putting
=A0 =A0 =A0> in L15 and then saying "you know I need to put in L7&q= uot;
=A0 =A0 particularly as no
=A0 =A0 =A0> other 0..15 is allowed.
=A0 =A0 =A0> Normally I would think that you would put in the compound l= abel
=A0 =A0 as a pair
=A0 =A0 =A0> and that is a good reason to use the compound label concept= .
=A0 =A0 =A0>
=A0 =A0 =A0> Also I see no reason for the inconsistency between L7 and a= ll of the
=A0 =A0 =A0> other L0..L15 cases.
=A0 =A0 =A0>
=A0 =A0 =A0> So I think that it's OK, but probably silly to allow L0= ..L15, but
=A0 =A0 to allow
=A0 =A0 =A0> the exception of just L7 just complicates things without go= od cause.

=A0 =A0 I'm not in a position to argue on this one as the debate and te= xt
=A0 =A0 were driven by
=A0 =A0 others.

=A0 =A0 I believe that the claim was that allowing L7 to be inserted
=A0 =A0 anywhere made
=A0 =A0 processing it easier not harder at the receiver.
=A0 =A0 Note that {XL,7} would be an error case in your way of looking at =A0 =A0 things so the
=A0 =A0 receiver should (must?) not process it.
=A0 =A0 But the claim was that h/w will simply search the stack for L7 so =A0 =A0 that allowing
=A0 =A0 {L7} and {XL, L7} to be treated in the same way made life easier fo= r
=A0 =A0 the h/w.

=A0 =A0 Bottom line, however, seems to be that you have a preference for =A0 =A0 doing it one
=A0 =A0 way, and the WG has a preference for doing it a different way. How<= br> =A0 =A0 to resolve
=A0 =A0 that?

=A0 =A0 Given the posting deadline, I've not made any change for this. = We
=A0 =A0 can continue
=A0 =A0 to discuss.

=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D=3D=3D
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> 3.2. =A0Process for Retiring Special Purpose Label= s

=A0 =A0 [snip]

=A0 =A0 =A0> >> Secondly I think the timescales are ridiculously o= ptimistic.
=A0 =A0 To get
=A0 =A0 =A0> >> a label out of circulation in 24 months seems most= unlikely. Also
=A0 =A0 =A0> >> 6 month checks is a lot of work.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> A more realistic schedule would be to poll at 12mo= nth
=A0 =A0 intervals until
=A0 =A0 =A0> >> such time as it is determined that reallocation wo= uld do not
=A0 =A0 harm and
=A0 =A0 =A0> >> then give a further 12 months notice.
=A0 =A0 =A0> > Erm, that's what the text says, I think...
=A0 =A0 =A0> >
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 12 months after the RFC deprecating th= e label value is
=A0 =A0 published,
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 an IETF-wide survey may be conducted t= o determine if the
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 deprecated label value is still in use= .
=A0 =A0 =A0> >
=A0 =A0 =A0> > The "may" in that means that the earliest yo= u can "poll" is 12
=A0 =A0 months after
=A0 =A0 the
=A0 =A0 =A0> > deprecation RFC is published (noting that the RFC won&= #39;t even
=A0 =A0 get published
=A0 =A0 =A0> > until lots of discussion and consensus to deprecate).<= br> =A0 =A0 =A0> > Then, *if* the poll response is OK, and then not earli= er than
=A0 =A0 24 months
=A0 =A0 after
=A0 =A0 =A0> > the deprecation RFC is published, publication can be r= equested
=A0 =A0 for a new RFC
=A0 =A0 =A0> > (which means that the WG has already reached consensus= , and that a
=A0 =A0 =A0> > subsequent IETF last call will be held).
=A0 =A0 =A0> >
=A0 =A0 =A0> > Frankly, I think that this process is only likely to b= e
=A0 =A0 executed for SPLs
=A0 =A0 that
=A0 =A0 =A0> > are allocated "in error", because other stuf= f will probably be
=A0 =A0 in the field.
=A0 =A0 Can
=A0 =A0 =A0> > you think of a label that was allocated in error? I ca= n :-)
=A0 =A0 =A0>
=A0 =A0 =A0> This seems like a lot of text to specify in detail somethin= g we
=A0 =A0 would never
=A0 =A0 =A0> run. In protocols, including this type of protocol, the few= er
=A0 =A0 words used to
=A0 =A0 =A0> describe the rarely executed exception path the better.

=A0 =A0 The case was considered worthy of inclusion because the SPL range i= s
=A0 =A0 so small.
=A0 =A0 If any SPL can be reclaimed at some future time it will be very
=A0 =A0 valuable and so
=A0 =A0 a mechanism needs to be documented against that happy day.

=A0 =A0 [snip]
=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0 =A0 [snip]
=A0 =A0 =A0> >> However that brings me to
=A0 =A0 =A0> >> suggest that you probably need to write an OPs sec= tion and
=A0 =A0 =A0> >> you might want to think about the PM implications = of the extra
=A0 =A0 =A0> >> metatdata in the packets.
=A0 =A0 =A0> >
=A0 =A0 =A0> > What OPS issues had you in mind that need to be addres= sed? I am
=A0 =A0 a fan of OPS
=A0 =A0 =A0> > sections, but not a fan of empty OPS sections, and whe= n we
=A0 =A0 looked through
=A0 =A0 =A0> > RFC 6123 (which is my favourite crib for what to descr= ibe wrt
=A0 =A0 manageability)
=A0 =A0 we
=A0 =A0 =A0> > didn't see anything that has changed from pre-exis= ting MPLS.
=A0 =A0 =A0> >
=A0 =A0 =A0> > What metadata are you talking about? Is an existing sp= ecial
=A0 =A0 purpose label
=A0 =A0 =A0> > metadata? If so, the PM issues are pre-existing. Is th= ere
=A0 =A0 something special
=A0 =A0 =A0> > introduced by this I-D that constitutes metadata?
=A0 =A0 =A0>
=A0 =A0 =A0> Well what follows an XL is certainly metadata, and one appl= ication is
=A0 =A0 =A0> certainly to introduce tags that would alert the PM devices= to
=A0 =A0 take an
=A0 =A0 =A0> interest.

=A0 =A0 OK it is a form of metadata as existing SPLs are metadata.
=A0 =A0 The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI=
=A0 =A0 that the SPL
=A0 =A0 is there.
=A0 =A0 What has changed?
=A0 =A0 We could certainly sit down and write an I-D about the implications=
=A0 =A0 of using
=A0 =A0 MPLS in an environment where PM might be present (BTW, I assume thi= s is
=A0 =A0 Pervasive Monitoring. Would be embarrassing to find you meant
=A0 =A0 something else
=A0 =A0 :-). I think such an I-D would discuss SPLs as indicative metadata<= br> =A0 =A0 and would
=A0 =A0 then note that ESPLs are in the same category.
=A0 =A0 Is *this* the I-D in which to have that discussion?

=A0 =A0 [snip]

=A0 =A0 I'll post the revised I-D in a few minutes and others can throw=
=A0 =A0 vegetables
=A0 =A0 (rotten or otherwise).

=A0 =A0 Adrian

=A0 =A0 _______________________________________________
=A0 =A0 mpls mailing list
=A0 =A0 mpls@ietf.org <mailto:mpls@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/mpls
=




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


--


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

--20cf3040e372d1862104f26b2259-- From nobody Sat Feb 15 02:13: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 8B36A1A0102 for ; Sat, 15 Feb 2014 02:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 XYXkZZgundSl for ; Sat, 15 Feb 2014 02:13:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90A151A00D5 for ; Sat, 15 Feb 2014 02:13:35 -0800 (PST) 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 BDP62435; Sat, 15 Feb 2014 10:13:33 +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; Sat, 15 Feb 2014 10:12:26 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 10:12:26 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 18:12:23 +0800 From: Tao chou To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKjZqT0gdNQ/IJUa+LMrbUoFSMA== Date: Sat, 15 Feb 2014 10:12:22 +0000 Message-ID: <28BF96E93B752C4886970D1815EB8E352BA5567E@nkgeml507-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.81.31] Content-Type: multipart/alternative; boundary="_000_28BF96E93B752C4886970D1815EB8E352BA5567Enkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/H3WeNKT_oiWkycRRWGVpUMIhviQ Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 15 Feb 2014 10:13:38 -0000 --_000_28BF96E93B752C4886970D1815EB8E352BA5567Enkgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KQmVzdCByZWdhcmRzLA0KVGFvDQoNCkZyb206IG1wbHMgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3NzIENhbGxvbg0KU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDI6NDYgUE0NClRvOiBtcGxzQGlldGYub3JnDQpDYzogbXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSBQb2xsIGZvciBBZG9wdGlv biBkcmFmdC1jaGVuLW1wbHMtcDJtcC1lZ3Jlc3MtcHJvdGVjdGlvbi0xMQ0KDQpUaGlzIGlzIHRv IHN0YXJ0IGEgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1jaGVuLW1wbHMtcDJtcC1lZ3Jlc3MtcHJv dGVjdGlvbi0xMQ0KYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBTaW5jZSBtYW55 IG9mIHVzIHdpbGwgYmUgaW4gdHJhbnNpdCB0byB0aGUNCklFVEYgYXBwcm94aW1hdGVseSB0d28g d2Vla3MgZnJvbSBub3csIEkgd2lsbCBleHRlbnQgdGhlIHBvbGwgYnkgb25lIHdlZWsgKHNvDQp0 aGF0IGl0IHdpbGwgYmUgYSB0aHJlZSB3ZWVrIHBvbGwpLg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNv bW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwDQpt YWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+KS4NCg0KVGhp cyBwb2xsIHdpbGwgZW5kIEZyaWRheSBNYXJjaCA3LCAyMDE0LiBOb3RlIHRoYXQgdGhpcyBpcyB0 aGUgRnJpZGF5IG9mIHRoZSBJRVRGLA0KYW5kIHRodXMgd2Ugd2lsbCBlYWNoIG5lZWQgdG8gcGxh biBvdXIgcmV2aWV3IG9mIHRoZSBkb2N1bWVudCBhbmQgcmVzcG9uc2UNCmFyb3VuZCBvdXIgdHJh dmVsIHBsYW5zIGFuZCBJRVRGIGFjdGl2aXRpZXMuDQoNClRoYW5rcywgUm9zcw0K --_000_28BF96E93B752C4886970D1815EB8E352BA5567Enkgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Support.

Best regards,
Tao
=  
= From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 2:46= PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org<= /font>
Subject: [mpls] Poll for Adoption draf= t-chen-mpls-p2mp-egress-protection-11
=  
= This is to start a poll on adopting draft= -chen-mpls-p2mp-egress-protection-11
= as an MPLS working group document. Since = many of us will be in transit to the
= IETF approximately two weeks from now, I = will extent the poll by one week (so
= that it will be a three week poll).
=  
=  
= This poll will end Friday March 7, 2014. = Note that this is the Friday of the IETF,
= and thus we will each need to plan our re= view of the document and response
= around our travel plans and IETF activiti= es.
=  
= Thanks, Ross<= /div>
--_000_28BF96E93B752C4886970D1815EB8E352BA5567Enkgeml507mbschi_-- From nobody Sat Feb 15 09:09: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 1ACB71A015F for ; Sat, 15 Feb 2014 09:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 AMw0CTXRxQwa for ; Sat, 15 Feb 2014 09:09:48 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 02B3D1A0185 for ; Sat, 15 Feb 2014 09:09:47 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 19so26806032ykq.7 for ; Sat, 15 Feb 2014 09:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vGWX1MTwe04yDeGOmGgfxYVDdtKqLFjJ5FU2TcaEup8=; b=l16GZ7XV4xDaMFvuT8NQobPxLXxjP0JH6qN/R36MwrZp5BGU+hUAI6cUrY3jIJkCcK z5ijgnS20iNHK1vtw/avEF1r2sewyaWCjiTwxn5zfXs1nywf0i5lyiWlxXjGfrfedn+c LIZd1LdCDGW4WDt7yEnd0z5gr4qPoVtLstinGZ1G5FnL6pl/U/fjNtR0bK6UssU8nNUe 2KGBvJba8JKEi2Mo8FtYMS+3oSEINLIoES2pvpjrLwHLNLmsu6s1GbfUuNwzZMqltg0z 6EXITRpvFSEs+t1Kh/0CLD7sWmyJgjLN0BKE57ieKOV43xExe/NZQSR/s0vwJdE39xzz b5Ig== MIME-Version: 1.0 X-Received: by 10.236.89.11 with SMTP id b11mr15089487yhf.16.1392484186037; Sat, 15 Feb 2014 09:09:46 -0800 (PST) Received: by 10.170.185.212 with HTTP; Sat, 15 Feb 2014 09:09:45 -0800 (PST) In-Reply-To: References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> Date: Sat, 15 Feb 2014 12:09:45 -0500 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf300e56b743a63304f274fd60 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/d_aeWMBwrvdWqSiGMP6jgUvg7GI Cc: "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 15 Feb 2014 17:09:53 -0000 --20cf300e56b743a63304f274fd60 Content-Type: text/plain; charset=ISO-8859-1 [+ietf] Loa, To clarify a bit better, what I'm trying to get clarified into the text is why the ELI value as an ESPL needs to be an exception (as the draft indicates). I believe it is because forbidding an ESPL of 7 can break some existing and deployed versions of RFC 6790 such that the transit traffic flows are affected. There may also be implementations of RFC 6790 that aren't affected. Regards, Alia On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas wrote: > Loa, > > On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson wrote: > >> Alia, >> >> Two comments on this. >> >> First a nit "An LSR wishing to insert an ...", LSR are boxes and can't >> wish anything for themselves, a Simple change would be "When an LSR >> insert..." >> >> Actually the same is true for the current text and should be changed the >> same way. >> > > [Alia] Sure - I took the original text and modified it. > > Second, and this is maybe more tricky - the reason given "simplify the >> data plane implementation" is not true and might even be wrong. >> The reason put always using the ELI as a "regular special purpose label" >> is backwards compatibility. >> I would claim that the treatment of the ELI is an (well motivated) >> exception, but exceptions always mean that things get more complicated. >> > > [Alia] There were three purposes to my suggested text change. First, to > specify that > an LSR MUST NOT insert the ELI as an ESPL. Second, to say that a > receiving LSR > MAY choose to not discard a packet with the ELI as an ESPL. Third, I > wanted to see > a clearer justification for why this exception is worth making. > > [Alia] Since the whole draft is about a data-plane change, what we've been > putting in doesn't > really articulate the full problem. Prelim text would around that would > be better as: > > "ELI is an exception because each LSR examines the whole label stack to > see if the ELI > appears; pre-existing implementations of [Entropy-Label] do this > examination without verifying > that the label above the ELI is not XL. If a packet used an ESPL of 7 and > that did not mean > ELI, then when that packet transited deployed LSRs, which implement > [Entropy-Label] and not this document, > the meaning of the ESPL would be misinterpreted. Such a misinterpretation > could result in poor traffic behavior (large flows, > reordered flows, etc.) depending on the label after the ESPL of 7. It is > to avoid such issues that ELI is defined as an exception > that can appear as an regular special label or as an ESPL with the same > value of 7." > > What do you think? > > Alia > > I don't want to propose a final text,but something along these lines: >> >> >> "Label 7 (when received) retains its meaning as ELI whether a >> regular special purpose label or an ESPL; this is because of backwards >> compatibility with existing implemented and deployed code and hardware >> that looks for the ELI without verifying if the previous label >> is XL or not. However, when an LSR insert an entropy label it SHOULD >> insert the ELI as a regular special purpose label, not as an ESPL." >> >> /Loa >> >> >> On 2014-02-15 10:52, Alia Atlas wrote: >> >>> Adrian and others, >>> >>> Having reviewed the 05 of this draft and this thread, I have the >>> following suggestions. Other than these, I'm quite happy with how this >>> draft has improved. >>> >>> a) In Sec 3.1, the following paragraph could be updated from: >>> >>> "Label 7 (when received) retains its meaning as ELI whether a >>> regular special purpose label or an ESPL; this simplifies a transit >>> LSR's task of looking for entropy labels since it may just look for >>> label 7 and need not verify that the previous label in the stack is not >>> the XL 15. However, an LSR wishing to insert an entropy label SHOULD >>> insert label 7 as a regular special purpose label, not as an ESPL." >>> >>> >>> to: >>> >>> >>> "An LSR wishing to insert an entropy label MUST insert label value 7 >>> (meaning ELI) as a regular special purpose >>> >>> label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data >>> plane. However, to simplify >>> >>> >>> the data plane implementation for Entropy Labels, an implementation MAY >>> >>> interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and >>> 8-15, an implementation >>> >>> MAY choose to not treat the packet as malformedand thus discard it. The >>> data plane simplification thus enabled >>> >>> >>> is the ability to determine if any label value is 7 without needing to >>> verify that the previous label in the stack is not the XL value of 15." >>> >>> >>> b)In Sec 3.2: "An RFC with at least Informational status is required." >>> How is this different from IETF Review in RFC 5226? Do BCPs count? What >>> is "at least Informational status"? >>> >>> >>> >>> On the concern about Pervasive Monitoring, the only advantage that (XL, >>> ESPL) offers is that the labels wouldn't (eventually) be hashed for >>> load-balancing. Otherwise, the label stack offers the ability for >>> meta-data already where only the receiver would need to understand it. >>> Consistent paths are very useful, but there are other ways of doing >>> this already - with the most trivial being just using label 15. I have >>> a hard time seeing this as a new attack vector (but I'm not >>> professionally paranoid yet). >>> >>> Alia >>> >>> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel >> > wrote: >>> >>> [snip] >>> >>> > >> XL The Extension Label that indicates that an extended >>> special >>> > >> purpose label follows. >>> > >> >>> > >> ESPL An Extended Special Purpose Label. >>> > >> >>> > >> Something that I think would be worthwhile clarifying right at >>> the >>> > >> front is that a label is an ESPL IFF it is preceded by an XL. >>> > >> It might even be worth noting that really we have a new label >>> type: >>> > >> a label couple in which the first label defines the type of the >>> > >> second label and neither are of any use as individual labels. >>> > > I can see how you would see this as a new label type. Maybe >>> "compound" >>> > > rather than "couple". >>> > > However, I am not convinced that it is new that one label leads >>> to the >>> semantics >>> > > of the next (for example the entropy label). >>> > > What is more, I am not sure that there will be more than this >>> instance of >>> this >>> > > type of tight coupling. >>> > > So I would rather leave this point out. >>> > I can foresee other cases where we might use label pairs to >>> mitigate the >>> > 20bit limit. I am sure it has been discussed, so creating the >>> reference >>> > might be useful. Just because this was not done in EL, does not >>> mean that >>> > we should not set down the concept here. >>> > >>> > However I agree compound would be a better term. >>> > >>> > > >>> > > But as to clarifying ESPL: yes. >>> > > The XP definition is, I think, clear. >>> > > How about... >>> > > >>> > > ESPL An Extended Special Purpose Label. A Special Purpose Label >>> that >>> > > is placed in the label stack after the Extension Label. >>> > >>> > Yes. Indeed it MUST be placed be placed there, however the >>> definition >>> > above is fine. >>> >>> OK, I updated to... >>> >>> ESPL An Extended Special Purpose Label. A Special Purpose Label >>> that >>> is placed in the label stack after the Extension Label. The >>> combination of XL and ESPL might be regarded as a new form >>> of >>> "compound label" comprising more than one consecutive entry >>> in >>> the label stack. >>> >>> ..to cover your other point as well. >>> >>> > >> ====== >>> > >> >>> > >> I think that the draft will need to provide some guidance >>> > >> on when to allocate a 0..15 and when to allocate an ESPL. >>> > >> >>> > >> I imagine that a 0..15 should only be used when it can be shown >>> > >> that the extra stack space of forwarding time is burdensome >>> > >> but that is a question that the WG should explicitly consider. >>> > > We discussed this at some point on the MPLS list (many >>> centuries ago, I >>> think) >>> > > and reached no conclusion. >>> > > The primary purpose of the XL is to handle the time when 0..15 >>> is depleted. >>> > > You're right that we could encourage people to start using >>> ESPLs now before >>> > > 0..15 is depleted. But it is hard to make the case for >>> requiring it when >>> there >>> > > is still some of 0..15 available and the rate of burn is not so >>> high. >>> > > >>> > > We could put in some text like... >>> > > >>> > > When allocating a new Special Purpose Label, protocol designers >>> should >>> > > consider whether they could, instead, use an Extended Special >>> Purpose >>> > > Label. Doing so would help to preserve the scarce resources of >>> Special >>> > > Purpose Labels for use in cases where minimizing the label >>> stack size is >>> > > particularly important. >>> > >>> > That would be useful text. >>> >>> Added as new section 3.1.2 with slight tweak to wording. >>> >>> [snip] >>> >>> > >> 6. [RFC6790] says that special purpose labels MUST NOT be >>> used for >>> > >> load balancing. The same logic applies to extended >>> special >>> > >> purpose labels (ESPLs). Thus, this document specifies >>> that ESPLs >>> > >> MUST NOT be used for load balancing. It is noted that >>> existing >>> > >> implementations may violate this, as they do not look >>> for the XL >>> > >> and thus for ESPLs. The consequence is that if ESPLs >>> are used in >>> > >> some packets of a flow, these packets may be delivered >>> on >>> > >> different paths and so could be re-ordered. However, >>> it is >>> > >> important to specify the correct behavior for future >>> > >> implementations, hence the use of "MUST NOT". >>> > >> >>> > >> I would suggest that most implementations do violate this. I >>> would >>> > >> also suggest that it seems unlikely that you will get to the >>> point >>> > >> where it is not violated in the foreseeable future. >>> > > I can't tell whether there is an action here for us. >>> > > There are two "violations" that exist: >>> > > 1. Some implementations violate 6790. Not sure what we can do >>> about >>> > > that in this document. Note that the entropy label can help >>> with this >>> > > but only to a limited extent since the implementations that >>> violate 6790 >>> > > probably also fail to recognise the entropy label. >>> > > 2. Implementations that conform to 6790 will understand that >>> the XL is >>> > > a special purpose label and will not use it to load balance. >>> But they will >>> > > not necessarily understand that the next label is an ESPL that >>> must be >>> > > skipped as well. Again, there is nothing we can do about this >>> except to >>> > > note it (done) and possibly to use the EL further up the stack. >>> > >>> > My point was that the may in "It is noted that existing >>> implementations may >>> > violate this" was a little soft. Most implementations, except the >>> latest >>> > designs of maybe as few as a single vendor, would certainly >>> violate this. >>> > >>> > Also of course you are making a statement of fact and not of >>> permission >>> > so I think it may be more precise to say: >>> > >>> > It is noted that most existing >>> > implementations currently violate this, as they do not look for >>> the XL >>> > and thus for ESPLs. >>> >>> OK. >>> >>> I've gone with... >>> >>> It is noted that existing >>> implementations would violate this, as they do not recognise >>> XL >>> as anything other than a single Special Purpose Label and >>> will >>> not expect an ESPL to follow. >>> >>> [snip] >>> >>> > >> Label 7 (when received) retains its meaning as ELI whether >>> a regular >>> > >> special purpose label or an ESPL; this simplifies a transit >>> LSR's >>> > >> task of looking for entropy labels since it may just look >>> for label 7 >>> > >> and need not verify that the previous label in the stack is >>> not the >>> > >> XL 15. However, an LSR wishing to insert an entropy label >>> SHOULD >>> > >> insert label 7 as a regular special purpose label, not as >>> an ESPL. >>> > >> >>> > >> Why is this not a MUST! There is no ESPL in the wild running an >>> > >> alternate behaviour, so why not simply mandate this? >>> > > If this was a MUST then there would be no case for handling >>> Label 7 after >>> XL. >>> > > There was some concern I believe that implementations might >>> have a path that >>> > > puts them on to XL insertion processing and then consider what >>> to do next. >>> At >>> > > that point they might decide that label 7 is needed. >>> > > >>> > > It seems esoteric, but I couldn't see a reason to prohibit it. >>> > > >>> > > Maybe "MUST NOT include" and "SHOULD process when received" are >>> > > compatible. >>> > > >>> > > Part of me hates the idea of this change just because I don't >>> want another >>> > > working group last call before we can move forward. How >>> important is it? >>> > >>> > The reason to be stricter at the TX is that the forwarding path >>> can be >>> > simpler at the RX. I cannot see how you would get to the point of >>> putting >>> > in L15 and then saying "you know I need to put in L7" >>> particularly as no >>> > other 0..15 is allowed. >>> > Normally I would think that you would put in the compound label >>> as a pair >>> > and that is a good reason to use the compound label concept. >>> > >>> > Also I see no reason for the inconsistency between L7 and all of >>> the >>> > other L0..L15 cases. >>> > >>> > So I think that it's OK, but probably silly to allow L0..L15, but >>> to allow >>> > the exception of just L7 just complicates things without good >>> cause. >>> >>> I'm not in a position to argue on this one as the debate and text >>> were driven by >>> others. >>> >>> I believe that the claim was that allowing L7 to be inserted >>> anywhere made >>> processing it easier not harder at the receiver. >>> Note that {XL,7} would be an error case in your way of looking at >>> things so the >>> receiver should (must?) not process it. >>> But the claim was that h/w will simply search the stack for L7 so >>> that allowing >>> {L7} and {XL, L7} to be treated in the same way made life easier for >>> the h/w. >>> >>> Bottom line, however, seems to be that you have a preference for >>> doing it one >>> way, and the WG has a preference for doing it a different way. How >>> to resolve >>> that? >>> >>> Given the posting deadline, I've not made any change for this. We >>> can continue >>> to discuss. >>> >>> > >> ======== >>> > >> >>> > >> 3.2. Process for Retiring Special Purpose Labels >>> >>> [snip] >>> >>> > >> Secondly I think the timescales are ridiculously optimistic. >>> To get >>> > >> a label out of circulation in 24 months seems most unlikely. >>> Also >>> > >> 6 month checks is a lot of work. >>> > >> >>> > >> A more realistic schedule would be to poll at 12month >>> intervals until >>> > >> such time as it is determined that reallocation would do not >>> harm and >>> > >> then give a further 12 months notice. >>> > > Erm, that's what the text says, I think... >>> > > >>> > > 12 months after the RFC deprecating the label value is >>> published, >>> > > an IETF-wide survey may be conducted to determine if the >>> > > deprecated label value is still in use. >>> > > >>> > > The "may" in that means that the earliest you can "poll" is 12 >>> months after >>> the >>> > > deprecation RFC is published (noting that the RFC won't even >>> get published >>> > > until lots of discussion and consensus to deprecate). >>> > > Then, *if* the poll response is OK, and then not earlier than >>> 24 months >>> after >>> > > the deprecation RFC is published, publication can be requested >>> for a new RFC >>> > > (which means that the WG has already reached consensus, and >>> that a >>> > > subsequent IETF last call will be held). >>> > > >>> > > Frankly, I think that this process is only likely to be >>> executed for SPLs >>> that >>> > > are allocated "in error", because other stuff will probably be >>> in the field. >>> Can >>> > > you think of a label that was allocated in error? I can :-) >>> > >>> > This seems like a lot of text to specify in detail something we >>> would never >>> > run. In protocols, including this type of protocol, the fewer >>> words used to >>> > describe the rarely executed exception path the better. >>> >>> The case was considered worthy of inclusion because the SPL range is >>> so small. >>> If any SPL can be reclaimed at some future time it will be very >>> valuable and so >>> a mechanism needs to be documented against that happy day. >>> >>> [snip] >>> > >> =========== >>> [snip] >>> > >> However that brings me to >>> > >> suggest that you probably need to write an OPs section and >>> > >> you might want to think about the PM implications of the extra >>> > >> metatdata in the packets. >>> > > >>> > > What OPS issues had you in mind that need to be addressed? I am >>> a fan of OPS >>> > > sections, but not a fan of empty OPS sections, and when we >>> looked through >>> > > RFC 6123 (which is my favourite crib for what to describe wrt >>> manageability) >>> we >>> > > didn't see anything that has changed from pre-existing MPLS. >>> > > >>> > > What metadata are you talking about? Is an existing special >>> purpose label >>> > > metadata? If so, the PM issues are pre-existing. Is there >>> something special >>> > > introduced by this I-D that constitutes metadata? >>> > >>> > Well what follows an XL is certainly metadata, and one >>> application is >>> > certainly to introduce tags that would alert the PM devices to >>> take an >>> > interest. >>> >>> OK it is a form of metadata as existing SPLs are metadata. >>> The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI >>> that the SPL >>> is there. >>> What has changed? >>> We could certainly sit down and write an I-D about the implications >>> of using >>> MPLS in an environment where PM might be present (BTW, I assume this >>> is >>> Pervasive Monitoring. Would be embarrassing to find you meant >>> something else >>> :-). I think such an I-D would discuss SPLs as indicative metadata >>> and would >>> then note that ESPLs are in the same category. >>> Is *this* the I-D in which to have that discussion? >>> >>> [snip] >>> >>> I'll post the revised I-D in a few minutes and others can throw >>> vegetables >>> (rotten or otherwise). >>> >>> Adrian >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> > > --20cf300e56b743a63304f274fd60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[+ietf]

Loa,

To clarify= a bit better, what I'm trying to get clarified into the text is why th= e ELI value as an ESPL
needs to be an exception (as the draft indicates= ). =A0I believe it is because forbidding an ESPL of 7
can break some existing and deployed versions of RFC 6790 such t= hat the transit traffic flows are affected.
There may also be implementations of RFC 6790 th= at aren't affected.

Regards,
Alia


On Sat,= Feb 15, 2014 at 12:24 AM, Alia Atlas <akatlas@gmail.com> wr= ote:
Loa,

On Fri, Feb 14, 2014= at 11:58 PM, Loa Andersson <loa@pi.nu> wrote:
Alia,

Two comments on this.

First a nit "An LSR wishing to insert an ...", LSR are boxes and = can't
wish anything for themselves, a Simple change would be "When an LSR insert..."

Actually the same is true for the current text and should be changed the same way.

[Alia] Sure - I took th= e original text and modified it.=A0

Second, and this is maybe more tricky - the reason given "simplify the=
data plane implementation" is not true and might even be wrong.
The reason put always using the ELI as a "regular special purpose labe= l"
is backwards compatibility.
I would claim that the treatment of the ELI is an (well motivated)
exception, but exceptions always mean that things get more complicated.
=

[Alia] There were three purposes to = my suggested text change. =A0First, to specify that
an LSR MUST N= OT insert the ELI as an ESPL. =A0 Second, to say that a receiving LSR
MAY choose to not discard a packet with the ELI as an ESPL. =A0Third, = I wanted to see
a clearer justification for why this exception is= worth making.

[Alia] Since the whole draft is abo= ut a data-plane change, what we've been putting in doesn't
really articulate the full problem. =A0Prelim text would around that w= ould be better as:

"ELI is an exception becau= se each LSR examines the whole label stack to see if the ELI
appe= ars; pre-existing implementations of [Entropy-Label] do this examination wi= thout verifying
that the label above the ELI is not XL. =A0If a packet used an ESPL of= 7 and that did not mean
ELI, then when that packet transited dep= loyed LSRs, which implement [Entropy-Label] and not this document,=A0
the meaning of the ESPL would be misinterpreted. =A0Such a misinterpre= tation could result in poor traffic behavior (large flows,
reorde= red flows, etc.) depending on the label after the ESPL of 7. =A0It is to av= oid such issues that ELI is defined as an exception
that can appear as an regular special label or as an ESPL with the sam= e value of 7."
=A0
What do you think?

Alia

I don't want to propose a final text,but something along these lines:

"Label 7 (when received) retains its meaning as ELI whether a
=A0regular special purpose label or an ESPL; this is because of backwards =A0compatibility with existing implemented and deployed code and hardware =A0that looks for the ELI without verifying if the previous label
=A0is XL or not. However, when an LSR insert an entropy label it SHOULD
=A0insert the ELI as a regular special purpose label, not as an ESPL."=

/Loa


On 2014-02-15 10:52, Alia Atlas wrote:
Adrian and others,

Having reviewed the 05 of this draft and this thread, I have the
following suggestions. =A0Other than these, I'm quite happy with how th= is
draft has improved.

a) In Sec 3.1, the following paragraph could be updated from:

"Label 7 (when received) retains its meaning as ELI whether a
regular special purpose label or an ESPL; this simplifies a transit
LSR's task of looking for entropy labels since it may just look for
label 7 =A0and need not verify that the previous label in the stack is not<= br> the XL 15. However, an LSR wishing to insert an entropy label SHOULD
insert label 7 as a regular special purpose label, not as an ESPL."

to:


"An LSR wishing to insert an entropy label MUST insert label value 7 (= meaning ELI) as a regular special purpose

label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data pl= ane. =A0However, to simplify


the data plane implementation for Entropy Labels, an implementation MAY

interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, = an implementation

MAY choose to not treat the packet as malformedand thus discard it. =A0The = data plane simplification thus enabled


is the ability to determine if any label value is 7 without needing to veri= fy that the previous label in the stack is not the XL value of 15."

b)In Sec 3.2: "An RFC with at =A0least Informational status is require= d." =A0 How is this different from IETF Review in RFC 5226? =A0Do BCPs= count? What is "at least Informational status"?



On the concern about Pervasive Monitoring, the only advantage that (XL,
ESPL) offers is that the labels wouldn't (eventually) be hashed for
load-balancing. =A0Otherwise, the label stack offers the ability for
meta-data already where only the receiver would need to understand it.
=A0 Consistent paths are very useful, but there are other ways of doing
this already - with the most trivial being just using label 15. =A0I have a hard time seeing this as a new attack vector (but I'm not
professionally paranoid yet).

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <adrian@olddog.co.uk
<mailto:adrian@= olddog.co.uk>> wrote:

=A0 =A0 [snip]

=A0 =A0 =A0> >> XL =A0 The Extension Label that indicates that an = extended special
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0 purpose label follows.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> ESPL An Extended Special Purpose Label.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> Something that I think would be worthwhile clarify= ing right at the
=A0 =A0 =A0> >> front is that a label is an ESPL IFF it is precede= d by an XL.
=A0 =A0 =A0> >> It might even be worth noting that really we have = a new label
=A0 =A0 type:
=A0 =A0 =A0> >> a label couple in which the first label defines th= e type of the
=A0 =A0 =A0> >> second label and neither are of any use as individ= ual labels.
=A0 =A0 =A0> > I can see how you would see this as a new label type. = Maybe
=A0 =A0 "compound"
=A0 =A0 =A0> > rather than "couple".
=A0 =A0 =A0> > However, I am not convinced that it is new that one la= bel leads
=A0 =A0 to the
=A0 =A0 semantics
=A0 =A0 =A0> > of the next (for example the entropy label).
=A0 =A0 =A0> > What is more, I am not sure that there will be more th= an this
=A0 =A0 instance of
=A0 =A0 this
=A0 =A0 =A0> > type of tight coupling.
=A0 =A0 =A0> > So I would rather leave this point out.
=A0 =A0 =A0> I can foresee other cases where we might use label pairs to=
=A0 =A0 mitigate the
=A0 =A0 =A0> 20bit limit. I am sure it has been discussed, so creating t= he
=A0 =A0 reference
=A0 =A0 =A0> might be useful. Just because this was not done in EL, does= not
=A0 =A0 mean that
=A0 =A0 =A0> we should not set down the concept here.
=A0 =A0 =A0>
=A0 =A0 =A0> However I agree compound would be a better term.
=A0 =A0 =A0>
=A0 =A0 =A0> >
=A0 =A0 =A0> > But as to clarifying ESPL: yes.
=A0 =A0 =A0> > The XP definition is, I think, clear.
=A0 =A0 =A0> > How about...
=A0 =A0 =A0> >
=A0 =A0 =A0> > ESPL An Extended Special Purpose Label. A Special Purp= ose Label
=A0 =A0 that
=A0 =A0 =A0> > =A0 =A0 =A0 is placed in the label stack after the Ext= ension Label.
=A0 =A0 =A0>
=A0 =A0 =A0> Yes. Indeed it MUST be placed be placed there, however the = definition
=A0 =A0 =A0> above is fine.

=A0 =A0 OK, I updated to...

=A0 =A0 =A0 =A0 ESPL An Extended Special Purpose Label. A Special Purpose L= abel that
=A0 =A0 =A0 =A0 =A0 =A0 =A0is placed in the label stack after the Extension= Label. =A0The
=A0 =A0 =A0 =A0 =A0 =A0 =A0combination of XL and ESPL might be regarded as = a new form of
=A0 =A0 =A0 =A0 =A0 =A0 =A0"compound label" comprising more than = one consecutive entry in
=A0 =A0 =A0 =A0 =A0 =A0 =A0the label stack.

=A0 =A0 ..to cover your other point as well.

=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I think that the draft will need to provide some g= uidance
=A0 =A0 =A0> >> on when to allocate a 0..15 and when to allocate a= n ESPL.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I imagine that a 0..15 should only be used when it= can be shown
=A0 =A0 =A0> >> that the extra stack space of forwarding time is b= urdensome
=A0 =A0 =A0> >> but that is a question that the WG should explicit= ly consider.
=A0 =A0 =A0> > We discussed this at some point on the MPLS list (many=
=A0 =A0 centuries ago, I
=A0 =A0 think)
=A0 =A0 =A0> > and reached no conclusion.
=A0 =A0 =A0> > The primary purpose of the XL is to handle the time wh= en 0..15
=A0 =A0 is depleted.
=A0 =A0 =A0> > You're right that we could encourage people to sta= rt using
=A0 =A0 ESPLs now before
=A0 =A0 =A0> > 0..15 is depleted. But it is hard to make the case for=
=A0 =A0 requiring it when
=A0 =A0 there
=A0 =A0 =A0> > is still some of 0..15 available and the rate of burn = is not so
=A0 =A0 high.
=A0 =A0 =A0> >
=A0 =A0 =A0> > We could put in some text like...
=A0 =A0 =A0> >
=A0 =A0 =A0> > When allocating a new Special Purpose Label, protocol = designers
=A0 =A0 should
=A0 =A0 =A0> > consider whether they could, instead, use an Extended = Special
=A0 =A0 Purpose
=A0 =A0 =A0> > Label. Doing so would help to preserve the scarce reso= urces of
=A0 =A0 Special
=A0 =A0 =A0> > Purpose Labels for use in cases where minimizing the l= abel
=A0 =A0 stack size is
=A0 =A0 =A0> > particularly important.
=A0 =A0 =A0>
=A0 =A0 =A0> That would be useful text.

=A0 =A0 Added as new section 3.1.2 with slight tweak to wording.

=A0 =A0 [snip]

=A0 =A0 =A0> >> =A0 =A0 6. =A0[RFC6790] says that special purpose = labels MUST NOT be
=A0 =A0 used for
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0load balancing. =A0The same logic a= pplies to extended special
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0purpose labels (ESPLs). =A0Thus, th= is document specifies
=A0 =A0 that ESPLs
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0MUST NOT be used for load balancing= . =A0It is noted that
=A0 =A0 existing
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0implementations may violate this, a= s they do not look
=A0 =A0 for the XL
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0and thus for ESPLs. =A0The conseque= nce is that if ESPLs
=A0 =A0 are used in
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0some packets of a flow, these packe= ts may be delivered on
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0different paths and so could be re-= ordered. =A0However, it is
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0important to specify the correct be= havior for future
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0implementations, hence the use of &= quot;MUST NOT".
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I would suggest that most implementations do viola= te this. I would
=A0 =A0 =A0> >> also suggest that it seems unlikely that you will = get to the point
=A0 =A0 =A0> >> where it is not violated in the foreseeable future= .
=A0 =A0 =A0> > I can't tell whether there is an action here for u= s.
=A0 =A0 =A0> > There are two "violations" that exist:
=A0 =A0 =A0> > 1. Some implementations violate 6790. Not sure what we= can do about
=A0 =A0 =A0> > that in this document. Note that the entropy label can= help
=A0 =A0 with this
=A0 =A0 =A0> > but only to a limited extent since the implementations= that
=A0 =A0 violate 6790
=A0 =A0 =A0> > probably also fail to recognise the entropy label.
=A0 =A0 =A0> > 2. Implementations that conform to 6790 will understan= d that
=A0 =A0 the XL is
=A0 =A0 =A0> > a special purpose label and will not use it to load ba= lance.
=A0 =A0 But they will
=A0 =A0 =A0> > not necessarily understand that the next label is an E= SPL that
=A0 =A0 must be
=A0 =A0 =A0> > skipped as well. Again, there is nothing we can do abo= ut this
=A0 =A0 except to
=A0 =A0 =A0> > note it (done) and possibly to use the EL further up t= he stack.
=A0 =A0 =A0>
=A0 =A0 =A0> My point was that the may in "It is noted that existin= g
=A0 =A0 implementations may
=A0 =A0 =A0> violate this" was a little soft. Most implementations,= except the
=A0 =A0 latest
=A0 =A0 =A0> designs of maybe as few as a single vendor, would certainly=
=A0 =A0 violate this.
=A0 =A0 =A0>
=A0 =A0 =A0> Also of course you are making a statement of fact and not o= f
=A0 =A0 permission
=A0 =A0 =A0> so I think it may be more precise to say:
=A0 =A0 =A0>
=A0 =A0 =A0> It is noted that most existing
=A0 =A0 =A0> implementations currently violate this, as they do not look= for
=A0 =A0 the XL
=A0 =A0 =A0> and thus for ESPLs.

=A0 =A0 OK.

=A0 =A0 I've gone with...

=A0 =A0 =A0 =A0 =A0 =A0 It is noted that existing
=A0 =A0 =A0 =A0 =A0 =A0 implementations would violate this, as they do not = recognise XL
=A0 =A0 =A0 =A0 =A0 =A0 as anything other than a single Special Purpose Lab= el and will
=A0 =A0 =A0 =A0 =A0 =A0 not expect an ESPL to follow.

=A0 =A0 [snip]

=A0 =A0 =A0> >> =A0 =A0Label 7 (when received) retains its meaning= as ELI whether
=A0 =A0 a regular
=A0 =A0 =A0> >> =A0 =A0special purpose label or an ESPL; this simp= lifies a transit
=A0 =A0 LSR's
=A0 =A0 =A0> >> =A0 =A0task of looking for entropy labels since it= may just look
=A0 =A0 for label 7
=A0 =A0 =A0> >> =A0 =A0and need not verify that the previous label= in the stack is
=A0 =A0 not the
=A0 =A0 =A0> >> =A0 =A0XL 15. =A0However, an LSR wishing to insert= an entropy label
=A0 =A0 SHOULD
=A0 =A0 =A0> >> =A0 =A0insert label 7 as a regular special purpose= label, not as
=A0 =A0 an ESPL.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> Why is this not a MUST! There is no ESPL in the wi= ld running an
=A0 =A0 =A0> >> alternate behaviour, so why not simply mandate thi= s?
=A0 =A0 =A0> > If this was a MUST then there would be no case for han= dling
=A0 =A0 Label 7 after
=A0 =A0 XL.
=A0 =A0 =A0> > There was some concern I believe that implementations = might
=A0 =A0 have a path that
=A0 =A0 =A0> > puts them on to XL insertion processing and then consi= der what
=A0 =A0 to do next.
=A0 =A0 At
=A0 =A0 =A0> > that point they might decide that label 7 is needed. =A0 =A0 =A0> >
=A0 =A0 =A0> > It seems esoteric, but I couldn't see a reason to = prohibit it.
=A0 =A0 =A0> >
=A0 =A0 =A0> > Maybe "MUST NOT include" and "SHOULD pr= ocess when received" are
=A0 =A0 =A0> > compatible.
=A0 =A0 =A0> >
=A0 =A0 =A0> > Part of me hates the idea of this change just because = I don't
=A0 =A0 want another
=A0 =A0 =A0> > working group last call before we can move forward. Ho= w
=A0 =A0 important is it?
=A0 =A0 =A0>
=A0 =A0 =A0> The reason to be stricter at the TX is that the forwarding = path
=A0 =A0 can be
=A0 =A0 =A0> simpler at the RX. I cannot see how you would get to the po= int of
=A0 =A0 putting
=A0 =A0 =A0> in L15 and then saying "you know I need to put in L7&q= uot;
=A0 =A0 particularly as no
=A0 =A0 =A0> other 0..15 is allowed.
=A0 =A0 =A0> Normally I would think that you would put in the compound l= abel
=A0 =A0 as a pair
=A0 =A0 =A0> and that is a good reason to use the compound label concept= .
=A0 =A0 =A0>
=A0 =A0 =A0> Also I see no reason for the inconsistency between L7 and a= ll of the
=A0 =A0 =A0> other L0..L15 cases.
=A0 =A0 =A0>
=A0 =A0 =A0> So I think that it's OK, but probably silly to allow L0= ..L15, but
=A0 =A0 to allow
=A0 =A0 =A0> the exception of just L7 just complicates things without go= od cause.

=A0 =A0 I'm not in a position to argue on this one as the debate and te= xt
=A0 =A0 were driven by
=A0 =A0 others.

=A0 =A0 I believe that the claim was that allowing L7 to be inserted
=A0 =A0 anywhere made
=A0 =A0 processing it easier not harder at the receiver.
=A0 =A0 Note that {XL,7} would be an error case in your way of looking at =A0 =A0 things so the
=A0 =A0 receiver should (must?) not process it.
=A0 =A0 But the claim was that h/w will simply search the stack for L7 so =A0 =A0 that allowing
=A0 =A0 {L7} and {XL, L7} to be treated in the same way made life easier fo= r
=A0 =A0 the h/w.

=A0 =A0 Bottom line, however, seems to be that you have a preference for =A0 =A0 doing it one
=A0 =A0 way, and the WG has a preference for doing it a different way. How<= br> =A0 =A0 to resolve
=A0 =A0 that?

=A0 =A0 Given the posting deadline, I've not made any change for this. = We
=A0 =A0 can continue
=A0 =A0 to discuss.

=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D=3D=3D
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> 3.2. =A0Process for Retiring Special Purpose Label= s

=A0 =A0 [snip]

=A0 =A0 =A0> >> Secondly I think the timescales are ridiculously o= ptimistic.
=A0 =A0 To get
=A0 =A0 =A0> >> a label out of circulation in 24 months seems most= unlikely. Also
=A0 =A0 =A0> >> 6 month checks is a lot of work.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> A more realistic schedule would be to poll at 12mo= nth
=A0 =A0 intervals until
=A0 =A0 =A0> >> such time as it is determined that reallocation wo= uld do not
=A0 =A0 harm and
=A0 =A0 =A0> >> then give a further 12 months notice.
=A0 =A0 =A0> > Erm, that's what the text says, I think...
=A0 =A0 =A0> >
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 12 months after the RFC deprecating th= e label value is
=A0 =A0 published,
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 an IETF-wide survey may be conducted t= o determine if the
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 deprecated label value is still in use= .
=A0 =A0 =A0> >
=A0 =A0 =A0> > The "may" in that means that the earliest yo= u can "poll" is 12
=A0 =A0 months after
=A0 =A0 the
=A0 =A0 =A0> > deprecation RFC is published (noting that the RFC won&= #39;t even
=A0 =A0 get published
=A0 =A0 =A0> > until lots of discussion and consensus to deprecate).<= br> =A0 =A0 =A0> > Then, *if* the poll response is OK, and then not earli= er than
=A0 =A0 24 months
=A0 =A0 after
=A0 =A0 =A0> > the deprecation RFC is published, publication can be r= equested
=A0 =A0 for a new RFC
=A0 =A0 =A0> > (which means that the WG has already reached consensus= , and that a
=A0 =A0 =A0> > subsequent IETF last call will be held).
=A0 =A0 =A0> >
=A0 =A0 =A0> > Frankly, I think that this process is only likely to b= e
=A0 =A0 executed for SPLs
=A0 =A0 that
=A0 =A0 =A0> > are allocated "in error", because other stuf= f will probably be
=A0 =A0 in the field.
=A0 =A0 Can
=A0 =A0 =A0> > you think of a label that was allocated in error? I ca= n :-)
=A0 =A0 =A0>
=A0 =A0 =A0> This seems like a lot of text to specify in detail somethin= g we
=A0 =A0 would never
=A0 =A0 =A0> run. In protocols, including this type of protocol, the few= er
=A0 =A0 words used to
=A0 =A0 =A0> describe the rarely executed exception path the better.

=A0 =A0 The case was considered worthy of inclusion because the SPL range i= s
=A0 =A0 so small.
=A0 =A0 If any SPL can be reclaimed at some future time it will be very
=A0 =A0 valuable and so
=A0 =A0 a mechanism needs to be documented against that happy day.

=A0 =A0 [snip]
=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0 =A0 [snip]
=A0 =A0 =A0> >> However that brings me to
=A0 =A0 =A0> >> suggest that you probably need to write an OPs sec= tion and
=A0 =A0 =A0> >> you might want to think about the PM implications = of the extra
=A0 =A0 =A0> >> metatdata in the packets.
=A0 =A0 =A0> >
=A0 =A0 =A0> > What OPS issues had you in mind that need to be addres= sed? I am
=A0 =A0 a fan of OPS
=A0 =A0 =A0> > sections, but not a fan of empty OPS sections, and whe= n we
=A0 =A0 looked through
=A0 =A0 =A0> > RFC 6123 (which is my favourite crib for what to descr= ibe wrt
=A0 =A0 manageability)
=A0 =A0 we
=A0 =A0 =A0> > didn't see anything that has changed from pre-exis= ting MPLS.
=A0 =A0 =A0> >
=A0 =A0 =A0> > What metadata are you talking about? Is an existing sp= ecial
=A0 =A0 purpose label
=A0 =A0 =A0> > metadata? If so, the PM issues are pre-existing. Is th= ere
=A0 =A0 something special
=A0 =A0 =A0> > introduced by this I-D that constitutes metadata?
=A0 =A0 =A0>
=A0 =A0 =A0> Well what follows an XL is certainly metadata, and one appl= ication is
=A0 =A0 =A0> certainly to introduce tags that would alert the PM devices= to
=A0 =A0 take an
=A0 =A0 =A0> interest.

=A0 =A0 OK it is a form of metadata as existing SPLs are metadata.
=A0 =A0 The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI=
=A0 =A0 that the SPL
=A0 =A0 is there.
=A0 =A0 What has changed?
=A0 =A0 We could certainly sit down and write an I-D about the implications=
=A0 =A0 of using
=A0 =A0 MPLS in an environment where PM might be present (BTW, I assume thi= s is
=A0 =A0 Pervasive Monitoring. Would be embarrassing to find you meant
=A0 =A0 something else
=A0 =A0 :-). I think such an I-D would discuss SPLs as indicative metadata<= br> =A0 =A0 and would
=A0 =A0 then note that ESPLs are in the same category.
=A0 =A0 Is *this* the I-D in which to have that discussion?

=A0 =A0 [snip]

=A0 =A0 I'll post the revised I-D in a few minutes and others can throw=
=A0 =A0 vegetables
=A0 =A0 (rotten or otherwise).

=A0 =A0 Adrian

=A0 =A0 _______________________________________________
=A0 =A0 mpls mailing list
=A0 =A0 mpls@ietf.org <mailto:mpls@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/mpls





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


--


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


--20cf300e56b743a63304f274fd60-- From nobody Sun Feb 16 01:53: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 6E3281A03CC for ; Sun, 16 Feb 2014 01:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6k2wPpgZYZb for ; Sun, 16 Feb 2014 01:53:26 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE551A03C6 for ; Sun, 16 Feb 2014 01:53:26 -0800 (PST) Received: from [10.128.1.195] (node-dac.pool-182-52.dynamic.totbb.net [182.52.67.68]) (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 A4E00180156A; Sun, 16 Feb 2014 10:53:21 +0100 (CET) Message-ID: <53008A8B.4040605@pi.nu> Date: Sun, 16 Feb 2014 17:53:15 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alia Atlas References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/b9Y239jVA8g1HRxOqJcSpfn1KT4 Cc: "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 16 Feb 2014 09:53:30 -0000 Alia, Of course I can take a spin on the text, once I'm convinced this is necessary and useful. Reading things a third or fourth time, I still think that the text Adrian had in the draft is the best so far. However, the draft is now in ietf last call, and wisdom says that we shall not change documents while they are in last call. We have at least two weeks to discuss this and converge on what we want to change if anything. My point is that there no other reason that the ELI is an exception than that we have running code (that were standards compatible when implemented) that breaks if we don't make the exception. /Loa On 2014-02-16 01:09, Alia Atlas wrote: > [+ietf] > > Loa, > > To clarify a bit better, what I'm trying to get clarified into the text > is why the ELI value as an ESPL > needs to be an exception (as the draft indicates). I believe it is > because forbidding an ESPL of 7 > can break some existing and deployed versions of RFC 6790 such that the > transit traffic flows are affected. > There may also be implementations of RFC 6790 that aren't affected. > > Regards, > Alia > > > On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas > wrote: > > Loa, > > On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson > wrote: > > Alia, > > Two comments on this. > > First a nit "An LSR wishing to insert an ...", LSR are boxes and > can't > wish anything for themselves, a Simple change would be "When an LSR > insert..." > > Actually the same is true for the current text and should be > changed the > same way. > > > [Alia] Sure - I took the original text and modified it. > > Second, and this is maybe more tricky - the reason given > "simplify the > data plane implementation" is not true and might even be wrong. > The reason put always using the ELI as a "regular special > purpose label" > is backwards compatibility. > I would claim that the treatment of the ELI is an (well motivated) > exception, but exceptions always mean that things get more > complicated. > > > [Alia] There were three purposes to my suggested text change. > First, to specify that > an LSR MUST NOT insert the ELI as an ESPL. Second, to say that a > receiving LSR > MAY choose to not discard a packet with the ELI as an ESPL. Third, > I wanted to see > a clearer justification for why this exception is worth making. > > [Alia] Since the whole draft is about a data-plane change, what > we've been putting in doesn't > really articulate the full problem. Prelim text would around that > would be better as: > > "ELI is an exception because each LSR examines the whole label stack > to see if the ELI > appears; pre-existing implementations of [Entropy-Label] do this > examination without verifying > that the label above the ELI is not XL. If a packet used an ESPL of > 7 and that did not mean > ELI, then when that packet transited deployed LSRs, which implement > [Entropy-Label] and not this document, > the meaning of the ESPL would be misinterpreted. Such a > misinterpretation could result in poor traffic behavior (large flows, > reordered flows, etc.) depending on the label after the ESPL of 7. > It is to avoid such issues that ELI is defined as an exception > that can appear as an regular special label or as an ESPL with the > same value of 7." > What do you think? > > Alia > > I don't want to propose a final text,but something along these > lines: > > > "Label 7 (when received) retains its meaning as ELI whether a > regular special purpose label or an ESPL; this is because of > backwards > compatibility with existing implemented and deployed code and > hardware > that looks for the ELI without verifying if the previous label > is XL or not. However, when an LSR insert an entropy label it > SHOULD > insert the ELI as a regular special purpose label, not as an > ESPL." > > /Loa > > > On 2014-02-15 10:52, Alia Atlas wrote: > > Adrian and others, > > Having reviewed the 05 of this draft and this thread, I have the > following suggestions. Other than these, I'm quite happy > with how this > draft has improved. > > a) In Sec 3.1, the following paragraph could be updated from: > > "Label 7 (when received) retains its meaning as ELI whether a > regular special purpose label or an ESPL; this simplifies a > transit > LSR's task of looking for entropy labels since it may just > look for > label 7 and need not verify that the previous label in the > stack is not > the XL 15. However, an LSR wishing to insert an entropy > label SHOULD > insert label 7 as a regular special purpose label, not as an > ESPL." > > > to: > > > "An LSR wishing to insert an entropy label MUST insert label > value 7 (meaning ELI) as a regular special purpose > > label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL > in the data plane. However, to simplify > > > the data plane implementation for Entropy Labels, an > implementation MAY > > interpret an ESPL of 7 as meaning ELI and, unlike for values > 0-6 and 8-15, an implementation > > MAY choose to not treat the packet as malformedand thus > discard it. The data plane simplification thus enabled > > > is the ability to determine if any label value is 7 without > needing to verify that the previous label in the stack is > not the XL value of 15." > > > b)In Sec 3.2: "An RFC with at least Informational status is > required." How is this different from IETF Review in RFC > 5226? Do BCPs count? What is "at least Informational status"? > > > > On the concern about Pervasive Monitoring, the only > advantage that (XL, > ESPL) offers is that the labels wouldn't (eventually) be > hashed for > load-balancing. Otherwise, the label stack offers the > ability for > meta-data already where only the receiver would need to > understand it. > Consistent paths are very useful, but there are other > ways of doing > this already - with the most trivial being just using label > 15. I have > a hard time seeing this as a new attack vector (but I'm not > professionally paranoid yet). > > Alia > > On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel > > >> > wrote: > > [snip] > > > >> XL The Extension Label that indicates that an > extended special > > >> purpose label follows. > > >> > > >> ESPL An Extended Special Purpose Label. > > >> > > >> Something that I think would be worthwhile > clarifying right at the > > >> front is that a label is an ESPL IFF it is > preceded by an XL. > > >> It might even be worth noting that really we have > a new label > type: > > >> a label couple in which the first label defines > the type of the > > >> second label and neither are of any use as > individual labels. > > > I can see how you would see this as a new label > type. Maybe > "compound" > > > rather than "couple". > > > However, I am not convinced that it is new that > one label leads > to the > semantics > > > of the next (for example the entropy label). > > > What is more, I am not sure that there will be > more than this > instance of > this > > > type of tight coupling. > > > So I would rather leave this point out. > > I can foresee other cases where we might use label > pairs to > mitigate the > > 20bit limit. I am sure it has been discussed, so > creating the > reference > > might be useful. Just because this was not done in > EL, does not > mean that > > we should not set down the concept here. > > > > However I agree compound would be a better term. > > > > > > > > But as to clarifying ESPL: yes. > > > The XP definition is, I think, clear. > > > How about... > > > > > > ESPL An Extended Special Purpose Label. A Special > Purpose Label > that > > > is placed in the label stack after the > Extension Label. > > > > Yes. Indeed it MUST be placed be placed there, > however the definition > > above is fine. > > OK, I updated to... > > ESPL An Extended Special Purpose Label. A Special > Purpose Label that > is placed in the label stack after the > Extension Label. The > combination of XL and ESPL might be regarded > as a new form of > "compound label" comprising more than one > consecutive entry in > the label stack. > > ..to cover your other point as well. > > > >> ====== > > >> > > >> I think that the draft will need to provide some > guidance > > >> on when to allocate a 0..15 and when to allocate > an ESPL. > > >> > > >> I imagine that a 0..15 should only be used when > it can be shown > > >> that the extra stack space of forwarding time is > burdensome > > >> but that is a question that the WG should > explicitly consider. > > > We discussed this at some point on the MPLS list (many > centuries ago, I > think) > > > and reached no conclusion. > > > The primary purpose of the XL is to handle the > time when 0..15 > is depleted. > > > You're right that we could encourage people to > start using > ESPLs now before > > > 0..15 is depleted. But it is hard to make the case for > requiring it when > there > > > is still some of 0..15 available and the rate of > burn is not so > high. > > > > > > We could put in some text like... > > > > > > When allocating a new Special Purpose Label, > protocol designers > should > > > consider whether they could, instead, use an > Extended Special > Purpose > > > Label. Doing so would help to preserve the scarce > resources of > Special > > > Purpose Labels for use in cases where minimizing > the label > stack size is > > > particularly important. > > > > That would be useful text. > > Added as new section 3.1.2 with slight tweak to wording. > > [snip] > > > >> 6. [RFC6790] says that special purpose > labels MUST NOT be > used for > > >> load balancing. The same logic applies to > extended special > > >> purpose labels (ESPLs). Thus, this > document specifies > that ESPLs > > >> MUST NOT be used for load balancing. It > is noted that > existing > > >> implementations may violate this, as they > do not look > for the XL > > >> and thus for ESPLs. The consequence is > that if ESPLs > are used in > > >> some packets of a flow, these packets may > be delivered on > > >> different paths and so could be > re-ordered. However, it is > > >> important to specify the correct behavior > for future > > >> implementations, hence the use of "MUST NOT". > > >> > > >> I would suggest that most implementations do > violate this. I would > > >> also suggest that it seems unlikely that you will > get to the point > > >> where it is not violated in the foreseeable future. > > > I can't tell whether there is an action here for us. > > > There are two "violations" that exist: > > > 1. Some implementations violate 6790. Not sure > what we can do about > > > that in this document. Note that the entropy label > can help > with this > > > but only to a limited extent since the > implementations that > violate 6790 > > > probably also fail to recognise the entropy label. > > > 2. Implementations that conform to 6790 will > understand that > the XL is > > > a special purpose label and will not use it to > load balance. > But they will > > > not necessarily understand that the next label is > an ESPL that > must be > > > skipped as well. Again, there is nothing we can do > about this > except to > > > note it (done) and possibly to use the EL further > up the stack. > > > > My point was that the may in "It is noted that existing > implementations may > > violate this" was a little soft. Most > implementations, except the > latest > > designs of maybe as few as a single vendor, would > certainly > violate this. > > > > Also of course you are making a statement of fact > and not of > permission > > so I think it may be more precise to say: > > > > It is noted that most existing > > implementations currently violate this, as they do > not look for > the XL > > and thus for ESPLs. > > OK. > > I've gone with... > > It is noted that existing > implementations would violate this, as they do > not recognise XL > as anything other than a single Special Purpose > Label and will > not expect an ESPL to follow. > > [snip] > > > >> Label 7 (when received) retains its meaning as > ELI whether > a regular > > >> special purpose label or an ESPL; this > simplifies a transit > LSR's > > >> task of looking for entropy labels since it > may just look > for label 7 > > >> and need not verify that the previous label in > the stack is > not the > > >> XL 15. However, an LSR wishing to insert an > entropy label > SHOULD > > >> insert label 7 as a regular special purpose > label, not as > an ESPL. > > >> > > >> Why is this not a MUST! There is no ESPL in the > wild running an > > >> alternate behaviour, so why not simply mandate this? > > > If this was a MUST then there would be no case for > handling > Label 7 after > XL. > > > There was some concern I believe that > implementations might > have a path that > > > puts them on to XL insertion processing and then > consider what > to do next. > At > > > that point they might decide that label 7 is needed. > > > > > > It seems esoteric, but I couldn't see a reason to > prohibit it. > > > > > > Maybe "MUST NOT include" and "SHOULD process when > received" are > > > compatible. > > > > > > Part of me hates the idea of this change just > because I don't > want another > > > working group last call before we can move > forward. How > important is it? > > > > The reason to be stricter at the TX is that the > forwarding path > can be > > simpler at the RX. I cannot see how you would get to > the point of > putting > > in L15 and then saying "you know I need to put in L7" > particularly as no > > other 0..15 is allowed. > > Normally I would think that you would put in the > compound label > as a pair > > and that is a good reason to use the compound label > concept. > > > > Also I see no reason for the inconsistency between > L7 and all of the > > other L0..L15 cases. > > > > So I think that it's OK, but probably silly to allow > L0..L15, but > to allow > > the exception of just L7 just complicates things > without good cause. > > I'm not in a position to argue on this one as the > debate and text > were driven by > others. > > I believe that the claim was that allowing L7 to be > inserted > anywhere made > processing it easier not harder at the receiver. > Note that {XL,7} would be an error case in your way of > looking at > things so the > receiver should (must?) not process it. > But the claim was that h/w will simply search the stack > for L7 so > that allowing > {L7} and {XL, L7} to be treated in the same way made > life easier for > the h/w. > > Bottom line, however, seems to be that you have a > preference for > doing it one > way, and the WG has a preference for doing it a > different way. How > to resolve > that? > > Given the posting deadline, I've not made any change > for this. We > can continue > to discuss. > > > >> ======== > > >> > > >> 3.2. Process for Retiring Special Purpose Labels > > [snip] > > > >> Secondly I think the timescales are ridiculously > optimistic. > To get > > >> a label out of circulation in 24 months seems > most unlikely. Also > > >> 6 month checks is a lot of work. > > >> > > >> A more realistic schedule would be to poll at 12month > intervals until > > >> such time as it is determined that reallocation > would do not > harm and > > >> then give a further 12 months notice. > > > Erm, that's what the text says, I think... > > > > > > 12 months after the RFC deprecating the > label value is > published, > > > an IETF-wide survey may be conducted to > determine if the > > > deprecated label value is still in use. > > > > > > The "may" in that means that the earliest you can > "poll" is 12 > months after > the > > > deprecation RFC is published (noting that the RFC > won't even > get published > > > until lots of discussion and consensus to deprecate). > > > Then, *if* the poll response is OK, and then not > earlier than > 24 months > after > > > the deprecation RFC is published, publication can > be requested > for a new RFC > > > (which means that the WG has already reached > consensus, and that a > > > subsequent IETF last call will be held). > > > > > > Frankly, I think that this process is only likely > to be > executed for SPLs > that > > > are allocated "in error", because other stuff will > probably be > in the field. > Can > > > you think of a label that was allocated in error? > I can :-) > > > > This seems like a lot of text to specify in detail > something we > would never > > run. In protocols, including this type of protocol, > the fewer > words used to > > describe the rarely executed exception path the better. > > The case was considered worthy of inclusion because the > SPL range is > so small. > If any SPL can be reclaimed at some future time it will > be very > valuable and so > a mechanism needs to be documented against that happy day. > > [snip] > > >> =========== > [snip] > > >> However that brings me to > > >> suggest that you probably need to write an OPs > section and > > >> you might want to think about the PM implications > of the extra > > >> metatdata in the packets. > > > > > > What OPS issues had you in mind that need to be > addressed? I am > a fan of OPS > > > sections, but not a fan of empty OPS sections, and > when we > looked through > > > RFC 6123 (which is my favourite crib for what to > describe wrt > manageability) > we > > > didn't see anything that has changed from > pre-existing MPLS. > > > > > > What metadata are you talking about? Is an > existing special > purpose label > > > metadata? If so, the PM issues are pre-existing. > Is there > something special > > > introduced by this I-D that constitutes metadata? > > > > Well what follows an XL is certainly metadata, and > one application is > > certainly to introduce tags that would alert the PM > devices to > take an > > interest. > > OK it is a form of metadata as existing SPLs are metadata. > The XL alerts a DPI that an ESPL follows, and an SPL > alerts the DPI > that the SPL > is there. > What has changed? > We could certainly sit down and write an I-D about the > implications > of using > MPLS in an environment where PM might be present (BTW, > I assume this is > Pervasive Monitoring. Would be embarrassing to find you > meant > something else > :-). I think such an I-D would discuss SPLs as > indicative metadata > and would > then note that ESPLs are in the same category. > Is *this* the I-D in which to have that discussion? > > [snip] > > I'll post the revised I-D in a few minutes and others > can throw > vegetables > (rotten or otherwise). > > Adrian > > _________________________________________________ > mpls mailing list > mpls@ietf.org > > https://www.ietf.org/mailman/__listinfo/mpls > > > > > > > _________________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/__listinfo/mpls > > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Feb 16 08:32: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 A42781A0081 for ; Sun, 16 Feb 2014 08:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyQHV0GJOoKg for ; Sun, 16 Feb 2014 08:32:08 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC1481A002C for ; Sun, 16 Feb 2014 08:32:07 -0800 (PST) Received: from [10.128.1.195] (node-dac.pool-182-52.dynamic.totbb.net [182.52.67.68]) (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 EA136180145E; Sun, 16 Feb 2014 17:32:03 +0100 (CET) Message-ID: <5300E7FE.40401@pi.nu> Date: Sun, 16 Feb 2014 23:31:58 +0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mark.tinka@seacom.mu, mpls@ietf.org, "draft-george-mpls-ipv6-only-gap@tools.ietf.org" References: <20140213223847.13307.40416.idtracker@ietfa.amsl.com> <201402141320.47691.mark.tinka@seacom.mu> In-Reply-To: <201402141320.47691.mark.tinka@seacom.mu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3nC8cSv9AY3854-kscWLNY5Z-mE Subject: Re: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 16:32:11 -0000 Mark, Working Group, The authors of this draft have told me that it is ready to be made a working group document, the process involves a couple of steps - a MPLS-RT review, mail have been sent to reviewers - IPR poll, expect that to be started within a few days - the actual poll, that will start as soon as the mpls-rt review or the IPR poll is done I suggest that the authors look at the comments from as part of resolving the mpls-rt review comments /Loa On 2014-02-14 18:20, Mark Tinka wrote: > Glad to see this work getting a lot more attention, as it is > one concern of mine as an operator. > > Just a few comments, for my own clarity: > > 1. This document focuses on a single-stack IPv6 > backbone, but for practical operations as well, I > think it might be necessary to look at dual - > stack scenarios as well, where a an operator > would like to transport both IPv4 and IPv6 over > an MPLS network, but natively for each protocol. > I concede that this may have to be done in > another document. > > 2. Section 3.2.3.1 (IGP) speaks to OSPFv2. Not sure > why given OSPFv2 does not support IPv6. > > 3. Curious why section 3.3.2.4.3 (PE-PE Multicast > Routing Protocol) out of scope for this gap > analysis. > > 4. While work is still ongoing for Segment Routing, > perhaps it might be good to make a reference to > it like you did for EVPN. > > Cheers, > > Mark. > > On Friday, February 14, 2014 12:38:47 AM internet- > drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item >> of the Multiprotocol Label Switching Working Group of >> the IETF. >> >> Title : Gap Analysis for Operating >> IPv6-only MPLS Networks Authors : Wesley George >> Carlos Pignataro >> Filename : draft-george-mpls-ipv6-only- > gap-04.txt >> Pages : 25 >> Date : 2014-02-13 >> >> Abstract: >> This document reviews the MPLS protocol suite in the >> context of IPv6 and identifies gaps that must be >> addressed in order to allow MPLS- related protocols and >> applications to be used with IPv6-only networks. This >> document is not intended to highlight a particular >> vendor's implementation (or lack thereof) in the context >> of IPv6-only MPLS functionality, but rather to focus on >> gaps in the standards defining the MPLS suite. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-george-mpls-ipv6-o >> nly-gap/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-george-mpls-ipv6-only-ga >> p-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-george-mpls-ipv6-o >> nly-gap-04 >> >> >> Please note that it may take a couple of minutes from the >> time of submission until the htmlized version and diff >> are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Feb 16 12:49: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 EEA771A02E7 for ; Sun, 16 Feb 2014 12:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 f_mWARoZp5bt for ; Sun, 16 Feb 2014 12:49:42 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id E5AA51A028A for ; Sun, 16 Feb 2014 12:49:41 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1GKncZe028942 for ; Sun, 16 Feb 2014 20:49:38 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1GKnbTu028927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 16 Feb 2014 20:49:38 GMT From: "Daniel King" To: References: <20140214204926.6260.62683.idtracker@ietfa.amsl.com> In-Reply-To: <20140214204926.6260.62683.idtracker@ietfa.amsl.com> Date: Sun, 16 Feb 2014 20:49:36 -0000 Message-ID: <03e601cf2b58$9ab31de0$d01959a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGkQfcXZ43FOE4axmrY5fUi7f1TU5sOKR5w Content-Language: en-ca Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jq8aokDJVZKghXS-TIPYTlZzWjg Subject: Re: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 20:49:45 -0000 Hi All, The LDP MT document was submitted to the IESG for publication late last year but during IESG and IANA reviews a few issues arose. This new version looks to address those outstanding issues, we (the Authors) will contact the commentators to make sure this new revision adequately addresses their comments. In summary, the new version contains the following updates: 1) Made MT Capability as global capability, and not per topology capability. 2) Fixed the use of Typed Wildcard FEC when sent in a MT Capability TLV. 3) Clarification of the Procedures (e.g., What to do if Dynamical Announcement Capability is not supported). 4) Proposed MPLS Registry (instead of LDP one) to track MT IDs. 5) Clarified that MIB extensions are beyond this doc scope. 6) Removed mLDP MT FEC and any reference to it. 7) Expanded Security section. 8) Clean-up of IANA section. A diff is also available: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-multi-topology-10. Those paying attention will see that the current version is actually version 11, the difference between v10 and v11 is the inclusion of a "Contributors" section which was unfortunately omitted when we submitted v10. Br, Dan and Authors. -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: February 14, 2014 8:49 PM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: I-D Action: draft-ietf-mpls-ldp-multi-topology-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Extensions for Multi Topology Authors : Quintin Zhao Kamran Raza Chao Zhou Luyuan Fang Lianyuan Li Daniel King Filename : draft-ietf-mpls-ldp-multi-topology-11.txt Pages : 18 Date : 2014-02-14 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-multi-topology-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Feb 16 17:37: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 F14CD1A0140 for ; Sun, 16 Feb 2014 17:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 LIZYxjDIp3dA for ; Sun, 16 Feb 2014 17:37:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DDB731A01BB for ; Sun, 16 Feb 2014 17:37:54 -0800 (PST) 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 BDQ58649; Mon, 17 Feb 2014 01:37:51 +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; Mon, 17 Feb 2014 01:37:46 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 01:37:49 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 09:37:39 +0800 From: Haoweiguo To: Tao chou , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKjZqILGJJua9u0mPVD07EUd8cpq4rQRZ Date: Mon, 17 Feb 2014 01:37:38 +0000 Message-ID: References: <28BF96E93B752C4886970D1815EB8E352BA5567E@nkgeml507-mbs.china.huawei.com> In-Reply-To: <28BF96E93B752C4886970D1815EB8E352BA5567E@nkgeml507-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.135.22.248] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7A5037nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/TBCC7uNoQ2jqzgJu3N3ZlhfU-sY Subject: [mpls] =?gb2312?b?tPC4tDogIFBvbGwgZm9yIEFkb3B0aW9uCWRyYWZ0LWNo?= =?gb2312?b?ZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uLTEx?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 01:37:58 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7A5037nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCENCg0KVGhhbmtzDQoNCndlaWd1bw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kt6K8/sjLOiBtcGxzIFttcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gVGFvIGNo b3UgW3Rhby5jaG91QGh1YXdlaS5jb21dDQq3osvNyrG85DogMjAxNMTqMtTCMTXI1SAxODoxMg0K ytW8/sjLOiBtcGxzQGlldGYub3JnDQrW98ziOiBSZTogW21wbHNdIFBvbGwgZm9yIEFkb3B0aW9u IGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uLTExDQoNClN1cHBvcnQuDQoN CkJlc3QgcmVnYXJkcywNClRhbw0KDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUm9zcyBDYWxsb24NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAxMywgMjAxNCAyOjQ2IFBNDQpUbzogbXBsc0BpZXRmLm9yZw0KQ2M6IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBbbXBsc10gUG9sbCBmb3IgQWRvcHRpb24gZHJhZnQtY2hl bi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb24tMTENCg0KVGhpcyBpcyB0byBzdGFydCBhIHBv bGwgb24gYWRvcHRpbmcgZHJhZnQtY2hlbi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb24tMTEN CmFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4gU2luY2UgbWFueSBvZiB1cyB3aWxs IGJlIGluIHRyYW5zaXQgdG8gdGhlDQpJRVRGIGFwcHJveGltYXRlbHkgdHdvIHdlZWtzIGZyb20g bm93LCBJIHdpbGwgZXh0ZW50IHRoZSBwb2xsIGJ5IG9uZSB3ZWVrIChzbw0KdGhhdCBpdCB3aWxs IGJlIGEgdGhyZWUgd2VlayBwb2xsKS4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3Vw cG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cA0KbWFpbGluZyBsaXN0 IChtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPikuDQoNClRoaXMgcG9sbCB3aWxs IGVuZCBGcmlkYXkgTWFyY2ggNywgMjAxNC4gTm90ZSB0aGF0IHRoaXMgaXMgdGhlIEZyaWRheSBv ZiB0aGUgSUVURiwNCmFuZCB0aHVzIHdlIHdpbGwgZWFjaCBuZWVkIHRvIHBsYW4gb3VyIHJldmll dyBvZiB0aGUgZG9jdW1lbnQgYW5kIHJlc3BvbnNlDQphcm91bmQgb3VyIHRyYXZlbCBwbGFucyBh bmQgSUVURiBhY3Rpdml0aWVzLg0KDQpUaGFua3MsIFJvc3MNCg== --_000_DD5FC8DE455C3348B94340C0AB5517334F7A5037nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support!

Thanks

weiguo

=B7=A2=BC=FE=C8=CB: mpls [mpls-bounces@ietf= .org] =B4=FA=B1=ED Tao chou [tao.chou@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C215=C8=D5 18:12
=CA=D5=BC=FE=C8=CB: mpls@ietf.org
=D6=F7=CC=E2: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egre= ss-protection-11

Support.

Best regards,
Tao
=  
= From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 2:46= PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org<= /font>
Subject: [mpls] Poll for Adoption draf= t-chen-mpls-p2mp-egress-protection-11
=  
= This is to start a poll on adopting draft= -chen-mpls-p2mp-egress-protection-11
= as an MPLS working group document. Since = many of us will be in transit to the
= IETF approximately two weeks from now, I = will extent the poll by one week (so
= that it will be a three week poll).
=  
=  
= This poll will end Friday March 7, 2014. = Note that this is the Friday of the IETF,
= and thus we will each need to plan our re= view of the document and response
= around our travel plans and IETF activiti= es.
=  
= Thanks, Ross<= /div>
--_000_DD5FC8DE455C3348B94340C0AB5517334F7A5037nkgeml501mbschi_-- From nobody Sun Feb 16 17:39: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 D504F1A02C3 for ; Sun, 16 Feb 2014 17:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 0UgZ1QyW-zpS for ; Sun, 16 Feb 2014 17:39:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BBF811A0140 for ; Sun, 16 Feb 2014 17:39:09 -0800 (PST) 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 BDQ58704; Mon, 17 Feb 2014 01:39:07 +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; Mon, 17 Feb 2014 01:39:01 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 01:39:04 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 09:38:59 +0800 From: Mach Chen To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPRIpPUShY7IUEKfeXCXoUCU4Jq4sAVw Date: Mon, 17 Feb 2014 01:38:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D96437CSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/F1Mm61g8bsC1ToJznDSpLEWzTqA Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 01:39:13 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D96437CSZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Best regards, Mach From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, February 14, 2014 3:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D96437CSZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Support.=

=  

= Best regards,

= Mach

=  

From: mpls [mailto:mpls-bounces@ietf.org] On= Behalf Of Ross Callon
Sent: Friday, February 14, 2= 014 3:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.o= rg
Subject: [mpls] Poll for Ado= ption draft-chen-mpls-p2mp-egress-protection-11

 

This is to start a poll on adopting draft-chen-mpls-p2mp-egress-p= rotection-11

as an MPLS working group document. Since many of us will be in tr= ansit to the

IETF approximately two weeks from now, I will extent the poll by = one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).=

 

This poll will end Friday March 7, 2014. Note that this is the Fr= iday of the IETF,

and thus we will each need to plan our review of the document and= response

around our travel plans and IETF activities.

 

Thanks, Ross

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D96437CSZXEMA510MBXchi_-- From nobody Sun Feb 16 18:16: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 3B8901A030C for ; Sun, 16 Feb 2014 18:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xYlfD-7dTNX for ; Sun, 16 Feb 2014 18:15:55 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-mba.ke.seacomnet.com [41.87.100.230]) by ietfa.amsl.com (Postfix) with ESMTP id B2D181A02F1 for ; Sun, 16 Feb 2014 18:15:53 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1WFDkB-00006H-7n; Mon, 17 Feb 2014 04:15:39 +0200 From: Mark Tinka Organization: SEACOM To: Loa Andersson Date: Mon, 17 Feb 2014 04:15:35 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140213223847.13307.40416.idtracker@ietfa.amsl.com> <201402141320.47691.mark.tinka@seacom.mu> <5300E7FE.40401@pi.nu> In-Reply-To: <5300E7FE.40401@pi.nu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3569616.v9MrPYYEQZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201402170415.35860.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LCn2y_71KpzHHOaPsIlijen_8Nk Cc: mpls@ietf.org, "draft-george-mpls-ipv6-only-gap@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 02:15:58 -0000 --nextPart3569616.v9MrPYYEQZ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Loa. Mark. On Sunday, February 16, 2014 06:31:58 PM Loa Andersson=20 wrote: > Mark, Working Group, >=20 > The authors of this draft have told me that it is ready > to be made a working group document, the process > involves a couple of steps >=20 > - a MPLS-RT review, mail have been sent to reviewers > - IPR poll, expect that to be started within a few days > - the actual poll, that will start as soon as the mpls-rt > review or the IPR poll is done >=20 > I suggest that the authors look at the comments from as > part of resolving the mpls-rt review comments >=20 > /Loa >=20 > On 2014-02-14 18:20, Mark Tinka wrote: > > Glad to see this work getting a lot more attention, as > > it is one concern of mine as an operator. > >=20 > > Just a few comments, for my own clarity: > > 1. This document focuses on a single-stack IPv6 > > =09 > > backbone, but for practical operations as well, I > > think it might be necessary to look at dual - > > stack scenarios as well, where a an operator > > would like to transport both IPv4 and IPv6 over > > an MPLS network, but natively for each protocol. > > I concede that this may have to be done in > > another document. > > =09 > > 2. Section 3.2.3.1 (IGP) speaks to OSPFv2. Not sure > > =09 > > why given OSPFv2 does not support IPv6. > > =09 > > 3. Curious why section 3.3.2.4.3 (PE-PE Multicast > > =09 > > Routing Protocol) out of scope for this gap > > analysis. > > =09 > > 4. While work is still ongoing for Segment Routing, > > =09 > > perhaps it might be good to make a reference to > > it like you did for EVPN. > >=20 > > Cheers, > >=20 > > Mark. > >=20 > > On Friday, February 14, 2014 12:38:47 AM internet- > >=20 > > drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. This draft is a work item > >> of the Multiprotocol Label Switching Working Group of > >> the IETF. > >>=20 > >> Title : Gap Analysis for Operating > >>=20 > >> IPv6-only MPLS Networks Authors : Wesley > >> George > >>=20 > >> Carlos Pignataro > >> =09 > >> Filename : draft-george-mpls-ipv6-only- > >=20 > > gap-04.txt > >=20 > >> Pages : 25 > >> Date : 2014-02-13 > >>=20 > >> Abstract: > >> This document reviews the MPLS protocol suite in > >> the > >>=20 > >> context of IPv6 and identifies gaps that must be > >> addressed in order to allow MPLS- related protocols > >> and applications to be used with IPv6-only networks.=20 > >> This document is not intended to highlight a > >> particular vendor's implementation (or lack thereof) > >> in the context of IPv6-only MPLS functionality, but > >> rather to focus on gaps in the standards defining the > >> MPLS suite. > >>=20 > >>=20 > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-george-mpls-ipv > >> 6-o nly-gap/ > >>=20 > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-george-mpls-ipv6-only > >> -ga p-04 > >>=20 > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-george-mpls-ipv > >> 6-o nly-gap-04 > >>=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 > >>=20 > >>=20 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls --nextPart3569616.v9MrPYYEQZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJTAXDHAAoJEGcZuYTeKm+GfwQP/1Z3REaROtvidG50hMKc2LNW RWHOcG9bUtMvoTU8H5prpJYh71VlhodoNsQqCLWPUM/cK4Pt4Vz3Xhn91qokOvmg DuQHI57cCmJFvHB+SX7cHVJ74K0hC+DDNX9SlOtgfe9W2NLv4+cOkADjzNVCq1ky NcgIIR5Zi+lKecX1b3zQPq6esipXnn5h2tWGl4FOzEl1d2gLCG3tan5gBKFOVHM0 RyRTtlkLjEfRzbLeoWzvo5PLue8h+4ew5GJ9hrpmfQUNY/gZ4h8zDyesg2zJiEqa PjqqsOnDBXGW9UBFtp7lzLxzfOupyvTRiYFrF0a11i6QWQF6BuZH2VIF7BXr75Qc NlHhdkTdFEKIh5KIe0yTyggeWVU43XX22dXMh2vQaRVIj+N1kmRj7Cxf27B/I+T5 y5/plh8KWl+0s293wdT4f8oozQMM/prg7DAFBTBBeh3BabfJ8qPjnXYvcbTtck+k XiaQHhdDWGyGTAw0hYEDfctoDKqzkPU9Z50MFI68Lg4BulSIOKxH8qkYWGXxfwT1 bPfDqZtRPZuEjutBj5zXW9jy1e+wZu7lwbJKlCeNvfVLQPRbWVhk1EjCaH/kzOqR jbb2WYD5ahSSPyITZGZFwTG31CVyHkp6suT2DSmYu8r4ejpXScr19ydepcey2vR7 EiglM5Xfe0momDlq9DLK =xz8n -----END PGP SIGNATURE----- --nextPart3569616.v9MrPYYEQZ-- From nobody Sun Feb 16 18:23: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 73A4D1A030F for ; Sun, 16 Feb 2014 18:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 3DLdV4tWZR-O for ; Sun, 16 Feb 2014 18:23:25 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3F1A030C for ; Sun, 16 Feb 2014 18:23:25 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s1H2NMh1017509 for ; Sun, 16 Feb 2014 21:23:22 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402170223.s1H2NMh1017509@maildrop2.v6ds.occnc.com> To: mpls@ietf.org From: Curtis Villamizar In-reply-to: Your message of "Fri, 14 Feb 2014 10:54:00 -0800." <20140214185400.3376.12133.idtracker@ietfa.amsl.com> Date: Sun, 16 Feb 2014 21:23:22 -0500 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Jh2KjN1OznA_IsxjTvuVCx7gfC8 Subject: Re: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 02:23:28 -0000 The LFIB/LIB/ILM/NHLFE terminology isn't quite right yet. In your earlier document I suggested that you just s/#LFIB/#ILM/g and things would be right (or close enough). If you interpret #ILM to be number of ILM entries per interface with platform label space or worst case number of ILM entries per interface with interface label space, then all is fine. This is the number most people are concerned about (how big does the ILM table on a given interface need to be). I'm really not sure why you put in #ILM, #LIB, #NHLFE and kept #LFIB. The prior suggestion was simpler but maybe I worded it wrong. The draft has a few tables like this: +--------------------+---------------+ | Parameter | Typical Value | +--------------------+---------------+ | IGP RIB Entries | 2 | | IP FIB Entries | 2 | | LDP LIB Entries | 200 | | MPLS NHLFE Entries | 200 | | MPLS ILM Entries | 0 | | BGP RIB Entries | 0 | | BGP FIB Entries | 0 | +--------------------+---------------+ It makes sense if the access LER never sees and incoming packet with a label (no ILM) because in one direction traffic is not MPLS (yet) but the NHLFE entries are used to add labels and on the other side PHP has removed all the labels before the packet arrived. You have this table: +--------------------+---------------+ | Parameter | Typical Value | +--------------------+---------------+ | IGP RIB Entries | 2 | | IP FIB Entries | 2 | | LDP LIB Entries | 1,400 | | MPLS NHLFE Entries | 1,400 | | MPLS ILM Entries | 1,400 | +--------------------+---------------+ This makes sense for platform label space if you means #LIB/platform = 1400, #NHLFE/platform = 1400, #ILM/interface = 1400. Note that if the packets go out a lot of different interfaces then #NHLFE/interface << 1400. You are recommending DoD to reduce label bindings. DoD goes well with interface label space, further reducing ILM size on any given interface. There is no advantage to interface label space with DU so in that case platform label space is often used. If interface label space was used then #ILM/interface <= 1400 (generally "<"). Perhaps you should state that you are assuming platform label space and change the above table to #LIB/platform, #NHLFE/platform, #ILM/interface which would all be equal in that case (with #NHLFE/interface <= these numbers and #LIB being in the RP/RE). If you want to then state that the case where platform label space is used and #LIB/platform == #NHLFE/platform == #ILM/interface is what you mean by #LFIB (or "MPLS ILM (LFIB)" as you've written it), then all the places where the draft has "MPLS ILM (LFIB)" would now make some sense to someone actually carefully reading this. Curtis In message <20140214185400.3376.12133.idtracker@ietfa.amsl.com> internet-drafts@ietf.org writes: > > 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 : Seamless MPLS Architecture > Authors : Nicolai Leymann > Bruno Decraene > Clarence Filsfils > Maciek Konstantynowicz > Dirk Steinberg > Filename : draft-ietf-mpls-seamless-mpls-06.txt > Pages : 40 > Date : 2014-02-14 > > Abstract: > This documents describes an architecture which can be used to extend > MPLS networks to integrate access and aggregation networks into a > single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is > based on existing and well known protocols. It provides a highly > flexible and a scalable architecture and the possibility to integrate > 100.000 of nodes. The separation of the service and transport plane > is one of the key elements; Seamless MPLS provides end to end service > independent transport. Therefore it removes the need for service > specific configurations in network transport nodes (without end to > end transport MPLS, some additional services nodes/configurations > would be required to glue each transport domain). This draft defines > a routing architecture using existing standardized protocols. It > does not invent any new protocols or defines extensions to existing > protocols. > [... etc ...] From nobody Sun Feb 16 19:03: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 325301A042D for ; Sun, 16 Feb 2014 19:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.674 X-Spam-Level: * X-Spam-Status: No, score=1.674 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 4EVOihMr7RVX for ; Sun, 16 Feb 2014 19:03:51 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 0A9EF1A040F for ; Sun, 16 Feb 2014 19:03:50 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee153017b9103e-dc03e; Mon, 17 Feb 2014 11:01:38 +0800 (CST) X-RM-TRANSID: 2ee153017b9103e-dc03e Received: from cmridkeeper (unknown[10.2.52.199]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee353017b91539-c0f0c; Mon, 17 Feb 2014 11:01:38 +0800 (CST) X-RM-TRANSID: 2ee353017b91539-c0f0c From: "HuangLu" To: Date: Mon, 17 Feb 2014 11:03:45 +0800 Message-ID: <032a01cf2b8c$df89ce80$9e9d6b80$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032B_01CF2BCF.EDAE1FF0" X-Mailer: Microsoft Outlook 14.0 Content-language: zh-cn Thread-index: Ac8rjMPlbzop/OhORbmUwNR9wmk7KQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NE1kGcD6fC9tqdoPcKMTpD4HAAY Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 03:03:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032B_01CF2BCF.EDAE1FF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Support as co-author -------------------------------- Best Regards! Lu Huang China Mobile Research Institute No.32 Xuanwumen West Street, Xicheng District Beijing, China, 100053 Mobile: +86 13810820540 Phone: +86 10 15801696688 Ext. 33287 Email: huanglu@chinamobile.com From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-11 as an MPLS working group document. Since many of us will be in transit to the IETF approximately two weeks from now, I will extent the poll by one week (so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list ( mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of the IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross ------=_NextPart_000_032B_01CF2BCF.EDAE1FF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support as co-author

 

--------------------------------

Best Regards!
Lu Huang
China Mobile Research Institute
No.32 = Xuanwumen West Street, Xicheng District
Beijing, China, = 100053
Mobile: +86 13810820540
Phone: +86 10 15801696688 Ext. = 33287
Email: huanglu@chinamobile.com<= /o:p>

 

From:= mpls [mailto:mpls-bounces@ietf.org] = On Behalf Of Ross Callon
Sent: Thursday, February 13, = 2014 2:46 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org=
Subject: [mpls] Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11

 

This is to = start a poll on adopting = draft-chen-mpls-p2mp-egress-protection-11

as an MPLS = working group document. Since many of us will be in transit to the =

IETF = approximately two weeks from now, I will extent the poll by one week (so =

that it = will be a three week poll).

 =

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

mailing = list (mpls@ietf.org).

 =

This poll = will end Friday March 7, 2014. Note that this is the Friday of the IETF, =

and thus = we will each need to plan our review of the document and response =

around our = travel plans and IETF activities.

 =

Thanks, = Ross

 =

------=_NextPart_000_032B_01CF2BCF.EDAE1FF0-- From nobody Sun Feb 16 22:53: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 070381A0442 for ; Sun, 16 Feb 2014 22:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 v7q9KDn_AC9I for ; Sun, 16 Feb 2014 22:53:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 308431A003D for ; Sun, 16 Feb 2014 22:53:06 -0800 (PST) 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 BDQ77201; Mon, 17 Feb 2014 06:53:02 +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, 17 Feb 2014 06:52:56 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 06:53:01 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 14:52:58 +0800 From: "Zengxinzong (Paul)" To: "mpls@ietf.org" Thread-Topic: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: Ac8rrOPjNUpZ4IbUSJqmkTIgVuhvHg== Date: Mon, 17 Feb 2014 06:52:58 +0000 Message-ID: <54B334E2F9AB214C80ABE154F4E754792AF524BF@nkgeml507-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.80.203] Content-Type: multipart/alternative; boundary="_000_54B334E2F9AB214C80ABE154F4E754792AF524BFnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/a62e1xyvpkxv087oq2aXjbpiX0I Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 06:53:09 -0000 --_000_54B334E2F9AB214C80ABE154F4E754792AF524BFnkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Best regards, Paul ---------------------------------------------------------------------------= ------------------------------------------ From: mpls [mailto:mpls-bounces at ietf.org] On Behalf Of Ross Callon Sent: Friday, February 14, 2014 3:46 AM To: mpls at ietf.org Cc: mpls-chairs at tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_54B334E2F9AB214C80ABE154F4E754792AF524BFnkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /o:p>

Best regards,<= span lang=3D"EN-US" style=3D"font-size:12.0pt;font-family:宋体"= >

Paul

---------------------= ---------------------------------------------------------------------------= ---------------------

 From: mpls [mailto:mpls-bounces at ietf.org] On Behalf Of Ross Callon
Sent: Friday, February 14, 2014 3:46 AM
To: mpls at ietf.org
Cc: mpls-chairs at tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 =

This is to start a= poll on adopting draft-chen-mpls-p2mp-egress-protection-11

as an MPLS working= group document. Since many of us will be in transit to the

IETF approximately= two weeks from now, I will extent the poll by one week (so

that it will be a = three week poll).

 

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

mailing list (mpls a= t ietf.org).

 

This poll will end= Friday March 7, 2014. Note that this is the Friday of the IETF,

and thus we will e= ach need to plan our review of the document and response

around our travel = plans and IETF activities.

 

Thanks, Ross

 

&n= bsp;

 

--_000_54B334E2F9AB214C80ABE154F4E754792AF524BFnkgeml507mbschi_-- From nobody Mon Feb 17 02:41: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 480B71A0485 for ; Mon, 17 Feb 2014 02:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.275 X-Spam-Level: *** X-Spam-Status: No, score=3.275 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 d9pdr5XrFchQ for ; Mon, 17 Feb 2014 02:41:43 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 59E571A03C7 for ; Mon, 17 Feb 2014 02:41:41 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15301e6d8019-e4019; Mon, 17 Feb 2014 18:39:21 +0800 (CST) X-RM-TRANSID: 2ee15301e6d8019-e4019 Received: from vicwork (unknown[10.2.54.228]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee25301e6d83cc-e7fcf; Mon, 17 Feb 2014 18:39:21 +0800 (CST) X-RM-TRANSID: 2ee25301e6d83cc-e7fcf From: =?gb2312?B?wfXWvrrjVmljIExpdQ==?= To: Date: Mon, 17 Feb 2014 18:41:42 +0800 Message-ID: <000001cf2bcc$d9107190$8b3154b0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CF2C0F.E7370CF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8rzNiLeobWKy2DSv6j4IC+IQWiRA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/upm4t1UNkz15GEJgq5dxfd11hp4 Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 10:41:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CF2C0F.E7370CF0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Support as a contributor Vic Liu China Mobile Research Institute Email: liuzhiheng@chinamobile.com From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-11 as an MPLS working group document. Since many of us will be in transit to the IETF approximately two weeks from now, I will extent the poll by one week (so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list ( mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of the IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross ------=_NextPart_000_0001_01CF2C0F.E7370CF0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support as a contributor

 

 

Vic Liu

China Mobile Research Institute
Email: liuzhiheng@chinamobile.com= =

 =

 

From:= mpls [mailto:mpls-bounces@ietf.org] = On Behalf Of Ross Callon
Sent: Thursday, February 13, = 2014 2:46 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org=
Subject: [mpls] Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11

 

This is to = start a poll on adopting = draft-chen-mpls-p2mp-egress-protection-11

as an MPLS = working group document. Since many of us will be in transit to the =

IETF = approximately two weeks from now, I will extent the poll by one week (so =

that it = will be a three week poll).

 =

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

mailing = list (mpls@ietf.org).

 =

This poll = will end Friday March 7, 2014. Note that this is the Friday of the IETF, =

and thus = we will each need to plan our review of the document and response =

around our = travel plans and IETF activities.

 =

Thanks, = Ross

 =

------=_NextPart_000_0001_01CF2C0F.E7370CF0-- From nobody Mon Feb 17 03:28: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 C7CA91A0125 for ; Mon, 17 Feb 2014 03:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESrPXnlcwPvX for ; Mon, 17 Feb 2014 03:28:23 -0800 (PST) Received: from smtp02.msg.oleane.net (smtp02.msg.oleane.net [62.161.4.2]) by ietfa.amsl.com (Postfix) with ESMTP id 77F2E1A0483 for ; Mon, 17 Feb 2014 03:28:21 -0800 (PST) Received: from MGosseDellM6800 (LMontsouris-656-01-05-162.w80-12.abo.wanadoo.fr [80.12.94.162]) (authenticated) by smtp02.msg.oleane.net (MSA) with ESMTP id s1HBSHsh006058 for ; Mon, 17 Feb 2014 12:28:17 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Mon, 17 Feb 2014 12:28:15 +0100 Message-ID: <006101cf2bd3$59ed2000$0dc76000$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01CF2BDB.BBB2C080" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8r0oJThFf1eBThQ9eKX9A+2fzapg== Content-Language: fr X-Backend: vm-smtp-sophos15 X-PMX-Spam: Probability=11% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.17.111515 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/fCpK0u7k9HygJ3PkQl7LwRlvSH4 Subject: [mpls] MPLS SDN World 2014 will start in one month X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 11:28:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0062_01CF2BDB.BBB2C080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit After its announcement during the 2013 edition, a large session will be dedicated to < Segment routing > update and future evolution. The 16th Edition of the Congress will also focus on Data Center Virtualization, and analyze the impact of SDN and NFV initiatives on the network architecture. More info: http://www.uppersideconferences.com/ ------=_NextPart_000_0062_01CF2BDB.BBB2C080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Af= ter its announcement during the 2013 edition, a large session will be = dedicated to « Segment routing » update and future = evolution.

Th= e 16th Edition of the Congress will also focus on Data Center = Virtualization, and analyze the impact of SDN and NFV initiatives on the = network architecture.

Mo= re info: http://www.uppersideconfere= nces.com/

 

------=_NextPart_000_0062_01CF2BDB.BBB2C080-- From nobody Mon Feb 17 03:42:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739E71A0486 for ; Mon, 17 Feb 2014 03:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Y8sRUk0O0GMt for ; Mon, 17 Feb 2014 03:42:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4EC1A00FE for ; Mon, 17 Feb 2014 03:42:13 -0800 (PST) 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 BDR07653; Mon, 17 Feb 2014 11:42:10 +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; Mon, 17 Feb 2014 11:41:58 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 11:42:04 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.204]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 19:41:59 +0800 From: Mengnan To: "mpls@ietf.org" , "rcallon@juniper.net" Thread-Topic: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: Ac8r1UMV+D6a+1pWSxiAT4gY1oND8Q== Date: Mon, 17 Feb 2014 11:41:58 +0000 Message-ID: <6A70085375009045B8212879C8E5A23A79FD44F4@szxema506-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.78.181] Content-Type: multipart/alternative; boundary="_000_6A70085375009045B8212879C8E5A23A79FD44F4szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vpRCTmkrBZjXhqTlsXiBLOhB_5E Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 11:42:16 -0000 --_000_6A70085375009045B8212879C8E5A23A79FD44F4szxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as the contributor. Best Regards, Meng nan ________________________________ * To: "mpls at ietf.org" > * Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protect= ion-11 * From: Ross Callon > * Date: Thu, 13 Feb 2014 19:46:26 +0000 * Accept-language: en-US * Archived-at: http://mailarchive.ietf.org/arch/msg/mpls/LYv9Hd60cbzg-R= q3wzR-J2H2TIU * Cc: "mpls-chairs at tools.ietf.org"= > * Delivered-to: mpls at ietfa.amsl.com * List-archive: * List-help: * List-id: Multi-Protocol Label Switching WG * List-post: * List-subscribe: , * List-unsubscribe: , * Thread-index: AQHPKPRIpPUShY7IUEKfeXCXoUCU4A=3D=3D * Thread-topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 ________________________________ This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_6A70085375009045B8212879C8E5A23A79FD44F4szxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support as the contributor.<= o:p>

 

Best Regards,

Meng nan

This is to start a= poll on adopting draft-chen-mpls-p2mp-egress-protection-11

as an MPLS working= group document. Since many of us will be in transit to the

IETF approximately= two weeks from now, I will extent the poll by one week (so

that it will be a = three week poll).

 

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

mailing list (mpls a= t ietf.org).

 

This poll will end= Friday March 7, 2014. Note that this is the Friday of the IETF,

and thus we will e= ach need to plan our review of the document and response

around our travel = plans and IETF activities.

 

Thanks, Ross

 

 

--_000_6A70085375009045B8212879C8E5A23A79FD44F4szxema506mbschi_-- From nobody Mon Feb 17 08:04: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 0B0231A0502 for ; Mon, 17 Feb 2014 08:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 LCkKXaiokMDy for ; Mon, 17 Feb 2014 08:04:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 036821A024B for ; Mon, 17 Feb 2014 08:04:38 -0800 (PST) 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 BBF45960; Mon, 17 Feb 2014 16:04:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 16:04:28 +0000 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; Mon, 17 Feb 2014 16:04:34 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 08:04:20 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQAa29QMy3TZQUa/WtY1/4nJhZqzrkuAgACQewD//3ofgIAAorWAgACRYBCAAJS4gP//efAQgACQkACABBKvEA== Date: Mon, 17 Feb 2014 16:04:19 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C3802F@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7627DE@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7627DE@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.170] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C3802FSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bA22si3I0EcCVUVBxsQhTJXlYhY Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 16:04:45 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C3802FSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, The egress protection draft follows most of the behaviors defined in RF= C 4090. Regarding to using link protection and/or node protection on the u= pstream node of an egress as PLR, it follows that defined in RFC 4090. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:42 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, AFAIK, you can use either link or node protection, not both at the same PLR= . If you believe otherwise, please illustrate with RSVP signaling scenario. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 9:16 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, For a transit node of an LSP and the link between the transit node and = the upstream node of the transit node, can we use both the link protection = define in RFC 4090 for protecting the link and the node protection defined = in RFC 4090 for protecting the transit node? If so, will this kind of deplo= yment lead to unpredictable results? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:04 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C3802FSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

    The eg= ress protection draft follows most of the behaviors defined in RFC 4090. Re= garding to using  link protection and/or node protection on the upstre= am node of an egress as PLR, it follows that defined in RFC 4090.<= /span>

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, February 14, 2014 12:42 PM
To: Huaimo Chen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

AFAIK, you can use either= link or node protection, not both at the same PLR. If you believe otherwis= e, please illustrate with RSVP signaling scenario.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 9:16 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    For a = transit node of an LSP and the link between the transit node and the upstre= am node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC= 4090 for protecting the transit node? If so, will this kind of deployment = lead to unpredictable results?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C3802FSJCEML701CHMchi_-- From nobody Mon Feb 17 09:51: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 9849B1A0177 for ; Mon, 17 Feb 2014 09:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZODtqLIDnQbW for ; Mon, 17 Feb 2014 09:51:29 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id B3B2F1A0101 for ; Mon, 17 Feb 2014 09:51:29 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id uq10so5638455igb.0 for ; Mon, 17 Feb 2014 09:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HAyFEqrhQ+mPwAcJXyq/prmoEof1g9VuKx++CLxEF90=; b=JZcYzfdhUv1ca9hUtWGgGYU6B7344EWX+a4ExWNBnZBi1y3inHOfL271K0xnE5Hhrl JCN5juCXM50OOl+uvurXktMR2rpbS/w4THNrHeNKoMnQcPBnDtMSirFm9RH5GSut7eX2 p2Lb5ohIXCzQZn8BTU+yyj9iRgnnjClltdTO3G7uivcvcSOrjH43Bgy7i9VttAJvbCgN Ya8VEFfS25yRtj1NJKIqRQA+Dq1tDwy3Tn7GqeqWnUjso+HdU2gAjutEVdy0LzqXG8uH qSbdOyCskjSc++pwk9qytixYZ19nKM/5+DF7qcCFMdSaISGHPl/UT8nXcSd8Ca8e0DyF 6dqg== MIME-Version: 1.0 X-Received: by 10.50.253.194 with SMTP id ac2mr11113419igd.41.1392659487023; Mon, 17 Feb 2014 09:51:27 -0800 (PST) Received: by 10.50.129.34 with HTTP; Mon, 17 Feb 2014 09:51:26 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Feb 2014 09:51:26 -0800 Message-ID: From: LEI LIU To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a1134c0aa04680604f29dce4f Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EHGknKofT05E2v38DROUmNEiQTA Cc: Ross Callon Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 17:51:31 -0000 --001a1134c0aa04680604f29dce4f Content-Type: text/plain; charset=ISO-8859-1 Support. Best regards, Lei 2014-02-13 11:46 GMT-08:00 Ross Callon : > This is to start a poll on adopting > draft-chen-mpls-p2mp-egress-protection-11 > > as an MPLS working group document. Since many of us will be in transit to > the > > IETF approximately two weeks from now, I will extent the poll by one week > (so > > that it will be a three week poll). > > > > Please send your comments (support/not support) to the mpls working group > > mailing list (mpls@ietf.org). > > > > This poll will end Friday March 7, 2014. Note that this is the Friday of > the IETF, > > and thus we will each need to plan our review of the document and response > > around our travel plans and IETF activities. > > > > Thanks, Ross > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- -- __________________________________ Best Regards, Sincerely Yours, Lei Liu, Ph.D -------------------- Photonic Transport Network Laboratory, KDDI R&D Laboratories Inc., 2-1-15 Ohara Fujimino-shi, Saitama, Japan TELE: +81-49-278-7536 FAX: +81-49-278-7510 ZIP: 356-8502 E-mail: le-liu@kddilabs.jp / liulei@ieee.org --001a1134c0aa04680604f29dce4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.
=
Best regards,
Lei
<= div class=3D"gmail_extra">

2014-02-13 11:= 46 GMT-08:00 Ross Callon <rcallon@juniper.net>:

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

=A0

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

mailing list (mpls@ietf.org).

=A0

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

=A0

Thanks, Ross

=A0


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




--
--= =A0
__________________________________
Best Regards,

Sincerely Yours,
Lei Liu, Ph.D
-= -------------------
Photonic Transport Network Laboratory,
KDDI R&D Laborato= ries Inc.,
2-1-15 Ohara Fujimino-shi, Saitama, Japan=A0
TELE: +81-49-278-7536
FAX: +81-49-278-7510
ZIP: 356-85= 02
--001a1134c0aa04680604f29dce4f-- From nobody Mon Feb 17 13:09:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16E91A0289 for ; Mon, 17 Feb 2014 13:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5fFZ9oPPOKf for ; Mon, 17 Feb 2014 13:09:02 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id D042B1A0277 for ; Mon, 17 Feb 2014 13:09:01 -0800 (PST) Received: from mail118-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Mon, 17 Feb 2014 21:08:58 +0000 Received: from mail118-co9 (localhost [127.0.0.1]) by mail118-co9-R.bigfish.com (Postfix) with ESMTP id CA972CC030F; Mon, 17 Feb 2014 21:08:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zzc85fh4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail118-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(164054003)(189002)(199002)(51856001)(81342001)(15975445006)(74706001)(83072002)(19300405004)(66066001)(59766001)(19580395003)(77982001)(80022001)(65816001)(56816005)(90146001)(83322001)(76786001)(94946001)(19580405001)(76796001)(74316001)(85852003)(74366001)(74876001)(81542001)(81816001)(76576001)(81686001)(54356001)(53806001)(94316002)(56776001)(15202345003)(74502001)(76482001)(74662001)(4396001)(87936001)(49866001)(18717965001)(63696002)(92566001)(80976001)(93136001)(93516002)(76176001)(16236675002)(69226001)(47736001)(2656002)(95666001)(50986001)(54316002)(87266001)(85306002)(47446002)(46102001)(31966008)(33646001)(95416001)(47976001)(86362001)(79102001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:3832769D.1CD097F5.1D9BFCC.4EEDF20.20109; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail118-co9 (localhost.localdomain [127.0.0.1]) by mail118-co9 (MessageSwitch) id 1392671336558769_26634; Mon, 17 Feb 2014 21:08:56 +0000 (UTC) Received: from CO9EHSMHS032.bigfish.com (unknown [10.236.132.232]) by mail118-co9.bigfish.com (Postfix) with ESMTP id 81868C400A2; Mon, 17 Feb 2014 21:08:56 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS032.bigfish.com (10.236.130.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 17 Feb 2014 21:08:56 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Mon, 17 Feb 2014 21:08:56 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.878.16; Mon, 17 Feb 2014 21:08:53 +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.0878.008; Mon, 17 Feb 2014 21:08:53 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+Q== Date: Mon, 17 Feb 2014 21:08:53 +0000 Message-ID: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 012570D5A0 Content-Type: multipart/alternative; boundary="_000_591bf06e63ac4d978c708c598bb49d82CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BPMkUMIof6udD8Bd51dEIwT4PpY Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 21:09:05 -0000 --_000_591bf06e63ac4d978c708c598bb49d82CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_591bf06e63ac4d978c708c598bb49d82CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_591bf06e63ac4d978c708c598bb49d82CO2PR05MB636namprd05pro_-- From nobody Mon Feb 17 13:13: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 257E61A0289 for ; Mon, 17 Feb 2014 13:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 TF2OGZavi9kw for ; Mon, 17 Feb 2014 13:13:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A599B1A0299 for ; Mon, 17 Feb 2014 13:13:07 -0800 (PST) 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 BDR50319; Mon, 17 Feb 2014 21:13:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 21:12:52 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 21:12:58 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 13:12:53 -0800 From: Huaimo Chen To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+Zq58S0w Date: Mon, 17 Feb 2014 21:12:53 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C3822A@SJCEML701-CHM.china.huawei.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.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.249] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C3822ASJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mwZf99tGbsUn3q_c2NUSY759VYA Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 21:13:10 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C3822ASJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support! (as an author) Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 4:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C3822ASJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support!

(as an author)=

 <= /p>

Best Regards,<= /span>

Huaimo

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_5316A0AB3C851246A7CA5758973207D445C3822ASJCEML701CHMchi_-- From nobody Mon Feb 17 13:34:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0F11A0295 for ; Mon, 17 Feb 2014 13:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q02jV1Cb-jZq for ; Mon, 17 Feb 2014 13:33:53 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 315651A0289 for ; Mon, 17 Feb 2014 13:33:53 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-62-5302803ae5a4 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AD.CE.12743.A3082035; Mon, 17 Feb 2014 22:33:46 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 16:33:49 -0500 From: Gregory Mirsky To: Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQQErWTRsEe5IUeaVctZClaFmpqztzjwgABYTAD//8I4UIABeH2A//+s7mCAAFt5gP//srUQAJ4JFYAAANNy4A== Date: Mon, 17 Feb 2014 21:33:49 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B76E8F7@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7627DE@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C3802F@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C3802F@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B76E8F7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn65VA1OwwasZFhZbn15htPh+aQmL xa2lK1kt/q64wuLA4tFy5C2rx5IlP5k8rjddZff4cvkzWwBLFJdNSmpOZllqkb5dAlfGtP5z LAU9PcwVt680sTYwNj1k6mLk5JAQMJE40vGdEcIWk7hwbz1bFyMXh5DAEUaJ5lMbWSGc5YwS 505tYAOpYhMwknixsYcdxBYRyJNofr4frJtZwFbizpNrYLawQKDE9NZrbBA1QRJLbjxggbCz JCa3PgCLswioSvzZdAKsnlfAV+J35xOoZUvZJCY82gB2HqdAmET3+4NgNiPQed9PrWGCWCYu cevJfKgXBCSW7DnPDGGLSrx8/I8VwlaU2Nc/nR2iPl/ixaTFbBDLBCVOznzCMoFRdBaSUbOQ lM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGWxiBEbhMQk23R2M e15aHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjxjN+yqbWZ4uFHc2V Fp1d6PH/NdehzCrn2xrTonaa3i07cDf33i37csmnL56b2XCv6Tlm+7s3m+NUk9FNs12TN3Ys 4q9gS1vOvlPj1PqAKHe7Mze8/gjd/9SywOeajuu8C88eF04O+P+jn1fZ2VXN8fmN+E0ftDpf it07ob/5T8fbA4fmhTWqKrEUZyQaajEXFScCAE72WziQAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eQkfsrgfXqhYCtddbWmbIujumcQ Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 21:34:01 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B76E8F7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, without clearly distinguishable detection of Egress Failure error FRR and p= roposed mechanics are mutually exclusive at PLR (R3 in Fig.1). Hence, I thi= nk that there's a question of which protection mechanism takes precedence w= hen both been signaled. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, February 17, 2014 8:04 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, The egress protection draft follows most of the behaviors defined in RF= C 4090. Regarding to using link protection and/or node protection on the u= pstream node of an egress as PLR, it follows that defined in RFC 4090. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:42 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, AFAIK, you can use either link or node protection, not both at the same PLR= . If you believe otherwise, please illustrate with RSVP signaling scenario. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 9:16 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, For a transit node of an LSP and the link between the transit node and = the upstream node of the transit node, can we use both the link protection = define in RFC 4090 for protecting the link and the node protection defined = in RFC 4090 for protecting the transit node? If so, will this kind of deplo= yment lead to unpredictable results? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:04 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B76E8F7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

without clearly distingui= shable detection of Egress Failure error FRR and proposed mechanics are mut= ually exclusive at PLR (R3 in Fig.1). Hence, I think that there’s a question of which protection mechanism takes precedence wh= en both been signaled.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Monday, February 17, 2014 8:04 AM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    The eg= ress protection draft follows most of the behaviors defined in RFC 4090. Re= garding to using  link protection and/or node protection on the upstre= am node of an egress as PLR, it follows that defined in RFC 4090.<= /span>

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:42 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

AFAIK, you can use either= link or node protection, not both at the same PLR. If you believe otherwis= e, please illustrate with RSVP signaling scenario.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 9:16 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    For a = transit node of an LSP and the link between the transit node and the upstre= am node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC= 4090 for protecting the transit node? If so, will this kind of deployment = lead to unpredictable results?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B76E8F7eusaamb103erics_-- From nobody Mon Feb 17 14:09: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 D06191A0528 for ; Mon, 17 Feb 2014 14:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 4oiE1uLav_HY for ; Mon, 17 Feb 2014 14:08:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB9E1A0523 for ; Mon, 17 Feb 2014 14:08:54 -0800 (PST) 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 BDR52650; Mon, 17 Feb 2014 22:08:49 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 22:08:40 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 22:08:46 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 14:08:35 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQAa29QMy3TZQUa/WtY1/4nJhZqzrkuAgACQewD//3ofgIAAorWAgACRYBCAAJS4gP//efAQgACQkACABBKvEIAA5R6A//98zgA= Date: Mon, 17 Feb 2014 22:08:35 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C3827B@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7627DE@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C3802F@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B76E8F7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B76E8F7@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.249] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C3827BSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/u0pNETZSJnNv0PJ7yTZjWrfXdic Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 17 Feb 2014 22:09:01 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C3827BSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Can you give more details about your question? It seems that the FRR defined in RFC 4090 does not have a requirement that = there MUST be a clearly distinguishable detection of a transit node failure= for people to use it for protecting the transit node failure. Egress prot= ection just follows this. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Monday, February 17, 2014 4:34 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, without clearly distinguishable detection of Egress Failure error FRR and p= roposed mechanics are mutually exclusive at PLR (R3 in Fig.1). Hence, I thi= nk that there's a question of which protection mechanism takes precedence w= hen both been signaled. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, February 17, 2014 8:04 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, The egress protection draft follows most of the behaviors defined in RF= C 4090. Regarding to using link protection and/or node protection on the u= pstream node of an egress as PLR, it follows that defined in RFC 4090. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:42 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, AFAIK, you can use either link or node protection, not both at the same PLR= . If you believe otherwise, please illustrate with RSVP signaling scenario. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 9:16 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, For a transit node of an LSP and the link between the transit node and = the upstream node of the transit node, can we use both the link protection = define in RFC 4090 for protecting the link and the node protection defined = in RFC 4090 for protecting the transit node? If so, will this kind of deplo= yment lead to unpredictable results? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:04 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C3827BSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

Can you give more details about your question?

It seems that the FRR defined in RFC 4090 does not have a requirement th= at there MUST be a clearly distinguishable detection of a tr= ansit node failure for people to use it for protecting the t= ransit node failure.  Egress protection just follows this.<= /span>

 

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Monday, February 17, 2014 4:34 PM
To: Huaimo Chen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

without clearly distingui= shable detection of Egress Failure error FRR and proposed mechanics are mut= ually exclusive at PLR (R3 in Fig.1). Hence, I think that there’s a question of which protection mechanism takes precedence wh= en both been signaled.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Monday, February 17, 2014 8:04 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    The eg= ress protection draft follows most of the behaviors defined in RFC 4090. Re= garding to using  link protection and/or node protection on the upstre= am node of an egress as PLR, it follows that defined in RFC 4090.<= /span>

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:42 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

AFAIK, you can use either= link or node protection, not both at the same PLR. If you believe otherwis= e, please illustrate with RSVP signaling scenario.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 9:16 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    For a = transit node of an LSP and the link between the transit node and the upstre= am node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC= 4090 for protecting the transit node? If so, will this kind of deployment = lead to unpredictable results?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C3827BSJCEML701CHMchi_-- From nobody Mon Feb 17 15:08: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 E35AC1A0548; Mon, 17 Feb 2014 15:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f11R0NApQJOX; Mon, 17 Feb 2014 15:08:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C30031A02CA; Mon, 17 Feb 2014 15:08:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140217230847.27113.4965.idtracker@ietfa.amsl.com> Date: Mon, 17 Feb 2014 15:08:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/520xy4ccVuWQVdL85SzdYYzDF3M Cc: mpls@ietf.org Subject: [mpls] Last Call: (Allocating and Retiring Special Purpose MPLS Labels) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:08:50 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Allocating and Retiring Special Purpose MPLS Labels' 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-03-03. 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 Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these special purpose labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines new procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. This document updates a number of previous RFCs that used the term "reserved label". The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 17 17:10: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 52AEA1A0024 for ; Mon, 17 Feb 2014 17:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 wW5TOe2f8mZm for ; Mon, 17 Feb 2014 17:10:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9951A001B for ; Mon, 17 Feb 2014 17:10:51 -0800 (PST) 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 BDR60239; Tue, 18 Feb 2014 01:10:48 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 01:10:40 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 01:10:47 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 09:10:41 +0800 From: Lizhenbin To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+Zq6NA1A Date: Tue, 18 Feb 2014 01:10:40 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4@nkgeml506-mbx.china.huawei.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wLLNXsjKQ4ra2KTr4_ctacyN9l0 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogUG9sbCBmb3IgQWRvcHRpb24gZHJhZnQtY2hl?= =?gb2312?b?bi1tcGxzLXAybXAtaW5ncmVzcy1wcm90ZWN0aW9uLTEx?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 01:10:55 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyB0aGUgY29udHJpYnV0b3IuDQoNClJlZ2FyZHMsDQpSb2Jpbg0KDQoNCg0Kt6K8 /sjLOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvc3MgQ2FsbG9u DQq3osvNyrG85DogMjAxNMTqMtTCMTjI1SA1OjA5DQrK1bz+yMs6IG1wbHNAaWV0Zi5vcmcNCrOt y806IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQrW98ziOiBbbXBsc10gUG9sbCBmb3IgQWRv cHRpb24gZHJhZnQtY2hlbi1tcGxzLXAybXAtaW5ncmVzcy1wcm90ZWN0aW9uLTExDQoNClRoaXMg aXMgdG8gc3RhcnQgYSBwb2xsIG9uIGFkb3B0aW5nIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWluZ3Jl c3MtcHJvdGVjdGlvbi0xMQ0KYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBTaW5j ZSB0aGlzIGNhbGwgd2lsbCBjb250aW51ZSB0aHJvdWdoIHRoZQ0KSUVURiBtZWV0aW5nIGluIExv bmRvbiwgSSB3aWxsIGV4dGVudCB0aGUgcG9sbCBieSBvbmUgd2VlayAoc28gdGhhdCBpdCB3aWxs IGJlIGENCnRocmVlIHdlZWsgcG9sbCkuDQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1 cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXANCm1haWxpbmcgbGlz dCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQpUaGlzIHBvbGwgd2ls bCBlbmQgVHVlc2RheSBNYXJjaCAxMSwgMjAxNC4gVGhpcyBpcyBvZiBjb3Vyc2UgdGhlIFR1ZXNk YXkgYWZ0ZXINCnRoZSBJRVRGLg0KDQpUaGFua3MsIFJvc3MNCg0KDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support as= the contributor.

 = ;

Regards,

Robin=

 = ;

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: mpls [mailto:mpls-bou= nces@ietf.org] =B4=FA=B1=ED = Ross Callon
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA2=D4=C2<= span lang=3D"EN-US">18=C8=D5 5:09
=CA=D5=BC=FE=C8=CB: mpls@ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11<= /o:p>

 

This is to start a poll = on adopting draft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group= document. Since this call will continue through the

IETF meeting in London, = I will extent the poll by one week (so that it will be a

three week poll).

 =

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

mailing list (mpls@ietf.org).

 =

This poll will end Tuesd= ay March 11, 2014. This is of course the Tuesday after

the IETF.

 =

Thanks, Ross<= /span>

 =

 = ;

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4nkgeml506mbxchi_-- From nobody Mon Feb 17 17:37: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 6F5F41A01E7 for ; Mon, 17 Feb 2014 17:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 ZqKoCVSo4iEz for ; Mon, 17 Feb 2014 17:37:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF68A1A0421 for ; Mon, 17 Feb 2014 17:37:28 -0800 (PST) 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 BDR61456; Tue, 18 Feb 2014 01:37:25 +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; Tue, 18 Feb 2014 01:37:17 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 01:37:24 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.231]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 09:37:17 +0800 From: Vero Zheng To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKPRIpPUShY7IUEKfeXCXoUCU4Jq6QdfA Date: Tue, 18 Feb 2014 01:37:16 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C7E4E45@SZXEMA504-MBS.china.huawei.com> References: 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.115] Content-Type: multipart/alternative; boundary="_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C7E4E45SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qHDIObHp2LgiJ30sfZY1sh_vqh4 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogUG9sbCBmb3IgQWRvcHRpb24gZHJhZnQtY2hl?= =?gb2312?b?bi1tcGxzLXAybXAtZWdyZXNzLXByb3RlY3Rpb24tMTE=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 01:37:33 -0000 --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C7E4E45SZXEMA504MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQNCg0KQ2hlZXJzLCBWZXJvDQoNCreivP7IyzogbXBscyBbbWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb3NzIENhbGxvbg0Kt6LLzcqxvOQ6IDIwMTTE6jLUwjE0 yNUgMzo0Ng0KytW8/sjLOiBtcGxzQGlldGYub3JnDQqzrcvNOiBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZw0K1vfM4jogW21wbHNdIFBvbGwgZm9yIEFkb3B0aW9uIGRyYWZ0LWNoZW4tbXBscy1w Mm1wLWVncmVzcy1wcm90ZWN0aW9uLTExDQoNClRoaXMgaXMgdG8gc3RhcnQgYSBwb2xsIG9uIGFk b3B0aW5nIGRyYWZ0LWNoZW4tbXBscy1wMm1wLWVncmVzcy1wcm90ZWN0aW9uLTExDQphcyBhbiBN UExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFNpbmNlIG1hbnkgb2YgdXMgd2lsbCBiZSBpbiB0 cmFuc2l0IHRvIHRoZQ0KSUVURiBhcHByb3hpbWF0ZWx5IHR3byB3ZWVrcyBmcm9tIG5vdywgSSB3 aWxsIGV4dGVudCB0aGUgcG9sbCBieSBvbmUgd2VlayAoc28NCnRoYXQgaXQgd2lsbCBiZSBhIHRo cmVlIHdlZWsgcG9sbCkuDQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90 IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXANCm1haWxpbmcgbGlzdCAobXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQpUaGlzIHBvbGwgd2lsbCBlbmQgRnJp ZGF5IE1hcmNoIDcsIDIwMTQuIE5vdGUgdGhhdCB0aGlzIGlzIHRoZSBGcmlkYXkgb2YgdGhlIElF VEYsDQphbmQgdGh1cyB3ZSB3aWxsIGVhY2ggbmVlZCB0byBwbGFuIG91ciByZXZpZXcgb2YgdGhl IGRvY3VtZW50IGFuZCByZXNwb25zZQ0KYXJvdW5kIG91ciB0cmF2ZWwgcGxhbnMgYW5kIElFVEYg YWN0aXZpdGllcy4NCg0KVGhhbmtzLCBSb3NzDQoNCg== --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C7E4E45SZXEMA504MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Yes/Suppor= t

 = ;

Cheers, Ve= ro

 = ;

=B7=A2=BC=FE=C8=CB: mpls [mailto:mpls-bou= nces@ietf.org] =B4=FA=B1=ED = Ross Callon
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA2=D4=C2<= span lang=3D"EN-US">14=C8=D5 3:46
=CA=D5=BC=FE=C8=CB: mpls@ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

 

This is to start a poll = on adopting draft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group= document. Since many of us will be in transit to the

IETF approximately two w= eeks from now, I will extent the poll by one week (so

that it will be a three = week poll).

 =

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

mailing list (mpls@ietf.org).

 =

This poll will end Frida= y March 7, 2014. Note that this is the Friday of the IETF,

and thus we will each ne= ed to plan our review of the document and response

around our travel plans = and IETF activities.

 =

Thanks, Ross<= /span>

 =

--_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C7E4E45SZXEMA504MBSchi_-- From nobody Mon Feb 17 17:43: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 E7BBB1A043D for ; Mon, 17 Feb 2014 17:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0N0xbeXcfsHc for ; Mon, 17 Feb 2014 17:43:06 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A434B1A01E7 for ; Mon, 17 Feb 2014 17:43:06 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-cb-5302baa43690 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B5.28.11484.4AAB2035; Tue, 18 Feb 2014 02:43:01 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 20:42:59 -0500 From: Autumn Liu To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: Ac8rzNiLeobWKy2DSv6j4IC+IQWiRAAfa1vQ Date: Tue, 18 Feb 2014 01:42:59 +0000 Message-ID: References: <000001cf2bcc$d9107190$8b3154b0$@chinamobile.com> In-Reply-To: <000001cf2bcc$d9107190$8b3154b0$@chinamobile.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_E4F89EAEF1386F42AA8E6FB5C35399A61C0D1467eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPlO7SXUzBBi+3c1jcWrqS1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGbMnNrMU9HlW7Dv+hrmBca5jFyMnh4SAicSL5s9MELaYxIV7 69lAbCGBI4wSrfdDuhi5gOzljBKNfXfBEmwCWhL79r9jB7FFBJQljkzsZgWxhQUCJZp/NbJC xIMkbk07AFVjJLFwy1cWEJtFQFXi/sLVYDW8Ar4Sd958ZYRYZitx8iZEDaeAncSlff1gBzEK yEpMe3QfzGYWEJe49WQ+1KECEkv2nGeGsEUlXj7+xwphK0lMWnoOyOYAqs+XuHm5HmKVoMTJ mU9YJjCKzEIyaRZC1SwkVRAlOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRo7S4tSy3HQj w02MwCg5JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDs 5ch+6rJV6qBOWjaTqTdfUOnPh7tmPWOy7yxNSJe8M0UyoicjNZLvkVX/wiY/99dnuT6LHX8b 9zR10gePkN+B+X92cJZyWD/9LX2jl/XNTZ3rNW6xhwqmrxJ4I182yTDvwE3Xs8pm1rOdBYOk PVazPbu9OjjR+qnekaM6G/TOWXUqR6zbzqXEUpyRaKjFXFScCAB9ndtEYAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4vyhHQpTLzl6FV5lZj3TvH-SOQ4 Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 01:43:09 -0000 --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C0D1467eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support -Autumn (As a co-author) From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 2:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C0D1467eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support=

-Autumn (As a co-author)<= o:p>

 

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 2:46 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_E4F89EAEF1386F42AA8E6FB5C35399A61C0D1467eusaamb103erics_-- From nobody Mon Feb 17 20:24:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3651A04D3 for ; Mon, 17 Feb 2014 20:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 506RlT191kGr for ; Mon, 17 Feb 2014 20:24:24 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 27B4F1A04B7 for ; Mon, 17 Feb 2014 20:24:24 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.117546101; Mon, 17 Feb 2014 21:24:18 -0700 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.36]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 23:24:18 -0500 From: "Toy, Mehmet" To: "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: Ac8sYUj1dcVDsP6PRQqrHInV0zWQsg== Date: Tue, 18 Feb 2014 04:24:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.249] Content-Type: multipart/alternative; boundary="_000_E0CCE9D2B396674BABDD84B7C422BE1C6F5E92F3PACDCEXMB13cabl_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Hp4h2u05cRwec6PpoccoAoSxhRE Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 04:24:26 -0000 --_000_E0CCE9D2B396674BABDD84B7C422BE1C6F5E92F3PACDCEXMB13cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As one of the co-authors, I support adoption of draft-chen-mpls-p2mp-ingre= ss-protection-11 as an MPLS working group document. Mehmet From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 4:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_E0CCE9D2B396674BABDD84B7C422BE1C6F5E92F3PACDCEXMB13cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As one of the co-authors,= I support adoption of  draft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group = document.

 <= /p>

Mehmet<= /p>

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_E0CCE9D2B396674BABDD84B7C422BE1C6F5E92F3PACDCEXMB13cabl_-- From nobody Mon Feb 17 21:50:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534C41A05CF for ; Mon, 17 Feb 2014 21:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 EUtz5r6vM_s2 for ; Mon, 17 Feb 2014 21:50:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C478E1A05B8 for ; Mon, 17 Feb 2014 21:50:51 -0800 (PST) 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 BBF86943; Tue, 18 Feb 2014 05:50:47 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 05:50:04 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 05:50:12 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 13:50:03 +0800 From: Haoweiguo To: Lizhenbin , Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+Zq6NA1AgABODp0= Date: Tue, 18 Feb 2014 05:50:03 +0000 Message-ID: References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com>, <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.22.248] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7A522Dnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RCyFknRhcbG3g0ZoUfCzYA1sFMs Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogUG9sbCBmb3IgQWRvcHRpb24gZHJhZnQtY2hl?= =?gb2312?b?bi1tcGxzLXAybXAtaW5ncmVzcy1wcm90ZWN0aW9uLTEx?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 05:50:56 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7A522Dnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCENCg0KVGhhbmtzDQoNCndlaWd1bw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kt6K8/sjLOiBtcGxzIFttcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTGl6aGVu YmluIFtsaXpoZW5iaW5AaHVhd2VpLmNvbV0NCreiy83KsbzkOiAyMDE0xOoy1MIxOMjVIDk6MTAN CsrVvP7IyzogUm9zcyBDYWxsb247IG1wbHNAaWV0Zi5vcmcNCrOty806IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnDQrW98ziOiBbbXBsc10gtPC4tDogUG9sbCBmb3IgQWRvcHRpb24gZHJhZnQt Y2hlbi1tcGxzLXAybXAtaW5ncmVzcy1wcm90ZWN0aW9uLTExDQoNClN1cHBvcnQgYXMgdGhlIGNv bnRyaWJ1dG9yLg0KDQpSZWdhcmRzLA0KUm9iaW4NCg0KDQoNCreivP7IyzogbXBscyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb3NzIENhbGxvbg0Kt6LLzcqxvOQ6IDIwMTTE 6jLUwjE4yNUgNTowOQ0KytW8/sjLOiBtcGxzQGlldGYub3JnDQqzrcvNOiBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZw0K1vfM4jogW21wbHNdIFBvbGwgZm9yIEFkb3B0aW9uIGRyYWZ0LWNoZW4t bXBscy1wMm1wLWluZ3Jlc3MtcHJvdGVjdGlvbi0xMQ0KDQpUaGlzIGlzIHRvIHN0YXJ0IGEgcG9s bCBvbiBhZG9wdGluZyBkcmFmdC1jaGVuLW1wbHMtcDJtcC1pbmdyZXNzLXByb3RlY3Rpb24tMTEN CmFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4gU2luY2UgdGhpcyBjYWxsIHdpbGwg Y29udGludWUgdGhyb3VnaCB0aGUNCklFVEYgbWVldGluZyBpbiBMb25kb24sIEkgd2lsbCBleHRl bnQgdGhlIHBvbGwgYnkgb25lIHdlZWsgKHNvIHRoYXQgaXQgd2lsbCBiZSBhDQp0aHJlZSB3ZWVr IHBvbGwpLg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0 KSB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwDQptYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+KS4NCg0KVGhpcyBwb2xsIHdpbGwgZW5kIFR1ZXNkYXkgTWFy Y2ggMTEsIDIwMTQuIFRoaXMgaXMgb2YgY291cnNlIHRoZSBUdWVzZGF5IGFmdGVyDQp0aGUgSUVU Ri4NCg0KVGhhbmtzLCBSb3NzDQoNCg0K --_000_DD5FC8DE455C3348B94340C0AB5517334F7A522Dnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support!

Thanks

weiguo

=B7=A2=BC=FE=C8=CB: mpls [mpls-bounces@ietf= .org] =B4=FA=B1=ED Lizhenbin [lizhenbin@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C218=C8=D5 9:10
=CA=D5=BC=FE=C8=CB: Ross Callon; mpls@ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] =B4=F0=B8=B4: Poll for Adoption draft-chen-mpls= -p2mp-ingress-protection-11

Support as the contributo= r.

 

Regards,

Robin

 

 

 

=B7=A2=BC=FE=C8=CB: mpls [mailto:mpls= -bounces@ietf.org] =B4=FA=B1=ED= Ross Callon
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA2=D4= =C218=C8=D5 5:09
=CA=D5=BC=FE=C8=CB: mpls@ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

 

This is to start a poll on adopting draft-c= hen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Since th= is call will continue through the

IETF meeting in London, I will extent the p= oll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 2014. = This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 

--_000_DD5FC8DE455C3348B94340C0AB5517334F7A522Dnkgeml501mbschi_-- From nobody Mon Feb 17 22:57:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78F41A0366 for ; Mon, 17 Feb 2014 22:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Db-_Ygg0RrY0 for ; Mon, 17 Feb 2014 22:57:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9E131A043B for ; Mon, 17 Feb 2014 22:57:52 -0800 (PST) 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 BBF91954; Tue, 18 Feb 2014 06:57:48 +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, 18 Feb 2014 06:57:40 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 06:57:47 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 14:57:43 +0800 From: Qin Wu To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+Zq6lHgg Date: Tue, 18 Feb 2014 06:57:42 +0000 Message-ID: References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C819BCnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2JNyU-TK7_mycxo3aq_SGjRKT3s Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 06:57:56 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C819BCnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards! -Qin From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, February 18, 2014 5:09 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_B8F9A780D330094D99AF023C5877DABA43C819BCnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

Regards!

-Qin

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Tuesday, February 18, 2014 5:09 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_B8F9A780D330094D99AF023C5877DABA43C819BCnkgeml501mbschi_-- From nobody Mon Feb 17 23:23: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 0C1FF1A0609 for ; Mon, 17 Feb 2014 23:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAEKRc94mKIb for ; Mon, 17 Feb 2014 23:23:18 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA471A060A for ; Mon, 17 Feb 2014 23:23:18 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-3e-53030a5f6e39 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D6.0A.12743.F5A03035; Tue, 18 Feb 2014 08:23:11 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Tue, 18 Feb 2014 02:23:14 -0500 From: Gregory Mirsky To: Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQQErWTRsEe5IUeaVctZClaFmpqztzjwgABYTAD//8I4UIABeH2A//+s7mCAAFt5gP//srUQAJ4JFYAAANNy4AAL5VqAAAhkdJA= Date: Tue, 18 Feb 2014 07:23:13 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B76EAC8@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7627DE@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C3802F@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B76E8F7@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C3827B@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C3827B@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B76EAC8eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPt248F3Owwfv9RhZbn15htPh+aQmL xa2lK1kt/q64wuLA4tFy5C2rx5IlP5k8rjddZff4cvkzWwBLFJdNSmpOZllqkb5dAlfGtT/n 2QoajzJXrO3cw9bAeG4ycxcjJ4eEgInEwtdLoWwxiQv31rN1MXJxCAkcYZR4P7kTylnOKHFm /RQmkCo2ASOJFxt72EFsEYE8iebn+xlBbGYBW4k7T66B2cICgRLTW6+xQdQESSy58YAFwi6T 2DPxHtgcFgFViT0998FsXgFfiX/X+1gglm1ll2i4sBIswSkQJrHg4CEwmxHovO+n1jBBLBOX uPVkPhPE2QISS/ach3pBVOLl43+sELaSxMff89kh6vMl5r38wwKxTFDi5MwnLBMYRWchGTUL SdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66kcEmRmAUHpNg093B uOel5SFGaQ4WJXHeL2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwVj68tNuNZ/PirguB BzZclb1TeXrunts6b+oy+I0eGi1YfrS4+Xv1sY0LT1u8klg1s3iRaoHXe6dH/mIFyzadSpm7 V3Pi/EnSW7Wf2C33YDw602Kr2g/2tNclFR2PeR2X3TIQ29r5L+dTlpWGss9j320runce3WW8 RHV53k65+1qdzguW+7/MilBiKc5INNRiLipOBABvRixpkAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ac3Eev2cr75jZhjuozSoBrxopuQ Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 07:23:25 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B76EAC8eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, the proposal in question does not and, what I really consider the problem, = cannot go beyond absolutely same continuity monitoring as for RFC 4090. Yo= u change interpretation of LoC between R3 and L1 and call it "egress failur= e" even though it could be just link failure. And to add to my concern is t= he fact that the proposal does not protect L1-CE link. But egress and the a= ccess link can be protected at the service layer if the protection domain s= et between CE nodes. That will provide true egress protection. Because of these considerations I believe that the proposed approach is lim= ited, not practical and offers solution to a problem that already been solv= ed. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, February 17, 2014 2:09 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, Can you give more details about your question? It seems that the FRR defined in RFC 4090 does not have a requirement that = there MUST be a clearly distinguishable detection of a transit node failure= for people to use it for protecting the transit node failure. Egress prot= ection just follows this. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Monday, February 17, 2014 4:34 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, without clearly distinguishable detection of Egress Failure error FRR and p= roposed mechanics are mutually exclusive at PLR (R3 in Fig.1). Hence, I thi= nk that there's a question of which protection mechanism takes precedence w= hen both been signaled. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, February 17, 2014 8:04 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, The egress protection draft follows most of the behaviors defined in RF= C 4090. Regarding to using link protection and/or node protection on the u= pstream node of an egress as PLR, it follows that defined in RFC 4090. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:42 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, AFAIK, you can use either link or node protection, not both at the same PLR= . If you believe otherwise, please illustrate with RSVP signaling scenario. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 9:16 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, For a transit node of an LSP and the link between the transit node and = the upstream node of the transit node, can we use both the link protection = define in RFC 4090 for protecting the link and the node protection defined = in RFC 4090 for protecting the transit node? If so, will this kind of deplo= yment lead to unpredictable results? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:04 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B76EAC8eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

the proposal in question = does not and, what I really consider the problem, cannot go  beyond ab= solutely same continuity monitoring as for RFC 4090. You change interpretation of LoC between R3 and L1 and call it “egress failure&= #8221; even though it could be just link failure. And to add to my concern = is the fact that the proposal does not protect L1-CE link. But egress and t= he access link can be protected at the service layer if the protection domain set between CE nodes. That will provide tru= e egress protection.

Because of these consider= ations I believe that the proposed approach is limited, not practical and o= ffers solution to a problem that already been solved.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Monday, February 17, 2014 2:09 PM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

Can you give more details about your question?

It seems that the FRR defined in RFC 4090 does not have a requirement th= at there MUST be a clearly distinguishable detection of a transit node failure for people to use it for protecting the transit node = failure.  Egress protection just follows this.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Monday, February 17, 2014 4:34 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

without clearly distingui= shable detection of Egress Failure error FRR and proposed mechanics are mut= ually exclusive at PLR (R3 in Fig.1). Hence, I think that there’s a question of which protection mechanism takes precedence wh= en both been signaled.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Monday, February 17, 2014 8:04 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    The eg= ress protection draft follows most of the behaviors defined in RFC 4090. Re= garding to using  link protection and/or node protection on the upstre= am node of an egress as PLR, it follows that defined in RFC 4090.<= /span>

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:42 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

AFAIK, you can use either= link or node protection, not both at the same PLR. If you believe otherwis= e, please illustrate with RSVP signaling scenario.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 9:16 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    For a = transit node of an LSP and the link between the transit node and the upstre= am node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC= 4090 for protecting the transit node? If so, will this kind of deployment = lead to unpredictable results?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B76EAC8eusaamb103erics_-- From nobody Tue Feb 18 01:21: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 BD4AC1A044B for ; Tue, 18 Feb 2014 01:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUEBMeeIcCVm for ; Tue, 18 Feb 2014 01:21:14 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6A81A05F9 for ; Tue, 18 Feb 2014 01:21:14 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so25073619qcz.17 for ; Tue, 18 Feb 2014 01:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ieaMjaJQKSU6C6yd2G8FTOn8jOp57HdBe85RwY3eBvk=; b=KKpClJxyCKQpUPVk6KW87uQaK7cDon2hYrSGfy8QlWqwTw6P+EPzxUOQUDkQUEz2V5 spzdw9VElNHY7eeDsY0CE0t3YIEExeRx0aw7uWdiXcZ6FPdWI/EjPH53pt0N0Jc7s/t3 r2qAjBuBLmyrLQnlcgli30V8sZd7IEZcAIhp8bCaSwzv0mJ0OYQZwFPvc9/f7vTnagAg hHWXjLRrUh2cpd1hJhubJkIYKeHWb5W/xwiHJASvdxNSuP5aXLJwipAGjmrqXgPwVakJ Oicu7Gn7KlioGN3AOuYb0s5NV4NK/m/sPdtWLvHHO7jpYvKsW4PnrYm+4b7pdxehe5rI 4Vbg== MIME-Version: 1.0 X-Received: by 10.140.48.172 with SMTP id o41mr38732306qga.16.1392715271319; Tue, 18 Feb 2014 01:21:11 -0800 (PST) Received: by 10.224.98.132 with HTTP; Tue, 18 Feb 2014 01:21:11 -0800 (PST) In-Reply-To: References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Date: Tue, 18 Feb 2014 17:21:11 +0800 Message-ID: From: weiqiang cheng To: Qin Wu Content-Type: multipart/alternative; boundary=001a11353500054f6904f2aacb4d Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/31aImfg9Y0Wry2fZbPSzikgh43A Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 09:21:17 -0000 --001a11353500054f6904f2aacb4d Content-Type: text/plain; charset=ISO-8859-1 Support! B.R. Weiqiang Cheng 2014-02-18 14:57 GMT+08:00 Qin Wu : > Support. > > > > Regards! > > -Qin > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross Callon > *Sent:* Tuesday, February 18, 2014 5:09 AM > *To:* mpls@ietf.org > *Cc:* mpls-chairs@tools.ietf.org > *Subject:* [mpls] Poll for Adoption > draft-chen-mpls-p2mp-ingress-protection-11 > > > > This is to start a poll on adopting > draft-chen-mpls-p2mp-ingress-protection-11 > > as an MPLS working group document. Since this call will continue through > the > > IETF meeting in London, I will extent the poll by one week (so that it > will be a > > three week poll). > > > > Please send your comments (support/not support) to the mpls working group > > mailing list (mpls@ietf.org). > > > > This poll will end Tuesday March 11, 2014. This is of course the Tuesday > after > > the IETF. > > > > Thanks, Ross > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001a11353500054f6904f2aacb4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support!
B.R.
Weiqiang Cheng


2014-0= 2-18 14:57 GMT+08:00 Qin Wu <bill.wu@huawei.com>:

Support.

=A0

Regards!

-Qin

From: mpls [mailto= :mpls-bounces@ie= tf.org] On Behalf Of Ross Callon
Sent: Tuesday, February 18, 2014 5:09 AM
To: mpls@ietf.org=
Cc: = mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

=A0

This is to start a poll on adopting draft= -chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Since = this call will continue through the

IETF meeting in London, I will extent the= poll by one week (so that it will be a

three week poll).

=A0

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

mailing list (mpls@ietf.org).

=A0

This poll will end Tuesday March 11, 2014= . This is of course the Tuesday after

the IETF.

=A0

Thanks, Ross

=A0

=A0


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


--001a11353500054f6904f2aacb4d-- From nobody Tue Feb 18 02:25: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 016261A05F9 for ; Tue, 18 Feb 2014 02:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9cDEScwlPIl for ; Tue, 18 Feb 2014 02:25:14 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D6D621A0625 for ; Tue, 18 Feb 2014 02:25:12 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id ar20so3489730iec.11 for ; Tue, 18 Feb 2014 02:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Nswe8VzTmS+FlKK5DMlTXB6oM2xSLSzA9Ia5l9LQwb8=; b=cIohoW3xcymkIMRvtH7ezF72C0civjv/UsFEgjTIrv/2T2Qyae92wQFEEdG3P2Wjy2 2qw3MwjieKUoRCkeAs4tdf4lNhAZYLcrdk936mc6Kt65YxRzspBk6IRCOetAZhVpeHYb pkMoIJ4yKNC0hjzrRPoW6uLwForDZBWOrmzGrZdRsgEmXU6/begWLbzYsfsuoue2UXRb DhSZxVyNKoCOfbP3Z3HaqSxXhBpBTUd6eoCxydvx1gmeP6h5AERYPvgoBrObctOyV4ln mghV+LXm+p+lVjC9Dfsk0j/R9OJZqXvm8cPlAvZbT0Qd5BTn+AImBLtZv+XB5wPlM8jO zGlg== MIME-Version: 1.0 X-Received: by 10.50.122.8 with SMTP id lo8mr21275959igb.31.1392719109955; Tue, 18 Feb 2014 02:25:09 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.160.231 with HTTP; Tue, 18 Feb 2014 02:25:09 -0800 (PST) In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Date: Tue, 18 Feb 2014 15:55:09 +0530 X-Google-Sender-Auth: 0xLXTzggn1z2vj_UYVqp_qrxS-M Message-ID: From: Dhruv Dhody To: Ross Callon Content-Type: multipart/alternative; boundary=089e015384fed223a504f2abaf8e Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/10y2bfAQH4O941tTv5lXLncTEIA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 10:25:17 -0000 --089e015384fed223a504f2abaf8e Content-Type: text/plain; charset=ISO-8859-1 Support! On Tue, Feb 18, 2014 at 2:38 AM, Ross Callon wrote: > This is to start a poll on adopting > draft-chen-mpls-p2mp-ingress-protection-11 > > as an MPLS working group document. Since this call will continue through > the > > IETF meeting in London, I will extent the poll by one week (so that it > will be a > > three week poll). > > > > Please send your comments (support/not support) to the mpls working group > > mailing list (mpls@ietf.org). > > > > This poll will end Tuesday March 11, 2014. This is of course the Tuesday > after > > the IETF. > > > > Thanks, Ross > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --089e015384fed223a504f2abaf8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support!=A0


On Tue, Feb 18, 2014 at 2:38 AM, Ross Callon <r= callon@juniper.net> wrote:

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

=A0

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

mailing list (mpls@ietf.org).

=A0

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

=A0

Thanks, Ross

=A0

=A0<= /p>


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


--089e015384fed223a504f2abaf8e-- From nobody Tue Feb 18 06:24:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2451A064A for ; Tue, 18 Feb 2014 06:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJlCONXyfnKX for ; Tue, 18 Feb 2014 06:24:46 -0800 (PST) Received: from oms-da04.r1000.mx.aol.com (oms-da04.r1000.mx.aol.com [205.188.92.208]) by ietfa.amsl.com (Postfix) with ESMTP id 524C81A01CB for ; Tue, 18 Feb 2014 06:24:46 -0800 (PST) Received: from mtaomg-mcd01.mx.aol.com (mtaomg-mcd01.mx.aol.com [172.26.223.207]) by oms-da04.r1000.mx.aol.com (AOL Outbound OMS Interface) with ESMTP id 57CAA380003E6; Tue, 18 Feb 2014 09:24:43 -0500 (EST) Received: from core-aba07b.mail.aol.com (core-aba07.mail.aol.com [172.27.22.7]) by mtaomg-mcd01.mx.aol.com (OMAG/Core Interface) with ESMTP id 84DE338000088; Tue, 18 Feb 2014 09:24:42 -0500 (EST) References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4@nkgeml506-mbx.china.huawei.com> To: lizhenbin@huawei.com, rcallon@juniper.net, mpls@ietf.org In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081EBAC4@nkgeml506-mbx.china.huawei.com> X-MB-Message-Source: WebUI Received: from 122.167.145.197 by webmail-d169.sysops.aol.com (205.188.252.84) with HTTP (WebMailUI); Tue, 18 Feb 2014 09:24:42 -0500 MIME-Version: 1.0 From: Dorian Davis X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D0FACC4C530F40_A78_3EE1_webmail-d169.sysops.aol.com" X-Mailer: AOL Webmail 38394-STANDARD Message-Id: <8D0FACC4B082F95-A78-10D8@webmail-d169.sysops.aol.com> X-Originating-IP: [122.167.145.197] Date: Tue, 18 Feb 2014 09:24:42 -0500 (EST) x-aol-global-disposition: S DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1392733483; bh=0sO4nHKoLrkMUfKsk6AhoyxrfS4clvqjIhPvJYHKeMU=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=R0g1LJRvh0e33EK0MjkrePdpw+XGH6H2qQSbPgmmCs2Azsi7bkP6zmgv01ynW5nrC RYaqbbhogC8rzj4pc+C3Oc/LfW2s+TfQdoGSRBDhDpm+MOXlBum1X3J9bUwDbCWXR0 RE6eCC4FTvmzOvr559bQTMfNuEz/uL6trt+DsXh4= X-AOL-REROUTE: YES x-aol-sid: 3039ac1adfcf53036d2a3fc5 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ATsrv3g9yJywMVIiXrpaLYzoOro Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBQb2xsIGZvciBBZG9wdGlvbiBkcmFmdC1jaGVu?= =?utf-8?q?-mpls-p2mp-ingress-protection-11?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 14:24:50 -0000 This is a multi-part message in MIME format. ----------MB_8D0FACC4C530F40_A78_3EE1_webmail-d169.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Support!=20 ------------------ Dorian Davis davis.dorian@aim.com -----Original Message----- From: Lizhenbin To: Ross Callon ; mpls Cc: mpls-chairs Sent: Tue, Feb 18, 2014 6:40 am Subject: [mpls] =E7=AD=94=E5=A4=8D: Poll for Adoption draft-chen-mpls-p2mp-= ingress-protection-11 Support as the contributor. =20 Regards, Robin =20 =20 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bounces@ietf.org]=E4=BB=A3= =E8=A1=A8 Ross Callon =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=8818=E6=97=A5 5:= 09 =E6=94=B6=E4=BB=B6=E4=BA=BA: mpls@ietf.org =E6=8A=84=E9=80=81: mpls-chairs@tools.ietf.org =E4=B8=BB=E9=A2=98: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11 =20 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). =20 Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). =20 This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. =20 Thanks, Ross =20 =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ----------MB_8D0FACC4C530F40_A78_3EE1_webmail-d169.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Support! 

= ------------------
Doria= n Davis
davis.dorian@aim.com


-----= Original Message-----
From: Lizhenbin <lizhenbin@huawei.com>
To: Ross Callon <rcallon@juniper.net>; mpls <mpls@ietf.org>
Cc: mpls-chairs <mpls-chairs@tools.ietf.org>
Sent: Tue, Feb 18, 2014 6:40 am
Subject: [mpls] =E7=AD=94=E5=A4=8D: Poll for Adoption draft-chen-mpls-p2mp-= ingress-protection-11

Support as the contributor.
 
Regards,
Robin
 
 
 
=E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Ross Callon
=E5=8F=91=E9= =80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B42=E6=9C=8818=E6=97=A5 5:09
=E6=94=B6=E4=BB=B6=E4=BA=BA: mpls@ietf.org
=E6=8A=84=E9=80=81: mpls-chairs@tools.iet= f.org
=E4=B8=BB=E9=A2=98: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11=
 
This is to start a poll on adopting draft-chen-mpls-p2mp-ingress= -protection-11
as an MPLS working group document. Since this call will continue= through the
IETF meeting in London, I will extent the poll by one week (so t= hat it will be a
three week poll).
 
Please send your comments (support/not support) to the mpls work= ing group
mailing list (mpls@ietf.org).
 
This poll will end Tuesday March 11, 2014. This is of course the= Tuesday after
the IETF.
 
Thanks, Ross
 
 
________________________________________=
_______
mpls mailing list
mpls@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/mpls
----------MB_8D0FACC4C530F40_A78_3EE1_webmail-d169.sysops.aol.com-- From nobody Tue Feb 18 06:39: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 A18E01A064A for ; Tue, 18 Feb 2014 06:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNKq5Z-fHpts for ; Tue, 18 Feb 2014 06:39:35 -0800 (PST) Received: from nm6-vm2.bullet.mail.ne1.yahoo.com (nm6-vm2.bullet.mail.ne1.yahoo.com [98.138.90.154]) by ietfa.amsl.com (Postfix) with ESMTP id 443301A015B for ; Tue, 18 Feb 2014 06:39:35 -0800 (PST) Received: from [98.138.226.180] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 14:39:32 -0000 Received: from [98.138.101.183] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 14:39:32 -0000 Received: from [127.0.0.1] by omp1094.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 14:39:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 229519.45483.bm@omp1094.mail.ne1.yahoo.com Received: (qmail 52976 invoked by uid 60001); 18 Feb 2014 14:39:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392734372; bh=M1A5CL0yBjGulujNrynCyYvt0sQ5QtHQrWKibWHHmuo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=WO7zZGKDtHPTqpiI+9ocT9iw0FmMuDDQoj4F1p9hqLgZOv886cNYxmn7Kb+vETmUoTB4/jReTEVs5scgY1JbY4BPXBQj6ZBh4dx/2ynUK7IWgoK2af/pcNqHNdSfnNXwzE9M+FdoVbPYxgLRkfC1tlPwN6+Z8bu8sR25bOTbs1w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=axEHQnF6VxlM9ycyH1mbpK2h//KdFDe6Zvo5lIxZuOLdDx10Dqh/Qza7d+Eju6xWq3ZkGals5E/xSq/XxITbCeJskhK7zia0akReTPzOu9AdKUjaYF2ssnILg3FSLrh1uLw/AUHIF2zmyki8F583I0xcuaOx/1hkab6n4IxROg0=; X-YMail-OSG: 8WC4nHAVM1k.WW3HbW6x9dx4GzQU.RKrS4u15n5Hi1sr0e5 zrNFTAsQrqsTzLvvu.f62Mla4qsnN_J9bmLVbLCoCmMqsinmsMGOcCeb8gYl VAM.M3U9ERRZslydV11dUfKmz1va6lgPwAmjitfG0XjwTiZp9GeqTXB4UVKX uJ_2D3I17oImllTo14588uKbLbOoObeb_w6OxBTkSEkQs.4pUcRLfCVNWEhy RP9v74AcSAhbW9UQ4GP41d_vzSuefgg0JNb.g95g2eldSmO79hVTQaaYq3Sw V5mcsml8P8VUottj3Xa8pPoByAdDY0dpLadX1qvIph6KuM7nXkLY6GGiaILD HEaoWj8hEiyjC.n16BJPbYLrnNWulvDT7_DAsd1fsxDpnIgblJ1Tl.RKFRKy qShhOjGdSu0LTkjVd.QsUau_glPz7lezxrdlKJQ4tnAQmxFmTc8cCVte9uBW BJhS1Le_MTfmOWFpvxwi_d8PUzXzDGUppH6M.ZleZmSF5ETq80qioruJZpCH kVxb4vSPJJD5VvVECIi3ZpNm7Lk3DoVG7sAFgFTvs9cXppAwaUJAQWtASg8L g45QBPgor5j.CbE4- Received: from [71.170.227.188] by web121001.mail.ne1.yahoo.com via HTTP; Tue, 18 Feb 2014 06:39:31 PST X-Rocket-MIMEInfo: 002.001, wqBTdXBwb3J0IGFzIGNvYXV0aG9yLgoKTmluZyBTbwo5NzItOTU1LTA5MTQKCkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3NzIENhbGxvbgpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE3LCAyMDE0IDQ6MDkgUE0KVG86IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc.CkNjOiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc.ClN1YmplY3Q6IFttcGxzXSBQb2xsIGZvciBBZG9wdGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: Message-ID: <1392734371.52926.YahooMailNeo@web121001.mail.ne1.yahoo.com> Date: Tue, 18 Feb 2014 06:39:31 -0800 (PST) From: ningso@yahoo.com To: "mpls@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="344044665-701655064-1392734371=:52926" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BOz-IqSRMlf1DxUk3X33LlHRjQE Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ningso@yahoo.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 14:39:37 -0000 --344044665-701655064-1392734371=:52926 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0Support as coauthor.=0A=0ANing So=0A972-955-0914=0A=0AFrom: mpls [mailto= :mpls-bounces@ietf.org] On Behalf Of Ross Callon=0ASent: Monday, February 1= 7, 2014 4:09 PM=0ATo: mpls@ietf.org=0ACc: mpls-chairs= @tools.ietf.org=0ASubject: [mpls] Poll f= or Adoption draft-chen-mpls-p2mp-ingress-protection-11=0A=0AThis is to star= t a poll on adopting draft-chen-mpls-p2mp-ingress-protection-11=0Aas an MPL= S working group document. Since this call will continue through the=0AIETF = meeting in London, I will extent the poll by one week (so that it will be a= =0Athree week poll).=0A=0APlease send your comments (support/not support) t= o the mpls working group=0Amailing list (mpls@ietf.org).=0A=0AThis poll will end Tuesday March 11, 2014. This is of course the T= uesday after=0Athe IETF.=0A=0AThanks, Ross=0A=0A=0A-------------- next part= --------------=0AAn HTML attachment was scrubbed...=0AURL: = =0A --344044665-701655064-1392734371=:52926 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --344044665-701655064-1392734371=:52926-- From nobody Tue Feb 18 06: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 E9DD51A06A8 for ; Tue, 18 Feb 2014 06:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 NCCGiirgH6Cq for ; Tue, 18 Feb 2014 06:47:03 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7529B1A06A0 for ; Tue, 18 Feb 2014 06:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=86044; q=dns/txt; s=iport; t=1392734818; x=1393944418; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=TV6xqVY8t8jZgyz2NPmLocNYS8vohWOMwdxlcZiTZFc=; b=I+YvFUTFLk4ptQstIJ+PB1nXU0NTEOJEE3Ozlmzhe3WPDwzbO3gdN8TG UApJfOMK2b8ggqvAIiPe4WrbyR6TbS4PkpYvLc+KelMTgG7xXKr/uj0gR SNa3VdHRAredPA19o0HgHtUtnTYj8HiGTrKB9LwgSj5jANF5BcOiFm5QF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FADFxA1OQ/khN/2dsb2JhbABZgwY4iTa2cYEYFnSCJQEBAQMBAQEBCwoCAUoGAwoBDgILDgoJFgEBBgcJAwIBAgEJBgYfEQYBDAEFAgEBFYdYAwkIDcNWDYgPFwSMY4E4CgEFAgEjLAeEOASWQIFsjF6FRYMtgWgBBhk X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208,217";a="643809" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-4.cisco.com with ESMTP; 18 Feb 2014 14:46:55 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1IEkt8l011723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 14:46:55 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1IEkqng012259; Tue, 18 Feb 2014 14:46:52 GMT Message-ID: <5303725C.6070007@cisco.com> Date: Tue, 18 Feb 2014 14:46:52 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alia Atlas , Loa Andersson References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090909090108090705030007" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/fL2C2eRMVcQrP68LlTt1w8MMMo0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels 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, 18 Feb 2014 14:47:11 -0000 This is a multi-part message in MIME format. --------------090909090108090705030007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This has me worried. Assume that nothing implements ESPL yet, there is no reason why all SPL implementations are not required to send L7 only as a regular (single) SPL. As Loa says, this would be a useful simplification, and one which I raised earlier with the authors. If that is the case, a parser will always get it right. The only problem I see is if a compound label is ever created L15, Lx, <0..maxLabel> but one one has defined such an Lx and to do so would be unwise. So I don't think Alia is correct in her proposed text change and I have yet to see a valid technical reason for not accepting Loa's proposed change. - Stewart On 15/02/2014 17:09, Alia Atlas wrote: > [+ietf] > > Loa, > > To clarify a bit better, what I'm trying to get clarified into the > text is why the ELI value as an ESPL > needs to be an exception (as the draft indicates). I believe it is > because forbidding an ESPL of 7 > can break some existing and deployed versions of RFC 6790 such that > the transit traffic flows are affected. > There may also be implementations of RFC 6790 that aren't affected. > > Regards, > Alia > > > On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas > wrote: > > Loa, > > On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson > wrote: > > Alia, > > Two comments on this. > > First a nit "An LSR wishing to insert an ...", LSR are boxes > and can't > wish anything for themselves, a Simple change would be "When > an LSR > insert..." > > Actually the same is true for the current text and should be > changed the > same way. > > > [Alia] Sure - I took the original text and modified it. > > Second, and this is maybe more tricky - the reason given > "simplify the > data plane implementation" is not true and might even be wrong. > The reason put always using the ELI as a "regular special > purpose label" > is backwards compatibility. > I would claim that the treatment of the ELI is an (well motivated) > exception, but exceptions always mean that things get more > complicated. > > > [Alia] There were three purposes to my suggested text change. > First, to specify that > an LSR MUST NOT insert the ELI as an ESPL. Second, to say that a > receiving LSR > MAY choose to not discard a packet with the ELI as an ESPL. > Third, I wanted to see > a clearer justification for why this exception is worth making. > > [Alia] Since the whole draft is about a data-plane change, what > we've been putting in doesn't > really articulate the full problem. Prelim text would around that > would be better as: > > "ELI is an exception because each LSR examines the whole label > stack to see if the ELI > appears; pre-existing implementations of [Entropy-Label] do this > examination without verifying > that the label above the ELI is not XL. If a packet used an ESPL > of 7 and that did not mean > ELI, then when that packet transited deployed LSRs, which > implement [Entropy-Label] and not this document, > the meaning of the ESPL would be misinterpreted. Such a > misinterpretation could result in poor traffic behavior (large flows, > reordered flows, etc.) depending on the label after the ESPL of 7. > It is to avoid such issues that ELI is defined as an exception > that can appear as an regular special label or as an ESPL with the > same value of 7." > What do you think? > > Alia > > I don't want to propose a final text,but something along these > lines: > > > "Label 7 (when received) retains its meaning as ELI whether a > regular special purpose label or an ESPL; this is because of > backwards > compatibility with existing implemented and deployed code and > hardware > that looks for the ELI without verifying if the previous label > is XL or not. However, when an LSR insert an entropy label it > SHOULD > insert the ELI as a regular special purpose label, not as an > ESPL." > > /Loa > > > On 2014-02-15 10:52, Alia Atlas wrote: > > Adrian and others, > > Having reviewed the 05 of this draft and this thread, I > have the > following suggestions. Other than these, I'm quite happy > with how this > draft has improved. > > a) In Sec 3.1, the following paragraph could be updated from: > > "Label 7 (when received) retains its meaning as ELI whether a > regular special purpose label or an ESPL; this simplifies > a transit > LSR's task of looking for entropy labels since it may just > look for > label 7 and need not verify that the previous label in > the stack is not > the XL 15. However, an LSR wishing to insert an entropy > label SHOULD > insert label 7 as a regular special purpose label, not as > an ESPL." > > > to: > > > "An LSR wishing to insert an entropy label MUST insert > label value 7 (meaning ELI) as a regular special purpose > > label and not as an ESPL.Value 7 MUST NOT be sent as an > ESPL in the data plane. However, to simplify > > > the data plane implementation for Entropy Labels, an > implementation MAY > > interpret an ESPL of 7 as meaning ELI and, unlike for > values 0-6 and 8-15, an implementation > > MAY choose to not treat the packet as malformedand thus > discard it. The data plane simplification thus enabled > > > is the ability to determine if any label value is 7 > without needing to verify that the previous label in the > stack is not the XL value of 15." > > > b)In Sec 3.2: "An RFC with at least Informational status > is required." How is this different from IETF Review in > RFC 5226? Do BCPs count? What is "at least Informational > status"? > > > > On the concern about Pervasive Monitoring, the only > advantage that (XL, > ESPL) offers is that the labels wouldn't (eventually) be > hashed for > load-balancing. Otherwise, the label stack offers the > ability for > meta-data already where only the receiver would need to > understand it. > Consistent paths are very useful, but there are other > ways of doing > this already - with the most trivial being just using > label 15. I have > a hard time seeing this as a new attack vector (but I'm not > professionally paranoid yet). > > Alia > > On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel > > >> > wrote: > > [snip] > > > >> XL The Extension Label that indicates that an > extended special > > >> purpose label follows. > > >> > > >> ESPL An Extended Special Purpose Label. > > >> > > >> Something that I think would be worthwhile > clarifying right at the > > >> front is that a label is an ESPL IFF it is > preceded by an XL. > > >> It might even be worth noting that really we > have a new label > type: > > >> a label couple in which the first label defines > the type of the > > >> second label and neither are of any use as > individual labels. > > > I can see how you would see this as a new label > type. Maybe > "compound" > > > rather than "couple". > > > However, I am not convinced that it is new that > one label leads > to the > semantics > > > of the next (for example the entropy label). > > > What is more, I am not sure that there will be > more than this > instance of > this > > > type of tight coupling. > > > So I would rather leave this point out. > > I can foresee other cases where we might use label > pairs to > mitigate the > > 20bit limit. I am sure it has been discussed, so > creating the > reference > > might be useful. Just because this was not done in > EL, does not > mean that > > we should not set down the concept here. > > > > However I agree compound would be a better term. > > > > > > > > But as to clarifying ESPL: yes. > > > The XP definition is, I think, clear. > > > How about... > > > > > > ESPL An Extended Special Purpose Label. A Special > Purpose Label > that > > > is placed in the label stack after the > Extension Label. > > > > Yes. Indeed it MUST be placed be placed there, > however the definition > > above is fine. > > OK, I updated to... > > ESPL An Extended Special Purpose Label. A Special > Purpose Label that > is placed in the label stack after the > Extension Label. The > combination of XL and ESPL might be regarded > as a new form of > "compound label" comprising more than one > consecutive entry in > the label stack. > > ..to cover your other point as well. > > > >> ====== > > >> > > >> I think that the draft will need to provide some > guidance > > >> on when to allocate a 0..15 and when to allocate > an ESPL. > > >> > > >> I imagine that a 0..15 should only be used when > it can be shown > > >> that the extra stack space of forwarding time is > burdensome > > >> but that is a question that the WG should > explicitly consider. > > > We discussed this at some point on the MPLS list > (many > centuries ago, I > think) > > > and reached no conclusion. > > > The primary purpose of the XL is to handle the > time when 0..15 > is depleted. > > > You're right that we could encourage people to > start using > ESPLs now before > > > 0..15 is depleted. But it is hard to make the > case for > requiring it when > there > > > is still some of 0..15 available and the rate of > burn is not so > high. > > > > > > We could put in some text like... > > > > > > When allocating a new Special Purpose Label, > protocol designers > should > > > consider whether they could, instead, use an > Extended Special > Purpose > > > Label. Doing so would help to preserve the scarce > resources of > Special > > > Purpose Labels for use in cases where minimizing > the label > stack size is > > > particularly important. > > > > That would be useful text. > > Added as new section 3.1.2 with slight tweak to wording. > > [snip] > > > >> 6. [RFC6790] says that special purpose > labels MUST NOT be > used for > > >> load balancing. The same logic applies > to extended special > > >> purpose labels (ESPLs). Thus, this > document specifies > that ESPLs > > >> MUST NOT be used for load balancing. It > is noted that > existing > > >> implementations may violate this, as they do > not look > for the XL > > >> and thus for ESPLs. The consequence is > that if ESPLs > are used in > > >> some packets of a flow, these packets may > be delivered on > > >> different paths and so could be > re-ordered. However, it is > > >> important to specify the correct behavior > for future > > >> implementations, hence the use of "MUST NOT". > > >> > > >> I would suggest that most implementations do > violate this. I would > > >> also suggest that it seems unlikely that you > will get to the point > > >> where it is not violated in the foreseeable future. > > > I can't tell whether there is an action here for us. > > > There are two "violations" that exist: > > > 1. Some implementations violate 6790. Not sure > what we can do about > > > that in this document. Note that the entropy > label can help > with this > > > but only to a limited extent since the > implementations that > violate 6790 > > > probably also fail to recognise the entropy label. > > > 2. Implementations that conform to 6790 will > understand that > the XL is > > > a special purpose label and will not use it to > load balance. > But they will > > > not necessarily understand that the next label is > an ESPL that > must be > > > skipped as well. Again, there is nothing we can > do about this > except to > > > note it (done) and possibly to use the EL further > up the stack. > > > > My point was that the may in "It is noted that existing > implementations may > > violate this" was a little soft. Most > implementations, except the > latest > > designs of maybe as few as a single vendor, would > certainly > violate this. > > > > Also of course you are making a statement of fact > and not of > permission > > so I think it may be more precise to say: > > > > It is noted that most existing > > implementations currently violate this, as they do > not look for > the XL > > and thus for ESPLs. > > OK. > > I've gone with... > > It is noted that existing > implementations would violate this, as they do > not recognise XL > as anything other than a single Special > Purpose Label and will > not expect an ESPL to follow. > > [snip] > > > >> Label 7 (when received) retains its meaning > as ELI whether > a regular > > >> special purpose label or an ESPL; this > simplifies a transit > LSR's > > >> task of looking for entropy labels since it > may just look > for label 7 > > >> and need not verify that the previous label > in the stack is > not the > > >> XL 15. However, an LSR wishing to insert an > entropy label > SHOULD > > >> insert label 7 as a regular special purpose > label, not as > an ESPL. > > >> > > >> Why is this not a MUST! There is no ESPL in the > wild running an > > >> alternate behaviour, so why not simply mandate this? > > > If this was a MUST then there would be no case > for handling > Label 7 after > XL. > > > There was some concern I believe that > implementations might > have a path that > > > puts them on to XL insertion processing and then > consider what > to do next. > At > > > that point they might decide that label 7 is needed. > > > > > > It seems esoteric, but I couldn't see a reason to > prohibit it. > > > > > > Maybe "MUST NOT include" and "SHOULD process when > received" are > > > compatible. > > > > > > Part of me hates the idea of this change just > because I don't > want another > > > working group last call before we can move > forward. How > important is it? > > > > The reason to be stricter at the TX is that the > forwarding path > can be > > simpler at the RX. I cannot see how you would get > to the point of > putting > > in L15 and then saying "you know I need to put in L7" > particularly as no > > other 0..15 is allowed. > > Normally I would think that you would put in the > compound label > as a pair > > and that is a good reason to use the compound label > concept. > > > > Also I see no reason for the inconsistency between > L7 and all of the > > other L0..L15 cases. > > > > So I think that it's OK, but probably silly to > allow L0..L15, but > to allow > > the exception of just L7 just complicates things > without good cause. > > I'm not in a position to argue on this one as the > debate and text > were driven by > others. > > I believe that the claim was that allowing L7 to be > inserted > anywhere made > processing it easier not harder at the receiver. > Note that {XL,7} would be an error case in your way of > looking at > things so the > receiver should (must?) not process it. > But the claim was that h/w will simply search the > stack for L7 so > that allowing > {L7} and {XL, L7} to be treated in the same way made > life easier for > the h/w. > > Bottom line, however, seems to be that you have a > preference for > doing it one > way, and the WG has a preference for doing it a > different way. How > to resolve > that? > > Given the posting deadline, I've not made any change > for this. We > can continue > to discuss. > > > >> ======== > > >> > > >> 3.2. Process for Retiring Special Purpose Labels > > [snip] > > > >> Secondly I think the timescales are ridiculously > optimistic. > To get > > >> a label out of circulation in 24 months seems > most unlikely. Also > > >> 6 month checks is a lot of work. > > >> > > >> A more realistic schedule would be to poll at > 12month > intervals until > > >> such time as it is determined that reallocation > would do not > harm and > > >> then give a further 12 months notice. > > > Erm, that's what the text says, I think... > > > > > > 12 months after the RFC deprecating the > label value is > published, > > > an IETF-wide survey may be conducted to > determine if the > > > deprecated label value is still in use. > > > > > > The "may" in that means that the earliest you can > "poll" is 12 > months after > the > > > deprecation RFC is published (noting that the RFC > won't even > get published > > > until lots of discussion and consensus to deprecate). > > > Then, *if* the poll response is OK, and then not > earlier than > 24 months > after > > > the deprecation RFC is published, publication can > be requested > for a new RFC > > > (which means that the WG has already reached > consensus, and that a > > > subsequent IETF last call will be held). > > > > > > Frankly, I think that this process is only likely > to be > executed for SPLs > that > > > are allocated "in error", because other stuff > will probably be > in the field. > Can > > > you think of a label that was allocated in error? > I can :-) > > > > This seems like a lot of text to specify in detail > something we > would never > > run. In protocols, including this type of protocol, > the fewer > words used to > > describe the rarely executed exception path the better. > > The case was considered worthy of inclusion because > the SPL range is > so small. > If any SPL can be reclaimed at some future time it > will be very > valuable and so > a mechanism needs to be documented against that happy day. > > [snip] > > >> =========== > [snip] > > >> However that brings me to > > >> suggest that you probably need to write an OPs > section and > > >> you might want to think about the PM > implications of the extra > > >> metatdata in the packets. > > > > > > What OPS issues had you in mind that need to be > addressed? I am > a fan of OPS > > > sections, but not a fan of empty OPS sections, > and when we > looked through > > > RFC 6123 (which is my favourite crib for what to > describe wrt > manageability) > we > > > didn't see anything that has changed from > pre-existing MPLS. > > > > > > What metadata are you talking about? Is an > existing special > purpose label > > > metadata? If so, the PM issues are pre-existing. > Is there > something special > > > introduced by this I-D that constitutes metadata? > > > > Well what follows an XL is certainly metadata, and > one application is > > certainly to introduce tags that would alert the PM > devices to > take an > > interest. > > OK it is a form of metadata as existing SPLs are metadata. > The XL alerts a DPI that an ESPL follows, and an SPL > alerts the DPI > that the SPL > is there. > What has changed? > We could certainly sit down and write an I-D about the > implications > of using > MPLS in an environment where PM might be present (BTW, > I assume this is > Pervasive Monitoring. Would be embarrassing to find > you meant > something else > :-). I think such an I-D would discuss SPLs as > indicative metadata > and would > then note that ESPLs are in the same category. > Is *this* the I-D in which to have that discussion? > > [snip] > > I'll post the revised I-D in a few minutes and others > can throw > vegetables > (rotten or otherwise). > > Adrian > > _______________________________________________ > mpls mailing list > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > _______________________________________________ > 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 --------------090909090108090705030007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This has me worried.

Assume that nothing implements ESPL yet, there is no reason why
all SPL implementations are not required to send L7 only as
a regular (single) SPL. As Loa says, this would be a useful
simplification, and one which I raised earlier with the authors.

If that is the case, a parser will always get it right.

The only problem I see is if a compound label is ever created
L15, Lx, <0..maxLabel> but one one has defined such an
Lx and to do so would be unwise.

So I don't think Alia is correct in her proposed text change and
I have yet to see a valid technical reason for not accepting Loa's
proposed change.

- Stewart


On 15/02/2014 17:09, Alia Atlas wrote:
[+ietf]

Loa,

To clarify a bit better, what I'm trying to get clarified into the text is why the ELI value as an ESPL
needs to be an exception (as the draft indicates).  I believe it is because forbidding an ESPL of 7
can break some existing and deployed versions of RFC 6790 such that the transit traffic flows are affected.
There may also be implementations of RFC 6790 that aren't affected.

Regards,
Alia


On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas <akatlas@gmail.com> wrote:
Loa,

On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson <loa@pi.nu> wrote:
Alia,

Two comments on this.

First a nit "An LSR wishing to insert an ...", LSR are boxes and can't
wish anything for themselves, a Simple change would be "When an LSR
insert..."

Actually the same is true for the current text and should be changed the
same way.

[Alia] Sure - I took the original text and modified it. 

Second, and this is maybe more tricky - the reason given "simplify the
data plane implementation" is not true and might even be wrong.
The reason put always using the ELI as a "regular special purpose label"
is backwards compatibility.
I would claim that the treatment of the ELI is an (well motivated)
exception, but exceptions always mean that things get more complicated.

[Alia] There were three purposes to my suggested text change.  First, to specify that
an LSR MUST NOT insert the ELI as an ESPL.   Second, to say that a receiving LSR
MAY choose to not discard a packet with the ELI as an ESPL.  Third, I wanted to see
a clearer justification for why this exception is worth making.

[Alia] Since the whole draft is about a data-plane change, what we've been putting in doesn't
really articulate the full problem.  Prelim text would around that would be better as:

"ELI is an exception because each LSR examines the whole label stack to see if the ELI
appears; pre-existing implementations of [Entropy-Label] do this examination without verifying
that the label above the ELI is not XL.  If a packet used an ESPL of 7 and that did not mean
ELI, then when that packet transited deployed LSRs, which implement [Entropy-Label] and not this document, 
the meaning of the ESPL would be misinterpreted.  Such a misinterpretation could result in poor traffic behavior (large flows,
reordered flows, etc.) depending on the label after the ESPL of 7.  It is to avoid such issues that ELI is defined as an exception
that can appear as an regular special label or as an ESPL with the same value of 7."
 
What do you think?

Alia

I don't want to propose a final text,but something along these lines:


"Label 7 (when received) retains its meaning as ELI whether a
 regular special purpose label or an ESPL; this is because of backwards
 compatibility with existing implemented and deployed code and hardware
 that looks for the ELI without verifying if the previous label
 is XL or not. However, when an LSR insert an entropy label it SHOULD
 insert the ELI as a regular special purpose label, not as an ESPL."

/Loa


On 2014-02-15 10:52, Alia Atlas wrote:
Adrian and others,

Having reviewed the 05 of this draft and this thread, I have the
following suggestions.  Other than these, I'm quite happy with how this
draft has improved.

a) In Sec 3.1, the following paragraph could be updated from:

"Label 7 (when received) retains its meaning as ELI whether a
regular special purpose label or an ESPL; this simplifies a transit
LSR's task of looking for entropy labels since it may just look for
label 7  and need not verify that the previous label in the stack is not
the XL 15. However, an LSR wishing to insert an entropy label SHOULD
insert label 7 as a regular special purpose label, not as an ESPL."


to:


"An LSR wishing to insert an entropy label MUST insert label value 7 (meaning ELI) as a regular special purpose

label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data plane.  However, to simplify


the data plane implementation for Entropy Labels, an implementation MAY

interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, an implementation

MAY choose to not treat the packet as malformedand thus discard it.  The data plane simplification thus enabled


is the ability to determine if any label value is 7 without needing to verify that the previous label in the stack is not the XL value of 15."


b)In Sec 3.2: "An RFC with at  least Informational status is required."   How is this different from IETF Review in RFC 5226?  Do BCPs count? What is "at least Informational status"?



On the concern about Pervasive Monitoring, the only advantage that (XL,
ESPL) offers is that the labels wouldn't (eventually) be hashed for
load-balancing.  Otherwise, the label stack offers the ability for
meta-data already where only the receiver would need to understand it.
  Consistent paths are very useful, but there are other ways of doing
this already - with the most trivial being just using label 15.  I have
a hard time seeing this as a new attack vector (but I'm not
professionally paranoid yet).

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <adrian@olddog.co.uk
<mailto:adrian@olddog.co.uk>> wrote:

    [snip]

     > >> XL   The Extension Label that indicates that an extended special
     > >>         purpose label follows.
     > >>
     > >> ESPL An Extended Special Purpose Label.
     > >>
     > >> Something that I think would be worthwhile clarifying right at the
     > >> front is that a label is an ESPL IFF it is preceded by an XL.
     > >> It might even be worth noting that really we have a new label
    type:
     > >> a label couple in which the first label defines the type of the
     > >> second label and neither are of any use as individual labels.
     > > I can see how you would see this as a new label type. Maybe
    "compound"
     > > rather than "couple".
     > > However, I am not convinced that it is new that one label leads
    to the
    semantics
     > > of the next (for example the entropy label).
     > > What is more, I am not sure that there will be more than this
    instance of
    this
     > > type of tight coupling.
     > > So I would rather leave this point out.
     > I can foresee other cases where we might use label pairs to
    mitigate the
     > 20bit limit. I am sure it has been discussed, so creating the
    reference
     > might be useful. Just because this was not done in EL, does not
    mean that
     > we should not set down the concept here.
     >
     > However I agree compound would be a better term.
     >
     > >
     > > But as to clarifying ESPL: yes.
     > > The XP definition is, I think, clear.
     > > How about...
     > >
     > > ESPL An Extended Special Purpose Label. A Special Purpose Label
    that
     > >       is placed in the label stack after the Extension Label.
     >
     > Yes. Indeed it MUST be placed be placed there, however the definition
     > above is fine.

    OK, I updated to...

        ESPL An Extended Special Purpose Label. A Special Purpose Label that
             is placed in the label stack after the Extension Label.  The
             combination of XL and ESPL might be regarded as a new form of
             "compound label" comprising more than one consecutive entry in
             the label stack.

    ..to cover your other point as well.

     > >> ======
     > >>
     > >> I think that the draft will need to provide some guidance
     > >> on when to allocate a 0..15 and when to allocate an ESPL.
     > >>
     > >> I imagine that a 0..15 should only be used when it can be shown
     > >> that the extra stack space of forwarding time is burdensome
     > >> but that is a question that the WG should explicitly consider.
     > > We discussed this at some point on the MPLS list (many
    centuries ago, I
    think)
     > > and reached no conclusion.
     > > The primary purpose of the XL is to handle the time when 0..15
    is depleted.
     > > You're right that we could encourage people to start using
    ESPLs now before
     > > 0..15 is depleted. But it is hard to make the case for
    requiring it when
    there
     > > is still some of 0..15 available and the rate of burn is not so
    high.
     > >
     > > We could put in some text like...
     > >
     > > When allocating a new Special Purpose Label, protocol designers
    should
     > > consider whether they could, instead, use an Extended Special
    Purpose
     > > Label. Doing so would help to preserve the scarce resources of
    Special
     > > Purpose Labels for use in cases where minimizing the label
    stack size is
     > > particularly important.
     >
     > That would be useful text.

    Added as new section 3.1.2 with slight tweak to wording.

    [snip]

     > >>     6.  [RFC6790] says that special purpose labels MUST NOT be
    used for
     > >>        load balancing.  The same logic applies to extended special
     > >>        purpose labels (ESPLs).  Thus, this document specifies
    that ESPLs
     > >>        MUST NOT be used for load balancing.  It is noted that
    existing
     > >>        implementations may violate this, as they do not look
    for the XL
     > >>        and thus for ESPLs.  The consequence is that if ESPLs
    are used in
     > >>        some packets of a flow, these packets may be delivered on
     > >>        different paths and so could be re-ordered.  However, it is
     > >>        important to specify the correct behavior for future
     > >>        implementations, hence the use of "MUST NOT".
     > >>
     > >> I would suggest that most implementations do violate this. I would
     > >> also suggest that it seems unlikely that you will get to the point
     > >> where it is not violated in the foreseeable future.
     > > I can't tell whether there is an action here for us.
     > > There are two "violations" that exist:
     > > 1. Some implementations violate 6790. Not sure what we can do about
     > > that in this document. Note that the entropy label can help
    with this
     > > but only to a limited extent since the implementations that
    violate 6790
     > > probably also fail to recognise the entropy label.
     > > 2. Implementations that conform to 6790 will understand that
    the XL is
     > > a special purpose label and will not use it to load balance.
    But they will
     > > not necessarily understand that the next label is an ESPL that
    must be
     > > skipped as well. Again, there is nothing we can do about this
    except to
     > > note it (done) and possibly to use the EL further up the stack.
     >
     > My point was that the may in "It is noted that existing
    implementations may
     > violate this" was a little soft. Most implementations, except the
    latest
     > designs of maybe as few as a single vendor, would certainly
    violate this.
     >
     > Also of course you are making a statement of fact and not of
    permission
     > so I think it may be more precise to say:
     >
     > It is noted that most existing
     > implementations currently violate this, as they do not look for
    the XL
     > and thus for ESPLs.

    OK.

    I've gone with...

            It is noted that existing
            implementations would violate this, as they do not recognise XL
            as anything other than a single Special Purpose Label and will
            not expect an ESPL to follow.

    [snip]

     > >>    Label 7 (when received) retains its meaning as ELI whether
    a regular
     > >>    special purpose label or an ESPL; this simplifies a transit
    LSR's
     > >>    task of looking for entropy labels since it may just look
    for label 7
     > >>    and need not verify that the previous label in the stack is
    not the
     > >>    XL 15.  However, an LSR wishing to insert an entropy label
    SHOULD
     > >>    insert label 7 as a regular special purpose label, not as
    an ESPL.
     > >>
     > >> Why is this not a MUST! There is no ESPL in the wild running an
     > >> alternate behaviour, so why not simply mandate this?
     > > If this was a MUST then there would be no case for handling
    Label 7 after
    XL.
     > > There was some concern I believe that implementations might
    have a path that
     > > puts them on to XL insertion processing and then consider what
    to do next.
    At
     > > that point they might decide that label 7 is needed.
     > >
     > > It seems esoteric, but I couldn't see a reason to prohibit it.
     > >
     > > Maybe "MUST NOT include" and "SHOULD process when received" are
     > > compatible.
     > >
     > > Part of me hates the idea of this change just because I don't
    want another
     > > working group last call before we can move forward. How
    important is it?
     >
     > The reason to be stricter at the TX is that the forwarding path
    can be
     > simpler at the RX. I cannot see how you would get to the point of
    putting
     > in L15 and then saying "you know I need to put in L7"
    particularly as no
     > other 0..15 is allowed.
     > Normally I would think that you would put in the compound label
    as a pair
     > and that is a good reason to use the compound label concept.
     >
     > Also I see no reason for the inconsistency between L7 and all of the
     > other L0..L15 cases.
     >
     > So I think that it's OK, but probably silly to allow L0..L15, but
    to allow
     > the exception of just L7 just complicates things without good cause.

    I'm not in a position to argue on this one as the debate and text
    were driven by
    others.

    I believe that the claim was that allowing L7 to be inserted
    anywhere made
    processing it easier not harder at the receiver.
    Note that {XL,7} would be an error case in your way of looking at
    things so the
    receiver should (must?) not process it.
    But the claim was that h/w will simply search the stack for L7 so
    that allowing
    {L7} and {XL, L7} to be treated in the same way made life easier for
    the h/w.

    Bottom line, however, seems to be that you have a preference for
    doing it one
    way, and the WG has a preference for doing it a different way. How
    to resolve
    that?

    Given the posting deadline, I've not made any change for this. We
    can continue
    to discuss.

     > >> ========
     > >>
     > >> 3.2.  Process for Retiring Special Purpose Labels

    [snip]

     > >> Secondly I think the timescales are ridiculously optimistic.
    To get
     > >> a label out of circulation in 24 months seems most unlikely. Also
     > >> 6 month checks is a lot of work.
     > >>
     > >> A more realistic schedule would be to poll at 12month
    intervals until
     > >> such time as it is determined that reallocation would do not
    harm and
     > >> then give a further 12 months notice.
     > > Erm, that's what the text says, I think...
     > >
     > >         12 months after the RFC deprecating the label value is
    published,
     > >         an IETF-wide survey may be conducted to determine if the
     > >         deprecated label value is still in use.
     > >
     > > The "may" in that means that the earliest you can "poll" is 12
    months after
    the
     > > deprecation RFC is published (noting that the RFC won't even
    get published
     > > until lots of discussion and consensus to deprecate).
     > > Then, *if* the poll response is OK, and then not earlier than
    24 months
    after
     > > the deprecation RFC is published, publication can be requested
    for a new RFC
     > > (which means that the WG has already reached consensus, and that a
     > > subsequent IETF last call will be held).
     > >
     > > Frankly, I think that this process is only likely to be
    executed for SPLs
    that
     > > are allocated "in error", because other stuff will probably be
    in the field.
    Can
     > > you think of a label that was allocated in error? I can :-)
     >
     > This seems like a lot of text to specify in detail something we
    would never
     > run. In protocols, including this type of protocol, the fewer
    words used to
     > describe the rarely executed exception path the better.

    The case was considered worthy of inclusion because the SPL range is
    so small.
    If any SPL can be reclaimed at some future time it will be very
    valuable and so
    a mechanism needs to be documented against that happy day.

    [snip]
     > >> ===========
    [snip]
     > >> However that brings me to
     > >> suggest that you probably need to write an OPs section and
     > >> you might want to think about the PM implications of the extra
     > >> metatdata in the packets.
     > >
     > > What OPS issues had you in mind that need to be addressed? I am
    a fan of OPS
     > > sections, but not a fan of empty OPS sections, and when we
    looked through
     > > RFC 6123 (which is my favourite crib for what to describe wrt
    manageability)
    we
     > > didn't see anything that has changed from pre-existing MPLS.
     > >
     > > What metadata are you talking about? Is an existing special
    purpose label
     > > metadata? If so, the PM issues are pre-existing. Is there
    something special
     > > introduced by this I-D that constitutes metadata?
     >
     > Well what follows an XL is certainly metadata, and one application is
     > certainly to introduce tags that would alert the PM devices to
    take an
     > interest.

    OK it is a form of metadata as existing SPLs are metadata.
    The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI
    that the SPL
    is there.
    What has changed?
    We could certainly sit down and write an I-D about the implications
    of using
    MPLS in an environment where PM might be present (BTW, I assume this is
    Pervasive Monitoring. Would be embarrassing to find you meant
    something else
    :-). I think such an I-D would discuss SPLs as indicative metadata
    and would
    then note that ESPLs are in the same category.
    Is *this* the I-D in which to have that discussion?

    [snip]

    I'll post the revised I-D in a few minutes and others can throw
    vegetables
    (rotten or otherwise).

    Adrian

    _______________________________________________
    mpls mailing list
    mpls@ietf.org <mailto:mpls@ietf.org>
    https://www.ietf.org/mailman/listinfo/mpls





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


--


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




_______________________________________________
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
--------------090909090108090705030007-- From nobody Tue Feb 18 06:50: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 AE8F41A01F5 for ; Tue, 18 Feb 2014 06:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 jse0_StG2XBh for ; Tue, 18 Feb 2014 06:50:31 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26C1A03DC for ; Tue, 18 Feb 2014 06:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1047; q=dns/txt; s=iport; t=1392735029; x=1393944629; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8yo3eu8c89Kzivn183Eom6T1LvfA96elcO07hc9lTKU=; b=VeguAyGDSNjYBhh8TIupNaKSY+pYkjZVk7S+ysZlPzbiTEg7XEZnVUUR aLWDVoVwSGWsutxWLx9Y4ImGffRVY0mYh9MlgW8NojNJhj1K1fYgFQ3Xc iT/3O+2Ca/+ZheS864WG5TKwUqMOtDfV/e9CVXuWAhpRJ2cnnRBxs4gb5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAB5yA1OQ/khM/2dsb2JhbABZgwa9VYMKgRgWdIIlAQEBBDhAARALGAkWDwkDAgECAUUGAQwBBwEBiAHLexeOMAEBTweEOAEDmCySI4MtgXE X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="5399587" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 18 Feb 2014 14:50:28 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1IEoRm0030824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 14:50:27 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1IEoQNR012390; Tue, 18 Feb 2014 14:50:27 GMT Message-ID: <53037332.8040208@cisco.com> Date: Tue, 18 Feb 2014 14:50:26 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Loa Andersson , Alia Atlas References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> <53008A8B.4040605@pi.nu> In-Reply-To: <53008A8B.4040605@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/35_CVskyqHSxUFLMoqWFMxEJZXE Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels 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, 18 Feb 2014 14:50:37 -0000 On 16/02/2014 09:53, Loa Andersson wrote: > Alia, > > Of course I can take a spin on the text, once I'm convinced this is > necessary and useful. > > Reading things a third or fourth time, I still think that the text > Adrian had in the draft is the best so far. > > However, the draft is now in ietf last call, and wisdom says that we > shall not change documents while they are in last call. We have at least > two weeks to discuss this and converge on what we want to change if > anything. > > My point is that there no other reason that the ELI is an exception than > that we have running code (that were standards compatible when > implemented) that breaks if we don't make the exception. > > /Loa Yes, but! I don't see how forbidding the extended version of L7 can possibly break anything. The only think it could break is a pre-standards version of the extended label that used this format. However it is unreasonable for the existing code to place a burden of complexity on all future implementations. Stewart From nobody Tue Feb 18 06:55: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 14B411A04FE for ; Tue, 18 Feb 2014 06:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 9bbIbHOWDsC7 for ; Tue, 18 Feb 2014 06:55:26 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DF59C1A0200 for ; Tue, 18 Feb 2014 06:55:25 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id f73so15543957yha.17 for ; Tue, 18 Feb 2014 06:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r51Rk/rjzvnEyissXpg7QNqf7Z4EGi42cf7aQHdx7zE=; b=zM9Ii08D4dwhVu8hQFAJaVpc+9FZEw93cLunAVcHQ1UkiNu3lXGvJDVQ6behHE9Jqj +d6Ee9JtOOqWEdMygCt1gl/1ZZpxNbf5sN/376XysYmb5DUujPTC8Gu+xS4OEDJXTq5/ FRuQMv6v9MsD+IU2is/dQaUVA8UegiOLcZmLTM1tVunflPI8tANIOC+CJUOqGLZeylcN b2J994iLrpwYrAdYhWJvHov3xvS0dKLJoo9gjxJCkWrmhiAkjnTlOCW8u5FY0Qt9YrOV p+gs1cbHrv6OBqtfFczBkrhdkaEPY+udiu3EVGg6COkHQOnj4OKd3bKEW6P5/s00Jt1+ Ta+Q== MIME-Version: 1.0 X-Received: by 10.236.135.172 with SMTP id u32mr4384037yhi.107.1392735322857; Tue, 18 Feb 2014 06:55:22 -0800 (PST) Received: by 10.170.194.140 with HTTP; Tue, 18 Feb 2014 06:55:22 -0800 (PST) In-Reply-To: <5303725C.6070007@cisco.com> References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> <5303725C.6070007@cisco.com> Date: Tue, 18 Feb 2014 09:55:22 -0500 Message-ID: From: Alia Atlas To: Stewart Bryant Content-Type: multipart/alternative; boundary=20cf301af7732f63a304f2af768a Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/f-NiuxRsUVZ4wq3yN0_2shLC_vc Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 14:55:31 -0000 --20cf301af7732f63a304f2af768a Content-Type: text/plain; charset=ISO-8859-1 Stewart, If you think that Loa's text is sufficiently strong about not sending XL, ESPL, then I am fine with his text. I was striving for more clarity on why the exception was made and suggesting MUST rather than SHOULD. Loa's text says: ""Label 7 (when received) retains its meaning as ELI whether a regular special purpose label or an ESPL; this is because of backwards >> compatibility with existing implemented and deployed code and hardware >> that looks for the ELI without verifying if the previous label >> is XL or not. However, when an LSR insert an entropy label it SHOULD >> insert the ELI as a regular special purpose label, not as an ESPL." > > This doesn't explain that bad traffic side-effects could happen, but I think the wording for why the exception is there is clear. Alia On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant wrote: > This has me worried. > > Assume that nothing implements ESPL yet, there is no reason why > all SPL implementations are not required to send L7 only as > a regular (single) SPL. As Loa says, this would be a useful > simplification, and one which I raised earlier with the authors. > > If that is the case, a parser will always get it right. > > The only problem I see is if a compound label is ever created > L15, Lx, <0..maxLabel> but one one has defined such an > Lx and to do so would be unwise. > > So I don't think Alia is correct in her proposed text change and > I have yet to see a valid technical reason for not accepting Loa's > proposed change. > > - Stewart > > > On 15/02/2014 17:09, Alia Atlas wrote: > > [+ietf] > > Loa, > > To clarify a bit better, what I'm trying to get clarified into the text > is why the ELI value as an ESPL > needs to be an exception (as the draft indicates). I believe it is > because forbidding an ESPL of 7 > can break some existing and deployed versions of RFC 6790 such that the > transit traffic flows are affected. > There may also be implementations of RFC 6790 that aren't affected. > > Regards, > Alia > > > On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas wrote: > >> Loa, >> >> On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson wrote: >> >>> Alia, >>> >>> Two comments on this. >>> >>> First a nit "An LSR wishing to insert an ...", LSR are boxes and can't >>> wish anything for themselves, a Simple change would be "When an LSR >>> insert..." >>> >>> Actually the same is true for the current text and should be changed the >>> same way. >>> >> >> [Alia] Sure - I took the original text and modified it. >> >> Second, and this is maybe more tricky - the reason given "simplify the >>> data plane implementation" is not true and might even be wrong. >>> The reason put always using the ELI as a "regular special purpose label" >>> is backwards compatibility. >>> I would claim that the treatment of the ELI is an (well motivated) >>> exception, but exceptions always mean that things get more complicated. >>> >> >> [Alia] There were three purposes to my suggested text change. First, >> to specify that >> an LSR MUST NOT insert the ELI as an ESPL. Second, to say that a >> receiving LSR >> MAY choose to not discard a packet with the ELI as an ESPL. Third, I >> wanted to see >> a clearer justification for why this exception is worth making. >> >> [Alia] Since the whole draft is about a data-plane change, what we've >> been putting in doesn't >> really articulate the full problem. Prelim text would around that would >> be better as: >> >> "ELI is an exception because each LSR examines the whole label stack to >> see if the ELI >> appears; pre-existing implementations of [Entropy-Label] do this >> examination without verifying >> that the label above the ELI is not XL. If a packet used an ESPL of 7 >> and that did not mean >> ELI, then when that packet transited deployed LSRs, which implement >> [Entropy-Label] and not this document, >> the meaning of the ESPL would be misinterpreted. Such a >> misinterpretation could result in poor traffic behavior (large flows, >> reordered flows, etc.) depending on the label after the ESPL of 7. It is >> to avoid such issues that ELI is defined as an exception >> that can appear as an regular special label or as an ESPL with the same >> value of 7." >> >> What do you think? >> >> Alia >> >> I don't want to propose a final text,but something along these lines: >>> >>> >>> "Label 7 (when received) retains its meaning as ELI whether a >>> regular special purpose label or an ESPL; this is because of backwards >>> compatibility with existing implemented and deployed code and hardware >>> that looks for the ELI without verifying if the previous label >>> is XL or not. However, when an LSR insert an entropy label it SHOULD >>> insert the ELI as a regular special purpose label, not as an ESPL." >>> >>> /Loa >>> >>> >>> On 2014-02-15 10:52, Alia Atlas wrote: >>> >>>> Adrian and others, >>>> >>>> Having reviewed the 05 of this draft and this thread, I have the >>>> following suggestions. Other than these, I'm quite happy with how this >>>> draft has improved. >>>> >>>> a) In Sec 3.1, the following paragraph could be updated from: >>>> >>>> "Label 7 (when received) retains its meaning as ELI whether a >>>> regular special purpose label or an ESPL; this simplifies a transit >>>> LSR's task of looking for entropy labels since it may just look for >>>> label 7 and need not verify that the previous label in the stack is not >>>> the XL 15. However, an LSR wishing to insert an entropy label SHOULD >>>> insert label 7 as a regular special purpose label, not as an ESPL." >>>> >>>> >>>> to: >>>> >>>> >>>> "An LSR wishing to insert an entropy label MUST insert label value 7 >>>> (meaning ELI) as a regular special purpose >>>> >>>> label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the >>>> data plane. However, to simplify >>>> >>>> >>>> the data plane implementation for Entropy Labels, an implementation MAY >>>> >>>> interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and >>>> 8-15, an implementation >>>> >>>> MAY choose to not treat the packet as malformedand thus discard it. >>>> The data plane simplification thus enabled >>>> >>>> >>>> is the ability to determine if any label value is 7 without needing to >>>> verify that the previous label in the stack is not the XL value of 15." >>>> >>>> >>>> b)In Sec 3.2: "An RFC with at least Informational status is >>>> required." How is this different from IETF Review in RFC 5226? Do BCPs >>>> count? What is "at least Informational status"? >>>> >>>> >>>> >>>> On the concern about Pervasive Monitoring, the only advantage that (XL, >>>> ESPL) offers is that the labels wouldn't (eventually) be hashed for >>>> load-balancing. Otherwise, the label stack offers the ability for >>>> meta-data already where only the receiver would need to understand it. >>>> Consistent paths are very useful, but there are other ways of doing >>>> this already - with the most trivial being just using label 15. I have >>>> a hard time seeing this as a new attack vector (but I'm not >>>> professionally paranoid yet). >>>> >>>> Alia >>>> >>>> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel >>> > wrote: >>>> >>>> [snip] >>>> >>>> > >> XL The Extension Label that indicates that an extended >>>> special >>>> > >> purpose label follows. >>>> > >> >>>> > >> ESPL An Extended Special Purpose Label. >>>> > >> >>>> > >> Something that I think would be worthwhile clarifying right >>>> at the >>>> > >> front is that a label is an ESPL IFF it is preceded by an XL. >>>> > >> It might even be worth noting that really we have a new label >>>> type: >>>> > >> a label couple in which the first label defines the type of >>>> the >>>> > >> second label and neither are of any use as individual labels. >>>> > > I can see how you would see this as a new label type. Maybe >>>> "compound" >>>> > > rather than "couple". >>>> > > However, I am not convinced that it is new that one label leads >>>> to the >>>> semantics >>>> > > of the next (for example the entropy label). >>>> > > What is more, I am not sure that there will be more than this >>>> instance of >>>> this >>>> > > type of tight coupling. >>>> > > So I would rather leave this point out. >>>> > I can foresee other cases where we might use label pairs to >>>> mitigate the >>>> > 20bit limit. I am sure it has been discussed, so creating the >>>> reference >>>> > might be useful. Just because this was not done in EL, does not >>>> mean that >>>> > we should not set down the concept here. >>>> > >>>> > However I agree compound would be a better term. >>>> > >>>> > > >>>> > > But as to clarifying ESPL: yes. >>>> > > The XP definition is, I think, clear. >>>> > > How about... >>>> > > >>>> > > ESPL An Extended Special Purpose Label. A Special Purpose Label >>>> that >>>> > > is placed in the label stack after the Extension Label. >>>> > >>>> > Yes. Indeed it MUST be placed be placed there, however the >>>> definition >>>> > above is fine. >>>> >>>> OK, I updated to... >>>> >>>> ESPL An Extended Special Purpose Label. A Special Purpose Label >>>> that >>>> is placed in the label stack after the Extension Label. >>>> The >>>> combination of XL and ESPL might be regarded as a new form >>>> of >>>> "compound label" comprising more than one consecutive >>>> entry in >>>> the label stack. >>>> >>>> ..to cover your other point as well. >>>> >>>> > >> ====== >>>> > >> >>>> > >> I think that the draft will need to provide some guidance >>>> > >> on when to allocate a 0..15 and when to allocate an ESPL. >>>> > >> >>>> > >> I imagine that a 0..15 should only be used when it can be >>>> shown >>>> > >> that the extra stack space of forwarding time is burdensome >>>> > >> but that is a question that the WG should explicitly consider. >>>> > > We discussed this at some point on the MPLS list (many >>>> centuries ago, I >>>> think) >>>> > > and reached no conclusion. >>>> > > The primary purpose of the XL is to handle the time when 0..15 >>>> is depleted. >>>> > > You're right that we could encourage people to start using >>>> ESPLs now before >>>> > > 0..15 is depleted. But it is hard to make the case for >>>> requiring it when >>>> there >>>> > > is still some of 0..15 available and the rate of burn is not so >>>> high. >>>> > > >>>> > > We could put in some text like... >>>> > > >>>> > > When allocating a new Special Purpose Label, protocol designers >>>> should >>>> > > consider whether they could, instead, use an Extended Special >>>> Purpose >>>> > > Label. Doing so would help to preserve the scarce resources of >>>> Special >>>> > > Purpose Labels for use in cases where minimizing the label >>>> stack size is >>>> > > particularly important. >>>> > >>>> > That would be useful text. >>>> >>>> Added as new section 3.1.2 with slight tweak to wording. >>>> >>>> [snip] >>>> >>>> > >> 6. [RFC6790] says that special purpose labels MUST NOT be >>>> used for >>>> > >> load balancing. The same logic applies to extended >>>> special >>>> > >> purpose labels (ESPLs). Thus, this document specifies >>>> that ESPLs >>>> > >> MUST NOT be used for load balancing. It is noted that >>>> existing >>>> > >> implementations may violate this, as they do not look >>>> for the XL >>>> > >> and thus for ESPLs. The consequence is that if ESPLs >>>> are used in >>>> > >> some packets of a flow, these packets may be delivered >>>> on >>>> > >> different paths and so could be re-ordered. However, >>>> it is >>>> > >> important to specify the correct behavior for future >>>> > >> implementations, hence the use of "MUST NOT". >>>> > >> >>>> > >> I would suggest that most implementations do violate this. I >>>> would >>>> > >> also suggest that it seems unlikely that you will get to the >>>> point >>>> > >> where it is not violated in the foreseeable future. >>>> > > I can't tell whether there is an action here for us. >>>> > > There are two "violations" that exist: >>>> > > 1. Some implementations violate 6790. Not sure what we can do >>>> about >>>> > > that in this document. Note that the entropy label can help >>>> with this >>>> > > but only to a limited extent since the implementations that >>>> violate 6790 >>>> > > probably also fail to recognise the entropy label. >>>> > > 2. Implementations that conform to 6790 will understand that >>>> the XL is >>>> > > a special purpose label and will not use it to load balance. >>>> But they will >>>> > > not necessarily understand that the next label is an ESPL that >>>> must be >>>> > > skipped as well. Again, there is nothing we can do about this >>>> except to >>>> > > note it (done) and possibly to use the EL further up the stack. >>>> > >>>> > My point was that the may in "It is noted that existing >>>> implementations may >>>> > violate this" was a little soft. Most implementations, except the >>>> latest >>>> > designs of maybe as few as a single vendor, would certainly >>>> violate this. >>>> > >>>> > Also of course you are making a statement of fact and not of >>>> permission >>>> > so I think it may be more precise to say: >>>> > >>>> > It is noted that most existing >>>> > implementations currently violate this, as they do not look for >>>> the XL >>>> > and thus for ESPLs. >>>> >>>> OK. >>>> >>>> I've gone with... >>>> >>>> It is noted that existing >>>> implementations would violate this, as they do not >>>> recognise XL >>>> as anything other than a single Special Purpose Label and >>>> will >>>> not expect an ESPL to follow. >>>> >>>> [snip] >>>> >>>> > >> Label 7 (when received) retains its meaning as ELI whether >>>> a regular >>>> > >> special purpose label or an ESPL; this simplifies a transit >>>> LSR's >>>> > >> task of looking for entropy labels since it may just look >>>> for label 7 >>>> > >> and need not verify that the previous label in the stack is >>>> not the >>>> > >> XL 15. However, an LSR wishing to insert an entropy label >>>> SHOULD >>>> > >> insert label 7 as a regular special purpose label, not as >>>> an ESPL. >>>> > >> >>>> > >> Why is this not a MUST! There is no ESPL in the wild running >>>> an >>>> > >> alternate behaviour, so why not simply mandate this? >>>> > > If this was a MUST then there would be no case for handling >>>> Label 7 after >>>> XL. >>>> > > There was some concern I believe that implementations might >>>> have a path that >>>> > > puts them on to XL insertion processing and then consider what >>>> to do next. >>>> At >>>> > > that point they might decide that label 7 is needed. >>>> > > >>>> > > It seems esoteric, but I couldn't see a reason to prohibit it. >>>> > > >>>> > > Maybe "MUST NOT include" and "SHOULD process when received" are >>>> > > compatible. >>>> > > >>>> > > Part of me hates the idea of this change just because I don't >>>> want another >>>> > > working group last call before we can move forward. How >>>> important is it? >>>> > >>>> > The reason to be stricter at the TX is that the forwarding path >>>> can be >>>> > simpler at the RX. I cannot see how you would get to the point of >>>> putting >>>> > in L15 and then saying "you know I need to put in L7" >>>> particularly as no >>>> > other 0..15 is allowed. >>>> > Normally I would think that you would put in the compound label >>>> as a pair >>>> > and that is a good reason to use the compound label concept. >>>> > >>>> > Also I see no reason for the inconsistency between L7 and all of >>>> the >>>> > other L0..L15 cases. >>>> > >>>> > So I think that it's OK, but probably silly to allow L0..L15, but >>>> to allow >>>> > the exception of just L7 just complicates things without good >>>> cause. >>>> >>>> I'm not in a position to argue on this one as the debate and text >>>> were driven by >>>> others. >>>> >>>> I believe that the claim was that allowing L7 to be inserted >>>> anywhere made >>>> processing it easier not harder at the receiver. >>>> Note that {XL,7} would be an error case in your way of looking at >>>> things so the >>>> receiver should (must?) not process it. >>>> But the claim was that h/w will simply search the stack for L7 so >>>> that allowing >>>> {L7} and {XL, L7} to be treated in the same way made life easier for >>>> the h/w. >>>> >>>> Bottom line, however, seems to be that you have a preference for >>>> doing it one >>>> way, and the WG has a preference for doing it a different way. How >>>> to resolve >>>> that? >>>> >>>> Given the posting deadline, I've not made any change for this. We >>>> can continue >>>> to discuss. >>>> >>>> > >> ======== >>>> > >> >>>> > >> 3.2. Process for Retiring Special Purpose Labels >>>> >>>> [snip] >>>> >>>> > >> Secondly I think the timescales are ridiculously optimistic. >>>> To get >>>> > >> a label out of circulation in 24 months seems most unlikely. >>>> Also >>>> > >> 6 month checks is a lot of work. >>>> > >> >>>> > >> A more realistic schedule would be to poll at 12month >>>> intervals until >>>> > >> such time as it is determined that reallocation would do not >>>> harm and >>>> > >> then give a further 12 months notice. >>>> > > Erm, that's what the text says, I think... >>>> > > >>>> > > 12 months after the RFC deprecating the label value is >>>> published, >>>> > > an IETF-wide survey may be conducted to determine if >>>> the >>>> > > deprecated label value is still in use. >>>> > > >>>> > > The "may" in that means that the earliest you can "poll" is 12 >>>> months after >>>> the >>>> > > deprecation RFC is published (noting that the RFC won't even >>>> get published >>>> > > until lots of discussion and consensus to deprecate). >>>> > > Then, *if* the poll response is OK, and then not earlier than >>>> 24 months >>>> after >>>> > > the deprecation RFC is published, publication can be requested >>>> for a new RFC >>>> > > (which means that the WG has already reached consensus, and >>>> that a >>>> > > subsequent IETF last call will be held). >>>> > > >>>> > > Frankly, I think that this process is only likely to be >>>> executed for SPLs >>>> that >>>> > > are allocated "in error", because other stuff will probably be >>>> in the field. >>>> Can >>>> > > you think of a label that was allocated in error? I can :-) >>>> > >>>> > This seems like a lot of text to specify in detail something we >>>> would never >>>> > run. In protocols, including this type of protocol, the fewer >>>> words used to >>>> > describe the rarely executed exception path the better. >>>> >>>> The case was considered worthy of inclusion because the SPL range is >>>> so small. >>>> If any SPL can be reclaimed at some future time it will be very >>>> valuable and so >>>> a mechanism needs to be documented against that happy day. >>>> >>>> [snip] >>>> > >> =========== >>>> [snip] >>>> > >> However that brings me to >>>> > >> suggest that you probably need to write an OPs section and >>>> > >> you might want to think about the PM implications of the extra >>>> > >> metatdata in the packets. >>>> > > >>>> > > What OPS issues had you in mind that need to be addressed? I am >>>> a fan of OPS >>>> > > sections, but not a fan of empty OPS sections, and when we >>>> looked through >>>> > > RFC 6123 (which is my favourite crib for what to describe wrt >>>> manageability) >>>> we >>>> > > didn't see anything that has changed from pre-existing MPLS. >>>> > > >>>> > > What metadata are you talking about? Is an existing special >>>> purpose label >>>> > > metadata? If so, the PM issues are pre-existing. Is there >>>> something special >>>> > > introduced by this I-D that constitutes metadata? >>>> > >>>> > Well what follows an XL is certainly metadata, and one >>>> application is >>>> > certainly to introduce tags that would alert the PM devices to >>>> take an >>>> > interest. >>>> >>>> OK it is a form of metadata as existing SPLs are metadata. >>>> The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI >>>> that the SPL >>>> is there. >>>> What has changed? >>>> We could certainly sit down and write an I-D about the implications >>>> of using >>>> MPLS in an environment where PM might be present (BTW, I assume >>>> this is >>>> Pervasive Monitoring. Would be embarrassing to find you meant >>>> something else >>>> :-). I think such an I-D would discuss SPLs as indicative metadata >>>> and would >>>> then note that ESPLs are in the same category. >>>> Is *this* the I-D in which to have that discussion? >>>> >>>> [snip] >>>> >>>> I'll post the revised I-D in a few minutes and others can throw >>>> vegetables >>>> (rotten or otherwise). >>>> >>>> Adrian >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64<%2B46%20739%2081%2021%2064> >>> >> >> > > > _______________________________________________ > mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls > > > > -- > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > --20cf301af7732f63a304f2af768a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stewart,

If you think that Loa's te= xt is sufficiently strong about not sending XL, ESPL, then I am fine with h= is text.
I was striving for more clarity on why the exception was made = and suggesting MUST rather than SHOULD.

Loa's text says:

"&qu= ot;Label 7 (when received) retains its meaning as ELI whether a
=A0regular special purpose labe= l or an ESPL; this is because of backwards
=A0compatibility with existing implemented and deployed code and hardware=A0that looks for the ELI without verifying if the previous label
=A0i= s XL or not. However, when an LSR insert an entropy label it SHOULD
=A0i= nsert the ELI as a regular special purpose label, not as an ESPL."
This doesn't explain that bad traffic side-effects could = happen, but I think the wording for why the
exception is there is clear.

Alia


On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant <stbr= yant@cisco.com> wrote:
=20 =20 =20
This has me worried.

Assume that nothing implements ESPL yet, there is no reason why
all SPL implementations are not required to send L7 only as
a regular (single) SPL. As Loa says, this would be a useful
simplification, and one which I raised earlier with the authors.

If that is the case, a parser will always get it right.

The only problem I see is if a compound label is ever created
L15, Lx, <0..maxLabel> but one one has defined such an
Lx and to do so would be unwise.

So I don't think Alia is correct in her proposed text change and<= br> I have yet to see a valid technical reason for not accepting Loa'= s
proposed change.

- Stewart


On 15/02/2014 17:09, Alia Atlas wrote:
=20
[+ietf]

Loa,

To clarify a bit better, what I'm trying to get clarified into the text is why the ELI value as an ESPL
needs to be an exception (as the draft indicates). =A0I believe it is because forbidding an ESPL of 7
can break some existing and deployed versions of RFC 6790 such that the transit traffic flows are affected.
There may also be implementations of RFC 6790 that aren't affected.

Regards,
Alia


On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas <akatlas@gmail.com> wrote:
Loa,

On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson <loa@pi.nu> wrote:
Alia,

Two comments on this.

First a nit "An LSR wishing to insert an ...&q= uot;, LSR are boxes and can't
wish anything for themselves, a Simple change would be "When an LSR
insert..."

Actually the same is true for the current text and should be changed the
same way.

[Alia] Sure - I took the original text and modified it.=A0

Second, and this is maybe more tricky - the reason given "simplify the
data plane implementation" is not true and mig= ht even be wrong.
The reason put always using the ELI as a "regular special purpose label"
is backwards compatibility.
I would claim that the treatment of the ELI is an (well motivated)
exception, but exceptions always mean that things get more complicated.

[Alia] There were three purposes to my suggested text change. =A0First, to specify that
an LSR MUST NOT insert the ELI as an ESPL. =A0 Second, to say that a receiving LSR
MAY choose to not discard a packet with the ELI as an ESPL. =A0Third, I wanted to see
a clearer justification for why this exception is worth making.

[Alia] Since the whole draft is about a data-plane change, what we've been putting in doesn't
really articulate the full problem. =A0Prelim text would around that would be better as:

"ELI is an exception because each LSR examine= s the whole label stack to see if the ELI
appears; pre-existing implementations of [Entropy-Label] do this examination without verifying
that the label above the ELI is not XL. =A0If a packet used an ESPL of 7 and that did not mean
ELI, then when that packet transited deployed LSRs, which implement [Entropy-Label] and not this document,=A0
the meaning of the ESPL would be misinterpreted. =A0Such a misinterpretation could result in poor traffic behavior (large flows,
reordered flows, etc.) depending on the label after the ESPL of 7. =A0It is to avoid such issues that ELI is defined as an exception
that can appear as an regular special label or as an ESPL with the same value of 7."
=A0
What do you think?

Alia

I don't want to propose a final text,but something along these lines:


"Label 7 (when received) retains its meani= ng as ELI whether a
=A0regular special purpose label or an ESPL; this is because of backwards
=A0compatibility with existing implemented and deployed code and hardware
=A0that looks for the ELI without verifying if the previous label
=A0is XL or not. However, when an LSR insert an entropy label it SHOULD
=A0insert the ELI as a regular special purpose label, not as an ESPL."

/Loa


On 2014-02-15 10:52, Alia Atlas wrote:
Adrian and others,

Having reviewed the 05 of this draft and this thread, I have the
following suggestions. =A0Other than these, I'm quite happy with how this
draft has improved.

a) In Sec 3.1, the following paragraph could be updated from:

"Label 7 (when received) retains its meaning as ELI whether a
regular special purpose label or an ESPL; this simplifies a transit
LSR's task of looking for entropy labels since it may just look for
label 7 =A0and need not verify that the previous label in the stack is not
the XL 15. However, an LSR wishing to insert an entropy label SHOULD
insert label 7 as a regular special purpose label, not as an ESPL."


to:


"An LSR wishing to insert an entropy lab= el MUST insert label value 7 (meaning ELI) as a regular special purpose

label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data plane. =A0However, to simplify


the data plane implementation for Entropy Labels, an implementation MAY

interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, an implementation

MAY choose to not treat the packet as malformedand thus discard it. =A0The data plane simplification thus enabled


is the ability to determine if any label value is 7 without needing to verify that the previous label in the stack is not the XL value of 15."


b)In Sec 3.2: "An RFC with at =A0least Informational status is required." =A0 How= is this different from IETF Review in RFC 5226? =A0Do BCPs count? What is "at least Informational status"?



On the concern about Pervasive Monitoring, the only advantage that (XL,
ESPL) offers is that the labels wouldn't (eventually) be hashed for
load-balancing. =A0Otherwise, the label stack offers the ability for
meta-data already where only the receiver would need to understand it.
=A0 Consistent paths are very useful, but there are other ways of doing
this already - with the most trivial being just using label 15. =A0I have
a hard time seeing this as a new attack vector (but I'm not
professionally paranoid yet).

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <adrian@olddog.co.uk
<mailto:adrian@olddog.co.uk>> wrote:

=A0 =A0 [snip]

=A0 =A0 =A0> >> XL =A0 The Extensi= on Label that indicates that an extended special
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0 pu= rpose label follows.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> ESPL An Extended Special Purpose Label.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> Something that I think would be worthwhile clarifying right at the
=A0 =A0 =A0> >> front is that a la= bel is an ESPL IFF it is preceded by an XL.
=A0 =A0 =A0> >> It might even be worth noting that really we have a new label
=A0 =A0 type:
=A0 =A0 =A0> >> a label couple in which the first label defines the type of the
=A0 =A0 =A0> >> second label and neither are of any use as individual labels.
=A0 =A0 =A0> > I can see how you woul= d see this as a new label type. Maybe
=A0 =A0 "compound"
=A0 =A0 =A0> > rather than "coup= le".
=A0 =A0 =A0> > However, I am not convinced that it is new that one label leads
=A0 =A0 to the
=A0 =A0 semantics
=A0 =A0 =A0> > of the next (for examp= le the entropy label).
=A0 =A0 =A0> > What is more, I am not sure that there will be more than this
=A0 =A0 instance of
=A0 =A0 this
=A0 =A0 =A0> > type of tight coupling= .
=A0 =A0 =A0> > So I would rather leav= e this point out.
=A0 =A0 =A0> I can foresee other cases where we might use label pairs to
=A0 =A0 mitigate the
=A0 =A0 =A0> 20bit limit. I am sure it h= as been discussed, so creating the
=A0 =A0 reference
=A0 =A0 =A0> might be useful. Just becau= se this was not done in EL, does not
=A0 =A0 mean that
=A0 =A0 =A0> we should not set down the concept here.
=A0 =A0 =A0>
=A0 =A0 =A0> However I agree compound wo= uld be a better term.
=A0 =A0 =A0>
=A0 =A0 =A0> >
=A0 =A0 =A0> > But as to clarifying ESPL: yes.
=A0 =A0 =A0> > The XP definition is, = I think, clear.
=A0 =A0 =A0> > How about...
=A0 =A0 =A0> >
=A0 =A0 =A0> > ESPL An Extended Speci= al Purpose Label. A Special Purpose Label
=A0 =A0 that
=A0 =A0 =A0> > =A0 =A0 =A0 is placed = in the label stack after the Extension Label.
=A0 =A0 =A0>
=A0 =A0 =A0> Yes. Indeed it MUST be plac= ed be placed there, however the definition
=A0 =A0 =A0> above is fine.

=A0 =A0 OK, I updated to...

=A0 =A0 =A0 =A0 ESPL An Extended Special Pu= rpose Label. A Special Purpose Label that
=A0 =A0 =A0 =A0 =A0 =A0 =A0is placed in the= label stack after the Extension Label. =A0The
=A0 =A0 =A0 =A0 =A0 =A0 =A0combination of X= L and ESPL might be regarded as a new form of
=A0 =A0 =A0 =A0 =A0 =A0 =A0"compound l= abel" comprising more than one consecutive entry in
=A0 =A0 =A0 =A0 =A0 =A0 =A0the label stack.=

=A0 =A0 ..to cover your other point as well= .

=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D=
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I think that the draft will need to provide some guidance =A0 =A0 =A0> >> on when to allocat= e a 0..15 and when to allocate an ESPL.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I imagine that a 0..15 should only be used when it can be shown
=A0 =A0 =A0> >> that the extra sta= ck space of forwarding time is burdensome
=A0 =A0 =A0> >> but that is a question that the WG should explicitly consider.
=A0 =A0 =A0> > We discussed this at s= ome point on the MPLS list (many
=A0 =A0 centuries ago, I
=A0 =A0 think)
=A0 =A0 =A0> > and reached no conclusion.
=A0 =A0 =A0> > The primary purpose of the XL is to handle the time when 0..15
=A0 =A0 is depleted.
=A0 =A0 =A0> > You're right that = we could encourage people to start using
=A0 =A0 ESPLs now before
=A0 =A0 =A0> > 0..15 is depleted. But= it is hard to make the case for
=A0 =A0 requiring it when
=A0 =A0 there
=A0 =A0 =A0> > is still some of 0..15 available and the rate of burn is not so =A0 =A0 high.
=A0 =A0 =A0> >
=A0 =A0 =A0> > We could put in some t= ext like...
=A0 =A0 =A0> >
=A0 =A0 =A0> > When allocating a new Special Purpose Label, protocol designers
=A0 =A0 should
=A0 =A0 =A0> > consider whether they could, instead, use an Extended Special
=A0 =A0 Purpose
=A0 =A0 =A0> > Label. Doing so would help to preserve the scarce resources of =A0 =A0 Special
=A0 =A0 =A0> > Purpose Labels for use= in cases where minimizing the label
=A0 =A0 stack size is
=A0 =A0 =A0> > particularly important= .
=A0 =A0 =A0>
=A0 =A0 =A0> That would be useful text.<= br>
=A0 =A0 Added as new section 3.1.2 with slight tweak to wording.

=A0 =A0 [snip]

=A0 =A0 =A0> >> =A0 =A0 6. =A0[RFC= 6790] says that special purpose labels MUST NOT be
=A0 =A0 used for
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0loa= d balancing. =A0The same logic applies to extended special
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0pur= pose labels (ESPLs). =A0Thus, this document specifies =A0 =A0 that ESPLs
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0MUS= T NOT be used for load balancing. =A0It is noted that
=A0 =A0 existing
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0implementations may violate this, as they do not look
=A0 =A0 for the XL
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0and= thus for ESPLs. =A0The consequence is that if ESPLs<= br> =A0 =A0 are used in
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0som= e packets of a flow, these packets may be delivered on
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0dif= ferent paths and so could be re-ordered. =A0However, it is
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0imp= ortant to specify the correct behavior for future
=A0 =A0 =A0> >> =A0 =A0 =A0 =A0implementations, hence the use of "= MUST NOT".
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> I would suggest th= at most implementations do violate this. I would
=A0 =A0 =A0> >> also suggest that = it seems unlikely that you will get to the point
=A0 =A0 =A0> >> where it is not violated in the foreseeable future.
=A0 =A0 =A0> > I can't tell wheth= er there is an action here for us.
=A0 =A0 =A0> > There are two "violations" that exist:
=A0 =A0 =A0> > 1. Some implementation= s violate 6790. Not sure what we can do about
=A0 =A0 =A0> > that in this document. Note that the entropy label can help
=A0 =A0 with this
=A0 =A0 =A0> > but only to a limited extent since the implementations that
=A0 =A0 violate 6790
=A0 =A0 =A0> > probably also fail to recognise the entropy label.
=A0 =A0 =A0> > 2. Implementations tha= t conform to 6790 will understand that
=A0 =A0 the XL is
=A0 =A0 =A0> > a special purpose labe= l and will not use it to load balance.
=A0 =A0 But they will
=A0 =A0 =A0> > not necessarily understand that the next label is an ESPL that
=A0 =A0 must be
=A0 =A0 =A0> > skipped as well. Again= , there is nothing we can do about this
=A0 =A0 except to
=A0 =A0 =A0> > note it (done) and possibly to use the EL further up the stack.
=A0 =A0 =A0>
=A0 =A0 =A0> My point was that the may i= n "It is noted that existing
=A0 =A0 implementations may
=A0 =A0 =A0> violate this" was a li= ttle soft. Most implementations, except the
=A0 =A0 latest
=A0 =A0 =A0> designs of maybe as few as = a single vendor, would certainly
=A0 =A0 violate this.
=A0 =A0 =A0>
=A0 =A0 =A0> Also of course you are maki= ng a statement of fact and not of
=A0 =A0 permission
=A0 =A0 =A0> so I think it may be more precise to say:
=A0 =A0 =A0>
=A0 =A0 =A0> It is noted that most exist= ing
=A0 =A0 =A0> implementations currently violate this, as they do not look for
=A0 =A0 the XL
=A0 =A0 =A0> and thus for ESPLs.

=A0 =A0 OK.

=A0 =A0 I've gone with...

=A0 =A0 =A0 =A0 =A0 =A0 It is noted that ex= isting
=A0 =A0 =A0 =A0 =A0 =A0 implementations wou= ld violate this, as they do not recognise XL
=A0 =A0 =A0 =A0 =A0 =A0 as anything other t= han a single Special Purpose Label and will
=A0 =A0 =A0 =A0 =A0 =A0 not expect an ESPL = to follow.

=A0 =A0 [snip]

=A0 =A0 =A0> >> =A0 =A0Label 7 (wh= en received) retains its meaning as ELI whether
=A0 =A0 a regular
=A0 =A0 =A0> >> =A0 =A0special pur= pose label or an ESPL; this simplifies a transit
=A0 =A0 LSR's
=A0 =A0 =A0> >> =A0 =A0task of loo= king for entropy labels since it may just look
=A0 =A0 for label 7
=A0 =A0 =A0> >> =A0 =A0and need no= t verify that the previous label in the stack is
=A0 =A0 not the
=A0 =A0 =A0> >> =A0 =A0XL 15. =A0H= owever, an LSR wishing to insert an entropy label
=A0 =A0 SHOULD
=A0 =A0 =A0> >> =A0 =A0insert labe= l 7 as a regular special purpose label, not as
=A0 =A0 an ESPL.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> Why is this not a MUST! There is no ESPL in the wild running an
=A0 =A0 =A0> >> alternate behaviou= r, so why not simply mandate this?
=A0 =A0 =A0> > If this was a MUST the= n there would be no case for handling
=A0 =A0 Label 7 after
=A0 =A0 XL.
=A0 =A0 =A0> > There was some concern= I believe that implementations might
=A0 =A0 have a path that
=A0 =A0 =A0> > puts them on to XL insertion processing and then consider what
=A0 =A0 to do next.
=A0 =A0 At
=A0 =A0 =A0> > that point they might decide that label 7 is needed.
=A0 =A0 =A0> >
=A0 =A0 =A0> > It seems esoteric, but= I couldn't see a reason to prohibit it. =A0 =A0 =A0> >
=A0 =A0 =A0> > Maybe "MUST NOT i= nclude" and "SHOULD process when received"= ; are
=A0 =A0 =A0> > compatible.
=A0 =A0 =A0> >
=A0 =A0 =A0> > Part of me hates the i= dea of this change just because I don't
=A0 =A0 want another
=A0 =A0 =A0> > working group last cal= l before we can move forward. How
=A0 =A0 important is it?
=A0 =A0 =A0>
=A0 =A0 =A0> The reason to be stricter a= t the TX is that the forwarding path
=A0 =A0 can be
=A0 =A0 =A0> simpler at the RX. I cannot see how you would get to the point of
=A0 =A0 putting
=A0 =A0 =A0> in L15 and then saying &quo= t;you know I need to put in L7"
=A0 =A0 particularly as no
=A0 =A0 =A0> other 0..15 is allowed.
=A0 =A0 =A0> Normally I would think that you would put in the compound label
=A0 =A0 as a pair
=A0 =A0 =A0> and that is a good reason t= o use the compound label concept.
=A0 =A0 =A0>
=A0 =A0 =A0> Also I see no reason for th= e inconsistency between L7 and all of the
=A0 =A0 =A0> other L0..L15 cases.
=A0 =A0 =A0>
=A0 =A0 =A0> So I think that it's OK= , but probably silly to allow L0..L15, but
=A0 =A0 to allow
=A0 =A0 =A0> the exception of just L7 ju= st complicates things without good cause.

=A0 =A0 I'm not in a position to argue = on this one as the debate and text
=A0 =A0 were driven by
=A0 =A0 others.

=A0 =A0 I believe that the claim was that allowing L7 to be inserted
=A0 =A0 anywhere made
=A0 =A0 processing it easier not harder at the receiver.
=A0 =A0 Note that {XL,7} would be an error case in your way of looking at
=A0 =A0 things so the
=A0 =A0 receiver should (must?) not process it.
=A0 =A0 But the claim was that h/w will simply search the stack for L7 so
=A0 =A0 that allowing
=A0 =A0 {L7} and {XL, L7} to be treated in the same way made life easier for
=A0 =A0 the h/w.

=A0 =A0 Bottom line, however, seems to be that you have a preference for
=A0 =A0 doing it one
=A0 =A0 way, and the WG has a preference fo= r doing it a different way. How
=A0 =A0 to resolve
=A0 =A0 that?

=A0 =A0 Given the posting deadline, I'v= e not made any change for this. We
=A0 =A0 can continue
=A0 =A0 to discuss.

=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D= =3D=3D
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> 3.2. =A0Process fo= r Retiring Special Purpose Labels

=A0 =A0 [snip]

=A0 =A0 =A0> >> Secondly I think t= he timescales are ridiculously optimistic.
=A0 =A0 To get
=A0 =A0 =A0> >> a label out of circulation in 24 months seems most unlikely. Also
=A0 =A0 =A0> >> 6 month checks is = a lot of work.
=A0 =A0 =A0> >>
=A0 =A0 =A0> >> A more realistic schedule would be to poll at 12month
=A0 =A0 intervals until
=A0 =A0 =A0> >> such time as it is determined that reallocation would do not
=A0 =A0 harm and
=A0 =A0 =A0> >> then give a furthe= r 12 months notice.
=A0 =A0 =A0> > Erm, that's what t= he text says, I think...
=A0 =A0 =A0> >
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 12 mon= ths after the RFC deprecating the label value is
=A0 =A0 published,
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 an IET= F-wide survey may be conducted to determine if the
=A0 =A0 =A0> > =A0 =A0 =A0 =A0 deprec= ated label value is still in use.
=A0 =A0 =A0> >
=A0 =A0 =A0> > The "may" in= that means that the earliest you can "poll" = is 12
=A0 =A0 months after
=A0 =A0 the
=A0 =A0 =A0> > deprecation RFC is published (noting that the RFC won't even
=A0 =A0 get published
=A0 =A0 =A0> > until lots of discussi= on and consensus to deprecate).
=A0 =A0 =A0> > Then, *if* the poll response is OK, and then not earlier than
=A0 =A0 24 months
=A0 =A0 after
=A0 =A0 =A0> > the deprecation RFC is published, publication can be requested
=A0 =A0 for a new RFC
=A0 =A0 =A0> > (which means that the = WG has already reached consensus, and that a
=A0 =A0 =A0> > subsequent IETF last c= all will be held).
=A0 =A0 =A0> >
=A0 =A0 =A0> > Frankly, I think that this process is only likely to be
=A0 =A0 executed for SPLs
=A0 =A0 that
=A0 =A0 =A0> > are allocated "in= error", because other stuff will probably be
=A0 =A0 in the field.
=A0 =A0 Can
=A0 =A0 =A0> > you think of a label t= hat was allocated in error? I can :-)
=A0 =A0 =A0>
=A0 =A0 =A0> This seems like a lot of te= xt to specify in detail something we
=A0 =A0 would never
=A0 =A0 =A0> run. In protocols, includin= g this type of protocol, the fewer
=A0 =A0 words used to
=A0 =A0 =A0> describe the rarely execute= d exception path the better.

=A0 =A0 The case was considered worthy of inclusion because the SPL range is
=A0 =A0 so small.
=A0 =A0 If any SPL can be reclaimed at some future time it will be very
=A0 =A0 valuable and so
=A0 =A0 a mechanism needs to be documented against that happy day.

=A0 =A0 [snip]
=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=A0 =A0 [snip]
=A0 =A0 =A0> >> However that bring= s me to
=A0 =A0 =A0> >> suggest that you probably need to write an OPs section and
=A0 =A0 =A0> >> you might want to think about the PM implications of the extra
=A0 =A0 =A0> >> metatdata in the packets.
=A0 =A0 =A0> >
=A0 =A0 =A0> > What OPS issues had yo= u in mind that need to be addressed? I am
=A0 =A0 a fan of OPS
=A0 =A0 =A0> > sections, but not a fa= n of empty OPS sections, and when we
=A0 =A0 looked through
=A0 =A0 =A0> > RFC 6123 (which is my favourite crib for what to describe wrt
=A0 =A0 manageability)
=A0 =A0 we
=A0 =A0 =A0> > didn't see anythin= g that has changed from pre-existing MPLS.
=A0 =A0 =A0> >
=A0 =A0 =A0> > What metadata are you talking about? Is an existing special
=A0 =A0 purpose label
=A0 =A0 =A0> > metadata? If so, the P= M issues are pre-existing. Is there
=A0 =A0 something special
=A0 =A0 =A0> > introduced by this I-D that constitutes metadata?
=A0 =A0 =A0>
=A0 =A0 =A0> Well what follows an XL is certainly metadata, and one application is
=A0 =A0 =A0> certainly to introduce tags that would alert the PM devices to
=A0 =A0 take an
=A0 =A0 =A0> interest.

=A0 =A0 OK it is a form of metadata as existing SPLs are metadata.
=A0 =A0 The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI
=A0 =A0 that the SPL
=A0 =A0 is there.
=A0 =A0 What has changed?
=A0 =A0 We could certainly sit down and write an I-D about the implications
=A0 =A0 of using
=A0 =A0 MPLS in an environment where PM might be present (BTW, I assume this is
=A0 =A0 Pervasive Monitoring. Would be embarrassing to find you meant
=A0 =A0 something else
=A0 =A0 :-). I think such an I-D would discuss SPLs as indicative metadata
=A0 =A0 and would
=A0 =A0 then note that ESPLs are in the sam= e category.
=A0 =A0 Is *this* the I-D in which to have that discussion?

=A0 =A0 [snip]

=A0 =A0 I'll post the revised I-D in a = few minutes and others can throw
=A0 =A0 vegetables
=A0 =A0 (rotten or otherwise).

=A0 =A0 Adrian

=A0 =A0 ___________________________________= ____________
=A0 =A0 mpls mailing list
=A0 =A0 mpls@ietf.org <mailto:mpls@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/mpl= s





_____________________________________________= __
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<= br>

--


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




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



-=
-=20
For corporate legal information go to:

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

 Support as coauthor.

Ning So
<= div id=3D"yiv0658320428yui_3_13_0_ym1_9_1392669050745_9">972-955-0914
=

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, Febr= uary 17, 2014 4:09 PM
To: mpls@ietf.org<mai= lto:mpls@ietf.org>
Cc: mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>= ;
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protect= ion-11

This is to start a poll on adopting draft-chen-mpls-p2mp-ingr= ess-protection-11
as an MPLS working group document. Since this call wil= l continue through the
IETF meeting in London, I will extent the poll by= one week (so that it will be a
three week poll).

Please send you= r comments (support/not support) to the mpls working group
mailing list = (mpls@ietf.org<mailto:mpls@ietf.org>).

This poll will end Tuesday March 11, 2014. This is of = course the Tuesday after
the IETF.

Thanks, Ross


------= -------- next part --------------
An HTML attachment was scrubbed...
= URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/20140218/498561a7/at= tachment.html>
<= /div>
--20cf301af7732f63a304f2af768a-- From nobody Tue Feb 18 07:16: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 395121A01E2 for ; Tue, 18 Feb 2014 07:16:45 -0800 (PST) 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 4ju6K5jOQ-LU for ; Tue, 18 Feb 2014 07:16:42 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 97D911A01D5 for ; Tue, 18 Feb 2014 07:16:42 -0800 (PST) Received: from mail109-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Feb 2014 15:16:38 +0000 Received: from mail109-va3 (localhost [127.0.0.1]) by mail109-va3-R.bigfish.com (Postfix) with ESMTP id 4A1E720102; Tue, 18 Feb 2014 15:16:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail109-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(24454002)(13464003)(189002)(199002)(479174003)(377454003)(4396001)(87266001)(63696002)(46102001)(85852003)(90146001)(85306002)(83072002)(56816005)(66066001)(47976001)(47736001)(65816001)(80022001)(81816001)(81686001)(92566001)(80976001)(74876001)(74706001)(76796001)(76786001)(76576001)(59766001)(77982001)(53806001)(49866001)(51856001)(79102001)(74316001)(15975445006)(50986001)(74366001)(33646001)(54316002)(19580405001)(19580395003)(56776001)(94316002)(93136001)(81342001)(74662001)(76482001)(54356001)(83322001)(86362001)(95666001)(81542001)(87936001)(69226001)(74502001)(47446002)(2656002)(31966008)(95416001)(93516002)(94946001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB562.namprd05.prod.outlook.com; CLIP:66.129.239.11; FPR:FCCCF13F.A6D2D4F6.B1D67DBB.C0E5F25D.202CF; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail109-va3 (localhost.localdomain [127.0.0.1]) by mail109-va3 (MessageSwitch) id 1392736596714168_10881; Tue, 18 Feb 2014 15:16:36 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.231]) by mail109-va3.bigfish.com (Postfix) with ESMTP id 9F3D0400049; Tue, 18 Feb 2014 15:16:36 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Feb 2014 15:16:26 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 18 Feb 2014 15:16:26 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.0.878.16; Tue, 18 Feb 2014 15:16:24 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0878.008; Tue, 18 Feb 2014 15:16:24 +0000 From: John E Drake To: "stbryant@cisco.com" , Loa Andersson , Alia Atlas Thread-Topic: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels Thread-Index: AQHZAbpQEHKtxixh1gWDHsjupsHBAwFVBBIXAfST0/2ahvSAYIAArU2AgAAjAwCAAAdeAIAAxRCAgAEYYICAA3eyAIAABSSA Date: Tue, 18 Feb 2014 15:16:24 +0000 Message-ID: References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> <53008A8B.4040605@pi.nu> <53037332.8040208@cisco.com> In-Reply-To: <53037332.8040208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-forefront-prvs: 0126A32F74 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cBVUn9CSZVjtWbQPW531YFDE9NY Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 15:16:45 -0000 Hi, Stewart is correct. An implementation of 6790 would use a regular label 7 = since that is what 6790 says to do. It would not use an ESL of 7 and so th= ere is absolutely no reason to set aside an ESL value of 7.=20 Yours Irrespectively, John > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Tuesday, February 18, 2014 6:50 AM > To: Loa Andersson; Alia Atlas > Cc: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org > Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels >=20 > On 16/02/2014 09:53, Loa Andersson wrote: > > Alia, > > > > Of course I can take a spin on the text, once I'm convinced this is > > necessary and useful. > > > > Reading things a third or fourth time, I still think that the text > > Adrian had in the draft is the best so far. > > > > However, the draft is now in ietf last call, and wisdom says that we > > shall not change documents while they are in last call. We have at > > least two weeks to discuss this and converge on what we want to change > > if anything. > > > > My point is that there no other reason that the ELI is an exception > > than that we have running code (that were standards compatible when > > implemented) that breaks if we don't make the exception. > > > > /Loa > Yes, but! I don't see how forbidding the extended version of L7 can possi= bly > break anything. The only think it could break is a pre-standards version = of the > extended label that used this format. However it is unreasonable for the > existing code to place a burden of complexity on all future implementatio= ns. >=20 > Stewart >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From nobody Tue Feb 18 08:22: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 8E84A1A0510 for ; Tue, 18 Feb 2014 08:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6PhO0xoOJw1 for ; Tue, 18 Feb 2014 08:22:39 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0D61A0504 for ; Tue, 18 Feb 2014 08:22:39 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id z60so7240212qgd.9 for ; Tue, 18 Feb 2014 08:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jNMiuESTWEKLxASPJuB5mFbi4RT6Y5JODINdy6cr8sI=; b=uurMu9WFYMW06Vy4ok2U/QRqk8Aap+sIPwI/9WfDqcssJJ9hCbNJtXUmOeE2DsBMEj eVXNMWxNULJW1PrphPR4yaEbo+JWi0Bbqrro8L9CSVzSJ0kM7opcybnmI19zPnGBVs+M QVhRn8gi7pG6XTPqrqWTWGc957SAlSV76MbGdw9+uB8NP24xXsiIt3cYL5UwBgcfexlC lyYFfg0QQfMCFNVuCd/74hd/lpF6ats1G3lXhDwF84AqZX89Gnx3HQXDLDb7V5ckJglX uXAW8DMgOIHF+ShNPIwnr5mhdjwskGq3Qbmc/shViDmGaQGiLCXOfizMuSsFumHVjpT7 sWow== X-Received: by 10.140.102.69 with SMTP id v63mr41650520qge.5.1392740556080; Tue, 18 Feb 2014 08:22:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Tue, 18 Feb 2014 08:22:16 -0800 (PST) In-Reply-To: <53037332.8040208@cisco.com> References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> <53008A8B.4040605@pi.nu> <53037332.8040208@cisco.com> From: "Andrew G. Malis" Date: Tue, 18 Feb 2014 11:22:16 -0500 Message-ID: To: Stewart Bryant Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/fMPAmRwE-oX9Y0EUTZiCFQiZGmE Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 16:22:41 -0000 I agree with Stewart that a very useful simplification is forbidding the sending of the extended version of label 7. Thus, in the draft, label 7 would simply join the list of reserved labels in section 5, and the paragraph regarding label 7 can be removed altogether from section 3.1. Thus, the label stack would never contain the combination on reception since it would never be transmitted. Cheers, Andy On Tue, Feb 18, 2014 at 9:50 AM, Stewart Bryant wrote: > On 16/02/2014 09:53, Loa Andersson wrote: >> >> Alia, >> >> Of course I can take a spin on the text, once I'm convinced this is >> necessary and useful. >> >> Reading things a third or fourth time, I still think that the text >> Adrian had in the draft is the best so far. >> >> However, the draft is now in ietf last call, and wisdom says that we >> shall not change documents while they are in last call. We have at least >> two weeks to discuss this and converge on what we want to change if >> anything. >> >> My point is that there no other reason that the ELI is an exception than >> that we have running code (that were standards compatible when >> implemented) that breaks if we don't make the exception. >> >> /Loa > > Yes, but! I don't see how forbidding the extended version of L7 can possibly > break anything. The only think it could break is a pre-standards version of > the extended label that used this format. However it is unreasonable for > the existing code to place a burden of complexity on all future > implementations. > > Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Feb 18 08:38:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878841A0516 for ; Tue, 18 Feb 2014 08:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5s2YnUwOulf for ; Tue, 18 Feb 2014 08:37:55 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id D32181A0402 for ; Tue, 18 Feb 2014 08:37:54 -0800 (PST) Received: from mail142-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Feb 2014 16:37:51 +0000 Received: from mail142-tx2 (localhost [127.0.0.1]) by mail142-tx2-R.bigfish.com (Postfix) with ESMTP id 6451F400B3; Tue, 18 Feb 2014 16:37:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail142-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(377454003)(479174003)(24454002)(13464003)(189002)(199002)(86362001)(92566001)(47446002)(95666001)(95416001)(94946001)(74662001)(74316001)(31966008)(74502001)(87936001)(94316002)(53806001)(54356001)(76482001)(54316002)(33646001)(2656002)(19580405001)(19580395003)(83072002)(81686001)(87266001)(80976001)(74366001)(81816001)(51856001)(83322001)(85852003)(85306002)(15975445006)(77982001)(59766001)(79102001)(50986001)(47976001)(49866001)(47736001)(81342001)(65816001)(66066001)(80022001)(69226001)(63696002)(81542001)(74706001)(74876001)(46102001)(56816005)(56776001)(76786001)(76576001)(90146001)(76796001)(93136001)(4396001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; CLIP:66.129.239.11; FPR:FCCEF1FF.A6F2D4F2.B1D67D8B.C4E5D35D.2031B; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail142-tx2 (localhost.localdomain [127.0.0.1]) by mail142-tx2 (MessageSwitch) id 1392741469529920_30478; Tue, 18 Feb 2014 16:37:49 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.243]) by mail142-tx2.bigfish.com (Postfix) with ESMTP id 7948A3A0082; Tue, 18 Feb 2014 16:37:49 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Feb 2014 16:37:46 +0000 Received: from BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 18 Feb 2014 16:37:36 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 18 Feb 2014 16:37:34 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0878.008; Tue, 18 Feb 2014 16:37:34 +0000 From: John E Drake To: "Andrew G. Malis" , Stewart Bryant Thread-Topic: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels Thread-Index: AQHZAbpQEHKtxixh1gWDHsjupsHBAwFVBBIXAfST0/2ahvSAYIAArU2AgAAjAwCAAAdeAIAAxRCAgAEYYICAA3eyAIAAGagAgAAEPvA= Date: Tue, 18 Feb 2014 16:37:33 +0000 Message-ID: References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> <53008A8B.4040605@pi.nu> <53037332.8040208@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-forefront-prvs: 0126A32F74 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/M6sGR_DKPbDuaXWwM7nhUA5fW5s Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 16:37:57 -0000 Exactly Yours Irrespectively, John > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis > Sent: Tuesday, February 18, 2014 8:22 AM > To: Stewart Bryant > Cc: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org > Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels >=20 > I agree with Stewart that a very useful simplification is forbidding the = sending > of the extended version of label 7. Thus, in the draft, label 7 would sim= ply join > the list of reserved labels in section 5, and the paragraph regarding lab= el 7 can > be removed altogether from section 3.1. Thus, the label stack would neve= r > contain the combination on reception since it would never be > transmitted. >=20 > Cheers, > Andy >=20 > On Tue, Feb 18, 2014 at 9:50 AM, Stewart Bryant > wrote: > > On 16/02/2014 09:53, Loa Andersson wrote: > >> > >> Alia, > >> > >> Of course I can take a spin on the text, once I'm convinced this is > >> necessary and useful. > >> > >> Reading things a third or fourth time, I still think that the text > >> Adrian had in the draft is the best so far. > >> > >> However, the draft is now in ietf last call, and wisdom says that we > >> shall not change documents while they are in last call. We have at > >> least two weeks to discuss this and converge on what we want to > >> change if anything. > >> > >> My point is that there no other reason that the ELI is an exception > >> than that we have running code (that were standards compatible when > >> implemented) that breaks if we don't make the exception. > >> > >> /Loa > > > > Yes, but! I don't see how forbidding the extended version of L7 can > > possibly break anything. The only think it could break is a > > pre-standards version of the extended label that used this format. > > However it is unreasonable for the existing code to place a burden of > > complexity on all future implementations. > > > > Stewart > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From nobody Tue Feb 18 08:39: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 441481A06A5 for ; Tue, 18 Feb 2014 08:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9r_t4w1vzoj for ; Tue, 18 Feb 2014 08:39:04 -0800 (PST) Received: from nm33.bullet.mail.ne1.yahoo.com (nm33.bullet.mail.ne1.yahoo.com [98.138.229.26]) by ietfa.amsl.com (Postfix) with ESMTP id 42AB81A06BC for ; Tue, 18 Feb 2014 08:39:02 -0800 (PST) Received: from [127.0.0.1] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 16:38:58 -0000 Received: from [98.138.100.112] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 16:36:06 -0000 Received: from [98.138.89.251] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 16:36:06 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 16:36:06 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 208902.9045.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 42481 invoked by uid 60001); 18 Feb 2014 16:36:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392741366; bh=JAeugxZFm2lk3kYSk2LRDINy6WU1Ds4IYxQeUa31rK8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LuFtuAH5tCK3GP0JalKid7gXJ3q9QoC1iSLIys8Ba5xxLmNw6fQOtl21OYwQ4fFQMvDmaExtFaD8a7jbBZ4nILA6l2BWgUloHq9YeW0Uum+317tsN4SudyU8lVUy/+o4QlPwuFHOBAEXbdLb4zMWZ2VpH59bJZlqVZTn4i6fBRQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HBKjd2llmkHxXSKGLWahx6D784QFyq3utCdnr7Kgbz0oLNdcJRH2G38DWENiiq91k71Lm4/eMxumSnHLwTt3cIRQelsYunNbfCg8oK6ctrxn8kROwgKcfKQIyQX7zbWOzWuTR7UT/Di1MPBzD6Lv9mE7/HUkbrgHqOH7FeEPAZ0=; X-YMail-OSG: E9LoNPcVM1l_Z64GJynVgRi8snntI.Tqyf5ilGBO5lNhOVy v9aPph6a3GwPeDMqTDubfgF8QzbooplDjSYDwfVoO5uRXhMpI597XAonzJCK 8SvSqe5U27U88eJ39SeNYmuJVKRCFKK5JXpBXuyjKxa1wPO7lU4KRYxBMld3 IIR6P7HNF1heBjvlgIfAnEvPzQT26455Tcuq6PqiY0dO2FN_7crmYuEaQWru q4iGrqJ4xxeLyuh5G9siAzIBLHXH0t8pwvM0d4aa4R.KIAs.3EmEiz.VJCUz FG4b2ygRYUJ_HKpfISj8EezG3f5tSX3gShE0zHRJRgUu4rjBk0FRnoVNEOZG 0LJ_AYISYycOU.AjCGXPzThEo7VBGC9tbbPNV76JSrf3BaABynUldqGo5uMH 81w0939e6PyiLwUoelVrpmXm.b4rOiiupd3cODecZS58aY0gGBeSeD7fU6Vw oQpAg9U9UcNGnMgkKd3UGCx3hUdChvnLQPPmLvHX5QihW3xrSLfN7fI__9Fu xtRvKmjp0dgOBabPLReUL1x4RkjFHda6okySPzQ-- Received: from [12.130.146.229] by web120001.mail.ne1.yahoo.com via HTTP; Tue, 18 Feb 2014 08:36:05 PST X-Rocket-MIMEInfo: 002.001, U3VwcG9ydC4KwqAKWW91bmcKCgoKT24gTW9uZGF5LCBGZWJydWFyeSAxNywgMjAxNCAzOjA5IFBNLCBSb3NzIENhbGxvbiA8cmNhbGxvbkBqdW5pcGVyLm5ldD4gd3JvdGU6CiAgCiAKVGhpcyBpcyB0byBzdGFydCBhIHBvbGwgb24gYWRvcHRpbmcgZHJhZnQtY2hlbi1tcGxzLXAybXAtaW5ncmVzcy1wcm90ZWN0aW9uLTExICAKYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBTaW5jZSB0aGlzIGNhbGwgd2lsbCBjb250aW51ZSB0aHJvdWdoIHRoZSAgCklFVEYgbWVldGluZyBpbiBMb25kb24sIEkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Message-ID: <1392741365.42227.YahooMailNeo@web120001.mail.ne1.yahoo.com> Date: Tue, 18 Feb 2014 08:36:05 -0800 (PST) From: Young Lee To: Ross Callon , "mpls@ietf.org" In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-134638194-1436758305-1392741365=:42227" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ri_QMfWlcVacF6jCkvIlpijoqxI Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Young Lee List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:39:06 -0000 ---134638194-1436758305-1392741365=:42227 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Support.=0A=A0=0AYoung=0A=0A=0A=0AOn Monday, February 17, 2014 3:09 PM, Ros= s Callon wrote:=0A =0A =0AThis is to start a poll on= adopting draft-chen-mpls-p2mp-ingress-protection-11 =0Aas an MPLS working= group document. Since this call will continue through the =0AIETF meeting= in London, I will extent the poll by one week (so that it will be a =0Ath= ree week poll). =0A=A0 =0APlease send your comments (support/not support= ) to the mpls working group =0Amailing list (mpls@ietf.org). =0A=A0 =0AT= his poll will end Tuesday March 11, 2014. This is of course the Tuesday aft= er =0Athe IETF. =0A=A0 =0AThanks, Ross =0A=A0 =0A=A0 =0A___________= ____________________________________=0Ampls mailing list=0Ampls@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mpls ---134638194-1436758305-1392741365=:42227 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Support.
 
Young


On Monday, February 17, 2014 3:09 PM, Ross Callon <rcallo= n@juniper.net> wrote:
=0A=0A =0A =0A=0A=0A
=0A
=0A
=0A
This is to start a poll on adopting draft-chen-mpls-p2mp-= ingress-protection-11
=0A
=0A
=0A
as an MPLS working group= document. Since this call will continue through the=0A
=0AIETF me= eting in London, I will extent the poll by one week (so that it will be a= =0A
=0A
three week poll).=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
Please send your comments (support/not support) = to the mpls working group=0A
=0A
mailing list (mpls@ietf.org).<= /div> =0A
=0A
=0A
 
=0A
=0A
=0A
This poll will en= d Tuesday March 11, 2014. This is of course the Tuesday after=0A =0A
 
=0A
= =0A
=0A
Thanks, Ross
=0A
=0A
=0A
 
=0A  
=0A
=0A
=0A
=0A
=
_______________________________________________
mpls mailing listmpls@iet= f.org
https://www.ietf.org/mailman/listinfo/mpls


---134638194-1436758305-1392741365=:42227-- From nobody Tue Feb 18 09:00:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449261A025F for ; Tue, 18 Feb 2014 09:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 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_12=0.6, RP_MATCHES_RCVD=-0.548, 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 A8tVTqeJ2XQC for ; Tue, 18 Feb 2014 08:59:56 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 725FE1A0228 for ; Tue, 18 Feb 2014 08:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129653; q=dns/txt; s=iport; t=1392742789; x=1393952389; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=kg646G0uKMbA1O0A5RSmEadVP1EFtV7FoQEwICJUd/Q=; b=XXU28g8Du/Xs3jR+DSSphDt1cU/kiod0X1mauElbiGxkZprdvT3ITSZh BUvK/7tnN1mEpMqTK1jRxJuUR9w4lYyf3eunQM4zmVQP6ErFxF1P2nuHA 7W2F9pdDCD6/WSwbhSS4LZNJX19VJDIvsTnE+YQar/UdvBJky0SFqZIyq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAEmRA1OQ/khL/2dsb2JhbABZgwY4iTa2cYEbFnSCJQEBAQMBAQEBCwoCAUoGAwoBDgILDgoJFgEBBgcJAwIBAgEJBgYfEQYNAQUCAQEVh1gDCQgNw3sNiA8XBIxjgTgKAQUCASMsB4IvggkElkCBbIxehUWDLYFoAQYZ X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208,217";a="4740553" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 16:59:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1IGxXMP015192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 16:59:34 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1IGxWfS022259; Tue, 18 Feb 2014 16:59:33 GMT Message-ID: <53039174.1040807@cisco.com> Date: Tue, 18 Feb 2014 16:59:32 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alia Atlas References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> <5303725C.6070007@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070109060504020208000209" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IED-jJtj4-71lPslNWi2mekShfE Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels 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, 18 Feb 2014 17:00:02 -0000 This is a multi-part message in MIME format. --------------070109060504020208000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alia Maybe we are out of sync. I think that the text should say that L7 MUST be sent as a single label, and MUST NOT be sent as a compound/extended label, and I think simplicity alone is sufficient justification. Stewart On 18/02/2014 14:55, Alia Atlas wrote: > Stewart, > > If you think that Loa's text is sufficiently strong about not sending > XL, ESPL, then I am fine with his text. > I was striving for more clarity on why the exception was made and > suggesting MUST rather than SHOULD. > > Loa's text says: > > ""Label 7 (when received) retains its meaning as ELI whether a >> >> regular special purpose label or an ESPL; this is because of >> backwards >> compatibility with existing implemented and deployed code >> and hardware >> that looks for the ELI without verifying if the previous label >> is XL or not. However, when an LSR insert an entropy label >> it SHOULD >> insert the ELI as a regular special purpose label, not as an >> ESPL." >> > This doesn't explain that bad traffic side-effects could happen, but I > think the wording for why the > exception is there is clear. > > Alia > > > On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant > wrote: > > This has me worried. > > Assume that nothing implements ESPL yet, there is no reason why > all SPL implementations are not required to send L7 only as > a regular (single) SPL. As Loa says, this would be a useful > simplification, and one which I raised earlier with the authors. > > If that is the case, a parser will always get it right. > > The only problem I see is if a compound label is ever created > L15, Lx, <0..maxLabel> but one one has defined such an > Lx and to do so would be unwise. > > So I don't think Alia is correct in her proposed text change and > I have yet to see a valid technical reason for not accepting Loa's > proposed change. > > - Stewart > > > On 15/02/2014 17:09, Alia Atlas wrote: >> [+ietf] >> >> Loa, >> >> To clarify a bit better, what I'm trying to get clarified into >> the text is why the ELI value as an ESPL >> needs to be an exception (as the draft indicates). I believe it >> is because forbidding an ESPL of 7 >> can break some existing and deployed versions of RFC 6790 such >> that the transit traffic flows are affected. >> There may also be implementations of RFC 6790 that aren't affected. >> >> Regards, >> Alia >> >> >> On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas > > wrote: >> >> Loa, >> >> On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson > > wrote: >> >> Alia, >> >> Two comments on this. >> >> First a nit "An LSR wishing to insert an ...", LSR are >> boxes and can't >> wish anything for themselves, a Simple change would be >> "When an LSR >> insert..." >> >> Actually the same is true for the current text and should >> be changed the >> same way. >> >> >> [Alia] Sure - I took the original text and modified it. >> >> Second, and this is maybe more tricky - the reason given >> "simplify the >> data plane implementation" is not true and might even be >> wrong. >> The reason put always using the ELI as a "regular special >> purpose label" >> is backwards compatibility. >> I would claim that the treatment of the ELI is an (well >> motivated) >> exception, but exceptions always mean that things get >> more complicated. >> >> >> [Alia] There were three purposes to my suggested text change. >> First, to specify that >> an LSR MUST NOT insert the ELI as an ESPL. Second, to say >> that a receiving LSR >> MAY choose to not discard a packet with the ELI as an ESPL. >> Third, I wanted to see >> a clearer justification for why this exception is worth making. >> >> [Alia] Since the whole draft is about a data-plane change, >> what we've been putting in doesn't >> really articulate the full problem. Prelim text would around >> that would be better as: >> >> "ELI is an exception because each LSR examines the whole >> label stack to see if the ELI >> appears; pre-existing implementations of [Entropy-Label] do >> this examination without verifying >> that the label above the ELI is not XL. If a packet used an >> ESPL of 7 and that did not mean >> ELI, then when that packet transited deployed LSRs, which >> implement [Entropy-Label] and not this document, >> the meaning of the ESPL would be misinterpreted. Such a >> misinterpretation could result in poor traffic behavior >> (large flows, >> reordered flows, etc.) depending on the label after the ESPL >> of 7. It is to avoid such issues that ELI is defined as an >> exception >> that can appear as an regular special label or as an ESPL >> with the same value of 7." >> What do you think? >> >> Alia >> >> I don't want to propose a final text,but something along >> these lines: >> >> >> "Label 7 (when received) retains its meaning as ELI whether a >> regular special purpose label or an ESPL; this is >> because of backwards >> compatibility with existing implemented and deployed >> code and hardware >> that looks for the ELI without verifying if the previous >> label >> is XL or not. However, when an LSR insert an entropy >> label it SHOULD >> insert the ELI as a regular special purpose label, not >> as an ESPL." >> >> /Loa >> >> >> On 2014-02-15 10:52, Alia Atlas wrote: >> >> Adrian and others, >> >> Having reviewed the 05 of this draft and this thread, >> I have the >> following suggestions. Other than these, I'm quite >> happy with how this >> draft has improved. >> >> a) In Sec 3.1, the following paragraph could be >> updated from: >> >> "Label 7 (when received) retains its meaning as ELI >> whether a >> regular special purpose label or an ESPL; this >> simplifies a transit >> LSR's task of looking for entropy labels since it may >> just look for >> label 7 and need not verify that the previous label >> in the stack is not >> the XL 15. However, an LSR wishing to insert an >> entropy label SHOULD >> insert label 7 as a regular special purpose label, >> not as an ESPL." >> >> >> to: >> >> >> "An LSR wishing to insert an entropy label MUST >> insert label value 7 (meaning ELI) as a regular >> special purpose >> >> label and not as an ESPL.Value 7 MUST NOT be sent as >> an ESPL in the data plane. However, to simplify >> >> >> the data plane implementation for Entropy Labels, an >> implementation MAY >> >> interpret an ESPL of 7 as meaning ELI and, unlike for >> values 0-6 and 8-15, an implementation >> >> MAY choose to not treat the packet as malformedand >> thus discard it. The data plane simplification thus >> enabled >> >> >> is the ability to determine if any label value is 7 >> without needing to verify that the previous label in >> the stack is not the XL value of 15." >> >> >> b)In Sec 3.2: "An RFC with at least Informational >> status is required." How is this different from >> IETF Review in RFC 5226? Do BCPs count? What is "at >> least Informational status"? >> >> >> >> On the concern about Pervasive Monitoring, the only >> advantage that (XL, >> ESPL) offers is that the labels wouldn't (eventually) >> be hashed for >> load-balancing. Otherwise, the label stack offers >> the ability for >> meta-data already where only the receiver would need >> to understand it. >> Consistent paths are very useful, but there are >> other ways of doing >> this already - with the most trivial being just using >> label 15. I have >> a hard time seeing this as a new attack vector (but >> I'm not >> professionally paranoid yet). >> >> Alia >> >> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel >> >> > >> wrote: >> >> [snip] >> >> > >> XL The Extension Label that indicates >> that an extended special >> > >> purpose label follows. >> > >> >> > >> ESPL An Extended Special Purpose Label. >> > >> >> > >> Something that I think would be worthwhile >> clarifying right at the >> > >> front is that a label is an ESPL IFF it is >> preceded by an XL. >> > >> It might even be worth noting that really >> we have a new label >> type: >> > >> a label couple in which the first label >> defines the type of the >> > >> second label and neither are of any use as >> individual labels. >> > > I can see how you would see this as a new >> label type. Maybe >> "compound" >> > > rather than "couple". >> > > However, I am not convinced that it is new >> that one label leads >> to the >> semantics >> > > of the next (for example the entropy label). >> > > What is more, I am not sure that there will >> be more than this >> instance of >> this >> > > type of tight coupling. >> > > So I would rather leave this point out. >> > I can foresee other cases where we might use >> label pairs to >> mitigate the >> > 20bit limit. I am sure it has been discussed, >> so creating the >> reference >> > might be useful. Just because this was not >> done in EL, does not >> mean that >> > we should not set down the concept here. >> > >> > However I agree compound would be a better term. >> > >> > > >> > > But as to clarifying ESPL: yes. >> > > The XP definition is, I think, clear. >> > > How about... >> > > >> > > ESPL An Extended Special Purpose Label. A >> Special Purpose Label >> that >> > > is placed in the label stack after the >> Extension Label. >> > >> > Yes. Indeed it MUST be placed be placed there, >> however the definition >> > above is fine. >> >> OK, I updated to... >> >> ESPL An Extended Special Purpose Label. A >> Special Purpose Label that >> is placed in the label stack after the >> Extension Label. The >> combination of XL and ESPL might be regarded as a >> new form of >> "compound label" comprising more than >> one consecutive entry in >> the label stack. >> >> ..to cover your other point as well. >> >> > >> ====== >> > >> >> > >> I think that the draft will need to provide >> some guidance >> > >> on when to allocate a 0..15 and when to >> allocate an ESPL. >> > >> >> > >> I imagine that a 0..15 should only be used >> when it can be shown >> > >> that the extra stack space of forwarding >> time is burdensome >> > >> but that is a question that the WG should >> explicitly consider. >> > > We discussed this at some point on the MPLS >> list (many >> centuries ago, I >> think) >> > > and reached no conclusion. >> > > The primary purpose of the XL is to handle >> the time when 0..15 >> is depleted. >> > > You're right that we could encourage people >> to start using >> ESPLs now before >> > > 0..15 is depleted. But it is hard to make >> the case for >> requiring it when >> there >> > > is still some of 0..15 available and the >> rate of burn is not so >> high. >> > > >> > > We could put in some text like... >> > > >> > > When allocating a new Special Purpose Label, >> protocol designers >> should >> > > consider whether they could, instead, use an >> Extended Special >> Purpose >> > > Label. Doing so would help to preserve the >> scarce resources of >> Special >> > > Purpose Labels for use in cases where >> minimizing the label >> stack size is >> > > particularly important. >> > >> > That would be useful text. >> >> Added as new section 3.1.2 with slight tweak to >> wording. >> >> [snip] >> >> > >> 6. [RFC6790] says that special purpose >> labels MUST NOT be >> used for >> > >> load balancing. The same logic applies >> to extended special >> > >> purpose labels (ESPLs). Thus, this >> document specifies >> that ESPLs >> > >> MUST NOT be used for load balancing. It >> is noted that >> existing >> > >> implementations may violate this, as >> they do not look >> for the XL >> > >> and thus for ESPLs. The consequence is >> that if ESPLs >> are used in >> > >> some packets of a flow, these packets >> may be delivered on >> > >> different paths and so could be >> re-ordered. However, it is >> > >> important to specify the correct >> behavior for future >> > >> implementations, hence the use of "MUST >> NOT". >> > >> >> > >> I would suggest that most implementations >> do violate this. I would >> > >> also suggest that it seems unlikely that >> you will get to the point >> > >> where it is not violated in the foreseeable >> future. >> > > I can't tell whether there is an action here >> for us. >> > > There are two "violations" that exist: >> > > 1. Some implementations violate 6790. Not >> sure what we can do about >> > > that in this document. Note that the entropy >> label can help >> with this >> > > but only to a limited extent since the >> implementations that >> violate 6790 >> > > probably also fail to recognise the entropy >> label. >> > > 2. Implementations that conform to 6790 will >> understand that >> the XL is >> > > a special purpose label and will not use it >> to load balance. >> But they will >> > > not necessarily understand that the next >> label is an ESPL that >> must be >> > > skipped as well. Again, there is nothing we >> can do about this >> except to >> > > note it (done) and possibly to use the EL >> further up the stack. >> > >> > My point was that the may in "It is noted that >> existing >> implementations may >> > violate this" was a little soft. Most >> implementations, except the >> latest >> > designs of maybe as few as a single vendor, >> would certainly >> violate this. >> > >> > Also of course you are making a statement of >> fact and not of >> permission >> > so I think it may be more precise to say: >> > >> > It is noted that most existing >> > implementations currently violate this, as >> they do not look for >> the XL >> > and thus for ESPLs. >> >> OK. >> >> I've gone with... >> >> It is noted that existing >> implementations would violate this, as they do not >> recognise XL >> as anything other than a single Special >> Purpose Label and will >> not expect an ESPL to follow. >> >> [snip] >> >> > >> Label 7 (when received) retains its >> meaning as ELI whether >> a regular >> > >> special purpose label or an ESPL; this >> simplifies a transit >> LSR's >> > >> task of looking for entropy labels since >> it may just look >> for label 7 >> > >> and need not verify that the previous >> label in the stack is >> not the >> > >> XL 15. However, an LSR wishing to insert >> an entropy label >> SHOULD >> > >> insert label 7 as a regular special >> purpose label, not as >> an ESPL. >> > >> >> > >> Why is this not a MUST! There is no ESPL in >> the wild running an >> > >> alternate behaviour, so why not simply >> mandate this? >> > > If this was a MUST then there would be no >> case for handling >> Label 7 after >> XL. >> > > There was some concern I believe that >> implementations might >> have a path that >> > > puts them on to XL insertion processing and >> then consider what >> to do next. >> At >> > > that point they might decide that label 7 is >> needed. >> > > >> > > It seems esoteric, but I couldn't see a >> reason to prohibit it. >> > > >> > > Maybe "MUST NOT include" and "SHOULD process >> when received" are >> > > compatible. >> > > >> > > Part of me hates the idea of this change >> just because I don't >> want another >> > > working group last call before we can move >> forward. How >> important is it? >> > >> > The reason to be stricter at the TX is that >> the forwarding path >> can be >> > simpler at the RX. I cannot see how you would >> get to the point of >> putting >> > in L15 and then saying "you know I need to put >> in L7" >> particularly as no >> > other 0..15 is allowed. >> > Normally I would think that you would put in >> the compound label >> as a pair >> > and that is a good reason to use the compound >> label concept. >> > >> > Also I see no reason for the inconsistency >> between L7 and all of the >> > other L0..L15 cases. >> > >> > So I think that it's OK, but probably silly to >> allow L0..L15, but >> to allow >> > the exception of just L7 just complicates >> things without good cause. >> >> I'm not in a position to argue on this one as the >> debate and text >> were driven by >> others. >> >> I believe that the claim was that allowing L7 to >> be inserted >> anywhere made >> processing it easier not harder at the receiver. >> Note that {XL,7} would be an error case in your >> way of looking at >> things so the >> receiver should (must?) not process it. >> But the claim was that h/w will simply search the >> stack for L7 so >> that allowing >> {L7} and {XL, L7} to be treated in the same way >> made life easier for >> the h/w. >> >> Bottom line, however, seems to be that you have a >> preference for >> doing it one >> way, and the WG has a preference for doing it a >> different way. How >> to resolve >> that? >> >> Given the posting deadline, I've not made any >> change for this. We >> can continue >> to discuss. >> >> > >> ======== >> > >> >> > >> 3.2. Process for Retiring Special Purpose >> Labels >> >> [snip] >> >> > >> Secondly I think the timescales are >> ridiculously optimistic. >> To get >> > >> a label out of circulation in 24 months >> seems most unlikely. Also >> > >> 6 month checks is a lot of work. >> > >> >> > >> A more realistic schedule would be to poll >> at 12month >> intervals until >> > >> such time as it is determined that >> reallocation would do not >> harm and >> > >> then give a further 12 months notice. >> > > Erm, that's what the text says, I think... >> > > >> > > 12 months after the RFC deprecating the >> label value is >> published, >> > > an IETF-wide survey may be conducted to >> determine if the >> > > deprecated label value is still in use. >> > > >> > > The "may" in that means that the earliest >> you can "poll" is 12 >> months after >> the >> > > deprecation RFC is published (noting that >> the RFC won't even >> get published >> > > until lots of discussion and consensus to >> deprecate). >> > > Then, *if* the poll response is OK, and then >> not earlier than >> 24 months >> after >> > > the deprecation RFC is published, >> publication can be requested >> for a new RFC >> > > (which means that the WG has already reached >> consensus, and that a >> > > subsequent IETF last call will be held). >> > > >> > > Frankly, I think that this process is only >> likely to be >> executed for SPLs >> that >> > > are allocated "in error", because other >> stuff will probably be >> in the field. >> Can >> > > you think of a label that was allocated in >> error? I can :-) >> > >> > This seems like a lot of text to specify in >> detail something we >> would never >> > run. In protocols, including this type of >> protocol, the fewer >> words used to >> > describe the rarely executed exception path >> the better. >> >> The case was considered worthy of inclusion >> because the SPL range is >> so small. >> If any SPL can be reclaimed at some future time >> it will be very >> valuable and so >> a mechanism needs to be documented against that >> happy day. >> >> [snip] >> > >> =========== >> [snip] >> > >> However that brings me to >> > >> suggest that you probably need to write an >> OPs section and >> > >> you might want to think about the PM >> implications of the extra >> > >> metatdata in the packets. >> > > >> > > What OPS issues had you in mind that need to >> be addressed? I am >> a fan of OPS >> > > sections, but not a fan of empty OPS >> sections, and when we >> looked through >> > > RFC 6123 (which is my favourite crib for >> what to describe wrt >> manageability) >> we >> > > didn't see anything that has changed from >> pre-existing MPLS. >> > > >> > > What metadata are you talking about? Is an >> existing special >> purpose label >> > > metadata? If so, the PM issues are >> pre-existing. Is there >> something special >> > > introduced by this I-D that constitutes >> metadata? >> > >> > Well what follows an XL is certainly metadata, >> and one application is >> > certainly to introduce tags that would alert >> the PM devices to >> take an >> > interest. >> >> OK it is a form of metadata as existing SPLs are >> metadata. >> The XL alerts a DPI that an ESPL follows, and an >> SPL alerts the DPI >> that the SPL >> is there. >> What has changed? >> We could certainly sit down and write an I-D >> about the implications >> of using >> MPLS in an environment where PM might be present >> (BTW, I assume this is >> Pervasive Monitoring. Would be embarrassing to >> find you meant >> something else >> :-). I think such an I-D would discuss SPLs as >> indicative metadata >> and would >> then note that ESPLs are in the same category. >> Is *this* the I-D in which to have that discussion? >> >> [snip] >> >> I'll post the revised I-D in a few minutes and >> others can throw >> vegetables >> (rotten or otherwise). >> >> Adrian >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 >> 64 >> >> >> >> >> >> _______________________________________________ >> 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 > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070109060504020208000209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Alia

Maybe we are out of sync.

I think that the text should say that L7 MUST be sent as a single label, and
MUST NOT be sent as a compound/extended label, and I think simplicity
alone is sufficient justification.

Stewart

On 18/02/2014 14:55, Alia Atlas wrote:
Stewart,

If you think that Loa's text is sufficiently strong about not sending XL, ESPL, then I am fine with his text.
I was striving for more clarity on why the exception was made and suggesting MUST rather than SHOULD.

Loa's text says:

""Label 7 (when received) retains its meaning as ELI whether a
 regular special purpose label or an ESPL; this is because of backwards
 compatibility with existing implemented and deployed code and hardware
 that looks for the ELI without verifying if the previous label
 is XL or not. However, when an LSR insert an entropy label it SHOULD
 insert the ELI as a regular special purpose label, not as an ESPL."
This doesn't explain that bad traffic side-effects could happen, but I think the wording for why the
exception is there is clear.

Alia


On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant <stbryant@cisco.com> wrote:
This has me worried.

Assume that nothing implements ESPL yet, there is no reason why
all SPL implementations are not required to send L7 only as
a regular (single) SPL. As Loa says, this would be a useful
simplification, and one which I raised earlier with the authors.

If that is the case, a parser will always get it right.

The only problem I see is if a compound label is ever created
L15, Lx, <0..maxLabel> but one one has defined such an
Lx and to do so would be unwise.

So I don't think Alia is correct in her proposed text change and
I have yet to see a valid technical reason for not accepting Loa's
proposed change.

- Stewart


On 15/02/2014 17:09, Alia Atlas wrote:
[+ietf]

Loa,

To clarify a bit better, what I'm trying to get clarified into the text is why the ELI value as an ESPL
needs to be an exception (as the draft indicates).  I believe it is because forbidding an ESPL of 7
can break some existing and deployed versions of RFC 6790 such that the transit traffic flows are affected.
There may also be implementations of RFC 6790 that aren't affected.

Regards,
Alia


On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas <akatlas@gmail.com> wrote:
Loa,

On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson <loa@pi.nu> wrote:
Alia,

Two comments on this.

First a nit "An LSR wishing to insert an ...", LSR are boxes and can't
wish anything for themselves, a Simple change would be "When an LSR
insert..."

Actually the same is true for the current text and should be changed the
same way.

[Alia] Sure - I took the original text and modified it. 

Second, and this is maybe more tricky - the reason given "simplify the
data plane implementation" is not true and might even be wrong.
The reason put always using the ELI as a "regular special purpose label"
is backwards compatibility.
I would claim that the treatment of the ELI is an (well motivated)
exception, but exceptions always mean that things get more complicated.

[Alia] There were three purposes to my suggested text change.  First, to specify that
an LSR MUST NOT insert the ELI as an ESPL.   Second, to say that a receiving LSR
MAY choose to not discard a packet with the ELI as an ESPL.  Third, I wanted to see
a clearer justification for why this exception is worth making.

[Alia] Since the whole draft is about a data-plane change, what we've been putting in doesn't
really articulate the full problem.  Prelim text would around that would be better as:

"ELI is an exception because each LSR examines the whole label stack to see if the ELI
appears; pre-existing implementations of [Entropy-Label] do this examination without verifying
that the label above the ELI is not XL.  If a packet used an ESPL of 7 and that did not mean
ELI, then when that packet transited deployed LSRs, which implement [Entropy-Label] and not this document, 
the meaning of the ESPL would be misinterpreted.  Such a misinterpretation could result in poor traffic behavior (large flows,
reordered flows, etc.) depending on the label after the ESPL of 7.  It is to avoid such issues that ELI is defined as an exception
that can appear as an regular special label or as an ESPL with the same value of 7."
 
What do you think?

Alia

I don't want to propose a final text,but something along these lines:


"Label 7 (when received) retains its meaning as ELI whether a
 regular special purpose label or an ESPL; this is because of backwards
 compatibility with existing implemented and deployed code and hardware
 that looks for the ELI without verifying if the previous label
 is XL or not. However, when an LSR insert an entropy label it SHOULD
 insert the ELI as a regular special purpose label, not as an ESPL."

/Loa


On 2014-02-15 10:52, Alia Atlas wrote:
Adrian and others,

Having reviewed the 05 of this draft and this thread, I have the
following suggestions.  Other than these, I'm quite happy with how this
draft has improved.

a) In Sec 3.1, the following paragraph could be updated from:

"Label 7 (when received) retains its meaning as ELI whether a
regular special purpose label or an ESPL; this simplifies a transit
LSR's task of looking for entropy labels since it may just look for
label 7  and need not verify that the previous label in the stack is not
the XL 15. However, an LSR wishing to insert an entropy label SHOULD
insert label 7 as a regular special purpose label, not as an ESPL."


to:


"An LSR wishing to insert an entropy label MUST insert label value 7 (meaning ELI) as a regular special purpose

label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data plane.  However, to simplify


the data plane implementation for Entropy Labels, an implementation MAY

interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, an implementation

MAY choose to not treat the packet as malformedand thus discard it.  The data plane simplification thus enabled


is the ability to determine if any label value is 7 without needing to verify that the previous label in the stack is not the XL value of 15."


b)In Sec 3.2: "An RFC with at  least Informational status is required."   How is this different from IETF Review in RFC 5226?  Do BCPs count? What is "at least Informational status"?



On the concern about Pervasive Monitoring, the only advantage that (XL,
ESPL) offers is that the labels wouldn't (eventually) be hashed for
load-balancing.  Otherwise, the label stack offers the ability for
meta-data already where only the receiver would need to understand it.
  Consistent paths are very useful, but there are other ways of doing
this already - with the most trivial being just using label 15.  I have
a hard time seeing this as a new attack vector (but I'm not
professionally paranoid yet).

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <adrian@olddog.co.uk
<mailto:adrian@olddog.co.uk>> wrote:

    [snip]

     > >> XL   The Extension Label that indicates that an extended special
     > >>         purpose label follows.
     > >>
     > >> ESPL An Extended Special Purpose Label.
     > >>
     > >> Something that I think would be worthwhile clarifying right at the
     > >> front is that a label is an ESPL IFF it is preceded by an XL.
     > >> It might even be worth noting that really we have a new label
    type:
     > >> a label couple in which the first label defines the type of the
     > >> second label and neither are of any use as individual labels.
     > > I can see how you would see this as a new label type. Maybe
    "compound"
     > > rather than "couple".
     > > However, I am not convinced that it is new that one label leads
    to the
    semantics
     > > of the next (for example the entropy label).
     > > What is more, I am not sure that there will be more than this
    instance of
    this
     > > type of tight coupling.
     > > So I would rather leave this point out.
     > I can foresee other cases where we might use label pairs to
    mitigate the
     > 20bit limit. I am sure it has been discussed, so creating the
    reference
     > might be useful. Just because this was not done in EL, does not
    mean that
     > we should not set down the concept here.
     >
     > However I agree compound would be a better term.
     >
     > >
     > > But as to clarifying ESPL: yes.
     > > The XP definition is, I think, clear.
     > > How about...
     > >
     > > ESPL An Extended Special Purpose Label. A Special Purpose Label
    that
     > >       is placed in the label stack after the Extension Label.
     >
     > Yes. Indeed it MUST be placed be placed there, however the definition
     > above is fine.

    OK, I updated to...

        ESPL An Extended Special Purpose Label. A Special Purpose Label that
             is placed in the label stack after the Extension Label.  The
             combination of XL and ESPL might be regarded as a new form of
             "compound label" comprising more than one consecutive entry in
             the label stack.

    ..to cover your other point as well.

     > >> ======
     > >>
     > >> I think that the draft will need to provide some guidance
     > >> on when to allocate a 0..15 and when to allocate an ESPL.
     > >>
     > >> I imagine that a 0..15 should only be used when it can be shown
     > >> that the extra stack space of forwarding time is burdensome
     > >> but that is a question that the WG should explicitly consider.
     > > We discussed this at some point on the MPLS list (many
    centuries ago, I
    think)
     > > and reached no conclusion.
     > > The primary purpose of the XL is to handle the time when 0..15
    is depleted.
     > > You're right that we could encourage people to start using
    ESPLs now before
     > > 0..15 is depleted. But it is hard to make the case for
    requiring it when
    there
     > > is still some of 0..15 available and the rate of burn is not so
    high.
     > >
     > > We could put in some text like...
     > >
     > > When allocating a new Special Purpose Label, protocol designers
    should
     > > consider whether they could, instead, use an Extended Special
    Purpose
     > > Label. Doing so would help to preserve the scarce resources of
    Special
     > > Purpose Labels for use in cases where minimizing the label
    stack size is
     > > particularly important.
     >
     > That would be useful text.

    Added as new section 3.1.2 with slight tweak to wording.

    [snip]

     > >>     6.  [RFC6790] says that special purpose labels MUST NOT be
    used for
     > >>        load balancing.  The same logic applies to extended special
     > >>        purpose labels (ESPLs).  Thus, this document specifies
    that ESPLs
     > >>        MUST NOT be used for load balancing.  It is noted that
    existing
     > >>        implementations may violate this, as they do not look
    for the XL
     > >>        and thus for ESPLs.  The consequence is that if ESPLs
    are used in
     > >>        some packets of a flow, these packets may be delivered on
     > >>        different paths and so could be re-ordered.  However, it is
     > >>        important to specify the correct behavior for future
     > >>        implementations, hence the use of "MUST NOT".
     > >>
     > >> I would suggest that most implementations do violate this. I would
     > >> also suggest that it seems unlikely that you will get to the point
     > >> where it is not violated in the foreseeable future.
     > > I can't tell whether there is an action here for us.
     > > There are two "violations" that exist:
     > > 1. Some implementations violate 6790. Not sure what we can do about
     > > that in this document. Note that the entropy label can help
    with this
     > > but only to a limited extent since the implementations that
    violate 6790
     > > probably also fail to recognise the entropy label.
     > > 2. Implementations that conform to 6790 will understand that
    the XL is
     > > a special purpose label and will not use it to load balance.
    But they will
     > > not necessarily understand that the next label is an ESPL that
    must be
     > > skipped as well. Again, there is nothing we can do about this
    except to
     > > note it (done) and possibly to use the EL further up the stack.
     >
     > My point was that the may in "It is noted that existing
    implementations may
     > violate this" was a little soft. Most implementations, except the
    latest
     > designs of maybe as few as a single vendor, would certainly
    violate this.
     >
     > Also of course you are making a statement of fact and not of
    permission
     > so I think it may be more precise to say:
     >
     > It is noted that most existing
     > implementations currently violate this, as they do not look for
    the XL
     > and thus for ESPLs.

    OK.

    I've gone with...

            It is noted that existing
            implementations would violate this, as they do not recognise XL
            as anything other than a single Special Purpose Label and will
            not expect an ESPL to follow.

    [snip]

     > >>    Label 7 (when received) retains its meaning as ELI whether
    a regular
     > >>    special purpose label or an ESPL; this simplifies a transit
    LSR's
     > >>    task of looking for entropy labels since it may just look
    for label 7
     > >>    and need not verify that the previous label in the stack is
    not the
     > >>    XL 15.  However, an LSR wishing to insert an entropy label
    SHOULD
     > >>    insert label 7 as a regular special purpose label, not as
    an ESPL.
     > >>
     > >> Why is this not a MUST! There is no ESPL in the wild running an
     > >> alternate behaviour, so why not simply mandate this?
     > > If this was a MUST then there would be no case for handling
    Label 7 after
    XL.
     > > There was some concern I believe that implementations might
    have a path that
     > > puts them on to XL insertion processing and then consider what
    to do next.
    At
     > > that point they might decide that label 7 is needed.
     > >
     > > It seems esoteric, but I couldn't see a reason to prohibit it.
     > >
     > > Maybe "MUST NOT include" and "SHOULD process when received" are
     > > compatible.
     > >
     > > Part of me hates the idea of this change just because I don't
    want another
     > > working group last call before we can move forward. How
    important is it?
     >
     > The reason to be stricter at the TX is that the forwarding path
    can be
     > simpler at the RX. I cannot see how you would get to the point of
    putting
     > in L15 and then saying "you know I need to put in L7"
    particularly as no
     > other 0..15 is allowed.
     > Normally I would think that you would put in the compound label
    as a pair
     > and that is a good reason to use the compound label concept.
     >
     > Also I see no reason for the inconsistency between L7 and all of the
     > other L0..L15 cases.
     >
     > So I think that it's OK, but probably silly to allow L0..L15, but
    to allow
     > the exception of just L7 just complicates things without good cause.

    I'm not in a position to argue on this one as the debate and text
    were driven by
    others.

    I believe that the claim was that allowing L7 to be inserted
    anywhere made
    processing it easier not harder at the receiver.
    Note that {XL,7} would be an error case in your way of looking at
    things so the
    receiver should (must?) not process it.
    But the claim was that h/w will simply search the stack for L7 so
    that allowing
    {L7} and {XL, L7} to be treated in the same way made life easier for
    the h/w.

    Bottom line, however, seems to be that you have a preference for
    doing it one
    way, and the WG has a preference for doing it a different way. How
    to resolve
    that?

    Given the posting deadline, I've not made any change for this. We
    can continue
    to discuss.

     > >> ========
     > >>
     > >> 3.2.  Process for Retiring Special Purpose Labels

    [snip]

     > >> Secondly I think the timescales are ridiculously optimistic.
    To get
     > >> a label out of circulation in 24 months seems most unlikely. Also
     > >> 6 month checks is a lot of work.
     > >>
     > >> A more realistic schedule would be to poll at 12month
    intervals until
     > >> such time as it is determined that reallocation would do not
    harm and
     > >> then give a further 12 months notice.
     > > Erm, that's what the text says, I think...
     > >
     > >         12 months after the RFC deprecating the label value is
    published,
     > >         an IETF-wide survey may be conducted to determine if the
     > >         deprecated label value is still in use.
     > >
     > > The "may" in that means that the earliest you can "poll" is 12
    months after
    the
     > > deprecation RFC is published (noting that the RFC won't even
    get published
     > > until lots of discussion and consensus to deprecate).
     > > Then, *if* the poll response is OK, and then not earlier than
    24 months
    after
     > > the deprecation RFC is published, publication can be requested
    for a new RFC
     > > (which means that the WG has already reached consensus, and that a
     > > subsequent IETF last call will be held).
     > >
     > > Frankly, I think that this process is only likely to be
    executed for SPLs
    that
     > > are allocated "in error", because other stuff will probably be
    in the field.
    Can
     > > you think of a label that was allocated in error? I can :-)
     >
     > This seems like a lot of text to specify in detail something we
    would never
     > run. In protocols, including this type of protocol, the fewer
    words used to
     > describe the rarely executed exception path the better.

    The case was considered worthy of inclusion because the SPL range is
    so small.
    If any SPL can be reclaimed at some future time it will be very
    valuable and so
    a mechanism needs to be documented against that happy day.

    [snip]
     > >> ===========
    [snip]
     > >> However that brings me to
     > >> suggest that you probably need to write an OPs section and
     > >> you might want to think about the PM implications of the extra
     > >> metatdata in the packets.
     > >
     > > What OPS issues had you in mind that need to be addressed? I am
    a fan of OPS
     > > sections, but not a fan of empty OPS sections, and when we
    looked through
     > > RFC 6123 (which is my favourite crib for what to describe wrt
    manageability)
    we
     > > didn't see anything that has changed from pre-existing MPLS.
     > >
     > > What metadata are you talking about? Is an existing special
    purpose label
     > > metadata? If so, the PM issues are pre-existing. Is there
    something special
     > > introduced by this I-D that constitutes metadata?
     >
     > Well what follows an XL is certainly metadata, and one application is
     > certainly to introduce tags that would alert the PM devices to
    take an
     > interest.

    OK it is a form of metadata as existing SPLs are metadata.
    The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI
    that the SPL
    is there.
    What has changed?
    We could certainly sit down and write an I-D about the implications
    of using
    MPLS in an environment where PM might be present (BTW, I assume this is
    Pervasive Monitoring. Would be embarrassing to find you meant
    something else
    :-). I think such an I-D would discuss SPLs as indicative metadata
    and would
    then note that ESPLs are in the same category.
    Is *this* the I-D in which to have that discussion?

    [snip]

    I'll post the revised I-D in a few minutes and others can throw
    vegetables
    (rotten or otherwise).

    Adrian

    _______________________________________________
    mpls mailing list
    mpls@ietf.org <mailto:mpls@ietf.org>
    https://www.ietf.org/mailman/listinfo/mpls





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


--


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




_______________________________________________
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





-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070109060504020208000209-- From nobody Tue Feb 18 09:17: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 6974F1A06C8 for ; Tue, 18 Feb 2014 09:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 2b-ZiHGcUe18 for ; Tue, 18 Feb 2014 09:17:26 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2681A06B4 for ; Tue, 18 Feb 2014 09:17:25 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id f10so15781502yha.35 for ; Tue, 18 Feb 2014 09:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zLDJwP27itB/pLR7pVgAhLpc1W5aS+L2JdFfSqjvs7o=; b=yVxGAQWGVOihcEsaeTwsqsuhCJFuSeCZi4Xsot+kediE1n1Pbprhalbe0u3aToB5T3 rnc35oTrX+ezWFK7zJ7/gJGJZKUvzxOKU7jv26Q8vv02neOij/gc/LruIYjZy5nKiJm8 /c5cCmOKfBEhCQG27xuUHEcZfL4Tbcspg5v6nee2bJWGLi04QMMb6sk51Oo/IhWidNC2 OVYUuaf7aNSVxhCiE04s1ZWAhS7AmCr6Sxxayp0RldKZwnODtRMexF4fZGItJ4CkYUv/ 66gAfZbVTQwMQkRVbl2plFAJHjKAAFlBG7/tTgRFGoPI+JBr2bgEqIklbnBl/jtDpGhP aw7A== MIME-Version: 1.0 X-Received: by 10.236.189.202 with SMTP id c50mr90099yhn.139.1392743842481; Tue, 18 Feb 2014 09:17:22 -0800 (PST) Received: by 10.170.194.140 with HTTP; Tue, 18 Feb 2014 09:17:22 -0800 (PST) Received: by 10.170.194.140 with HTTP; Tue, 18 Feb 2014 09:17:22 -0800 (PST) In-Reply-To: <53039174.1040807@cisco.com> References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> <5303725C.6070007@cisco.com> <53039174.1040807@cisco.com> Date: Tue, 18 Feb 2014 12:17:22 -0500 Message-ID: From: Alia Atlas To: Stewart Bryant Content-Type: multipart/alternative; boundary=089e0160ac2cfe8c4a04f2b171ca Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1zcTJae_Fg1dnyrw_ViPaIQk72s Cc: mpls@ietf.org, "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 17:17:34 -0000 --089e0160ac2cfe8c4a04f2b171ca Content-Type: text/plain; charset=ISO-8859-1 Stewart, Yes, I agree with that text. MUST send as 7 and MUST NOT as the compound. That's what was lacking in Loa's text. With that behavior, I'm not sure that it needs to be an exception for receiving, but ok with what the WG says. Alia On Feb 18, 2014 11:59 AM, "Stewart Bryant" wrote: > Alia > > Maybe we are out of sync. > > I think that the text should say that L7 MUST be sent as a single label, > and > MUST NOT be sent as a compound/extended label, and I think simplicity > alone is sufficient justification. > > Stewart > > On 18/02/2014 14:55, Alia Atlas wrote: > > Stewart, > > If you think that Loa's text is sufficiently strong about not sending > XL, ESPL, then I am fine with his text. > I was striving for more clarity on why the exception was made and > suggesting MUST rather than SHOULD. > > Loa's text says: > > ""Label 7 (when received) retains its meaning as ELI whether a > > regular special purpose label or an ESPL; this is because of >>> backwards >>> compatibility with existing implemented and deployed code and hardware >>> that looks for the ELI without verifying if the previous label >>> is XL or not. However, when an LSR insert an entropy label it SHOULD >>> insert the ELI as a regular special purpose label, not as an ESPL." >> >> This doesn't explain that bad traffic side-effects could happen, but > I think the wording for why the > exception is there is clear. > > Alia > > > On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant wrote: > >> This has me worried. >> >> Assume that nothing implements ESPL yet, there is no reason why >> all SPL implementations are not required to send L7 only as >> a regular (single) SPL. As Loa says, this would be a useful >> simplification, and one which I raised earlier with the authors. >> >> If that is the case, a parser will always get it right. >> >> The only problem I see is if a compound label is ever created >> L15, Lx, <0..maxLabel> but one one has defined such an >> Lx and to do so would be unwise. >> >> So I don't think Alia is correct in her proposed text change and >> I have yet to see a valid technical reason for not accepting Loa's >> proposed change. >> >> - Stewart >> >> >> On 15/02/2014 17:09, Alia Atlas wrote: >> >> [+ietf] >> >> Loa, >> >> To clarify a bit better, what I'm trying to get clarified into the text >> is why the ELI value as an ESPL >> needs to be an exception (as the draft indicates). I believe it is >> because forbidding an ESPL of 7 >> can break some existing and deployed versions of RFC 6790 such that the >> transit traffic flows are affected. >> There may also be implementations of RFC 6790 that aren't affected. >> >> Regards, >> Alia >> >> >> On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas wrote: >> >>> Loa, >>> >>> On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson wrote: >>> >>>> Alia, >>>> >>>> Two comments on this. >>>> >>>> First a nit "An LSR wishing to insert an ...", LSR are boxes and can't >>>> wish anything for themselves, a Simple change would be "When an LSR >>>> insert..." >>>> >>>> Actually the same is true for the current text and should be changed the >>>> same way. >>>> >>> >>> [Alia] Sure - I took the original text and modified it. >>> >>> Second, and this is maybe more tricky - the reason given "simplify the >>>> data plane implementation" is not true and might even be wrong. >>>> The reason put always using the ELI as a "regular special purpose label" >>>> is backwards compatibility. >>>> I would claim that the treatment of the ELI is an (well motivated) >>>> exception, but exceptions always mean that things get more complicated. >>>> >>> >>> [Alia] There were three purposes to my suggested text change. First, >>> to specify that >>> an LSR MUST NOT insert the ELI as an ESPL. Second, to say that a >>> receiving LSR >>> MAY choose to not discard a packet with the ELI as an ESPL. Third, I >>> wanted to see >>> a clearer justification for why this exception is worth making. >>> >>> [Alia] Since the whole draft is about a data-plane change, what we've >>> been putting in doesn't >>> really articulate the full problem. Prelim text would around that would >>> be better as: >>> >>> "ELI is an exception because each LSR examines the whole label stack >>> to see if the ELI >>> appears; pre-existing implementations of [Entropy-Label] do this >>> examination without verifying >>> that the label above the ELI is not XL. If a packet used an ESPL of 7 >>> and that did not mean >>> ELI, then when that packet transited deployed LSRs, which implement >>> [Entropy-Label] and not this document, >>> the meaning of the ESPL would be misinterpreted. Such a >>> misinterpretation could result in poor traffic behavior (large flows, >>> reordered flows, etc.) depending on the label after the ESPL of 7. It >>> is to avoid such issues that ELI is defined as an exception >>> that can appear as an regular special label or as an ESPL with the same >>> value of 7." >>> >>> What do you think? >>> >>> Alia >>> >>> I don't want to propose a final text,but something along these lines: >>>> >>>> >>>> "Label 7 (when received) retains its meaning as ELI whether a >>>> regular special purpose label or an ESPL; this is because of backwards >>>> compatibility with existing implemented and deployed code and hardware >>>> that looks for the ELI without verifying if the previous label >>>> is XL or not. However, when an LSR insert an entropy label it SHOULD >>>> insert the ELI as a regular special purpose label, not as an ESPL." >>>> >>>> /Loa >>>> >>>> >>>> On 2014-02-15 10:52, Alia Atlas wrote: >>>> >>>>> Adrian and others, >>>>> >>>>> Having reviewed the 05 of this draft and this thread, I have the >>>>> following suggestions. Other than these, I'm quite happy with how this >>>>> draft has improved. >>>>> >>>>> a) In Sec 3.1, the following paragraph could be updated from: >>>>> >>>>> "Label 7 (when received) retains its meaning as ELI whether a >>>>> regular special purpose label or an ESPL; this simplifies a transit >>>>> LSR's task of looking for entropy labels since it may just look for >>>>> label 7 and need not verify that the previous label in the stack is >>>>> not >>>>> the XL 15. However, an LSR wishing to insert an entropy label SHOULD >>>>> insert label 7 as a regular special purpose label, not as an ESPL." >>>>> >>>>> >>>>> to: >>>>> >>>>> >>>>> "An LSR wishing to insert an entropy label MUST insert label value 7 >>>>> (meaning ELI) as a regular special purpose >>>>> >>>>> label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the >>>>> data plane. However, to simplify >>>>> >>>>> >>>>> the data plane implementation for Entropy Labels, an implementation MAY >>>>> >>>>> interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and >>>>> 8-15, an implementation >>>>> >>>>> MAY choose to not treat the packet as malformedand thus discard it. >>>>> The data plane simplification thus enabled >>>>> >>>>> >>>>> is the ability to determine if any label value is 7 without needing to >>>>> verify that the previous label in the stack is not the XL value of 15." >>>>> >>>>> >>>>> b)In Sec 3.2: "An RFC with at least Informational status is >>>>> required." How is this different from IETF Review in RFC 5226? Do BCPs >>>>> count? What is "at least Informational status"? >>>>> >>>>> >>>>> >>>>> On the concern about Pervasive Monitoring, the only advantage that (XL, >>>>> ESPL) offers is that the labels wouldn't (eventually) be hashed for >>>>> load-balancing. Otherwise, the label stack offers the ability for >>>>> meta-data already where only the receiver would need to understand it. >>>>> Consistent paths are very useful, but there are other ways of doing >>>>> this already - with the most trivial being just using label 15. I have >>>>> a hard time seeing this as a new attack vector (but I'm not >>>>> professionally paranoid yet). >>>>> >>>>> Alia >>>>> >>>>> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel >>>> > wrote: >>>>> >>>>> [snip] >>>>> >>>>> > >> XL The Extension Label that indicates that an extended >>>>> special >>>>> > >> purpose label follows. >>>>> > >> >>>>> > >> ESPL An Extended Special Purpose Label. >>>>> > >> >>>>> > >> Something that I think would be worthwhile clarifying right >>>>> at the >>>>> > >> front is that a label is an ESPL IFF it is preceded by an XL. >>>>> > >> It might even be worth noting that really we have a new label >>>>> type: >>>>> > >> a label couple in which the first label defines the type of >>>>> the >>>>> > >> second label and neither are of any use as individual labels. >>>>> > > I can see how you would see this as a new label type. Maybe >>>>> "compound" >>>>> > > rather than "couple". >>>>> > > However, I am not convinced that it is new that one label >>>>> leads >>>>> to the >>>>> semantics >>>>> > > of the next (for example the entropy label). >>>>> > > What is more, I am not sure that there will be more than this >>>>> instance of >>>>> this >>>>> > > type of tight coupling. >>>>> > > So I would rather leave this point out. >>>>> > I can foresee other cases where we might use label pairs to >>>>> mitigate the >>>>> > 20bit limit. I am sure it has been discussed, so creating the >>>>> reference >>>>> > might be useful. Just because this was not done in EL, does not >>>>> mean that >>>>> > we should not set down the concept here. >>>>> > >>>>> > However I agree compound would be a better term. >>>>> > >>>>> > > >>>>> > > But as to clarifying ESPL: yes. >>>>> > > The XP definition is, I think, clear. >>>>> > > How about... >>>>> > > >>>>> > > ESPL An Extended Special Purpose Label. A Special Purpose >>>>> Label >>>>> that >>>>> > > is placed in the label stack after the Extension Label. >>>>> > >>>>> > Yes. Indeed it MUST be placed be placed there, however the >>>>> definition >>>>> > above is fine. >>>>> >>>>> OK, I updated to... >>>>> >>>>> ESPL An Extended Special Purpose Label. A Special Purpose >>>>> Label that >>>>> is placed in the label stack after the Extension Label. >>>>> The >>>>> combination of XL and ESPL might be regarded as a new >>>>> form of >>>>> "compound label" comprising more than one consecutive >>>>> entry in >>>>> the label stack. >>>>> >>>>> ..to cover your other point as well. >>>>> >>>>> > >> ====== >>>>> > >> >>>>> > >> I think that the draft will need to provide some guidance >>>>> > >> on when to allocate a 0..15 and when to allocate an ESPL. >>>>> > >> >>>>> > >> I imagine that a 0..15 should only be used when it can be >>>>> shown >>>>> > >> that the extra stack space of forwarding time is burdensome >>>>> > >> but that is a question that the WG should explicitly >>>>> consider. >>>>> > > We discussed this at some point on the MPLS list (many >>>>> centuries ago, I >>>>> think) >>>>> > > and reached no conclusion. >>>>> > > The primary purpose of the XL is to handle the time when 0..15 >>>>> is depleted. >>>>> > > You're right that we could encourage people to start using >>>>> ESPLs now before >>>>> > > 0..15 is depleted. But it is hard to make the case for >>>>> requiring it when >>>>> there >>>>> > > is still some of 0..15 available and the rate of burn is not >>>>> so >>>>> high. >>>>> > > >>>>> > > We could put in some text like... >>>>> > > >>>>> > > When allocating a new Special Purpose Label, protocol >>>>> designers >>>>> should >>>>> > > consider whether they could, instead, use an Extended Special >>>>> Purpose >>>>> > > Label. Doing so would help to preserve the scarce resources of >>>>> Special >>>>> > > Purpose Labels for use in cases where minimizing the label >>>>> stack size is >>>>> > > particularly important. >>>>> > >>>>> > That would be useful text. >>>>> >>>>> Added as new section 3.1.2 with slight tweak to wording. >>>>> >>>>> [snip] >>>>> >>>>> > >> 6. [RFC6790] says that special purpose labels MUST NOT >>>>> be >>>>> used for >>>>> > >> load balancing. The same logic applies to extended >>>>> special >>>>> > >> purpose labels (ESPLs). Thus, this document specifies >>>>> that ESPLs >>>>> > >> MUST NOT be used for load balancing. It is noted that >>>>> existing >>>>> > >> implementations may violate this, as they do not look >>>>> for the XL >>>>> > >> and thus for ESPLs. The consequence is that if ESPLs >>>>> are used in >>>>> > >> some packets of a flow, these packets may be >>>>> delivered on >>>>> > >> different paths and so could be re-ordered. However, >>>>> it is >>>>> > >> important to specify the correct behavior for future >>>>> > >> implementations, hence the use of "MUST NOT". >>>>> > >> >>>>> > >> I would suggest that most implementations do violate this. I >>>>> would >>>>> > >> also suggest that it seems unlikely that you will get to the >>>>> point >>>>> > >> where it is not violated in the foreseeable future. >>>>> > > I can't tell whether there is an action here for us. >>>>> > > There are two "violations" that exist: >>>>> > > 1. Some implementations violate 6790. Not sure what we can do >>>>> about >>>>> > > that in this document. Note that the entropy label can help >>>>> with this >>>>> > > but only to a limited extent since the implementations that >>>>> violate 6790 >>>>> > > probably also fail to recognise the entropy label. >>>>> > > 2. Implementations that conform to 6790 will understand that >>>>> the XL is >>>>> > > a special purpose label and will not use it to load balance. >>>>> But they will >>>>> > > not necessarily understand that the next label is an ESPL that >>>>> must be >>>>> > > skipped as well. Again, there is nothing we can do about this >>>>> except to >>>>> > > note it (done) and possibly to use the EL further up the >>>>> stack. >>>>> > >>>>> > My point was that the may in "It is noted that existing >>>>> implementations may >>>>> > violate this" was a little soft. Most implementations, except >>>>> the >>>>> latest >>>>> > designs of maybe as few as a single vendor, would certainly >>>>> violate this. >>>>> > >>>>> > Also of course you are making a statement of fact and not of >>>>> permission >>>>> > so I think it may be more precise to say: >>>>> > >>>>> > It is noted that most existing >>>>> > implementations currently violate this, as they do not look for >>>>> the XL >>>>> > and thus for ESPLs. >>>>> >>>>> OK. >>>>> >>>>> I've gone with... >>>>> >>>>> It is noted that existing >>>>> implementations would violate this, as they do not >>>>> recognise XL >>>>> as anything other than a single Special Purpose Label and >>>>> will >>>>> not expect an ESPL to follow. >>>>> >>>>> [snip] >>>>> >>>>> > >> Label 7 (when received) retains its meaning as ELI whether >>>>> a regular >>>>> > >> special purpose label or an ESPL; this simplifies a >>>>> transit >>>>> LSR's >>>>> > >> task of looking for entropy labels since it may just look >>>>> for label 7 >>>>> > >> and need not verify that the previous label in the stack >>>>> is >>>>> not the >>>>> > >> XL 15. However, an LSR wishing to insert an entropy label >>>>> SHOULD >>>>> > >> insert label 7 as a regular special purpose label, not as >>>>> an ESPL. >>>>> > >> >>>>> > >> Why is this not a MUST! There is no ESPL in the wild running >>>>> an >>>>> > >> alternate behaviour, so why not simply mandate this? >>>>> > > If this was a MUST then there would be no case for handling >>>>> Label 7 after >>>>> XL. >>>>> > > There was some concern I believe that implementations might >>>>> have a path that >>>>> > > puts them on to XL insertion processing and then consider what >>>>> to do next. >>>>> At >>>>> > > that point they might decide that label 7 is needed. >>>>> > > >>>>> > > It seems esoteric, but I couldn't see a reason to prohibit it. >>>>> > > >>>>> > > Maybe "MUST NOT include" and "SHOULD process when received" >>>>> are >>>>> > > compatible. >>>>> > > >>>>> > > Part of me hates the idea of this change just because I don't >>>>> want another >>>>> > > working group last call before we can move forward. How >>>>> important is it? >>>>> > >>>>> > The reason to be stricter at the TX is that the forwarding path >>>>> can be >>>>> > simpler at the RX. I cannot see how you would get to the point >>>>> of >>>>> putting >>>>> > in L15 and then saying "you know I need to put in L7" >>>>> particularly as no >>>>> > other 0..15 is allowed. >>>>> > Normally I would think that you would put in the compound label >>>>> as a pair >>>>> > and that is a good reason to use the compound label concept. >>>>> > >>>>> > Also I see no reason for the inconsistency between L7 and all >>>>> of the >>>>> > other L0..L15 cases. >>>>> > >>>>> > So I think that it's OK, but probably silly to allow L0..L15, >>>>> but >>>>> to allow >>>>> > the exception of just L7 just complicates things without good >>>>> cause. >>>>> >>>>> I'm not in a position to argue on this one as the debate and text >>>>> were driven by >>>>> others. >>>>> >>>>> I believe that the claim was that allowing L7 to be inserted >>>>> anywhere made >>>>> processing it easier not harder at the receiver. >>>>> Note that {XL,7} would be an error case in your way of looking at >>>>> things so the >>>>> receiver should (must?) not process it. >>>>> But the claim was that h/w will simply search the stack for L7 so >>>>> that allowing >>>>> {L7} and {XL, L7} to be treated in the same way made life easier >>>>> for >>>>> the h/w. >>>>> >>>>> Bottom line, however, seems to be that you have a preference for >>>>> doing it one >>>>> way, and the WG has a preference for doing it a different way. How >>>>> to resolve >>>>> that? >>>>> >>>>> Given the posting deadline, I've not made any change for this. We >>>>> can continue >>>>> to discuss. >>>>> >>>>> > >> ======== >>>>> > >> >>>>> > >> 3.2. Process for Retiring Special Purpose Labels >>>>> >>>>> [snip] >>>>> >>>>> > >> Secondly I think the timescales are ridiculously optimistic. >>>>> To get >>>>> > >> a label out of circulation in 24 months seems most unlikely. >>>>> Also >>>>> > >> 6 month checks is a lot of work. >>>>> > >> >>>>> > >> A more realistic schedule would be to poll at 12month >>>>> intervals until >>>>> > >> such time as it is determined that reallocation would do not >>>>> harm and >>>>> > >> then give a further 12 months notice. >>>>> > > Erm, that's what the text says, I think... >>>>> > > >>>>> > > 12 months after the RFC deprecating the label value is >>>>> published, >>>>> > > an IETF-wide survey may be conducted to determine if >>>>> the >>>>> > > deprecated label value is still in use. >>>>> > > >>>>> > > The "may" in that means that the earliest you can "poll" is 12 >>>>> months after >>>>> the >>>>> > > deprecation RFC is published (noting that the RFC won't even >>>>> get published >>>>> > > until lots of discussion and consensus to deprecate). >>>>> > > Then, *if* the poll response is OK, and then not earlier than >>>>> 24 months >>>>> after >>>>> > > the deprecation RFC is published, publication can be requested >>>>> for a new RFC >>>>> > > (which means that the WG has already reached consensus, and >>>>> that a >>>>> > > subsequent IETF last call will be held). >>>>> > > >>>>> > > Frankly, I think that this process is only likely to be >>>>> executed for SPLs >>>>> that >>>>> > > are allocated "in error", because other stuff will probably be >>>>> in the field. >>>>> Can >>>>> > > you think of a label that was allocated in error? I can :-) >>>>> > >>>>> > This seems like a lot of text to specify in detail something we >>>>> would never >>>>> > run. In protocols, including this type of protocol, the fewer >>>>> words used to >>>>> > describe the rarely executed exception path the better. >>>>> >>>>> The case was considered worthy of inclusion because the SPL range >>>>> is >>>>> so small. >>>>> If any SPL can be reclaimed at some future time it will be very >>>>> valuable and so >>>>> a mechanism needs to be documented against that happy day. >>>>> >>>>> [snip] >>>>> > >> =========== >>>>> [snip] >>>>> > >> However that brings me to >>>>> > >> suggest that you probably need to write an OPs section and >>>>> > >> you might want to think about the PM implications of the >>>>> extra >>>>> > >> metatdata in the packets. >>>>> > > >>>>> > > What OPS issues had you in mind that need to be addressed? I >>>>> am >>>>> a fan of OPS >>>>> > > sections, but not a fan of empty OPS sections, and when we >>>>> looked through >>>>> > > RFC 6123 (which is my favourite crib for what to describe wrt >>>>> manageability) >>>>> we >>>>> > > didn't see anything that has changed from pre-existing MPLS. >>>>> > > >>>>> > > What metadata are you talking about? Is an existing special >>>>> purpose label >>>>> > > metadata? If so, the PM issues are pre-existing. Is there >>>>> something special >>>>> > > introduced by this I-D that constitutes metadata? >>>>> > >>>>> > Well what follows an XL is certainly metadata, and one >>>>> application is >>>>> > certainly to introduce tags that would alert the PM devices to >>>>> take an >>>>> > interest. >>>>> >>>>> OK it is a form of metadata as existing SPLs are metadata. >>>>> The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI >>>>> that the SPL >>>>> is there. >>>>> What has changed? >>>>> We could certainly sit down and write an I-D about the implications >>>>> of using >>>>> MPLS in an environment where PM might be present (BTW, I assume >>>>> this is >>>>> Pervasive Monitoring. Would be embarrassing to find you meant >>>>> something else >>>>> :-). I think such an I-D would discuss SPLs as indicative metadata >>>>> and would >>>>> then note that ESPLs are in the same category. >>>>> Is *this* the I-D in which to have that discussion? >>>>> >>>>> [snip] >>>>> >>>>> I'll post the revised I-D in a few minutes and others can throw >>>>> vegetables >>>>> (rotten or otherwise). >>>>> >>>>> Adrian >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64<%2B46%20739%2081%2021%2064> >>>> >>> >>> >> >> >> _______________________________________________ >> mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls >> >> >> >> -- >> 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 > > --089e0160ac2cfe8c4a04f2b171ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Stewart,

Yes, I agree with that text.=A0 MUST send as 7 and MUST NOT = as the compound.=A0 That's what was lacking in Loa's text.

With that behavior, I'm not sure that it needs to be an = exception for receiving, but ok with what the WG says.

Alia

On Feb 18, 2014 11:59 AM, "Stewart Bryant&q= uot; <stbryant@cisco.com> w= rote:
=20 =20 =20
Alia

Maybe we are out of sync.

I think that the text should say that L7 MUST be sent as a single label, and
MUST NOT be sent as a compound/extended label, and I think simplicity
alone is sufficient justification.

Stewart

On 18/02/2014 14:55, Alia Atlas wrote:
=20
Stewart,

If you think that Loa's text is sufficiently strong about not sending XL, ESPL, then I am fine with his text.
I was striving for more clarity on why the exception was made and suggesting MUST rather than SHOULD.

Loa's text says:

""Label 7 (when received) retains its meaning as E= LI whether a
=A0regular special purpose label or an ESPL; this is because of backwards
=A0compatibility with existing implemented and deployed code and hardware
=A0that looks for the ELI without verifying if the previous label
=A0is XL or not. However, when an LSR insert an entropy label it SHOULD
=A0insert the ELI as a regular special purpose label, not as an ESPL."
This doesn't explain that bad traf= fic side-effects could happen, but I think the wording for why the
exception is there is clear.

Alia


On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant <stbryant@cisco.com> wrote:
This has me worried.

Assume that nothing implements ESPL yet, there is no reason why
all SPL implementations are not required to send L7 only as
a regular (single) SPL. As Loa says, this would be a useful
simplification, and one which I raised earlier with the authors.

If that is the case, a parser will always get it right.

The only problem I see is if a compound label is ever created
L15, Lx, <0..maxLabel> but one one has defined such an
Lx and to do so would be unwise.

So I don't think Alia is correct in her proposed text change and
I have yet to see a valid technical reason for not accepting Loa's
proposed change.

- Stewart


On 15/02/2014 17:09, Alia Atlas wrote:
[+ietf]

Loa,

To clarify a bit better, what I'm trying to get clarified into the text is why the ELI value as an ESPL
needs to be an exception (as the draft indicates). =A0I believe it is because forbidding an ESPL of 7
can break some existing and deployed versions of RFC 6790 such that the transit traffic flows are affected.
There may also be implementations of RFC 6790 that aren't affected.

Regards,
Alia


On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas <akatlas@gmail.= com> wrote:
Loa,

On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson <loa@pi.nu> wrote:
Alia,

Two comments on this.

First a nit "An LSR wishing = to insert an ...", LSR are boxe= s and can't
wish anything for themselves, a Simple change would be "Wh= en an LSR
insert..."

Actually the same is true for the current text and should be changed the
same way.

[Alia] Sure - I took the original text and modified it.=A0

Second, and this is maybe more tricky - the reason given "simplify the
data plane implementation" i= s not true and might even be wrong.
The reason put always using the ELI as a "regular specia= l purpose label"
is backwards compatibility.
I would claim that the treatment of the ELI is an (well motivated)
exception, but exceptions always mean that things get more complicated.

[Alia] There were three purposes to my suggested text change. =A0First, to specify that
an LSR MUST NOT insert the ELI as an ESPL. =A0 Second, to say that a receiving LSR
MAY choose to not discard a packet with the ELI as an ESPL. =A0Third, I wanted to see
a clearer justification for why this exception is worth making.

[Alia] Since the whole draft is about a data-plane change, what we've been putting in doesn't
really articulate the full problem. =A0Prelim text would around that would be better as:

"ELI is an exception becaus= e each LSR examines the whole label stack to see if the ELI
appears; pre-existing implementations of [Entropy-Label] do this examination without verifying
that the label above the ELI is not XL. =A0If a packet used an ESPL of 7 and that did not mean
ELI, then when that packet transited deployed LSRs, which implement [Entropy-Label] and not this document,=A0
the meaning of the ESPL would be misinterpreted. =A0Such a misinterpretation could result in poor traffic behavior (large flows,
reordered flows, etc.) depending on the label after the ESPL of 7. =A0It is to avoid such issues that ELI is defined as an exception
that can appear as an regular special label or as an ESPL with the same value of 7."
=A0
What do you think?

Alia

I don't want to propose a final text,but something along these lines:


"Label 7 (when received) retains its meaning as ELI whether a
=A0regular special purpose label or an ESPL; this is because of backwards
=A0compatibility with existing implemented and deployed code and hardware
=A0that looks for the ELI without verifying if the previous label
=A0is XL or not. However, when an LSR insert an entropy label it SHOULD
=A0insert the ELI as a regular special purpose label, not as an ESPL."

/Loa


On 2014-02-15 10:52, Alia Atlas wrote:
Adrian and others,

Having reviewed the 05 of this draft and this thread, I have the
following suggestions. =A0Other than these, I'= m quite happy with how this
draft has improved.

a) In Sec 3.1, the following paragraph could be updated from:

"Label 7 (when receive= d) retains its meaning as ELI whether a
regular special purpose label or an ESPL; this simplifies a transit
LSR's task of looking for entropy labels since it may just look for
label 7 =A0and need not verify that the previous label in the stack is not
the XL 15. However, an LSR wishing to insert an entropy label SHOULD
insert label 7 as a regular special purpose label, not as an ESPL."= ;


to:


"An LSR wishing to insert an entropy label MUST insert label value 7 (meaning ELI) as a regular special purpose

label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data plane. =A0However, to simplify


the data plane implementation for Entropy Labels, an implementation MAY

interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, an implementation

MAY choose to not treat the packet as malformedand thus discard it. =A0The data plane simplification thus enabled


is the ability to determine if any label value is 7 without needing to verify that the previous label in the stack is not the XL value of 15."


b)In Sec 3.2: "An RFC wi= th at =A0least Informational status is required." =A0= How is this different from IETF Review in RFC 5226? =A0Do BCPs count? What is "at least Informational status"?



On the concern about Pervasive Monitoring, the only advantage that (XL,
ESPL) offers is that the labels wouldn't (eventually) be hashed for
load-balancing. =A0Otherwise, the label stack offers the ability for
meta-data already where only the receiver would need to understand it.
=A0 Consistent paths are very useful, but there are other ways of doing
this already - with the most trivial being just using label 15. =A0I have a hard time seeing this as a new attack vector (but I'm not
professionally paranoid yet).

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <adrian@olddog.co.uk
<mailto:adrian@olddog.co.uk>&= gt; wrote:

=A0 =A0 [snip]

=A0 =A0 =A0> >> = XL =A0 The Extension Label that indicates that an extended special
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0 purpose label follows.
=A0 =A0 =A0> >><= br> =A0 =A0 =A0> >> ESPL An Extended Special Purpose Label. =A0 =A0 =A0> >><= br> =A0 =A0 =A0> >> Something that I think would be worthwhile clarifying right at the
=A0 =A0 =A0> >> front is that a label is an ESPL IFF it is preceded by an XL.
=A0 =A0 =A0> >> = It might even be worth noting that really we have a new label
=A0 =A0 type:
=A0 =A0 =A0> >> = a label couple in which the first label defines the type of the
=A0 =A0 =A0> >> second label and neither are of any use as individual labels.
=A0 =A0 =A0> > I ca= n see how you would see this as a new label type. Maybe
=A0 =A0 "compound&qu= ot;
=A0 =A0 =A0> > rath= er than "couple".<= br> =A0 =A0 =A0> > However, I am not convinced that it is new that one label leads
=A0 =A0 to the
=A0 =A0 semantics
=A0 =A0 =A0> > of t= he next (for example the entropy label).
=A0 =A0 =A0> > What= is more, I am not sure that there will be more than this
=A0 =A0 instance of
=A0 =A0 this
=A0 =A0 =A0> > type= of tight coupling.
=A0 =A0 =A0> > So I would rather leave this point out.
=A0 =A0 =A0> I can foresee other cases where we might use label pairs to
=A0 =A0 mitigate the
=A0 =A0 =A0> 20bit lim= it. I am sure it has been discussed, so creating the
=A0 =A0 reference
=A0 =A0 =A0> might be useful. Just because this was not done in EL, does not
=A0 =A0 mean that
=A0 =A0 =A0> we should not set down the concept here.
=A0 =A0 =A0>
=A0 =A0 =A0> However I agree compound would be a better term.
=A0 =A0 =A0>
=A0 =A0 =A0> >
=A0 =A0 =A0> > But = as to clarifying ESPL: yes.
=A0 =A0 =A0> > The = XP definition is, I think, clear.
=A0 =A0 =A0> > How about...
=A0 =A0 =A0> >
=A0 =A0 =A0> > ESPL= An Extended Special Purpose Label. A Special Purpose Label
=A0 =A0 that
=A0 =A0 =A0> > =A0 = =A0 =A0 is placed in the label stack after the Extension Label.
=A0 =A0 =A0>
=A0 =A0 =A0> Yes. Inde= ed it MUST be placed be placed there, however the definition
=A0 =A0 =A0> above is fine.

=A0 =A0 OK, I updated to...

=A0 =A0 =A0 =A0 ESPL An Extended Special Purpose Label. A Special Purpose Label that
=A0 =A0 =A0 =A0 =A0 =A0 = =A0is placed in the label stack after the Extension Label. =A0The
=A0 =A0 =A0 =A0 =A0 =A0 =A0combination of XL and ESPL might be regarded as a new form of
=A0 =A0 =A0 =A0 =A0 =A0 = =A0"compound label" comprising mo= re than one consecutive entry in
=A0 =A0 =A0 =A0 =A0 =A0 = =A0the label stack.

=A0 =A0 ..to cover your other point as well.

=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D
=A0 =A0 =A0> >><= br> =A0 =A0 =A0> >> = I think that the draft will need to provide some guidance
=A0 =A0 =A0> >> = on when to allocate a 0..15 and when to allocate an ESPL.
=A0 =A0 =A0> >><= br> =A0 =A0 =A0> >> = I imagine that a 0..15 should only be used when it can be shown
=A0 =A0 =A0> >> that the extra stack space of forwarding time is burdensome
=A0 =A0 =A0> >> = but that is a question that the WG should explicitly consider.
=A0 =A0 =A0> > We discussed this at some point on the MPLS list (many
=A0 =A0 centuries ago, I<= br> =A0 =A0 think)
=A0 =A0 =A0> > and reached no conclusion. =A0 =A0 =A0> > The primary purpose of the XL is to handle the time when 0..15
=A0 =A0 is depleted.
=A0 =A0 =A0> > You&= #39;re right that we could encourage people to start using
=A0 =A0 ESPLs now before<= br> =A0 =A0 =A0> > 0..1= 5 is depleted. But it is hard to make the case for
=A0 =A0 requiring it when=
=A0 =A0 there
=A0 =A0 =A0> > is still some of 0..15 available and the rate of burn is not so
=A0 =A0 high.
=A0 =A0 =A0> >
=A0 =A0 =A0> > We could put in some text like...
=A0 =A0 =A0> >
=A0 =A0 =A0> > When allocating a new Special Purpose Label, protocol designers
=A0 =A0 should
=A0 =A0 =A0> > consider whether they could, instead, use an Extended Special
=A0 =A0 Purpose
=A0 =A0 =A0> > Labe= l. Doing so would help to preserve the scarce resources of
=A0 =A0 Special
=A0 =A0 =A0> > Purp= ose Labels for use in cases where minimizing the label
=A0 =A0 stack size is
=A0 =A0 =A0> > particularly important.
=A0 =A0 =A0>
=A0 =A0 =A0> That woul= d be useful text.

=A0 =A0 Added as new section 3.1.2 with slight tweak to wording.

=A0 =A0 [snip]

=A0 =A0 =A0> >> = =A0 =A0 6. =A0[RFC6790] says that special purpose labels MUST NOT be
=A0 =A0 used for
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0load balancing. =A0The same logic applies to extended special
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0purpose labels (ESPLs). =A0Thus, this document specifies
=A0 =A0 that ESPLs
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0MUST NOT be used for load balancing. =A0It is noted that
=A0 =A0 existing
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0implementations ma= y violate this, as they do not look
=A0 =A0 for the XL
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0and thus for ESPLs= . =A0The consequence is that if ESPLs
=A0 =A0 are used in
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0some packets of a flow, these packets may be delivered on
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0different paths an= d so could be re-ordered. =A0However, it is
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0important to specify the correct behavior for future
=A0 =A0 =A0> >> = =A0 =A0 =A0 =A0implementations, hence the use of "MU= ST NOT".
=A0 =A0 =A0> >><= br> =A0 =A0 =A0> >> = I would suggest that most implementations do violate this. I would
=A0 =A0 =A0> >> also suggest that it seems unlikely that you will get to the point
=A0 =A0 =A0> >> where it is not violated in the foreseeable future.
=A0 =A0 =A0> > I ca= n't tell whether there is an action here for us. =A0 =A0 =A0> > Ther= e are two "violations&= quot; that exist:
=A0 =A0 =A0> > 1. S= ome implementations violate 6790. Not sure what we can do about
=A0 =A0 =A0> > that= in this document. Note that the entropy label can help
=A0 =A0 with this
=A0 =A0 =A0> > but only to a limited extent since the implementations that
=A0 =A0 violate 6790
=A0 =A0 =A0> > probably also fail to recognise the entropy label.
=A0 =A0 =A0> > 2. Implementations that conform to 6790 will understand that
=A0 =A0 the XL is
=A0 =A0 =A0> > a special purpose label and will not use it to load balance.
=A0 =A0 But they will
=A0 =A0 =A0> > not necessarily understand that the next label is an ESPL that
=A0 =A0 must be
=A0 =A0 =A0> > skip= ped as well. Again, there is nothing we can do about this
=A0 =A0 except to
=A0 =A0 =A0> > note= it (done) and possibly to use the EL further up the stack.
=A0 =A0 =A0>
=A0 =A0 =A0> My point = was that the may in "It = is noted that existing
=A0 =A0 implementations may
=A0 =A0 =A0> violate this" was a little soft. Most implementations, except the
=A0 =A0 latest
=A0 =A0 =A0> designs o= f maybe as few as a single vendor, would certainly
=A0 =A0 violate this.
=A0 =A0 =A0>
=A0 =A0 =A0> Also of course you are making a statement of fact and not of
=A0 =A0 permission
=A0 =A0 =A0> so I thin= k it may be more precise to say:
=A0 =A0 =A0>
=A0 =A0 =A0> It is not= ed that most existing
=A0 =A0 =A0> implementations currently violate this, as they do not look for
=A0 =A0 the XL
=A0 =A0 =A0> and thus = for ESPLs.

=A0 =A0 OK.

=A0 =A0 I've gone wit= h...

=A0 =A0 =A0 =A0 =A0 =A0 I= t is noted that existing
=A0 =A0 =A0 =A0 =A0 =A0 implementations would violate this, as they do not recognise XL
=A0 =A0 =A0 =A0 =A0 =A0 a= s anything other than a single Special Purpose Label and will
=A0 =A0 =A0 =A0 =A0 =A0 n= ot expect an ESPL to follow.

=A0 =A0 [snip]

=A0 =A0 =A0> >> = =A0 =A0Label 7 (when received) retains its meaning as ELI whether =A0 =A0 a regular
=A0 =A0 =A0> >> = =A0 =A0special purpose label or an ESPL; this simplifies a transit
=A0 =A0 LSR's
=A0 =A0 =A0> >> = =A0 =A0task of looking for entropy labels since it may just look
=A0 =A0 for label 7
=A0 =A0 =A0> >> = =A0 =A0and need not verify that the previous label in the stack is
=A0 =A0 not the
=A0 =A0 =A0> >> = =A0 =A0XL 15. =A0However, an LSR wishing to insert an entropy label
=A0 =A0 SHOULD
=A0 =A0 =A0> >> = =A0 =A0insert label 7 as a regular special purpose label, not as
=A0 =A0 an ESPL.
=A0 =A0 =A0> >><= br> =A0 =A0 =A0> >> = Why is this not a MUST! There is no ESPL in the wild running an
=A0 =A0 =A0> >> alternate behaviour, so why not simply mandate this?
=A0 =A0 =A0> > If t= his was a MUST then there would be no case for handling
=A0 =A0 Label 7 after
=A0 =A0 XL.
=A0 =A0 =A0> > Ther= e was some concern I believe that implementations might
=A0 =A0 have a path that<= br> =A0 =A0 =A0> > puts them on to XL insertion processing and then consider what =A0 =A0 to do next.
=A0 =A0 At
=A0 =A0 =A0> > that point they might decide that label 7 is needed.
=A0 =A0 =A0> >
=A0 =A0 =A0> > It seems esoteric, but I couldn't see a reason to prohibit it.
=A0 =A0 =A0> >
=A0 =A0 =A0> > Mayb= e "MUST NOT include&qu= ot; and "SHOULD process when received" are
=A0 =A0 =A0> > compatible.
=A0 =A0 =A0> >
=A0 =A0 =A0> > Part= of me hates the idea of this change just because I don't
=A0 =A0 want another
=A0 =A0 =A0> > work= ing group last call before we can move forward. How
=A0 =A0 important is it?<= br> =A0 =A0 =A0>
=A0 =A0 =A0> The reaso= n to be stricter at the TX is that the forwarding path
=A0 =A0 can be
=A0 =A0 =A0> simpler a= t the RX. I cannot see how you would get to the point of
=A0 =A0 putting
=A0 =A0 =A0> in L15 an= d then saying "you kno= w I need to put in L7"=
=A0 =A0 particularly as n= o
=A0 =A0 =A0> other 0..= 15 is allowed.
=A0 =A0 =A0> Normally = I would think that you would put in the compound label
=A0 =A0 as a pair
=A0 =A0 =A0> and that = is a good reason to use the compound label concept.
=A0 =A0 =A0>
=A0 =A0 =A0> Also I se= e no reason for the inconsistency between L7 and all of the
=A0 =A0 =A0> other L0..L15 cases.
=A0 =A0 =A0>
=A0 =A0 =A0> So I thin= k that it's OK, but probably silly to allow L0..L15, but
=A0 =A0 to allow
=A0 =A0 =A0> the exception of just L7 just complicates things without good cause.

=A0 =A0 I'm not in a position to argue on this one as the debate and text
=A0 =A0 were driven by =A0 =A0 others.

=A0 =A0 I believe that th= e claim was that allowing L7 to be inserted
=A0 =A0 anywhere made
=A0 =A0 processing it easier not harder at the receiver.
=A0 =A0 Note that {XL,7} would be an error case in your way of looking at
=A0 =A0 things so the
=A0 =A0 receiver should (must?) not process it.
=A0 =A0 But the claim was that h/w will simply search the stack for L7 so
=A0 =A0 that allowing
=A0 =A0 {L7} and {XL, L7} to be treated in the same way made life easier for
=A0 =A0 the h/w.

=A0 =A0 Bottom line, however, seems to be that you have a preference for
=A0 =A0 doing it one
=A0 =A0 way, and the WG has a preference for doing it a different way. How
=A0 =A0 to resolve
=A0 =A0 that?

=A0 =A0 Given the posting deadline, I've not made any change for this. We
=A0 =A0 can continue
=A0 =A0 to discuss.

=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D=3D=3D<= br> =A0 =A0 =A0> >><= br> =A0 =A0 =A0> >> 3.2. =A0Process for Retiring Special Purpose Labels

=A0 =A0 [snip]

=A0 =A0 =A0> >> Secondly I think the timescales are ridiculously optimistic.
=A0 =A0 To get
=A0 =A0 =A0> >> = a label out of circulation in 24 months seems most unlikely. Also
=A0 =A0 =A0> >> = 6 month checks is a lot of work.
=A0 =A0 =A0> >><= br> =A0 =A0 =A0> >> = A more realistic schedule would be to poll at 12month
=A0 =A0 intervals until =A0 =A0 =A0> >> such time as it is determined that reallocation would do not
=A0 =A0 harm and
=A0 =A0 =A0> >> then give a further 12 months notice.
=A0 =A0 =A0> > Erm, that's what the text says, I think...
=A0 =A0 =A0> >
=A0 =A0 =A0> > =A0 = =A0 =A0 =A0 12 months after the RFC deprecating the label value is
=A0 =A0 published,
=A0 =A0 =A0> > =A0 = =A0 =A0 =A0 an IETF-wide survey may be conducted to determine if the
=A0 =A0 =A0> > =A0 = =A0 =A0 =A0 deprecated label value is still in use.
=A0 =A0 =A0> >
=A0 =A0 =A0> > The "may" in that m= eans that the earliest you can "poll" is 1= 2
=A0 =A0 months after
=A0 =A0 the
=A0 =A0 =A0> > deprecation RFC is published (noting that the RFC won't even =A0 =A0 get published
=A0 =A0 =A0> > unti= l lots of discussion and consensus to deprecate).
=A0 =A0 =A0> > Then= , *if* the poll response is OK, and then not earlier than
=A0 =A0 24 months
=A0 =A0 after
=A0 =A0 =A0> > the deprecation RFC is published, publication can be requested
=A0 =A0 for a new RFC
=A0 =A0 =A0> > (whi= ch means that the WG has already reached consensus, and that a
=A0 =A0 =A0> > subsequent IETF last call will be held).
=A0 =A0 =A0> >
=A0 =A0 =A0> > Frankly, I think that this process is only likely to be
=A0 =A0 executed for SPLs=
=A0 =A0 that
=A0 =A0 =A0> > are allocated "in error&= quot;, because other stuff will probably be
=A0 =A0 in the field.
=A0 =A0 Can
=A0 =A0 =A0> > you think of a label that was allocated in error? I can :-)
=A0 =A0 =A0>
=A0 =A0 =A0> This seem= s like a lot of text to specify in detail something we
=A0 =A0 would never
=A0 =A0 =A0> run. In protocols, including this type of protocol, the fewer
=A0 =A0 words used to
=A0 =A0 =A0> describe = the rarely executed exception path the better.

=A0 =A0 The case was considered worthy of inclusion because the SPL range is
=A0 =A0 so small.
=A0 =A0 If any SPL can be reclaimed at some future time it will be very
=A0 =A0 valuable and so =A0 =A0 a mechanism needs to be documented against that happy day.

=A0 =A0 [snip]
=A0 =A0 =A0> >> =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
=A0 =A0 [snip]
=A0 =A0 =A0> >> However that brings me to
=A0 =A0 =A0> >> suggest that you probably need to write an OPs section and
=A0 =A0 =A0> >> = you might want to think about the PM implications of the extra
=A0 =A0 =A0> >> metatdata in the packets.
=A0 =A0 =A0> >
=A0 =A0 =A0> > What OPS issues had you in mind that need to be addressed? I am
=A0 =A0 a fan of OPS
=A0 =A0 =A0> > sections, but not a fan of empty OPS sections, and when we
=A0 =A0 looked through =A0 =A0 =A0> > RFC 6123 (which is my favourite crib for what to describe wrt
=A0 =A0 manageability) =A0 =A0 we
=A0 =A0 =A0> > didn= 't see anything that has changed from pre-existing MPLS.
=A0 =A0 =A0> >
=A0 =A0 =A0> > What metadata are you talking about? Is an existing special
=A0 =A0 purpose label
=A0 =A0 =A0> > metadata? If so, the PM issues are pre-existing. Is there =A0 =A0 something special=
=A0 =A0 =A0> > introduced by this I-D that constitutes metadata?
=A0 =A0 =A0>
=A0 =A0 =A0> Well what follows an XL is certainly metadata, and one application is =A0 =A0 =A0> certainly= to introduce tags that would alert the PM devices to
=A0 =A0 take an
=A0 =A0 =A0> interest.=

=A0 =A0 OK it is a form o= f metadata as existing SPLs are metadata.
=A0 =A0 The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI
=A0 =A0 that the SPL
=A0 =A0 is there.
=A0 =A0 What has changed?=
=A0 =A0 We could certainl= y sit down and write an I-D about the implications
=A0 =A0 of using
=A0 =A0 MPLS in an environment where PM might be present (BTW, I assume this is
=A0 =A0 Pervasive Monitoring. Would be embarrassing to find you meant
=A0 =A0 something else =A0 =A0 :-). I think such an I-D would discuss SPLs as indicative metadata
=A0 =A0 and would
=A0 =A0 then note that ESPLs are in the same category.
=A0 =A0 Is *this* the I-D in which to have that discussion?

=A0 =A0 [snip]

=A0 =A0 I'll post the revised I-D in a few minutes and others can throw
=A0 =A0 vegetables
=A0 =A0 (rotten or otherwise).

=A0 =A0 Adrian

=A0 =A0 _________________________= ______________________
=A0 =A0 mpls mailing list=
=A0 =A0 mpls@ietf.org <mailto:mpls@ietf.org>
=A0 =A0 https://www.ietf.org/ma= ilman/listinfo/mpls





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


--


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




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



--=20
For corporate legal information go to:

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





--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/c=
ri/index.html
--089e0160ac2cfe8c4a04f2b171ca-- From nobody Tue Feb 18 09:19: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 ED3361A03CE for ; Tue, 18 Feb 2014 09:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrmNmSO0kOCe for ; Tue, 18 Feb 2014 09:19:09 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 614231A06C6 for ; Tue, 18 Feb 2014 09:19:09 -0800 (PST) Received: from mail96-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Feb 2014 17:19:06 +0000 Received: from mail96-tx2 (localhost [127.0.0.1]) by mail96-tx2-R.bigfish.com (Postfix) with ESMTP id 2477B1400EA; Tue, 18 Feb 2014 17:19:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI62a3I98dI9371I936eIc85fh1dbaI1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail96-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(252514010)(51704005)(24454002)(51444003)(199002)(189002)(377424004)(479174003)(377454003)(4396001)(87266001)(63696002)(46102001)(90146001)(85852003)(85306002)(83072002)(16236675002)(56816005)(19300405004)(66066001)(47976001)(65816001)(47736001)(80022001)(81816001)(81686001)(92566001)(80976001)(74876001)(74706001)(76796001)(76576001)(76786001)(77982001)(53806001)(49866001)(59766001)(79102001)(74316001)(74366001)(15975445006)(50986001)(33646001)(15202345003)(51856001)(54316002)(19580405001)(19580395003)(56776001)(94316002)(93136001)(81342001)(74662001)(76482001)(83322001)(54356001)(95666001)(86362001)(81542001)(87936001)(69226001)(74502001)(2656002)(47446002)(31966008)(95416001)(93516002)(94946001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB562.namprd05.prod.outlook.com; CLIP:66.129.239.11; FPR:E82FFFE4.AFFAE381.7DE3BD8F.42AAFA41.20AAE; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail96-tx2 (localhost.localdomain [127.0.0.1]) by mail96-tx2 (MessageSwitch) id 1392743941182686_2014; Tue, 18 Feb 2014 17:19:01 +0000 (UTC) Received: from TX2EHSMHS013.bigfish.com (unknown [10.9.14.240]) by mail96-tx2.bigfish.com (Postfix) with ESMTP id AA5A11C006E; Tue, 18 Feb 2014 17:19:00 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS013.bigfish.com (10.9.99.113) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Feb 2014 17:18:56 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 18 Feb 2014 17:18:51 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.0.878.16; Tue, 18 Feb 2014 17:18:49 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0878.008; Tue, 18 Feb 2014 17:18:49 +0000 From: John E Drake To: "stbryant@cisco.com" , Alia Atlas Thread-Topic: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels Thread-Index: AQHZAbpQEHKtxixh1gWDHsjupsHBAwFVBBIXAfST0/2ahvSAYIAArU2AgAAjAwCAAAdeAIAAxRCAgASPEwCAAAJgAIAAIrEAgAAFLNA= Date: Tue, 18 Feb 2014 17:18:48 +0000 Message-ID: References: <52FA0E02.4050906@cisco.com> <04bd01cf2764$ea868110$bf938330$@olddog.co.uk> <52FE2E14.3010903@cisco.com> <007001cf29ab$335bbbb0$9a133310$@olddog.co.uk> <52FEF3DC.2000105@pi.nu> <5303725C.6070007@cisco.com> <53039174.1040807@cisco.com> In-Reply-To: <53039174.1040807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-forefront-prvs: 0126A32F74 Content-Type: multipart/alternative; boundary="_000_eb3b967a7cff4a86ae812a93d5fea04eBLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/t-0sUC8_DN4fxD06wMZeybScqsM Cc: "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 17:19:18 -0000 --_000_eb3b967a7cff4a86ae812a93d5fea04eBLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, My thoughts exactly. This is also what RFC 6790 currently states. Yours Irrespectively, John From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Tuesday, February 18, 2014 9:00 AM To: Alia Atlas Cc: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels Alia Maybe we are out of sync. I think that the text should say that L7 MUST be sent as a single label, an= d MUST NOT be sent as a compound/extended label, and I think simplicity alone is sufficient justification. Stewart On 18/02/2014 14:55, Alia Atlas wrote: Stewart, If you think that Loa's text is sufficiently strong about not sending XL, E= SPL, then I am fine with his text. I was striving for more clarity on why the exception was made and suggestin= g MUST rather than SHOULD. Loa's text says: ""Label 7 (when received) retains its meaning as ELI whether a regular special purpose label or an ESPL; this is because of backwards compatibility with existing implemented and deployed code and hardware that looks for the ELI without verifying if the previous label is XL or not. However, when an LSR insert an entropy label it SHOULD insert the ELI as a regular special purpose label, not as an ESPL." This doesn't explain that bad traffic side-effects could happen, but I thin= k the wording for why the exception is there is clear. Alia On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant > wrote: This has me worried. Assume that nothing implements ESPL yet, there is no reason why all SPL implementations are not required to send L7 only as a regular (single) SPL. As Loa says, this would be a useful simplification, and one which I raised earlier with the authors. If that is the case, a parser will always get it right. The only problem I see is if a compound label is ever created L15, Lx, <0..maxLabel> but one one has defined such an Lx and to do so would be unwise. So I don't think Alia is correct in her proposed text change and I have yet to see a valid technical reason for not accepting Loa's proposed change. - Stewart On 15/02/2014 17:09, Alia Atlas wrote: [+ietf] Loa, To clarify a bit better, what I'm trying to get clarified into the text is = why the ELI value as an ESPL needs to be an exception (as the draft indicates). I believe it is because= forbidding an ESPL of 7 can break some existing and deployed versions of RFC 6790 such that the tra= nsit traffic flows are affected. There may also be implementations of RFC 6790 that aren't affected. Regards, Alia On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas > wrote: Loa, On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson > wrote: Alia, Two comments on this. First a nit "An LSR wishing to insert an ...", LSR are boxes and can't wish anything for themselves, a Simple change would be "When an LSR insert..." Actually the same is true for the current text and should be changed the same way. [Alia] Sure - I took the original text and modified it. Second, and this is maybe more tricky - the reason given "simplify the data plane implementation" is not true and might even be wrong. The reason put always using the ELI as a "regular special purpose label" is backwards compatibility. I would claim that the treatment of the ELI is an (well motivated) exception, but exceptions always mean that things get more complicated. [Alia] There were three purposes to my suggested text change. First, to sp= ecify that an LSR MUST NOT insert the ELI as an ESPL. Second, to say that a receivin= g LSR MAY choose to not discard a packet with the ELI as an ESPL. Third, I wante= d to see a clearer justification for why this exception is worth making. [Alia] Since the whole draft is about a data-plane change, what we've been = putting in doesn't really articulate the full problem. Prelim text would around that would be= better as: "ELI is an exception because each LSR examines the whole label stack to see= if the ELI appears; pre-existing implementations of [Entropy-Label] do this examinatio= n without verifying that the label above the ELI is not XL. If a packet used an ESPL of 7 and = that did not mean ELI, then when that packet transited deployed LSRs, which implement [Entrop= y-Label] and not this document, the meaning of the ESPL would be misinterpreted. Such a misinterpretation = could result in poor traffic behavior (large flows, reordered flows, etc.) depending on the label after the ESPL of 7. It is t= o avoid such issues that ELI is defined as an exception that can appear as an regular special label or as an ESPL with the same val= ue of 7." What do you think? Alia I don't want to propose a final text,but something along these lines: "Label 7 (when received) retains its meaning as ELI whether a regular special purpose label or an ESPL; this is because of backwards compatibility with existing implemented and deployed code and hardware that looks for the ELI without verifying if the previous label is XL or not. However, when an LSR insert an entropy label it SHOULD insert the ELI as a regular special purpose label, not as an ESPL." /Loa On 2014-02-15 10:52, Alia Atlas wrote: Adrian and others, Having reviewed the 05 of this draft and this thread, I have the following suggestions. Other than these, I'm quite happy with how this draft has improved. a) In Sec 3.1, the following paragraph could be updated from: "Label 7 (when received) retains its meaning as ELI whether a regular special purpose label or an ESPL; this simplifies a transit LSR's task of looking for entropy labels since it may just look for label 7 and need not verify that the previous label in the stack is not the XL 15. However, an LSR wishing to insert an entropy label SHOULD insert label 7 as a regular special purpose label, not as an ESPL." to: "An LSR wishing to insert an entropy label MUST insert label value 7 (meani= ng ELI) as a regular special purpose label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data pl= ane. However, to simplify the data plane implementation for Entropy Labels, an implementation MAY interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, = an implementation MAY choose to not treat the packet as malformedand thus discard it. The da= ta plane simplification thus enabled is the ability to determine if any label value is 7 without needing to veri= fy that the previous label in the stack is not the XL value of 15." b)In Sec 3.2: "An RFC with at least Informational status is required." H= ow is this different from IETF Review in RFC 5226? Do BCPs count? What is = "at least Informational status"? On the concern about Pervasive Monitoring, the only advantage that (XL, ESPL) offers is that the labels wouldn't (eventually) be hashed for load-balancing. Otherwise, the label stack offers the ability for meta-data already where only the receiver would need to understand it. Consistent paths are very useful, but there are other ways of doing this already - with the most trivial being just using label 15. I have a hard time seeing this as a new attack vector (but I'm not professionally paranoid yet). Alia On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel >> wrote: [snip] > >> XL The Extension Label that indicates that an extended special > >> purpose label follows. > >> > >> ESPL An Extended Special Purpose Label. > >> > >> Something that I think would be worthwhile clarifying right at th= e > >> front is that a label is an ESPL IFF it is preceded by an XL. > >> It might even be worth noting that really we have a new label type: > >> a label couple in which the first label defines the type of the > >> second label and neither are of any use as individual labels. > > I can see how you would see this as a new label type. Maybe "compound" > > rather than "couple". > > However, I am not convinced that it is new that one label leads to the semantics > > of the next (for example the entropy label). > > What is more, I am not sure that there will be more than this instance of this > > type of tight coupling. > > So I would rather leave this point out. > I can foresee other cases where we might use label pairs to mitigate the > 20bit limit. I am sure it has been discussed, so creating the reference > might be useful. Just because this was not done in EL, does not mean that > we should not set down the concept here. > > However I agree compound would be a better term. > > > > > But as to clarifying ESPL: yes. > > The XP definition is, I think, clear. > > How about... > > > > ESPL An Extended Special Purpose Label. A Special Purpose Label that > > is placed in the label stack after the Extension Label. > > Yes. Indeed it MUST be placed be placed there, however the definitio= n > above is fine. OK, I updated to... ESPL An Extended Special Purpose Label. A Special Purpose Label tha= t is placed in the label stack after the Extension Label. The combination of XL and ESPL might be regarded as a new form of "compound label" comprising more than one consecutive entry in the label stack. ..to cover your other point as well. > >> =3D=3D=3D=3D=3D=3D > >> > >> I think that the draft will need to provide some guidance > >> on when to allocate a 0..15 and when to allocate an ESPL. > >> > >> I imagine that a 0..15 should only be used when it can be shown > >> that the extra stack space of forwarding time is burdensome > >> but that is a question that the WG should explicitly consider. > > We discussed this at some point on the MPLS list (many centuries ago, I think) > > and reached no conclusion. > > The primary purpose of the XL is to handle the time when 0..15 is depleted. > > You're right that we could encourage people to start using ESPLs now before > > 0..15 is depleted. But it is hard to make the case for requiring it when there > > is still some of 0..15 available and the rate of burn is not so high. > > > > We could put in some text like... > > > > When allocating a new Special Purpose Label, protocol designers should > > consider whether they could, instead, use an Extended Special Purpose > > Label. Doing so would help to preserve the scarce resources of Special > > Purpose Labels for use in cases where minimizing the label stack size is > > particularly important. > > That would be useful text. Added as new section 3.1.2 with slight tweak to wording. [snip] > >> 6. [RFC6790] says that special purpose labels MUST NOT be used for > >> load balancing. The same logic applies to extended specia= l > >> purpose labels (ESPLs). Thus, this document specifies that ESPLs > >> MUST NOT be used for load balancing. It is noted that existing > >> implementations may violate this, as they do not look for the XL > >> and thus for ESPLs. The consequence is that if ESPLs are used in > >> some packets of a flow, these packets may be delivered on > >> different paths and so could be re-ordered. However, it i= s > >> important to specify the correct behavior for future > >> implementations, hence the use of "MUST NOT". > >> > >> I would suggest that most implementations do violate this. I woul= d > >> also suggest that it seems unlikely that you will get to the poin= t > >> where it is not violated in the foreseeable future. > > I can't tell whether there is an action here for us. > > There are two "violations" that exist: > > 1. Some implementations violate 6790. Not sure what we can do abou= t > > that in this document. Note that the entropy label can help with this > > but only to a limited extent since the implementations that violate 6790 > > probably also fail to recognise the entropy label. > > 2. Implementations that conform to 6790 will understand that the XL is > > a special purpose label and will not use it to load balance. But they will > > not necessarily understand that the next label is an ESPL that must be > > skipped as well. Again, there is nothing we can do about this except to > > note it (done) and possibly to use the EL further up the stack. > > My point was that the may in "It is noted that existing implementations may > violate this" was a little soft. Most implementations, except the latest > designs of maybe as few as a single vendor, would certainly violate this. > > Also of course you are making a statement of fact and not of permission > so I think it may be more precise to say: > > It is noted that most existing > implementations currently violate this, as they do not look for the XL > and thus for ESPLs. OK. I've gone with... It is noted that existing implementations would violate this, as they do not recognise XL as anything other than a single Special Purpose Label and will not expect an ESPL to follow. [snip] > >> Label 7 (when received) retains its meaning as ELI whether a regular > >> special purpose label or an ESPL; this simplifies a transit LSR's > >> task of looking for entropy labels since it may just look for label 7 > >> and need not verify that the previous label in the stack is not the > >> XL 15. However, an LSR wishing to insert an entropy label SHOULD > >> insert label 7 as a regular special purpose label, not as an ESPL. > >> > >> Why is this not a MUST! There is no ESPL in the wild running an > >> alternate behaviour, so why not simply mandate this? > > If this was a MUST then there would be no case for handling Label 7 after XL. > > There was some concern I believe that implementations might have a path that > > puts them on to XL insertion processing and then consider what to do next. At > > that point they might decide that label 7 is needed. > > > > It seems esoteric, but I couldn't see a reason to prohibit it. > > > > Maybe "MUST NOT include" and "SHOULD process when received" are > > compatible. > > > > Part of me hates the idea of this change just because I don't want another > > working group last call before we can move forward. How important is it? > > The reason to be stricter at the TX is that the forwarding path can be > simpler at the RX. I cannot see how you would get to the point of putting > in L15 and then saying "you know I need to put in L7" particularly as no > other 0..15 is allowed. > Normally I would think that you would put in the compound label as a pair > and that is a good reason to use the compound label concept. > > Also I see no reason for the inconsistency between L7 and all of the > other L0..L15 cases. > > So I think that it's OK, but probably silly to allow L0..L15, but to allow > the exception of just L7 just complicates things without good cause. I'm not in a position to argue on this one as the debate and text were driven by others. I believe that the claim was that allowing L7 to be inserted anywhere made processing it easier not harder at the receiver. Note that {XL,7} would be an error case in your way of looking at things so the receiver should (must?) not process it. But the claim was that h/w will simply search the stack for L7 so that allowing {L7} and {XL, L7} to be treated in the same way made life easier for the h/w. Bottom line, however, seems to be that you have a preference for doing it one way, and the WG has a preference for doing it a different way. How to resolve that? Given the posting deadline, I've not made any change for this. We can continue to discuss. > >> =3D=3D=3D=3D=3D=3D=3D=3D > >> > >> 3.2. Process for Retiring Special Purpose Labels [snip] > >> Secondly I think the timescales are ridiculously optimistic. To get > >> a label out of circulation in 24 months seems most unlikely. Also > >> 6 month checks is a lot of work. > >> > >> A more realistic schedule would be to poll at 12month intervals until > >> such time as it is determined that reallocation would do not harm and > >> then give a further 12 months notice. > > Erm, that's what the text says, I think... > > > > 12 months after the RFC deprecating the label value is published, > > an IETF-wide survey may be conducted to determine if the > > deprecated label value is still in use. > > > > The "may" in that means that the earliest you can "poll" is 12 months after the > > deprecation RFC is published (noting that the RFC won't even get published > > until lots of discussion and consensus to deprecate). > > Then, *if* the poll response is OK, and then not earlier than 24 months after > > the deprecation RFC is published, publication can be requested for a new RFC > > (which means that the WG has already reached consensus, and that a > > subsequent IETF last call will be held). > > > > Frankly, I think that this process is only likely to be executed for SPLs that > > are allocated "in error", because other stuff will probably be in the field. Can > > you think of a label that was allocated in error? I can :-) > > This seems like a lot of text to specify in detail something we would never > run. In protocols, including this type of protocol, the fewer words used to > describe the rarely executed exception path the better. The case was considered worthy of inclusion because the SPL range is so small. If any SPL can be reclaimed at some future time it will be very valuable and so a mechanism needs to be documented against that happy day. [snip] > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [snip] > >> However that brings me to > >> suggest that you probably need to write an OPs section and > >> you might want to think about the PM implications of the extra > >> metatdata in the packets. > > > > What OPS issues had you in mind that need to be addressed? I am a fan of OPS > > sections, but not a fan of empty OPS sections, and when we looked through > > RFC 6123 (which is my favourite crib for what to describe wrt manageability) we > > didn't see anything that has changed from pre-existing MPLS. > > > > What metadata are you talking about? Is an existing special purpose label > > metadata? If so, the PM issues are pre-existing. Is there something special > > introduced by this I-D that constitutes metadata? > > Well what follows an XL is certainly metadata, and one application i= s > certainly to introduce tags that would alert the PM devices to take an > interest. OK it is a form of metadata as existing SPLs are metadata. The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI that the SPL is there. What has changed? We could certainly sit down and write an I-D about the implications of using MPLS in an environment where PM might be present (BTW, I assume this is Pervasive Monitoring. Would be embarrassing to find you meant something else :-). I think such an I-D would discuss SPLs as indicative metadata and would then note that ESPLs are in the same category. Is *this* the I-D in which to have that discussion? [snip] I'll post the revised I-D in a few minutes and others can throw vegetables (rotten or otherwise). Adrian _______________________________________________ mpls mailing list mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ 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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_eb3b967a7cff4a86ae812a93d5fea04eBLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

 <= /p>

My thoughts exactly. = ; This is also what RFC 6790 currently states.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Tuesday, February 18, 2014 9:00 AM
To: Alia Atlas
Cc: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf= .org
Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-l= abels

 

Alia

Maybe we are out of sync.

I think that the text should say that L7 MUST be sent as a single label, an= d
MUST NOT be sent as a compound/extended label, and I think simplicity
alone is sufficient justification.

Stewart

On 18/02/2014 14:55, Alia Atlas wrote:

Stewart,

 

If you think that Loa's text is sufficiently strong = about not sending XL, ESPL, then I am fine with his text.

I was striving for more clarity on why the exception= was made and suggesting MUST rather than SHOULD.

 

Loa's text says:

 

""Label 7 (when received) retains its mean= ing as ELI whether a

 regular special = purpose label or an ESPL; this is because of backwards
 compatibility with existing implemented and deployed code and hardwar= e
 that looks for the ELI without verifying if the previous label
 is XL or not. However, when an LSR insert an entropy label it SHOULD<= br>  insert the ELI as a regular special purpose label, not as an ESPL.&qu= ot;

This doesn't explain that bad traffic side-effects c= ould happen, but I think the wording for why the

exception is there is clear.

 

Alia

 

On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant <= stbryant@cisco.com<= /a>> wrote:

This has me worried.

Assume that nothing implements ESPL yet, there is no reason why
all SPL implementations are not required to send L7 only as
a regular (single) SPL. As Loa says, this would be a useful
simplification, and one which I raised earlier with the authors.

If that is the case, a parser will always get it right.

The only problem I see is if a compound label is ever created
L15, Lx, <0..maxLabel> but one one has defined such an
Lx and to do so would be unwise.

So I don't think Alia is correct in her proposed text change and
I have yet to see a valid technical reason for not accepting Loa's
proposed change.

- Stewart



On 15/02/2014 17:09, Alia Atlas wrote:

[+ietf]

 

Loa,

 

To clarify a bit better, what I'm trying to get clar= ified into the text is why the ELI value as an ESPL

needs to be an exception (as the draft indicates). &= nbsp;I believe it is because forbidding an ESPL of 7

can break some existing and deployed versions of RFC= 6790 such that the transit traffic flows are affected.

There may also be implementations of RFC 6790 that a= ren't affected.

 

Regards,

Alia

 

 

On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas <akatlas@gmail.com&g= t; wrote:

Loa,

 

On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson <= loa@pi.nu> wrote:

Alia,

Two comments on this.

First a nit "An LSR wishing to insert an ...", LSR are boxes and = can't
wish anything for themselves, a Simple change would be "When an LSR insert..."

Actually the same is true for the current text and should be changed the same way.

 

[Alia] Sure - I took the original text and modified = it. 

 

Second, and this is maybe more tricky - the reason g= iven "simplify the
data plane implementation" is not true and might even be wrong.
The reason put always using the ELI as a "regular special purpose labe= l"
is backwards compatibility.
I would claim that the treatment of the ELI is an (well motivated)
exception, but exceptions always mean that things get more complicated.

 

[Alia] There were three purposes to my suggested tex= t change.  First, to specify that

an LSR MUST NOT insert the ELI as an ESPL.   Se= cond, to say that a receiving LSR

MAY choose to not discard a packet with the ELI as a= n ESPL.  Third, I wanted to see

a clearer justification for why this exception is wo= rth making.

 

[Alia] Since the whole draft is about a data-plane c= hange, what we've been putting in doesn't

really articulate the full problem.  Prelim tex= t would around that would be better as:

 

"ELI is an exception because each LSR examines = the whole label stack to see if the ELI

appears; pre-existing implementations of [Entropy-La= bel] do this examination without verifying

that the label above the ELI is not XL.  If a p= acket used an ESPL of 7 and that did not mean

ELI, then when that packet transited deployed LSRs, = which implement [Entropy-Label] and not this document, 

the meaning of the ESPL would be misinterpreted. &nb= sp;Such a misinterpretation could result in poor traffic behavior (large fl= ows,

reordered flows, etc.) depending on the label after = the ESPL of 7.  It is to avoid such issues that ELI is defined as an e= xception

that can appear as an regular special label or as an= ESPL with the same value of 7."

 

What do you think?

 

Alia=

 

I don't want to propose a final text,but something a= long these lines:



"Label 7 (when received) retains its meaning as ELI whether a

 regular special purpose label or an ESPL; this= is because of backwards
 compatibility with existing implemented and deployed code and hardwar= e
 that looks for the ELI without verifying if the previous label
 is XL or not. However, when an LSR insert an entropy label it SHOULD<= br>  insert the ELI as a regular special purpose label, not as an ESPL.&qu= ot;

/Loa



On 2014-02-15 10:52, Alia Atlas wrote:

Adrian and others,
Having reviewed the 05 of this draft and this thread, I have the
following suggestions.  Other than these, I'm quite happy with how thi= s
draft has improved.

a) In Sec 3.1, the following paragraph could be updated from:

"Label 7 (when received) retains its meaning as ELI whether a
regular special purpose label or an ESPL; this simplifies a transit
LSR's task of looking for entropy labels since it may just look for
label 7  and need not verify that the previous label in the stack is n= ot
the XL 15. However, an LSR wishing to insert an entropy label SHOULD
insert label 7 as a regular special purpose label, not as an ESPL."

to:


"An LSR wishing to insert an entropy label MUST insert label value 7 (= meaning ELI) as a regular special purpose

label and not as an ESPL.Value 7 MUST NOT be sent as= an ESPL in the data plane.  However, to simplify



the data plane implementation for Entropy Labels, an implementation MAY

interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, = an implementation

MAY choose to not treat the packet as malformedand t= hus discard it.  The data plane simplification thus enabled



is the ability to determine if any label value is 7 without needing to veri= fy that the previous label in the stack is not the XL value of 15."

b)In Sec 3.2: "An RFC with at  least Infor= mational status is required."   How is this different from IETF R= eview in RFC 5226?  Do BCPs count? What is "at least Informationa= l status"?




On the concern about Pervasive Monitoring, the only advantage that (XL,
ESPL) offers is that the labels wouldn't (eventually) be hashed for
load-balancing.  Otherwise, the label stack offers the ability for
meta-data already where only the receiver would need to understand it.
  Consistent paths are very useful, but there are other ways of doing<= br> this already - with the most trivial being just using label 15.  I hav= e
a hard time seeing this as a new attack vector (but I'm not
professionally paranoid yet).

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <adrian@olddog.co.uk

<mailto:adrian@olddog.co.uk>> wrote:

    [snip]

     > >> XL   The Extension Label that indica= tes that an extended special
     > >>         purpose label= follows.
     > >>
     > >> ESPL An Extended Special Purpose Label.      > >>
     > >> Something that I think would be worthwhil= e clarifying right at the
     > >> front is that a label is an ESPL IFF it i= s preceded by an XL.
     > >> It might even be worth noting that really= we have a new label
    type:
     > >> a label couple in which the first label d= efines the type of the
     > >> second label and neither are of any use a= s individual labels.
     > > I can see how you would see this as a new lab= el type. Maybe
    "compound"
     > > rather than "couple".
     > > However, I am not convinced that it is new th= at one label leads
    to the
    semantics
     > > of the next (for example the entropy label).<= br>      > > What is more, I am not sure that there will b= e more than this
    instance of
    this
     > > type of tight coupling.
     > > So I would rather leave this point out.
     > I can foresee other cases where we might use label= pairs to
    mitigate the
     > 20bit limit. I am sure it has been discussed, so c= reating the
    reference
     > might be useful. Just because this was not done in= EL, does not
    mean that
     > we should not set down the concept here.
     >
     > However I agree compound would be a better term.      >
     > >
     > > But as to clarifying ESPL: yes.
     > > The XP definition is, I think, clear.
     > > How about...
     > >
     > > ESPL An Extended Special Purpose Label. A Spe= cial Purpose Label
    that
     > >       is placed in the label s= tack after the Extension Label.
     >
     > Yes. Indeed it MUST be placed be placed there, how= ever the definition
     > above is fine.

    OK, I updated to...

        ESPL An Extended Special Purpose Label. A Speci= al Purpose Label that
             is placed in the label stac= k after the Extension Label.  The
             combination of XL and ESPL = might be regarded as a new form of
             "compound label" = comprising more than one consecutive entry in
             the label stack.

    ..to cover your other point as well.

     > >> =3D=3D=3D=3D=3D=3D
     > >>
     > >> I think that the draft will need to provi= de some guidance
     > >> on when to allocate a 0..15 and when to a= llocate an ESPL.
     > >>
     > >> I imagine that a 0..15 should only be use= d when it can be shown
     > >> that the extra stack space of forwarding = time is burdensome
     > >> but that is a question that the WG should= explicitly consider.
     > > We discussed this at some point on the MPLS l= ist (many
    centuries ago, I
    think)
     > > and reached no conclusion.
     > > The primary purpose of the XL is to handle th= e time when 0..15
    is depleted.
     > > You're right that we could encourage people t= o start using
    ESPLs now before
     > > 0..15 is depleted. But it is hard to make the= case for
    requiring it when
    there
     > > is still some of 0..15 available and the rate= of burn is not so
    high.
     > >
     > > We could put in some text like...
     > >
     > > When allocating a new Special Purpose Label, = protocol designers
    should
     > > consider whether they could, instead, use an = Extended Special
    Purpose
     > > Label. Doing so would help to preserve the sc= arce resources of
    Special
     > > Purpose Labels for use in cases where minimiz= ing the label
    stack size is
     > > particularly important.
     >
     > That would be useful text.

    Added as new section 3.1.2 with slight tweak to wording.

    [snip]

     > >>     6.  [RFC6790] says tha= t special purpose labels MUST NOT be
    used for
     > >>        load balancing= .  The same logic applies to extended special
     > >>        purpose labels= (ESPLs).  Thus, this document specifies
    that ESPLs
     > >>        MUST NOT be us= ed for load balancing.  It is noted that
    existing
     > >>        implementation= s may violate this, as they do not look
    for the XL
     > >>        and thus for E= SPLs.  The consequence is that if ESPLs
    are used in
     > >>        some packets o= f a flow, these packets may be delivered on
     > >>        different path= s and so could be re-ordered.  However, it is
     > >>        important to s= pecify the correct behavior for future
     > >>        implementation= s, hence the use of "MUST NOT".
     > >>
     > >> I would suggest that most implementations= do violate this. I would
     > >> also suggest that it seems unlikely that = you will get to the point
     > >> where it is not violated in the foreseeab= le future.
     > > I can't tell whether there is an action here = for us.
     > > There are two "violations" that exi= st:
     > > 1. Some implementations violate 6790. Not sur= e what we can do about
     > > that in this document. Note that the entropy = label can help
    with this
     > > but only to a limited extent since the implem= entations that
    violate 6790
     > > probably also fail to recognise the entropy l= abel.
     > > 2. Implementations that conform to 6790 will = understand that
    the XL is
     > > a special purpose label and will not use it t= o load balance.
    But they will
     > > not necessarily understand that the next labe= l is an ESPL that
    must be
     > > skipped as well. Again, there is nothing we c= an do about this
    except to
     > > note it (done) and possibly to use the EL fur= ther up the stack.
     >
     > My point was that the may in "It is noted tha= t existing
    implementations may
     > violate this" was a little soft. Most impleme= ntations, except the
    latest
     > designs of maybe as few as a single vendor, would = certainly
    violate this.
     >
     > Also of course you are making a statement of fact = and not of
    permission
     > so I think it may be more precise to say:
     >
     > It is noted that most existing
     > implementations currently violate this, as they do= not look for
    the XL
     > and thus for ESPLs.

    OK.

    I've gone with...

            It is noted that existing
            implementations would violate thi= s, as they do not recognise XL
            as anything other than a single S= pecial Purpose Label and will
            not expect an ESPL to follow.

    [snip]

     > >>    Label 7 (when received) reta= ins its meaning as ELI whether
    a regular
     > >>    special purpose label or an = ESPL; this simplifies a transit
    LSR's
     > >>    task of looking for entropy = labels since it may just look
    for label 7
     > >>    and need not verify that the= previous label in the stack is
    not the
     > >>    XL 15.  However, an LSR= wishing to insert an entropy label
    SHOULD
     > >>    insert label 7 as a regular = special purpose label, not as
    an ESPL.
     > >>
     > >> Why is this not a MUST! There is no ESPL = in the wild running an
     > >> alternate behaviour, so why not simply ma= ndate this?
     > > If this was a MUST then there would be no cas= e for handling
    Label 7 after
    XL.
     > > There was some concern I believe that impleme= ntations might
    have a path that
     > > puts them on to XL insertion processing and t= hen consider what
    to do next.
    At
     > > that point they might decide that label 7 is = needed.
     > >
     > > It seems esoteric, but I couldn't see a reaso= n to prohibit it.
     > >
     > > Maybe "MUST NOT include" and "= SHOULD process when received" are
     > > compatible.
     > >
     > > Part of me hates the idea of this change just= because I don't
    want another
     > > working group last call before we can move fo= rward. How
    important is it?
     >
     > The reason to be stricter at the TX is that the fo= rwarding path
    can be
     > simpler at the RX. I cannot see how you would get = to the point of
    putting
     > in L15 and then saying "you know I need to pu= t in L7"
    particularly as no
     > other 0..15 is allowed.
     > Normally I would think that you would put in the c= ompound label
    as a pair
     > and that is a good reason to use the compound labe= l concept.
     >
     > Also I see no reason for the inconsistency between= L7 and all of the
     > other L0..L15 cases.
     >
     > So I think that it's OK, but probably silly to all= ow L0..L15, but
    to allow
     > the exception of just L7 just complicates things w= ithout good cause.

    I'm not in a position to argue on this one as the debate and = text
    were driven by
    others.

    I believe that the claim was that allowing L7 to be inserted<= br>     anywhere made
    processing it easier not harder at the receiver.
    Note that {XL,7} would be an error case in your way of lookin= g at
    things so the
    receiver should (must?) not process it.
    But the claim was that h/w will simply search the stack for L= 7 so
    that allowing
    {L7} and {XL, L7} to be treated in the same way made life eas= ier for
    the h/w.

    Bottom line, however, seems to be that you have a preference = for
    doing it one
    way, and the WG has a preference for doing it a different way= . How
    to resolve
    that?

    Given the posting deadline, I've not made any change for this= . We
    can continue
    to discuss.

     > >> =3D=3D=3D=3D=3D=3D=3D=3D
     > >>
     > >> 3.2.  Process for Retiring Special P= urpose Labels

    [snip]

     > >> Secondly I think the timescales are ridic= ulously optimistic.
    To get
     > >> a label out of circulation in 24 months s= eems most unlikely. Also
     > >> 6 month checks is a lot of work.
     > >>
     > >> A more realistic schedule would be to pol= l at 12month
    intervals until
     > >> such time as it is determined that reallo= cation would do not
    harm and
     > >> then give a further 12 months notice.
     > > Erm, that's what the text says, I think...      > >
     > >         12 months after t= he RFC deprecating the label value is
    published,
     > >         an IETF-wide surv= ey may be conducted to determine if the
     > >         deprecated label = value is still in use.
     > >
     > > The "may" in that means that the ea= rliest you can "poll" is 12
    months after
    the
     > > deprecation RFC is published (noting that the= RFC won't even
    get published
     > > until lots of discussion and consensus to dep= recate).
     > > Then, *if* the poll response is OK, and then = not earlier than
    24 months
    after
     > > the deprecation RFC is published, publication= can be requested
    for a new RFC
     > > (which means that the WG has already reached = consensus, and that a
     > > subsequent IETF last call will be held).
     > >
     > > Frankly, I think that this process is only li= kely to be
    executed for SPLs
    that
     > > are allocated "in error", because o= ther stuff will probably be
    in the field.
    Can
     > > you think of a label that was allocated in er= ror? I can :-)
     >
     > This seems like a lot of text to specify in detail= something we
    would never
     > run. In protocols, including this type of protocol= , the fewer
    words used to
     > describe the rarely executed exception path the be= tter.

    The case was considered worthy of inclusion because the SPL r= ange is
    so small.
    If any SPL can be reclaimed at some future time it will be ve= ry
    valuable and so
    a mechanism needs to be documented against that happy day.
    [snip]
     > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    [snip]
     > >> However that brings me to
     > >> suggest that you probably need to write a= n OPs section and
     > >> you might want to think about the PM impl= ications of the extra
     > >> metatdata in the packets.
     > >
     > > What OPS issues had you in mind that need to = be addressed? I am
    a fan of OPS
     > > sections, but not a fan of empty OPS sections= , and when we
    looked through
     > > RFC 6123 (which is my favourite crib for what= to describe wrt
    manageability)
    we
     > > didn't see anything that has changed from pre= -existing MPLS.
     > >
     > > What metadata are you talking about? Is an ex= isting special
    purpose label
     > > metadata? If so, the PM issues are pre-existi= ng. Is there
    something special
     > > introduced by this I-D that constitutes metad= ata?
     >
     > Well what follows an XL is certainly metadata, and= one application is
     > certainly to introduce tags that would alert the P= M devices to
    take an
     > interest.

    OK it is a form of metadata as existing SPLs are metadata.     The XL alerts a DPI that an ESPL follows, and an SPL alerts t= he DPI
    that the SPL
    is there.
    What has changed?
    We could certainly sit down and write an I-D about the implic= ations
    of using
    MPLS in an environment where PM might be present (BTW, I assu= me this is
    Pervasive Monitoring. Would be embarrassing to find you meant=
    something else
    :-). I think such an I-D would discuss SPLs as indicative met= adata
    and would
    then note that ESPLs are in the same category.
    Is *this* the I-D in which to have that discussion?

    [snip]

    I'll post the revised I-D in a few minutes and others can thr= ow
    vegetables
    (rotten or otherwise).

    Adrian

    _______________________________________________
    mpls mailing list

    mpls@ietf.org <mailto:mpls@ietf.org>
    https://www.ietf.org/mailman/listinfo/mpls






_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://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

 

 



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

 

-- 
For corporate legal information go to:
 
http://www.cisco.c=
om/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=

 
--_000_eb3b967a7cff4a86ae812a93d5fea04eBLUPR05MB562namprd05pro_-- From nobody Tue Feb 18 09:24: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 611BC1A0521 for ; Tue, 18 Feb 2014 09:24:09 -0800 (PST) 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 0bFhdGDwcT2H for ; Tue, 18 Feb 2014 09:24:07 -0800 (PST) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8477B1A06CF for ; Tue, 18 Feb 2014 09:24:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe03.verizonbusiness.com with ESMTP; 18 Feb 2014 17:24:04 +0000 From: "Xu, Fengman" X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208,217";a="674517256" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 18 Feb 2014 17:24:00 +0000 Received: from FHDP1LUMXC7V33.us.one.verizon.com ([166.68.125.34]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Tue, 18 Feb 2014 12:23:53 -0500 To: "mpls@ietf.org" Date: Tue, 18 Feb 2014 12:23:52 -0500 Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: Ac8suCAcPWeZjYenTQORtvZlZ6msLw== Message-ID: <65017ED8D0F1E343AF27F9E2F24859F216B6B91194@FHDP1LUMXC7V33.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_65017ED8D0F1E343AF27F9E2F24859F216B6B91194FHDP1LUMXC7V3_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jXH13R3wHyv9qQ0P3Oah20T8ZG0 Subject: [mpls] FW: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 17:24:09 -0000 --_000_65017ED8D0F1E343AF27F9E2F24859F216B6B91194FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as co-author. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 4:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_65017ED8D0F1E343AF27F9E2F24859F216B6B91194FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support a= s co-author.

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross CallonSent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [m= pls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

 

This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-= protection-11

as an MPLS work= ing group document. Since this call will continue through the

IETF meeting in London, I will extent the poll by on= e week (so that it will be a

three week= poll).

 <= /span>

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

maili= ng list (= mpls@ietf.org).

&n= bsp;

This poll will end Tuesd= ay March 11, 2014. This is of course the Tuesday after

the IETF.

&n= bsp;

Thanks, Ross<= /span>

 

 

= --_000_65017ED8D0F1E343AF27F9E2F24859F216B6B91194FHDP1LUMXC7V3_-- From nobody Tue Feb 18 11:48: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 0D5501A06BC for ; Tue, 18 Feb 2014 11:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG4Kh4QnUCwQ for ; Tue, 18 Feb 2014 11:48:54 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2161A052B for ; Tue, 18 Feb 2014 11:48:54 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so23733877qac.22 for ; Tue, 18 Feb 2014 11:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PLKKubJ3lHxkOG8/RUy4hOl3aOhcKHUIm/GXipF/ZLw=; b=KUO4WD0jMqfgY1rTM00iDXTpVxImFuhr+s8VcjA+Q1PJOGXnBfr7Y6TTVKARCJbNZA FIoOrcOzV95TGNmK8PdOo7Yk0bIK05XeyHaYELVlxASI+OjxWcoRCEPoFCSTTQBLInPt rxW20ClgFWh0JeWpZgf8kUSmum3P8m6KxsBK6oWizZfdwrS7XTemWBd5DQ4Qd3ck++LI c0jEfcwcMVwqvMycsiGnHTth08K/S87JPdZTUVXwy5ER6+LAD4Fhrs0MkmCR1lcNOFYZ vP/RTHqxB9bM6cvb4tasLqjO6Xx8Hs+UoVDMIJt+pJoRwz3ekCNtkdPSwAH9xJKUgEug bCvg== X-Received: by 10.224.172.133 with SMTP id l5mr46150030qaz.25.1392752930990; Tue, 18 Feb 2014 11:48:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.136 with HTTP; Tue, 18 Feb 2014 11:48:30 -0800 (PST) In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> From: "Andrew G. Malis" Date: Tue, 18 Feb 2014 14:48:30 -0500 Message-ID: To: Ross Callon Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/oVsMD1qkyWciQtsrWuNad1CVgyE Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 19:48:56 -0000 I support the adoption of this draft. Cheers, Andy On Mon, Feb 17, 2014 at 4:08 PM, Ross Callon wrote: > This is to start a poll on adopting > draft-chen-mpls-p2mp-ingress-protection-11 > > as an MPLS working group document. Since this call will continue through the > > IETF meeting in London, I will extent the poll by one week (so that it will > be a > > three week poll). > > > > Please send your comments (support/not support) to the mpls working group > > mailing list (mpls@ietf.org). > > > > This poll will end Tuesday March 11, 2014. This is of course the Tuesday > after > > the IETF. > > > > Thanks, Ross > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Feb 18 12:10: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 D10091A0103 for ; Tue, 18 Feb 2014 12:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nbETtbJbG3qL for ; Tue, 18 Feb 2014 12:09:59 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF7661A0516 for ; Tue, 18 Feb 2014 12:09:58 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-c2-5303be06ac16 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 65.97.12743.60EB3035; Tue, 18 Feb 2014 21:09:43 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Tue, 18 Feb 2014 15:09:43 -0500 From: Gregory Mirsky To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+Zq6nEvA Date: Tue, 18 Feb 2014 20:09:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.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_7347100B5761DC41A166AC17F22DF1121B76EE6Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXSPty77PuZggynnuS2+X1rCYnFr6UpW i78rrrA4MHssWfKTyeN601V2jy+XP7MFMEdx2aSk5mSWpRbp2yVwZbxYblGwIqbiy4U25gbG n4FdjJwcEgImEpuamlkhbDGJC/fWs3UxcnEICRxhlLh18AQThLOcUeLKmjksIFVsAkYSLzb2 sIPYIgJuEnP6QYo4OZgFbCXuPLnG2MXIwSEs4Cnx/5scRImXxKwN69ggbCOJiyeeMILYLAKq EhNvHQSL8wr4Sjzu6gcbIyQQKvHn016wMZwCYRJPHxmDhBmBbvt+ag3UJnGJW0/mM0HcLCCx ZM95ZghbVOLl439QvyhK7Oufzg5Rny+xaNEEdohVghInZz5hmcAoOgvJqFlIymYhKYOI60gs 2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDYxAqPsmASb7g7GPS8tDzFKc7Ao ifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx5ZTO+8w3/KInutc/mXnfpkrnQ9Pq 7nSd3e5vt4ol1ew44h1iO/HfR8OYi/6JE+Ji2su3vWx8V/+pJLw6/v3V5O7Foq4NMv7XeLJZ VrXd9BPkP3/jildQwNHYY/LzgmceMtSemnaMTTekUnJDyYliRd0DVu1sNVLz7s0+aHREpv9x xInUp5OVWIozEg21mIuKEwFy7wwmgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/w5O5tX-wnUwkSJYp8SaC8EiCBBs Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 20:10:02 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B76EE6Feusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable do not support Proposed solution cannot offer complete protection as in its root is miscon= ception that running multiple CC sessions between two nodes can help with d= etecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable ca= se presented in section 3.3 where CE is monitoring access link to the ingre= ss. This is well-known case, e.g. Ethernet First Mile, and can be addressed= in many different ways already. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 1:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B76EE6Feusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

do not support=

 <= /p>

Proposed solution cannot = offer complete protection as in its root is misconception that running mult= iple CC sessions between two nodes can help with detecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable case prese= nted in section 3.3 where CE is monitoring access link to the ingress. This= is well-known case, e.g. Ethernet First Mile, and can be addressed in many= different ways already.

 <= /p>

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

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

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 1:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_7347100B5761DC41A166AC17F22DF1121B76EE6Feusaamb103erics_-- From nobody Tue Feb 18 12:56: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 D68521A025A for ; Tue, 18 Feb 2014 12:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC04ofx0s4hC for ; Tue, 18 Feb 2014 12:56:10 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 174051A0081 for ; Tue, 18 Feb 2014 12:56:10 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id tp5so1689664ieb.13 for ; Tue, 18 Feb 2014 12:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=esddF+Z+q9dCN4VKwPjTHIEDyN0KsNUyiBRct93y+go=; b=fxiMuGKNmn2ab6fb7tJbHmUuZXLmGsxnrsKC4D7v+bLjgWQ/CldFT58ycHylleE3nY 8AM1RuEaHBebHIxCb2xpEmXgnA3I74+SKALmHqgzzBR1IQE1PMQsOUKZEYI1JqLQ+gnM SmdyARNv0qAHqp9/xSchEJWgKQ0mIJ36qnqpQ6zfnZ6b9F85FeErosR5aWwEEuyJIWHE B9Czj/I6Y8T9jbkljMCLalvH/XxyPsSozYUVVF5RWCVx3mruoYm/OrXwuJ5hv3uAnIwI 3LFsR6dks0yTGTI5TOvlUyMYBJXAAygA69If9DU9s5Hd05gGQ0jWSVy7aJeJ7a0CRFaw VqyA== MIME-Version: 1.0 X-Received: by 10.50.37.205 with SMTP id a13mr16258471igk.41.1392756967133; Tue, 18 Feb 2014 12:56:07 -0800 (PST) Received: by 10.50.129.34 with HTTP; Tue, 18 Feb 2014 12:56:07 -0800 (PST) In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Date: Tue, 18 Feb 2014 12:56:07 -0800 Message-ID: From: LEI LIU To: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=f46d0447f1da48d6d404f2b48030 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZH0w-0Rl3TMgx2XRN8zNV0MGyaU Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 18 Feb 2014 20:56:12 -0000 --f46d0447f1da48d6d404f2b48030 Content-Type: text/plain; charset=ISO-8859-1 Yes, support as a co-author. Thanks, Best regards, Lei 2014-02-17 13:08 GMT-08:00 Ross Callon : > This is to start a poll on adopting > draft-chen-mpls-p2mp-ingress-protection-11 > > as an MPLS working group document. Since this call will continue through > the > > IETF meeting in London, I will extent the poll by one week (so that it > will be a > > three week poll). > > > > Please send your comments (support/not support) to the mpls working group > > mailing list (mpls@ietf.org). > > > > This poll will end Tuesday March 11, 2014. This is of course the Tuesday > after > > the IETF. > > > > Thanks, Ross > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- -- __________________________________ Best Regards, Sincerely Yours, Lei Liu, Ph.D -------------------- Photonic Transport Network Laboratory, KDDI R&D Laboratories Inc., 2-1-15 Ohara Fujimino-shi, Saitama, Japan TELE: +81-49-278-7536 FAX: +81-49-278-7510 ZIP: 356-8502 E-mail: le-liu@kddilabs.jp / liulei@ieee.org --f46d0447f1da48d6d404f2b48030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, support as a co-author.=A0

Thanks,= =A0
Best regards,=A0

Lei


2014-02-17 13:08 = GMT-08:00 Ross Callon <rcallon@juniper.net>:

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

=A0

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

mailing list (mpls@ietf.org).

=A0

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

=A0

Thanks, Ross

=A0

=A0<= /p>


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




--
--= =A0
__________________________________
Best Regards,

Sincerely Yours,
Lei Liu, Ph.D
-= -------------------
Photonic Transport Network Laboratory,
KDDI R&D Laborato= ries Inc.,
2-1-15 Ohara Fujimino-shi, Saitama, Japan=A0
TELE: +81-49-278-7536
FAX: +81-49-278-7510
ZIP: 356-85= 02
--f46d0447f1da48d6d404f2b48030-- From nobody Tue Feb 18 12:59:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172C41A0467 for ; Tue, 18 Feb 2014 12:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548, 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 9CPFeHQQ1yaw for ; Tue, 18 Feb 2014 12:59:37 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEEF1A0276 for ; Tue, 18 Feb 2014 12:59:36 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,503,1389762000"; d="scan'208";a="70677236" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 18 Feb 2014 15:59:24 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 18 Feb 2014 15:59:33 -0500 From: "George, Wes" To: "mark.tinka@seacom.mu" Date: Tue, 18 Feb 2014 15:59:31 -0500 Thread-Topic: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt Thread-Index: Ac8s7FKYr3tqboD7TQuG3cR3XhBzMQ== Message-ID: References: <20140213223847.13307.40416.idtracker@ietfa.amsl.com> <201402141320.47691.mark.tinka@seacom.mu> <5300E7FE.40401@pi.nu> <201402170415.35860.mark.tinka@seacom.mu> In-Reply-To: <201402170415.35860.mark.tinka@seacom.mu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/16wsTKAaMV4Pb_cuJhmGBrI4gMQ Cc: "mpls@ietf.org" , "draft-george-mpls-ipv6-only-gap@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 20:59:39 -0000 SGkgTWFyayAtIHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBNeSByZXNwb25zZXMgaW5saW5lIGJl bG93Lg0KDQoNCj4+T24gMjAxNC0wMi0xNCAxODoyMCwgTWFyayBUaW5rYSB3cm90ZToNCj4+ID4g R2xhZCB0byBzZWUgdGhpcyB3b3JrIGdldHRpbmcgYSBsb3QgbW9yZSBhdHRlbnRpb24sIGFzDQo+ PiA+IGl0IGlzIG9uZSBjb25jZXJuIG9mIG1pbmUgYXMgYW4gb3BlcmF0b3IuDQo+PiA+DQo+PiA+ IEp1c3QgYSBmZXcgY29tbWVudHMsIGZvciBteSBvd24gY2xhcml0eToNCj4+ID4gICAgMS4gVGhp cyBkb2N1bWVudCBmb2N1c2VzIG9uIGEgc2luZ2xlLXN0YWNrIElQdjYNCj4+ID4NCj4+ID4gICAg ICAgYmFja2JvbmUsIGJ1dCBmb3IgcHJhY3RpY2FsIG9wZXJhdGlvbnMgYXMgd2VsbCwgSQ0KPj4g PiAgICAgICB0aGluayBpdCBtaWdodCBiZSBuZWNlc3NhcnkgdG8gbG9vayBhdCBkdWFsIC0NCj4+ ID4gICAgICAgc3RhY2sgc2NlbmFyaW9zIGFzIHdlbGwsIHdoZXJlIGEgYW4gb3BlcmF0b3INCj4+ ID4gICAgICAgd291bGQgbGlrZSB0byB0cmFuc3BvcnQgYm90aCBJUHY0IGFuZCBJUHY2IG92ZXIN Cj4+ID4gICAgICAgYW4gTVBMUyBuZXR3b3JrLCBidXQgbmF0aXZlbHkgZm9yIGVhY2ggcHJvdG9j b2wuDQo+PiA+ICAgICAgIEkgY29uY2VkZSB0aGF0IHRoaXMgbWF5IGhhdmUgdG8gYmUgZG9uZSBp bg0KPj4gPiAgICAgICBhbm90aGVyIGRvY3VtZW50Lg0KV0ddIE15IHZpZXcgaXMgdGhhdCB0aGVy ZSBpcyBnZW5lcmFsbHkgbm8gZ2FwIGlmIHNvbWVvbmUgd2FudHMgdG8gb3BlcmF0ZQ0KdGhpcyB3 YXksIHNpbmNlIElQdjQgKGFuZCBJUHY0LW9ubHkpIHdvcmtzIHRvZGF5LCBhbmQgSVB2Ni1vbmx5 L25hdGl2ZSBpcw0KZGVhbHQgd2l0aCBpbiB0aGlzIGRyYWZ0LiBEdWFsIHN0YWNrIG5hdGl2ZSAo dnMgZW5jYXBzdWxhdGluZyBvbmUNCnByb3RvY29sKSBzaW1wbHkgcnVucyBib3RoIGluIHBhcmFs bGVsLCBhbmQgdGhlIG9ubHkgZGlmZmVyZW5jZXMgSSBjb3VsZA0Kc2VlIHdvdWxkIGJlIHRvIGVu c3VyZSB0aGF0IHRoZXJlIGFyZSBubyBkZXBlbmRlbmNpZXMgYmV0d2VlbiB0aGUgYWRkcmVzcw0K ZmFtaWxpZXMgc3VjaCBhcyB0aGVyZSBpcyB0b2RheSwgbWVhbmluZyB0aGF0IGlmIHlvdSBhZGRy ZXNzIHRoZSBnYXBzIGZvcg0KSVB2Ni1vbmx5IG9wZXJhdGlvbiwgeW914oCZcmUgY292ZXJlZC4g RG8geW91IGhhdmUgc29tZXRoaW5nIHNwZWNpZmljIGluDQptaW5kIHRoYXQgeW91IHRoaW5rIGlz IG1pc3NpbmcgZnJvbSB0aGlzIGdhcCBhbmFseXNpcyB0byBjb3ZlciB0aGlzDQpkdWFsLXN0YWNr IHVzZSBjYXNlLCBvciBpcyBpdCBtb3JlIGEgbWF0dGVyIG9mIHNpbXBseSBtZW50aW9uaW5nIGl0 IGFzIGENCnBvc3NpYmxlIG1vZGUgb2Ygb3BlcmF0aW9uIGFuZCB0aGF0IGl04oCZcyBhIG5vbi1p c3N1ZT8NCg0KPj4gPg0KPj4gPiAgICAyLiBTZWN0aW9uIDMuMi4zLjEgKElHUCkgc3BlYWtzIHRv IE9TUEZ2Mi4gTm90IHN1cmUNCj4+ID4NCj4+ID4gICAgICAgd2h5IGdpdmVuIE9TUEZ2MiBkb2Vz IG5vdCBzdXBwb3J0IElQdjYuDQpXR10gSXQgaXMgZXN0YWJsaXNoaW5nIHRoYXQgYSBmZWF0dXJl IGV4aXN0cyBpbiBJUHY0ICh2aWEgT1NQRnYyKSB0aGF0DQpuZWVkcyB0byBiZSBzdXBwb3J0ZWQg aW4gSVB2Ni4gVGhlIGZvbGxvd2luZyBzZW50ZW5jZSBub3RlcyB0aGF0IHRoZQ0KZXF1aXZhbGVu dCBmdW5jdGlvbnMgZm9yIElQdjYgaGF2ZSBiZWVuIGFkZGVkIHRvIE9TUEZ2My4gT3BlbiB0bw0K c3VnZ2VzdGlvbnMgb24gaG93IHRvIG1ha2UgdGhhdCBjbGVhcmVyLg0KDQo+PiA+DQo+PiA+ICAg IDMuIEN1cmlvdXMgd2h5IHNlY3Rpb24gMy4zLjIuNC4zIChQRS1QRSBNdWx0aWNhc3QNCj4+ID4N Cj4+ID4gICAgICAgUm91dGluZyBQcm90b2NvbCkgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGdhcA0K Pj4gPiAgICAgICBhbmFseXNpcy4NCldHXSBUaGUgd29yZGluZyBjb3VsZCBwcm9iYWJseSBiZSBp bXByb3ZlZCB0byBjbGFyaWZ5LCBidXQgc3BlYWtpbmcgYXMNCmVkaXRvciwgYW5kIG5vdCBhdXRo b3Igb2YgdGhhdCBzcGVjaWZpYyBzZWN0aW9uIEkgdGhpbmsgdGhlIHJhdGlvbmFsZSBpcw0KYXMg Zm9sbG93czogUElNIGFuZCBCR1AgYXJlIGJvdGggdXNlZCBvdXRzaWRlIG9mIHRoaXMgYXBwbGlj YXRpb24sIHNvIGlmDQp0aGV5IGhhdmUgcHJvYmxlbXMgd2l0aCBJUHY2LW9ubHkgb3BlcmF0aW9u LCB0aGV5IG5lZWQgdG8gYmUgYWRkcmVzc2VkDQpvdXRzaWRlIG9mIE1QTFMsIHVubGVzcyB0aGVy ZSBhcmUgaXNzdWVzIHNwZWNpZmljIHdpdGggdGhlaXINCmltcGxlbWVudGF0aW9uIGFzIGFuIE1Q THMgUEUtQ0Ugb3IgUEUtUEUgcHJvdG9jb2wgdGhhdCB3ZSBoYXZlbuKAmXQNCmRpc2N1c3NlZC4g VGhlIGNvbnRyaWJ1dG9yIGZvciB0aGF0IHNlY3Rpb24gd2lsbCBoYXZlIHRvIGNoaW1lIGluIGlm IEnigJltDQptaXNyZXByZXNlbnRpbmcuDQoNCj4+ID4NCj4+ID4gICAgNC4gV2hpbGUgd29yayBp cyBzdGlsbCBvbmdvaW5nIGZvciBTZWdtZW50IFJvdXRpbmcsDQo+PiA+DQo+PiA+ICAgICAgIHBl cmhhcHMgaXQgbWlnaHQgYmUgZ29vZCB0byBtYWtlIGEgcmVmZXJlbmNlIHRvDQo+PiA+ICAgICAg IGl0IGxpa2UgeW91IGRpZCBmb3IgRVZQTi4NCldHXSBXZeKAmXJlIHNraXJ0aW5nIGEgZmluZSBs aW5lIGJldHdlZW4gbm90aW5nIGEgZmV3IGJpZyB0aGluZ3MgaW4gcHJvZ3Jlc3MNCnRoYXQgbmVl ZCB0byBjb25zaWRlciB0aGlzIGdhcCBhbmFseXNpcyBkdWUgdG8gbGlrZWx5IGhhdmluZyBpbXBh Y3RzLCBhbmQNCmhhdmluZyB0aGUgZHJhZnQgY29sbGFwc2UgdW5kZXIgaXRzIG93biB3ZWlnaHQv bmV2ZXIgYmUgY29tcGxldGUgZHVlIHRvDQpuZWVkaW5nIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiBh bGwgb2YgdGhlIHRoaW5ncyB0aGF0IGFyZSBpbiBwcm9ncmVzcyBpbg0KTVBMUyBhbmQgcmVsYXRl ZCBXR3MuIFBhcnQgb2YgbWUgdGhpbmtzIGl0IG1pZ2h0IGJlIGJldHRlciB0byByZW1vdmUgdGhl DQpFVlBOIHNlY3Rpb24gYW5kL29yIHJlcGxhY2UgaXQgd2l0aCBhIG1vcmUgZ2VuZXJpYyBzdGF0 ZW1lbnQgYWJvdXQgdGhpbmdzDQppbiBwcm9ncmVzcyBiZWluZyBvdXQgb2Ygc2NvcGUgYW5kIHJl c3BvbnNpYmxlIGZvciB0aGVpciBvd24gZXZhbHVhdGlvbiBvZg0KSVB2Ni1vbmx5IE1QTFMgb3Bl cmF0aW9uLiBPcGVuIHRvIHN1Z2dlc3Rpb25zIGZyb20gdGhlIFdHLg0KDQpUaGFua3MgYWdhaW4h DQoNCldlcyBHZW9yZ2UNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwg d2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdo dCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gg aXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9m IHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0 byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhp cyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Wed Feb 19 01:01: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 680111A057E for ; Wed, 19 Feb 2014 01:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 87-CEU1tqKzi for ; Wed, 19 Feb 2014 01:01:09 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id BAFDB1A006A for ; Wed, 19 Feb 2014 01:01:09 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id x10so108196pdj.25 for ; Wed, 19 Feb 2014 01:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=0gmOhqdXiZbQucnnR2nwx5GVVb8q6RN9BYjBM783H7E=; b=cGu7/cHtg0kMq7tw6/nUA2vc7UXIsc6K1fNptGk6/9pmSXbjnOcBWEwuluoNamNk3+ qCu/6vEzGfoQNe1T/IINT21LT2ao/8XcKfq2T9X/vFew/nWd3wSDhIUnTA8u+wBVPuOy TYu2DzjwTlIueGAyglDkqrGvNPf1LTpDxNPXdlPioWn19bLBMWuxdnI/SP70kuuCQMxU CbfU0WUDwmfncKgUBuJ06j+7EWf3W4swudLTfXSw3y+tZAovlDH35xG9wnwoXdV/CZJM JdEPnUi6YJg0l5kajWY6BzjCAa563oGvNPde+kLAwH22CT5BGJciR0Iog04AlWvZn/Kj 99sQ== X-Received: by 10.68.249.100 with SMTP id yt4mr863279pbc.165.1392800466712; Wed, 19 Feb 2014 01:01:06 -0800 (PST) Received: from [192.168.1.5] ([120.35.118.115]) by mx.google.com with ESMTPSA id un5sm161506335pab.3.2014.02.19.01.00.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 01:00:59 -0800 (PST) References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6E2FF27B-1E6B-4B9A-B43C-2DA956DCD5D0 Content-Transfer-Encoding: 7bit Message-Id: <85C0D9DD-60FE-47BD-B384-F290B21EF271@gmail.com> X-Mailer: iPhone Mail (10B142) From: Emily Date: Wed, 19 Feb 2014 17:00:52 +0800 To: Ross Callon Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Dk_o8saO5lAgw5t6TIhfRYo7M40 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Feb 2014 09:01:12 -0000 --Apple-Mail-6E2FF27B-1E6B-4B9A-B43C-2DA956DCD5D0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Support. Best regards, Emily On Feb 18, 2014, at 5:08, Ross Callon wrote: > This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protectio= n-11 > as an MPLS working group document. Since this call will continue through t= he > IETF meeting in London, I will extent the poll by one week (so that it wil= l be a > three week poll). > =20 > Please send your comments (support/not support) to the mpls working group > mailing list (mpls@ietf.org). > =20 > This poll will end Tuesday March 11, 2014. This is of course the Tuesday a= fter > the IETF. > =20 > Thanks, Ross > =20 > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-6E2FF27B-1E6B-4B9A-B43C-2DA956DCD5D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Support.


Best regards,
Emily

On Feb 18, 2014, at 5:08, Ross Callon <rcallon@juniper.net> wrote:

This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Since this call will continue through the

IETF meeting in London, I will extent the poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 2014. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--Apple-Mail-6E2FF27B-1E6B-4B9A-B43C-2DA956DCD5D0-- From nobody Wed Feb 19 01:18: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 C87681A008D for ; Wed, 19 Feb 2014 01:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMbjJlNjrjYY for ; Wed, 19 Feb 2014 01:18:20 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-mba.ke.seacomnet.com [41.87.100.230]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7641A057E for ; Wed, 19 Feb 2014 01:18:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1WG3Gy-0004JN-0L; Wed, 19 Feb 2014 11:16:56 +0200 From: Mark Tinka Organization: SEACOM To: "George, Wes" Date: Wed, 19 Feb 2014 11:16:36 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <20140213223847.13307.40416.idtracker@ietfa.amsl.com> <201402170415.35860.mark.tinka@seacom.mu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2405947.zYbu5LiZkb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201402191116.39241.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lE6TcBiU2tCgS7oo7h38Tv04hMQ Cc: "mpls@ietf.org" , "draft-george-mpls-ipv6-only-gap@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 09:18:23 -0000 --nextPart2405947.zYbu5LiZkb Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday, February 18, 2014 10:59:31 PM George, Wes wrote: > WG] My view is that there is generally no gap if someone > wants to operate this way, since IPv4 (and IPv4-only) > works today, and IPv6-only/native is dealt with in this > draft. Dual stack native (vs encapsulating one protocol) > simply runs both in parallel, and the only differences I > could see would be to ensure that there are no > dependencies between the address families such as there > is today, meaning that if you address the gaps for > IPv6-only operation, you=E2=80=99re covered. Do you have > something specific in mind that you think is missing > from this gap analysis to cover this dual-stack use > case, or is it more a matter of simply mentioning it as > a possible mode of operation and that it=E2=80=99s a non-issue? Perhaps the latter. I just wonder whether implementations might find themselves=20 in conflict for how to data plane IP-in-MPLS encapsulations=20 depending on: - What type of traffic it is (IPv4, IPv6, Ethernet, e.t.c.). - Whether the destination is an IPv4 or IPv6 destination. - What control plane signaled the IPv4 or IPv6 LSP, and whether there is any congruency between the signaled LSP and underlying carriage. I expect this might be easy for implementors to resolve if=20 the incoming traffic is IP, e.g., if incoming traffic is=20 IPv4, use MPLSv4; and if incoming traffic IPv6, use MPLSv6=20 (where MPLSv4|v6 has congruency between the control and data=20 plane). However, if inbound traffic is IP-protocol agnostic, e.g.,=20 Ethernet, PPP, e.t.c., how does the router determine whether=20 to place that traffic on MPLSv4 or MPLSv6 (without=20 considering potentially complex options like looking into=20 the Ethernet frame to determine the Layer 3 payload)? Again, not sure whether this draft should cover this, but=20 given successful operator deployments of MPLSv6 (both=20 control and data planes) are very likely to live in dual- stack environments initially (especially with very little=20 MPLSv6 experience), it might be good to think about the=20 concerns mentioned above. What I'm not sure about is if this=20 "thinking" is best done here, or somewhere else. > WG] It is establishing that a feature exists in IPv4 (via > OSPFv2) that needs to be supported in IPv6. The > following sentence notes that the equivalent functions > for IPv6 have been added to OSPFv3. Open to suggestions > on how to make that clearer. Okay, understand. I can think of ways to make it clearer, but since assertions=20 to both OSPFv2 and OSPFv3 are reasonably generic in the=20 context of Traffic Engineering extensions, I'm happy to=20 leave it this way without delving too much into how those=20 extensions aid MPLS operations. On a side note, it would be interesting to find out whether=20 there has been any thought toward RFC 5838 implementations=20 for operational deployment of IPv4 address families over=20 OSPFv3, and how they are affected by MPLS-TE for IPv4 across=20 this scenario. But I digress... > WG] The wording could probably be improved to clarify, > but speaking as editor, and not author of that specific > section I think the rationale is as follows: PIM and BGP > are both used outside of this application, so if they > have problems with IPv6-only operation, they need to be > addressed outside of MPLS, unless there are issues > specific with their implementation as an MPLs PE-CE or > PE-PE protocol that we haven=E2=80=99t discussed. The > contributor for that section will have to chime in if > I=E2=80=99m misrepresenting. Well, looking at RFC 4659 and 6514, it would certainly be an=20 implementation issue if BGPv6 was not supported as a PE-PE=20 Multicast routing protocol, i.e., the RFC's appear to cover=20 support for IPv6 reasonably well. I'll make some time to go=20 over them with a finer comb just in case there are any gaps=20 from a spec. perspective. I can't speak to PIM as a PE-PE Multicast routing protocol=20 in the context of MPLSv6. Perhaps someone else on this list=20 is willing to go through that and report back... In practice (and speaking to my first concern, above), it=20 would be interesting to see how the network handles IPv4 and=20 IPv6 Multicast traffic carried over an NG-MVPN architecture=20 at the same time, with native MPLSv4 and MPLSv6 control and=20 data planes. =20 > WG] We=E2=80=99re skirting a fine line between noting a few big > things in progress that need to consider this gap > analysis due to likely having impacts, and having the > draft collapse under its own weight/never be complete > due to needing an exhaustive list of all of the things > that are in progress in MPLS and related WGs. Part of me > thinks it might be better to remove the EVPN section > and/or replace it with a more generic statement about > things in progress being out of scope and responsible > for their own evaluation of IPv6-only MPLS operation. > Open to suggestions from the WG. I would be in support of not listing ongoing work as well,=20 in this particular case, as it may infer a responsibility=20 (even if it shouldn't) to consider all other in-progress=20 work that may or may not be looking at a gap analysis of=20 MPLS services or features between IPv4 and IPv6 networks in=20 their specific contexts. As mentioned in this draft, ideal is that all independent=20 work implements RFC 6540 as a best practice. Cheers, Mark. --nextPart2405947.zYbu5LiZkb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJTBHZ3AAoJEGcZuYTeKm+GPIoQAKzDE7ggpZkHgPuhIZae8unp 8aOt80XUtAAdrUBeYtYVgcoLse2EmotEmvyjrfMMTt3LsTZFcoeVZlc62Vp9GUV6 kl9chkFKK1L40pt1G3/DT6u9qjyo9dzopSKnXqRjgXngyXosOrrmLFoVGoSJIfM7 8e9p+af06nyw/C4odewsMNRLLdXzGErWYBK3OKM21PHBxZkUsKmWH1PrvEQ+chEB v8/mHZ8SBYytaoGfOVTP7nI24oehUIEs5f+D0RbxqCIhchGS4WvtR3uT83izFrp5 QbiOC5x2mawcngsMjEfPRqVXLiZNMIVWdqhOebEYy3MVJvyIJVYYOoxb09n09Evc ODdqf0+0ZzAkO/iNSHC9gbE5PnDrMU2H2O1viabQFLEqyioX5oflT8SVaSDaQZ4E hTcmynLYSo09hreJj1fmMnc2Ot8Ygd1m8rpZA57iPqL4nuj32a4ecR6I8A3VxRXe ZvTd2Ctat0h076mai6Ge5KRxlcU051fUhXqHNgopJdI91qRDP1frkBs9zFZkjvQ+ GDTIP/eaDqnk7RfAXXfYmT7om/Ihchccy99EVACQV2MN86lu5vJ0xmghAOXNmp3e O9oU2qFBJtgu00qFciQ7L4mFw1z8gufcGaHmZrGy/w6U1YUml8z1+oSyQODf0nrS QzbwtILs9AkcR+C37P1m =PIyW -----END PGP SIGNATURE----- --nextPart2405947.zYbu5LiZkb-- From nobody Wed Feb 19 04:29: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 C38A11A05A6 for ; Wed, 19 Feb 2014 04:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FqDAbrjWH2B for ; Wed, 19 Feb 2014 04:29:10 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 501821A0594 for ; Wed, 19 Feb 2014 04:29:10 -0800 (PST) Received: from [2.69.143.61] (2.69.143.61.mobile.tre.se [2.69.143.61]) (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 633D7180156A; Wed, 19 Feb 2014 13:29:06 +0100 (CET) Message-ID: <5304A391.8010100@pi.nu> Date: Wed, 19 Feb 2014 13:29:05 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <52F08085.9000907@pi.nu> In-Reply-To: <52F08085.9000907@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/8a6DJxUfZH9djPnRLH4Qmm2x5rc Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-extended-admin-group@tools.ietf.org Subject: [mpls] Closed wglc - Re: working group last call for draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Feb 2014 12:29:13 -0000 Working Group, This working group last call is closed. There have been comments. Could the author please address the comments and post a new version as necessary. /Loa On 2014-02-04 06:54, Loa Andersson wrote: > Working Group, > > This is to initiate a working group last call on > draft-ietf-mpls-extended-admin-group-02. > > There are no IPR disclosures against this document. The author has > stated that he is unaware of any 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 Feb 18, 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 Wed Feb 19 05:30: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 5A3BF1A0148 for ; Wed, 19 Feb 2014 05:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 YdNeL65vy5Gq for ; Wed, 19 Feb 2014 05:29:54 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id A10AC1A01CF for ; Wed, 19 Feb 2014 05:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6779; q=dns/txt; s=iport; t=1392816591; x=1394026191; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nCRa4ykltHYU0d8gXM9x7DYQT5PgD4tBWkVCYOgynK8=; b=JsgYy3mUcT7/tyYT+5UL/WXtt1oEW4D3XisdWZIzQoAOpcVBXdnw3lkB 3GsBWy4lztmEQC1CJh9FB49fTNuBZfMdOpEMQ25bWWSAgf3x00CoePbmZ SMh+bOmsGRoYTaULvg44gM12ZVedFFGQm8GnKffYkhmTolfCM5+pbF9ND 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADKxBFOtJV2c/2dsb2JhbABZgwaBD795gRcWdIIlAQEBBGcSEgEIEgZgFw4CBA4FiAXNcReOZAeEOASJEI8gkiSDLYIq X-IronPort-AV: E=Sophos;i="4.97,505,1389744000"; d="scan'208";a="21554169" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 19 Feb 2014 13:29:51 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1JDTplW025839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 13:29:51 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.253]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 07:29:50 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: "mark.tinka@seacom.mu" , "George, Wes" Thread-Topic: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt Thread-Index: AQHPKQxjtYhZ8zU6jk2j85Vqn3KtF5q1ABYAgAN7nwCAAKMPgIACzFuAgADN8AD///LvAA== Date: Wed, 19 Feb 2014 13:29:50 +0000 Message-ID: In-Reply-To: <201402191116.39241.mark.tinka@seacom.mu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.150.52.152] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eFoOv6F0JKWRNjB0-RwndgS99Ww Cc: "mpls@ietf.org" , "draft-george-mpls-ipv6-only-gap@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 13:29:57 -0000 Hi Mark, Well, looking at RFC 4659 and 6514, it would certainly be an implementation issue if BGPv6 was not supported as a PE-PE Multicast routing protocol, i.e., the RFC's appear to cover support for IPv6 reasonably well. I'll make some time to go over them with a finer comb just in case there are any gaps from a spec. perspective. Thanks. I also think any gap raises as part of the same may not be related to this document. BGP I sussed as overlay and the underlying path (or the PMSI tunnel) can be GRE, IP or LSP. Any gap when LSP is used as PMSI will be covered in section 3.3.2.4.2. Any gaps when GRE or IP is used IMO is not within the scope of this document. I can't speak to PIM as a PE-PE Multicast routing protocol in the context of MPLSv6. Perhaps someone else on this list is willing to go through that and report back... When PIM is used as PE-PE protocol, it doesn't impose any need or signal what would be the PMSI tunnel to be used. It is more like a local matter and can be LSP or GRE. So any gaps can be covered as part of the respective protocol and I think is not related to this document. Thanks, Nagendra On 2/19/14 4:16 AM, "Mark Tinka" wrote: >On Tuesday, February 18, 2014 10:59:31 PM George, Wes wrote: > >> WG] My view is that there is generally no gap if someone >> wants to operate this way, since IPv4 (and IPv4-only) >> works today, and IPv6-only/native is dealt with in this >> draft. Dual stack native (vs encapsulating one protocol) >> simply runs both in parallel, and the only differences I >> could see would be to ensure that there are no >> dependencies between the address families such as there >> is today, meaning that if you address the gaps for >> IPv6-only operation, you=B9re covered. Do you have >> something specific in mind that you think is missing >> from this gap analysis to cover this dual-stack use >> case, or is it more a matter of simply mentioning it as >> a possible mode of operation and that it=B9s a non-issue? > >Perhaps the latter. > >I just wonder whether implementations might find themselves >in conflict for how to data plane IP-in-MPLS encapsulations >depending on: > > - What type of traffic it is (IPv4, IPv6, Ethernet, > e.t.c.). > > - Whether the destination is an IPv4 or IPv6 > destination. > > - What control plane signaled the IPv4 or IPv6 LSP, > and whether there is any congruency between the > signaled LSP and underlying carriage. > >I expect this might be easy for implementors to resolve if >the incoming traffic is IP, e.g., if incoming traffic is >IPv4, use MPLSv4; and if incoming traffic IPv6, use MPLSv6 >(where MPLSv4|v6 has congruency between the control and data >plane). > >However, if inbound traffic is IP-protocol agnostic, e.g., >Ethernet, PPP, e.t.c., how does the router determine whether >to place that traffic on MPLSv4 or MPLSv6 (without >considering potentially complex options like looking into >the Ethernet frame to determine the Layer 3 payload)? > >Again, not sure whether this draft should cover this, but >given successful operator deployments of MPLSv6 (both >control and data planes) are very likely to live in dual- >stack environments initially (especially with very little >MPLSv6 experience), it might be good to think about the >concerns mentioned above. What I'm not sure about is if this >"thinking" is best done here, or somewhere else. > >> WG] It is establishing that a feature exists in IPv4 (via >> OSPFv2) that needs to be supported in IPv6. The >> following sentence notes that the equivalent functions >> for IPv6 have been added to OSPFv3. Open to suggestions >> on how to make that clearer. > >Okay, understand. > >I can think of ways to make it clearer, but since assertions >to both OSPFv2 and OSPFv3 are reasonably generic in the >context of Traffic Engineering extensions, I'm happy to >leave it this way without delving too much into how those >extensions aid MPLS operations. > >On a side note, it would be interesting to find out whether >there has been any thought toward RFC 5838 implementations >for operational deployment of IPv4 address families over >OSPFv3, and how they are affected by MPLS-TE for IPv4 across >this scenario. But I digress... > >> WG] The wording could probably be improved to clarify, >> but speaking as editor, and not author of that specific >> section I think the rationale is as follows: PIM and BGP >> are both used outside of this application, so if they >> have problems with IPv6-only operation, they need to be >> addressed outside of MPLS, unless there are issues >> specific with their implementation as an MPLs PE-CE or >> PE-PE protocol that we haven=B9t discussed. The >> contributor for that section will have to chime in if >> I=B9m misrepresenting. > >Well, looking at RFC 4659 and 6514, it would certainly be an >implementation issue if BGPv6 was not supported as a PE-PE >Multicast routing protocol, i.e., the RFC's appear to cover >support for IPv6 reasonably well. I'll make some time to go >over them with a finer comb just in case there are any gaps >from a spec. perspective. > >I can't speak to PIM as a PE-PE Multicast routing protocol >in the context of MPLSv6. Perhaps someone else on this list >is willing to go through that and report back... > >In practice (and speaking to my first concern, above), it >would be interesting to see how the network handles IPv4 and >IPv6 Multicast traffic carried over an NG-MVPN architecture >at the same time, with native MPLSv4 and MPLSv6 control and >data planes. >=20 >> WG] We=B9re skirting a fine line between noting a few big >> things in progress that need to consider this gap >> analysis due to likely having impacts, and having the >> draft collapse under its own weight/never be complete >> due to needing an exhaustive list of all of the things >> that are in progress in MPLS and related WGs. Part of me >> thinks it might be better to remove the EVPN section >> and/or replace it with a more generic statement about >> things in progress being out of scope and responsible >> for their own evaluation of IPv6-only MPLS operation. >> Open to suggestions from the WG. > >I would be in support of not listing ongoing work as well, >in this particular case, as it may infer a responsibility >(even if it shouldn't) to consider all other in-progress >work that may or may not be looking at a gap analysis of >MPLS services or features between IPv4 and IPv6 networks in >their specific contexts. > >As mentioned in this draft, ideal is that all independent >work implements RFC 6540 as a best practice. > >Cheers, > >Mark. From Dmitry.Volkov@interactivedata.com Tue Feb 18 11:03: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 E10B31A050E for ; Tue, 18 Feb 2014 11:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 VmZC31IDBRRA for ; Tue, 18 Feb 2014 11:03:45 -0800 (PST) Received: from mxgateway01.interactivedata.com (mxgateway01.interactivedata.com [199.181.252.99]) by ietfa.amsl.com (Postfix) with ESMTP id D99741A015F for ; Tue, 18 Feb 2014 11:03:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,502,1389762000"; d="scan'208";a="145087589" Received: from dlp-extmx01.intdata.com ([192.245.63.35]) by mxgateway01.interactivedata.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2014 14:03:41 -0500 Received: from SWPMA1EXCAS02.idco.intdata.com ([10.170.32.201]) by dlp-extmx01.intdata.com (RSA Interceptor); Tue, 18 Feb 2014 14:03:30 -0500 Received: from SWPMA1EXMAIL01.idco.intdata.com ([fe80::b9ba:2bdd:93cc:7b49]) by SWPMA1EXCAS02.idco.intdata.com ([fe80::f5db:cc19:f626:5fad%10]) with mapi id 14.03.0169.001; Tue, 18 Feb 2014 14:03:30 -0500 From: "Volkov, Dmitry" To: "loa@pi.nu" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Thread-Topic: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQK2a8EIp9dmBA2KiMux9W3jyVdbopjYZwjg Date: Tue, 18 Feb 2014 19:03:29 +0000 Message-ID: References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.157.149] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yT2UxxeLDrV20lFqJ8EMA6n02kw X-Mailman-Approved-At: Wed, 19 Feb 2014 08:02:39 -0800 Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:05:11 -0000 This looks like a logical and valuable extension of rfc6826 which should fi= nd its application in financial SPs. Support. Please adopt. = Thanks Dmitry Volkov, CCIE 10292 (SP/Sec/R&S) | Sr.Network Architect | Interactive= Data (Europe) -----Original Message----- From: loa@pi.nu [mailto:loa@pi.nu] = Sent: 05 February 2014 06:29 Subject: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-enco= ding Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-in-ba= nd-wildcard-encoding as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. Please note that we have identified an overlap between this document and dr= aft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this document = unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp to cover this. There are no IPR claims against this document. The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends February 19, 2014. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 ******************************************************* This message (including any files transmitted with it) may contain confiden= tial and/or proprietary information, is the property of Interactive Data Co= rporation and/or its subsidiaries, and is directed only to the addressee(s)= . If you are not the designated recipient or have reason to believe you rec= eived this message in error, please delete this message from your system an= d notify the sender immediately. An unintended recipient's disclosure, copy= ing, distribution, or use of this message or any attachments is prohibited = and may be unlawful. = ******************************************************* From nobody Wed Feb 19 08:50: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 7EB071A0503 for ; Wed, 19 Feb 2014 08:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 90iRT8dMnpc8 for ; Wed, 19 Feb 2014 08:50:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A8B7B1A04F3 for ; Wed, 19 Feb 2014 08:50:04 -0800 (PST) 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 BDT35215; Wed, 19 Feb 2014 16:50:00 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 16:47:21 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 16:47:34 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 08:47:22 -0800 From: Quintin zhao To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLZJCHJ/AoCbCa0CJKoCBKdBRgQ== Date: Wed, 19 Feb 2014 16:47:21 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C03071E403@SJCEML701-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.210] 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/NbtV2fa_Q1eS_fqJrfFBXLHSkN4 Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 19 Feb 2014 16:50:07 -0000 Support. On Feb 18, 2014, at 5:08, Ross Callon wrote: > This is to start a poll on adopting=20 > draft-chen-mpls-p2mp-ingress-protection-11 > as an MPLS working group document. Since this call will continue=20 > through the IETF meeting in London, I will extent the poll by one week=20 > (so that it will be a three week poll). > =20 > Please send your comments (support/not support) to the mpls working=20 > group mailing list (mpls@ietf.org). > =20 > This poll will end Tuesday March 11, 2014. This is of course the=20 > Tuesday after the IETF. > =20 > Thanks, Ross > =20 > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -------------- next part -------------- An HTML attachment was scrubbed... URL: ** From nobody Wed Feb 19 09:47: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 175DA1A04F1 for ; Wed, 19 Feb 2014 09:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548, 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 YaxiQ_8opz_T for ; Wed, 19 Feb 2014 09:47:32 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id AD1091A0249 for ; Wed, 19 Feb 2014 09:47:32 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,507,1389762000"; d="scan'208";a="70907885" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 19 Feb 2014 12:47:17 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 19 Feb 2014 12:47:28 -0500 From: "George, Wes" To: Mach Chen , "draft-george-mpls-ipv6-only-gap@tools.ietf.org" , "mpls@ietf.org" Date: Wed, 19 Feb 2014 12:47:26 -0500 Thread-Topic: draft-george-mpls-ipv6-only-gap-04.txt Thread-Index: Ac8tmqfCPP/NsmVlRJiAt1SLr7g0LQ== Message-ID: References: <52FF2006.7060900@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EiJHg5TlR3pk5SdvTVcZJspyRFs Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:47:35 -0000 QWRkaW5nIE1QTFMgV0csIHNvbWUgcmVzcG9uc2VzIGJlbG93LCBhbmQgSeKAmW0gc3VyZSBteSBj by1hdXRob3JzIHdpbGwNCmNoaW1lIGluIGFzIHdlbGwuIFRoYW5rcyBmb3IgdGhlIHJldmlldyEN Cg0KV2VzIEdlb3JnZQ0KDQoNCk9uIDIvMTkvMTQsIDI6MjMgQU0sICJNYWNoIENoZW4iIDxtYWNo LmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5TcGVjaWZpYyBjb21tZW50czoNCj4NCj4xLiBT ZWN0aW9uIDMuMg0KPg0KPklHUCB1c2VkIGZvciBsYWJlbCBtYXBwaW5nIGlzIHByb3Bvc2VkIGJ5 IFNlZ21lbnQgcm91dGluZywgdGhlcmUgbWF5IG5lZWQNCj5hIHN1YiBzZWN0aW9uIGZvciB0aGlz Lg0KDQpXR10gSSBiZWxpZXZlIHdl4oCZbGwgbmVlZCB0byBtYWtlIHN1cmUgdGhlIGZvbGtzIGlu IFNQUklORyBhcmUgY29uc2lkZXJpbmcNCklQdjYtb25seSBvcGVyYXRpb24gYW5kIHB1dCBhIG1v cmUgZ2VuZXJpYyBub3RlIHRoYXQgZHJhZnQgdGVjaG5vbG9naWVzDQoobGlrZSBFVlBOIGFuZCBT ZWdtZW50IFJvdXRpbmcpIGFyZSBub3QgaW4gc2NvcGUgZm9yIHRoZSBnYXAgYW5hbHlzaXMgKHNl ZQ0KbXkgcHJldmlvdXMgb24tbGlzdCByZXNwb25zZSkNCj4NCj4yLiBTZWN0aW9uIDMuMi4zLjEu DQo+DQo+MSkgVG8gZ2l2ZSBhIGNvbXByZWhlbnNpdmUgaW50cm9kdWN0aW9uIG9mIFRFIGxpbmsg YWR2ZXJ0aXNlbWVudCwgaXQgbWF5DQo+bmVlZCB0byBtZW50aW9uIElHUCBleHRlbnNpb25zIGZv ciBpbnRlci1BUyBURSBsaW5rIGFkdmVydGlzZW1lbnQNCj4oUkZDNTMxNiBhbmQgUkZDNTM5Miku DQo+DQo+MikuIEJHUC1MUyBtYXkgbmVlZCB0byBiZSBtZW50aW9uZWQgc29tZXdoZXJlDQo+DQo+ My4gU2VjdGlvbiAzLjMuMy4gIE1QTFMtVFANCj4NCj4iICBNUExTLVRQIGRvZXMgbm90IHJlcXVp cmUgSVAgKHNlZSBzZWN0aW9uIDIgb2YgUkZDIDU5MjEgW1JGQzU5MjFdKSBhbmQNCj4gICBzaG91 bGQgbm90IGJlIGFmZmVjdGVkIGJ5IG9wZXJhdGlvbiBvbiBhbiBJUHY2LW9ubHkgbmV0d29yay4N Cj4gICBUaGVyZWZvcmUgdGhpcyBpcyBjb25zaWRlcmVkIG91dCBvZiBzY29wZSBmb3IgdGhpcyBk b2N1bWVudC4NCj4NCj4gICBHYXA6IE5vbmUuDQo+Ig0KPkkgYW0gbm90IHN1cmUgdGhlIGFib3Zl IHN0YXRlbWVudCBpcyBhY2N1cmF0ZSwgTVBMUy1UUCBjYW4gcnVuIHdpdGhvdXQNCj5JUCwgaXQg YWxzbyBjYW4gcnVuIHdpdGggSVAuIElNSE8sIHRoZXJlIHNob3VsZCBiZSBzb21lIGdhcHMgbmVl ZCB0bw0KPnNvbG92ZWQgaW4gY2FzZSBvZiBJUHY2LW9ubHkgbmV0d29yay4gQXMgSSBrbm93LCB0 aGVyZSBpcyBhdCBsZWFzdCBvbmUNCj5nYXAgbmVlZCB0byBiZSBtZW50aW9uZWQuDQo+UkZDNjM3 MCwgc2Vjb25kIHBhcmEgb2Ygc2VjdGlvbiA0ICBzdGF0ZXM6DQo+ICJUaGUgTm9kZV9JRCBpcyBh IHVuaXF1ZSAzMi1iaXQgdmFsdWUgYXNzaWduZWQgYnkgdGhlDQo+ICAgb3BlcmF0b3Igd2l0aGlu IHRoZSBzY29wZSBvZiBhIEdsb2JhbF9JRC4iDQo+DQo+QW5kIHRoZW4gc2VjdGlvbiA1LjMgTWFw cGluZyB0byBSU1ZQIFNpZ25hbGluZywgd2hlcmUNCj4NCj4gICAgICAqICBFeHRlbmRlZCBUdW5u ZWxfSUQgPSBBMS1Ob2RlX0lEDQo+ICAgICAgKiAgVHVubmVsIFNlbmRlciBBZGRyZXNzID0gQTEt Tm9kZV9JRA0KPkFuZCBpbiBSRkMzMjA5LCBzZWN0aW9uIDQuNi4xLjIuIExTUF9UVU5ORUxfSVB2 NiBTZXNzaW9uIE9iamVjdCBpcw0KPmRlZmluZWQuIFNvLCBpbiBJUHY2LW9ubHkgbmV0d29yaywg aXQgb2J2aW91c2x5IHRoYXQgRXh0ZW5kZWQgVHVubmVsX0lEDQo+YW5kIFR1bm5lbCBTZW5kZXIg QWRkcmVzcyBjYW5ub3QgYmUgbWFwcGVkIHRvIE5vZGVfSUQgYW55bW9yZS4NCg0KV0ddIFRoZXJl 4oCZcyBhIHJlbGF0ZWQgZGlzY3Vzc2lvbiBoYXBwZW5pbmcgaW4gSURSL3Y2b3BzIHJpZ2h0IG5v dw0KKGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9zZWFyY2gvP3E9QkdQK0lkZW50 aWZpZXImcWRyPXcmZl9saXN0PWlkDQpyJmdidD0xIHN0YXJ0aW5nIDE0IEZlYikgcmVzcG9uZGlu ZyB0byBhIHByb3Bvc2FsIHRvIG1ha2UgQkdQIFJvdXRlciBJRCBhDQoxMjggYml0IGZpZWxkIGJl Y2F1c2Ugb2YgdGhlIGxhY2sgb2YgZGlyZWN0IG1hcHBpbmcgYmV0d2VlbiB0aGUgMzIgYml0DQpm aWVsZCBhbmQgYSBwb3RlbnRpYWxseSAxMjggYml0IGFkZHJlc3Mgb24gYW4gSVB2Ni1vbmx5IGRl dmljZS4gU28gZmFyLA0KdGhlcmUgaGFzIGJlZW4gc2lnbmlmaWNhbnQgZmVlZGJhY2sgZnJvbSBv cGVyYXRvcnMgdGhhdCBpbiB0aGUgY2FzZSB3aGVyZQ0KdGhlc2UgYXJlIHNpbXBseSBmaWVsZHMg dGhhdCBjb250YWluIGFuIGFyYml0cmFyeSAzMiBiaXQgdmFsdWUgd2hvc2Ugb25seQ0KcmVxdWly ZW1lbnQgaXMgdGhhdCBpdCBpcyB1bmlxdWUgYWNyb3NzIHNvbWUgc2NvcGUsIHdlIG5lZWQgdG8g YmUgY2xlYXINCnRoYXQgdGhlIGxpbmsgYmV0d2VlbiB0aGF0IGZpZWxk4oCZcyB2YWx1ZSBhbmQg YW55IHBhcnRpY3VsYXIgSVB2NCBhZGRyZXNzDQppcyBtZXJlbHkgYnkgY29udmVudGlvbiwgbm90 IGJ5IHByb3RvY29sIG5lY2Vzc2l0eSwgYW5kIHRoZXJlZm9yZSB0aGUNCnNvbHV0aW9uIGluIGFu IElQdjYtb25seSBuZXR3b3JrIG1heSBzaW1wbHkgYmUgdG8gbm90ZSB0aGF0IGluIG9yZGVyIGZv cg0KdGhpcyB0byB3b3JrLCB0aGUgb3BlcmF0b3IgbXVzdCBoYXZlIGEgbWV0aG9kIHRvIGRlcml2 ZSBhIHVuaXF1ZSB2YWx1ZSwNCmVpdGhlciBtYW51YWxseS9wcm9ncmFtbWF0aWNhbGx5IGFzc2ln bmVkIGF0IHByb3Zpc2lvbmluZyB0aW1lLCBvciB2aWENCnNvbWUgc29ydCBvZiBtYXBwaW5nIGZy b20gYW4gSVB2NiBhZGRyZXNzIHByZXNlbnQgb24gdGhlIGJveC4gSeKAmW0gaW5jbGluZWQNCnRv IGhhbmRsZSB0aGlzIHBvdGVudGlhbCBnYXAgaW4gdGhlIHNhbWUgd2F5LCBzaW5jZSB0aGUgcHJv YmxlbSBhbmQNCmRpc2N1c3Npb24gaW4gSURSIGlzIGluIG5vIHdheSBzcGVjaWZpYyB0byBCR1As IGJ1dCBJIHRoaW5rIGl04oCZcyBzb21ldGhpbmcNCnRoYXQgd2UgbmVlZCB0byBkaXNjdXNzIGlu IHRoaXMgc3BlY2lmaWMgY29udGV4dCAtIEkuZS4gZG9lcyBpdCBicmVhaw0KYW55dGhpbmcgaWYg dGhlIHZhbHVlIGlzIGFyYml0cmFyeSBhbmQgbm90IGxpbmtlZCB0byBhbiBJUCBhZGRyZXNzIHBy ZXNlbnQNCm9uIHRoZSBkZXZpY2U/DQoNCg0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFz IGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29u dHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBp bmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0 IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWls IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBp biByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1t YWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55 IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Wed Feb 19 17:37: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 DB5A01A0423 for ; Wed, 19 Feb 2014 17:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_12=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 uGD48BidFY0o for ; Wed, 19 Feb 2014 17:37:32 -0800 (PST) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 07A3D1A00FA for ; Wed, 19 Feb 2014 17:37:31 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id um1so1189478pbc.19 for ; Wed, 19 Feb 2014 17:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=BRgqb7QfF8PFkMIV3GF0ZfwnTAa6r2daz6uEMtA2SBs=; b=VmvoM0wdZ/7hxi1X+GGYAna4WI1ze0JaqWTWIiEbA++xvkBh+5lJ0R4icSJcbWMT5a Qq1t3/1SVc/MJywcgBfs7UH/vgSivDFhnnCyER4ishmXukOT3OYDVTg0AVC9PxvdITjV Jxfw/fq5lXHiogZ2wMCl7pAk29PXXitk/y3g0J6UK7iPq3Zlb29taq+T/e2LIkCvFJRK UeWifUWWRd1r3IBM+4tpqM9L/8KZOC6++pC5gFVhkcnbAgwXMBJkMMiTUu+gK65qv1uo iM2y+PeWVT4WQ2G+eVtQ0KmWfeWBGhl5lREtDtSQ/39s7HahdcGUMnQ18VXVsTVNU/Ct 565g== X-Received: by 10.66.121.131 with SMTP id lk3mr5793846pab.61.1392860248761; Wed, 19 Feb 2014 17:37:28 -0800 (PST) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id sx8sm13200878pab.5.2014.02.19.17.37.16 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 19 Feb 2014 17:37:27 -0800 (PST) From: "Lizhong Jin" To: , Date: Thu, 20 Feb 2014 09:37:07 +0800 Message-ID: <008f01cf2ddc$4a3bc5c0$deb35140$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8tiyIKp3pM3XDDTuq9KvnX0UOLWg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/woSkgFJU9vzeJNqSRrBACYbmxt4 Cc: draft-ietf-mpls-special-purpose-labels@tools.ietf.org Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 20 Feb 2014 01:37:36 -0000 I am happy to see the change to "MUST". That will simplify the dataplane implementation. Regards Lizhong > > Message: 1 > Date: Tue, 18 Feb 2014 16:59:32 +0000 > From: Stewart Bryant > To: Alia Atlas > Cc: "mpls@ietf.org" , > "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" > > Subject: Re: [mpls] Mail regarding > draft-ietf-mpls-special-purpose-labels > Message-ID: <53039174.1040807@cisco.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Alia > > Maybe we are out of sync. > > I think that the text should say that L7 MUST be sent as a single label, and > MUST NOT be sent as a compound/extended label, and I think simplicity > alone is sufficient justification. > > Stewart > > On 18/02/2014 14:55, Alia Atlas wrote: > > Stewart, > > > > If you think that Loa's text is sufficiently strong about not sending > > XL, ESPL, then I am fine with his text. > > I was striving for more clarity on why the exception was made and > > suggesting MUST rather than SHOULD. > > > > Loa's text says: > > > > ""Label 7 (when received) retains its meaning as ELI whether a > >> > >> regular special purpose label or an ESPL; this is because of > >> backwards > >> compatibility with existing implemented and deployed code > >> and hardware > >> that looks for the ELI without verifying if the previous label > >> is XL or not. However, when an LSR insert an entropy label > >> it SHOULD > >> insert the ELI as a regular special purpose label, not as an > >> ESPL." > >> > > This doesn't explain that bad traffic side-effects could happen, but I > > think the wording for why the exception is there is clear. > > > > Alia > > > > > > On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant > > wrote: > > > > This has me worried. > > > > Assume that nothing implements ESPL yet, there is no reason why > > all SPL implementations are not required to send L7 only as > > a regular (single) SPL. As Loa says, this would be a useful > > simplification, and one which I raised earlier with the authors. > > > > If that is the case, a parser will always get it right. > > > > The only problem I see is if a compound label is ever created > > L15, Lx, <0..maxLabel> but one one has defined such an > > Lx and to do so would be unwise. > > > > So I don't think Alia is correct in her proposed text change and > > I have yet to see a valid technical reason for not accepting Loa's > > proposed change. > > > > - Stewart > > > > > > On 15/02/2014 17:09, Alia Atlas wrote: > >> [+ietf] > >> > >> Loa, > >> > >> To clarify a bit better, what I'm trying to get clarified into > >> the text is why the ELI value as an ESPL > >> needs to be an exception (as the draft indicates). I believe it > >> is because forbidding an ESPL of 7 > >> can break some existing and deployed versions of RFC 6790 such > >> that the transit traffic flows are affected. > >> There may also be implementations of RFC 6790 that aren't affected. > >> > >> Regards, > >> Alia > >> > >> > >> On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas >> > wrote: > >> > >> Loa, > >> > >> On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson >> > wrote: > >> > >> Alia, > >> > >> Two comments on this. > >> > >> First a nit "An LSR wishing to insert an ...", LSR are > >> boxes and can't > >> wish anything for themselves, a Simple change would be > >> "When an LSR > >> insert..." > >> > >> Actually the same is true for the current text and should > >> be changed the > >> same way. > >> > >> > >> [Alia] Sure - I took the original text and modified it. > >> > >> Second, and this is maybe more tricky - the reason given > >> "simplify the > >> data plane implementation" is not true and might even be > >> wrong. > >> The reason put always using the ELI as a "regular special > >> purpose label" > >> is backwards compatibility. > >> I would claim that the treatment of the ELI is an (well > >> motivated) > >> exception, but exceptions always mean that things get > >> more complicated. > >> > >> > >> [Alia] There were three purposes to my suggested text change. > >> First, to specify that > >> an LSR MUST NOT insert the ELI as an ESPL. Second, to say > >> that a receiving LSR > >> MAY choose to not discard a packet with the ELI as an ESPL. > >> Third, I wanted to see > >> a clearer justification for why this exception is worth making. > >> > >> [Alia] Since the whole draft is about a data-plane change, > >> what we've been putting in doesn't > >> really articulate the full problem. Prelim text would around > >> that would be better as: > >> > >> "ELI is an exception because each LSR examines the whole > >> label stack to see if the ELI > >> appears; pre-existing implementations of [Entropy-Label] do > >> this examination without verifying > >> that the label above the ELI is not XL. If a packet used an > >> ESPL of 7 and that did not mean > >> ELI, then when that packet transited deployed LSRs, which > >> implement [Entropy-Label] and not this document, > >> the meaning of the ESPL would be misinterpreted. Such a > >> misinterpretation could result in poor traffic behavior > >> (large flows, > >> reordered flows, etc.) depending on the label after the ESPL > >> of 7. It is to avoid such issues that ELI is defined as an > >> exception > >> that can appear as an regular special label or as an ESPL > >> with the same value of 7." > >> What do you think? > >> > >> Alia > >> > >> I don't want to propose a final text,but something along > >> these lines: > >> > >> > >> "Label 7 (when received) retains its meaning as ELI whether a > >> regular special purpose label or an ESPL; this is > >> because of backwards > >> compatibility with existing implemented and deployed > >> code and hardware > >> that looks for the ELI without verifying if the previous > >> label > >> is XL or not. However, when an LSR insert an entropy > >> label it SHOULD > >> insert the ELI as a regular special purpose label, not > >> as an ESPL." > >> > >> /Loa > >> > >> > >> On 2014-02-15 10:52, Alia Atlas wrote: > >> > >> Adrian and others, > >> > >> Having reviewed the 05 of this draft and this thread, > >> I have the > >> following suggestions. Other than these, I'm quite > >> happy with how this > >> draft has improved. > >> > >> a) In Sec 3.1, the following paragraph could be > >> updated from: > >> > >> "Label 7 (when received) retains its meaning as ELI > >> whether a > >> regular special purpose label or an ESPL; this > >> simplifies a transit > >> LSR's task of looking for entropy labels since it may > >> just look for > >> label 7 and need not verify that the previous label > >> in the stack is not > >> the XL 15. However, an LSR wishing to insert an > >> entropy label SHOULD > >> insert label 7 as a regular special purpose label, > >> not as an ESPL." > >> > >> > >> to: > >> > >> > >> "An LSR wishing to insert an entropy label MUST > >> insert label value 7 (meaning ELI) as a regular > >> special purpose > >> > >> label and not as an ESPL.Value 7 MUST NOT be sent as > >> an ESPL in the data plane. However, to simplify > >> > >> > >> the data plane implementation for Entropy Labels, an > >> implementation MAY > >> > >> interpret an ESPL of 7 as meaning ELI and, unlike for > >> values 0-6 and 8-15, an implementation > >> > >> MAY choose to not treat the packet as malformedand > >> thus discard it. The data plane simplification thus > >> enabled > >> > >> > >> is the ability to determine if any label value is 7 > >> without needing to verify that the previous label in > >> the stack is not the XL value of 15." > >> > >> > >> b)In Sec 3.2: "An RFC with at least Informational > >> status is required." How is this different from > >> IETF Review in RFC 5226? Do BCPs count? What is "at > >> least Informational status"? > >> > >> > >> > >> On the concern about Pervasive Monitoring, the only > >> advantage that (XL, > >> ESPL) offers is that the labels wouldn't (eventually) > >> be hashed for > >> load-balancing. Otherwise, the label stack offers > >> the ability for > >> meta-data already where only the receiver would need > >> to understand it. > >> Consistent paths are very useful, but there are > >> other ways of doing > >> this already - with the most trivial being just using > >> label 15. I have > >> a hard time seeing this as a new attack vector (but > >> I'm not > >> professionally paranoid yet). > >> > >> Alia > >> > >> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel > >> > >> >> >> wrote: > >> > >> [snip] > >> > >> > >> XL The Extension Label that indicates > >> that an extended special > >> > >> purpose label follows. > >> > >> > >> > >> ESPL An Extended Special Purpose Label. > >> > >> > >> > >> Something that I think would be worthwhile > >> clarifying right at the > >> > >> front is that a label is an ESPL IFF it is > >> preceded by an XL. > >> > >> It might even be worth noting that really > >> we have a new label > >> type: > >> > >> a label couple in which the first label > >> defines the type of the > >> > >> second label and neither are of any use as > >> individual labels. > >> > > I can see how you would see this as a new > >> label type. Maybe > >> "compound" > >> > > rather than "couple". > >> > > However, I am not convinced that it is new > >> that one label leads > >> to the > >> semantics > >> > > of the next (for example the entropy label). > >> > > What is more, I am not sure that there will > >> be more than this > >> instance of > >> this > >> > > type of tight coupling. > >> > > So I would rather leave this point out. > >> > I can foresee other cases where we might use > >> label pairs to > >> mitigate the > >> > 20bit limit. I am sure it has been discussed, > >> so creating the > >> reference > >> > might be useful. Just because this was not > >> done in EL, does not > >> mean that > >> > we should not set down the concept here. > >> > > >> > However I agree compound would be a better term. > >> > > >> > > > >> > > But as to clarifying ESPL: yes. > >> > > The XP definition is, I think, clear. > >> > > How about... > >> > > > >> > > ESPL An Extended Special Purpose Label. A > >> Special Purpose Label > >> that > >> > > is placed in the label stack after the > >> Extension Label. > >> > > >> > Yes. Indeed it MUST be placed be placed there, > >> however the definition > >> > above is fine. > >> > >> OK, I updated to... > >> > >> ESPL An Extended Special Purpose Label. A > >> Special Purpose Label that > >> is placed in the label stack after the > >> Extension Label. The > >> combination of XL and ESPL might be regarded as a > >> new form of > >> "compound label" comprising more than > >> one consecutive entry in > >> the label stack. > >> > >> ..to cover your other point as well. > >> > >> > >> ====== > >> > >> > >> > >> I think that the draft will need to provide > >> some guidance > >> > >> on when to allocate a 0..15 and when to > >> allocate an ESPL. > >> > >> > >> > >> I imagine that a 0..15 should only be used > >> when it can be shown > >> > >> that the extra stack space of forwarding > >> time is burdensome > >> > >> but that is a question that the WG should > >> explicitly consider. > >> > > We discussed this at some point on the MPLS > >> list (many > >> centuries ago, I > >> think) > >> > > and reached no conclusion. > >> > > The primary purpose of the XL is to handle > >> the time when 0..15 > >> is depleted. > >> > > You're right that we could encourage people > >> to start using > >> ESPLs now before > >> > > 0..15 is depleted. But it is hard to make > >> the case for > >> requiring it when > >> there > >> > > is still some of 0..15 available and the > >> rate of burn is not so > >> high. > >> > > > >> > > We could put in some text like... > >> > > > >> > > When allocating a new Special Purpose Label, > >> protocol designers > >> should > >> > > consider whether they could, instead, use an > >> Extended Special > >> Purpose > >> > > Label. Doing so would help to preserve the > >> scarce resources of > >> Special > >> > > Purpose Labels for use in cases where > >> minimizing the label > >> stack size is > >> > > particularly important. > >> > > >> > That would be useful text. > >> > >> Added as new section 3.1.2 with slight tweak to > >> wording. > >> > >> [snip] > >> > >> > >> 6. [RFC6790] says that special purpose > >> labels MUST NOT be > >> used for > >> > >> load balancing. The same logic applies > >> to extended special > >> > >> purpose labels (ESPLs). Thus, this > >> document specifies > >> that ESPLs > >> > >> MUST NOT be used for load balancing. It > >> is noted that > >> existing > >> > >> implementations may violate this, as > >> they do not look > >> for the XL > >> > >> and thus for ESPLs. The consequence is > >> that if ESPLs > >> are used in > >> > >> some packets of a flow, these packets > >> may be delivered on > >> > >> different paths and so could be > >> re-ordered. However, it is > >> > >> important to specify the correct > >> behavior for future > >> > >> implementations, hence the use of "MUST > >> NOT". > >> > >> > >> > >> I would suggest that most implementations > >> do violate this. I would > >> > >> also suggest that it seems unlikely that > >> you will get to the point > >> > >> where it is not violated in the foreseeable > >> future. > >> > > I can't tell whether there is an action here > >> for us. > >> > > There are two "violations" that exist: > >> > > 1. Some implementations violate 6790. Not > >> sure what we can do about > >> > > that in this document. Note that the entropy > >> label can help > >> with this > >> > > but only to a limited extent since the > >> implementations that > >> violate 6790 > >> > > probably also fail to recognise the entropy > >> label. > >> > > 2. Implementations that conform to 6790 will > >> understand that > >> the XL is > >> > > a special purpose label and will not use it > >> to load balance. > >> But they will > >> > > not necessarily understand that the next > >> label is an ESPL that > >> must be > >> > > skipped as well. Again, there is nothing we > >> can do about this > >> except to > >> > > note it (done) and possibly to use the EL > >> further up the stack. > >> > > >> > My point was that the may in "It is noted that > >> existing > >> implementations may > >> > violate this" was a little soft. Most > >> implementations, except the > >> latest > >> > designs of maybe as few as a single vendor, > >> would certainly > >> violate this. > >> > > >> > Also of course you are making a statement of > >> fact and not of > >> permission > >> > so I think it may be more precise to say: > >> > > >> > It is noted that most existing > >> > implementations currently violate this, as > >> they do not look for > >> the XL > >> > and thus for ESPLs. > >> > >> OK. > >> > >> I've gone with... > >> > >> It is noted that existing > >> implementations would violate this, as they do not > >> recognise XL > >> as anything other than a single Special > >> Purpose Label and will > >> not expect an ESPL to follow. > >> > >> [snip] > >> > >> > >> Label 7 (when received) retains its > >> meaning as ELI whether > >> a regular > >> > >> special purpose label or an ESPL; this > >> simplifies a transit > >> LSR's > >> > >> task of looking for entropy labels since > >> it may just look > >> for label 7 > >> > >> and need not verify that the previous > >> label in the stack is > >> not the > >> > >> XL 15. However, an LSR wishing to insert > >> an entropy label > >> SHOULD > >> > >> insert label 7 as a regular special > >> purpose label, not as > >> an ESPL. > >> > >> > >> > >> Why is this not a MUST! There is no ESPL in > >> the wild running an > >> > >> alternate behaviour, so why not simply > >> mandate this? > >> > > If this was a MUST then there would be no > >> case for handling > >> Label 7 after > >> XL. > >> > > There was some concern I believe that > >> implementations might > >> have a path that > >> > > puts them on to XL insertion processing and > >> then consider what > >> to do next. > >> At > >> > > that point they might decide that label 7 is > >> needed. > >> > > > >> > > It seems esoteric, but I couldn't see a > >> reason to prohibit it. > >> > > > >> > > Maybe "MUST NOT include" and "SHOULD process > >> when received" are > >> > > compatible. > >> > > > >> > > Part of me hates the idea of this change > >> just because I don't > >> want another > >> > > working group last call before we can move > >> forward. How > >> important is it? > >> > > >> > The reason to be stricter at the TX is that > >> the forwarding path > >> can be > >> > simpler at the RX. I cannot see how you would > >> get to the point of > >> putting > >> > in L15 and then saying "you know I need to put > >> in L7" > >> particularly as no > >> > other 0..15 is allowed. > >> > Normally I would think that you would put in > >> the compound label > >> as a pair > >> > and that is a good reason to use the compound > >> label concept. > >> > > >> > Also I see no reason for the inconsistency > >> between L7 and all of the > >> > other L0..L15 cases. > >> > > >> > So I think that it's OK, but probably silly to > >> allow L0..L15, but > >> to allow > >> > the exception of just L7 just complicates > >> things without good cause. > >> > >> I'm not in a position to argue on this one as the > >> debate and text > >> were driven by > >> others. > >> > >> I believe that the claim was that allowing L7 to > >> be inserted > >> anywhere made > >> processing it easier not harder at the receiver. > >> Note that {XL,7} would be an error case in your > >> way of looking at > >> things so the > >> receiver should (must?) not process it. > >> But the claim was that h/w will simply search the > >> stack for L7 so > >> that allowing > >> {L7} and {XL, L7} to be treated in the same way > >> made life easier for > >> the h/w. > >> > >> Bottom line, however, seems to be that you have a > >> preference for > >> doing it one > >> way, and the WG has a preference for doing it a > >> different way. How > >> to resolve > >> that? > >> > >> Given the posting deadline, I've not made any > >> change for this. We > >> can continue > >> to discuss. > >> > >> > >> ======== > >> > >> > >> > >> 3.2. Process for Retiring Special Purpose > >> Labels > >> > >> [snip] > >> > >> > >> Secondly I think the timescales are > >> ridiculously optimistic. > >> To get > >> > >> a label out of circulation in 24 months > >> seems most unlikely. Also > >> > >> 6 month checks is a lot of work. > >> > >> > >> > >> A more realistic schedule would be to poll > >> at 12month > >> intervals until > >> > >> such time as it is determined that > >> reallocation would do not > >> harm and > >> > >> then give a further 12 months notice. > >> > > Erm, that's what the text says, I think... > >> > > > >> > > 12 months after the RFC deprecating the > >> label value is > >> published, > >> > > an IETF-wide survey may be conducted to > >> determine if the > >> > > deprecated label value is still in use. > >> > > > >> > > The "may" in that means that the earliest > >> you can "poll" is 12 > >> months after > >> the > >> > > deprecation RFC is published (noting that > >> the RFC won't even > >> get published > >> > > until lots of discussion and consensus to > >> deprecate). > >> > > Then, *if* the poll response is OK, and then > >> not earlier than > >> 24 months > >> after > >> > > the deprecation RFC is published, > >> publication can be requested > >> for a new RFC > >> > > (which means that the WG has already reached > >> consensus, and that a > >> > > subsequent IETF last call will be held). > >> > > > >> > > Frankly, I think that this process is only > >> likely to be > >> executed for SPLs > >> that > >> > > are allocated "in error", because other > >> stuff will probably be > >> in the field. > >> Can > >> > > you think of a label that was allocated in > >> error? I can :-) > >> > > >> > This seems like a lot of text to specify in > >> detail something we > >> would never > >> > run. In protocols, including this type of > >> protocol, the fewer > >> words used to > >> > describe the rarely executed exception path > >> the better. > >> > >> The case was considered worthy of inclusion > >> because the SPL range is > >> so small. > >> If any SPL can be reclaimed at some future time > >> it will be very > >> valuable and so > >> a mechanism needs to be documented against that > >> happy day. > >> > >> [snip] > >> > >> =========== > >> [snip] > >> > >> However that brings me to > >> > >> suggest that you probably need to write an > >> OPs section and > >> > >> you might want to think about the PM > >> implications of the extra > >> > >> metatdata in the packets. > >> > > > >> > > What OPS issues had you in mind that need to > >> be addressed? I am > >> a fan of OPS > >> > > sections, but not a fan of empty OPS > >> sections, and when we > >> looked through > >> > > RFC 6123 (which is my favourite crib for > >> what to describe wrt > >> manageability) > >> we > >> > > didn't see anything that has changed from > >> pre-existing MPLS. > >> > > > >> > > What metadata are you talking about? Is an > >> existing special > >> purpose label > >> > > metadata? If so, the PM issues are > >> pre-existing. Is there > >> something special > >> > > introduced by this I-D that constitutes > >> metadata? > >> > > >> > Well what follows an XL is certainly metadata, > >> and one application is > >> > certainly to introduce tags that would alert > >> the PM devices to > >> take an > >> > interest. > >> > >> OK it is a form of metadata as existing SPLs are > >> metadata. > >> The XL alerts a DPI that an ESPL follows, and an > >> SPL alerts the DPI > >> that the SPL > >> is there. > >> What has changed? > >> We could certainly sit down and write an I-D > >> about the implications > >> of using > >> MPLS in an environment where PM might be present > >> (BTW, I assume this is > >> Pervasive Monitoring. Would be embarrassing to > >> find you meant > >> something else > >> :-). I think such an I-D would discuss SPLs as > >> indicative metadata > >> and would > >> then note that ESPLs are in the same category. > >> Is *this* the I-D in which to have that discussion? > >> > >> [snip] > >> > >> I'll post the revised I-D in a few minutes and > >> others can throw > >> vegetables > >> (rotten or otherwise). > >> > >> Adrian > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> > > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 > >> 64 > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/mpls/attachments/20140218/27ab9440/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > ------------------------------ > > End of mpls Digest, Vol 118, Issue 73 > ************************************* From nobody Wed Feb 19 17:54: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 C6C2A1A0423 for ; Wed, 19 Feb 2014 17:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Ba4gz70iM6Qd for ; Wed, 19 Feb 2014 17:54:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA361A00F5 for ; Wed, 19 Feb 2014 17:54:45 -0800 (PST) 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 BBH67897; Thu, 20 Feb 2014 01:54:41 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Feb 2014 01:54:24 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Feb 2014 01:54:38 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 09:54:32 +0800 From: Tao chou To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLd6y4O+P+ZldrEGE09kIqxSIMw== Date: Thu, 20 Feb 2014 01:54:31 +0000 Message-ID: <28BF96E93B752C4886970D1815EB8E352BA558D4@nkgeml507-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.81.31] Content-Type: multipart/alternative; boundary="_000_28BF96E93B752C4886970D1815EB8E352BA558D4nkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lLSyt8ylulVdaSjy1aJOrhb7V_U Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 20 Feb 2014 01:54:48 -0000 --_000_28BF96E93B752C4886970D1815EB8E352BA558D4nkgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KQmVzdCByZWdhcmRzLA0KVGFvDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9zcyBDYWxsb24NClNlbnQ6IE1vbmRheSwg RmVicnVhcnkgMTcsIDIwMTQgNDowOSBQTQ0KVG86IG1wbHNAaWV0Zi5vcmcNCkNjOiBtcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogW21wbHNdIFBvbGwgZm9yIEFkb3B0aW9uIGRy YWZ0LWNoZW4tbXBscy1wMm1wLWluZ3Jlc3MtcHJvdGVjdGlvbi0xMQ0KDQpUaGlzIGlzIHRvIHN0 YXJ0IGEgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1jaGVuLW1wbHMtcDJtcC1pbmdyZXNzLXByb3Rl Y3Rpb24tMTENCmFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4gU2luY2UgdGhpcyBj YWxsIHdpbGwgY29udGludWUgdGhyb3VnaCB0aGUNCklFVEYgbWVldGluZyBpbiBMb25kb24sIEkg d2lsbCBleHRlbnQgdGhlIHBvbGwgYnkgb25lIHdlZWsgKHNvIHRoYXQgaXQgd2lsbCBiZSBhDQp0 aHJlZSB3ZWVrIHBvbGwpLg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25v dCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwDQptYWlsaW5nIGxpc3QgKG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+KS4NCg0KVGhpcyBwb2xsIHdpbGwgZW5kIFR1 ZXNkYXkgTWFyY2ggMTEsIDIwMTQuIFRoaXMgaXMgb2YgY291cnNlIHRoZSBUdWVzZGF5IGFmdGVy DQp0aGUgSUVURi4NCg0KVGhhbmtzLCBSb3NzDQoNCg0K --_000_28BF96E93B752C4886970D1815EB8E352BA558D4nkgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

= Support.

Best regards,
Tao

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting draft-chen-mpls-p2mp-i= ngress-protection-11

as an MPLS working group document. Since this call will co= ntinue through the

IETF meeting in London, I will extent the poll by one week= (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).<= /p>

 

This poll will end Tuesday March 11, 2014. This is of cour= se the Tuesday after

the IETF.

 

Thanks, Ross

 

 

--_000_28BF96E93B752C4886970D1815EB8E352BA558D4nkgeml507mbschi_-- From nobody Wed Feb 19 18:03:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B271A062C for ; Wed, 19 Feb 2014 18:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1OOd04eIlOD for ; Wed, 19 Feb 2014 18:03:53 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-mba.ke.seacomnet.com [41.87.100.230]) by ietfa.amsl.com (Postfix) with ESMTP id EFFB01A0628 for ; Wed, 19 Feb 2014 18:03:51 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1WGIyu-0002k9-1J; Thu, 20 Feb 2014 04:03:20 +0200 From: Mark Tinka Organization: SEACOM To: "Nagendra Kumar Nainar (naikumar)" Date: Thu, 20 Feb 2014 04:03:13 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1541947.VTVb2HmCGN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201402200403.16417.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/s3ggz34p0tJ3DBSasYCFZmX2vsU Cc: "mpls@ietf.org" , "draft-george-mpls-ipv6-only-gap@tools.ietf.org" Subject: Re: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:03:55 -0000 --nextPart1541947.VTVb2HmCGN Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday, February 19, 2014 03:29:50 PM Nagendra Kumar=20 Nainar (naikumar) wrote: > Thanks. I also think any gap raises as part of > the same may not be related to this document. BGP I > sussed as overlay and the underlying path (or the PMSI > tunnel) can be GRE, IP or LSP. Any gap when LSP is used > as PMSI will be covered in section 3.3.2.4.2. Any gaps > when GRE or IP is used IMO is not within the scope of > this document. That's reasonable. In NG-MVPN, BGP is used both for PIM functionality=20 (Multicast routing) as well as signaling the PMSI tunnel=20 type (PMSI Tunnel BGP attribute), but this is already part=20 of today's implementations so there is no gap.=20 And also, as you mention, BGP is an overlay. All it needs to=20 do is signal the underlying carriage to the network (MPLS,=20 IP or GRE). Operationally, we just need to make sure that signaling of=20 the PMSI tunnel type works fine for both MCAST-VPNv6 as it=20 does for MCAST-VPNv4. Spec-wise, no reason it shouldn't. > When PIM is used as PE-PE protocol, it doesn't > impose any need or signal what would be the PMSI tunnel > to be used. It is more like a local matter and can be > LSP or GRE. So any gaps can be covered as part of the > respective protocol and I think is not related to this > document. Agree. Mark. --nextPart1541947.VTVb2HmCGN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJTBWJkAAoJEGcZuYTeKm+GyHMQALvVdaCCKLXSjUvCOpp36AAj lr7781YEj7qnmqsYVHiZoOrhyvY7P7loArCFWMbkL1g9tIXVhbWvamcjVcbKP00Z gTRnSAu29gy6bookMj5J3VjNLcHy+FbwiJLu0e34C1cKMXC6gNubEFauEKaXEPIu 2iLY+59mLSF0xmpyLgULNLqUmWV5XnC9WKch7fa4g+mr7op7aqcTfbiqyOhuPuig YV2BRn9nmR0S85hz00r2a91d0/kw8j767jx4yZwS3EoCLd2n3NrI2EsIl9m0H33g nZPv3o8gZE7rZ7hakBqc3Dbzzfuo4b4FTEYYLlK08Y9oMbz4zt7tM7CBh1h+azig xJtHDC/qLUL0lx9FtUip8vKtvq54BeiUw7B6A38K+gTIOBQKSj5TSuAQ3DiQMF83 XV8tBs0kTMXhvC5NmgD5kP/dNVU/uzePd3NdQOEKrnljIHIqPNZOJWPyricFupQm sMyozCJoGE3ar1V5VAWV0F7G+n3VMBCJsadgd+RPrvsxzVCVPkdH1cKMyUcXhd/e wU3hDO764v0Qh+x3m5mK3Ni6TY7ZYT9XNFBUhdUk6UQ6PaaXR7g5ouKdXeGSbH5S pc/qV8lV6vIs42dozO+qvFkgvlpadnva2ONHZCrK4hlDWexEwgh1E2CiWtL3i3TM baTkoGDvC5Y1Au14Um9M =W0fn -----END PGP SIGNATURE----- --nextPart1541947.VTVb2HmCGN-- From nobody Wed Feb 19 18:05: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 B2CDF1A0623 for ; Wed, 19 Feb 2014 18:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 ud-LenPncKHv for ; Wed, 19 Feb 2014 18:05:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 684DE1A0628 for ; Wed, 19 Feb 2014 18:05:37 -0800 (PST) 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 BDT60762; Thu, 20 Feb 2014 02:05:33 +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; Thu, 20 Feb 2014 02:05:18 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Feb 2014 02:05:32 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 10:05:25 +0800 From: Mach Chen To: "George, Wes" , "draft-george-mpls-ipv6-only-gap@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: draft-george-mpls-ipv6-only-gap-04.txt Thread-Index: AQHPKiTeeHr62ku65E2rFjwiQo1LM5q8IyqAgAA3vQCAAP9Y8A== Date: Thu, 20 Feb 2014 02:05:24 +0000 Message-ID: References: <52FF2006.7060900@pi.nu> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: 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/ubpB1CsnGHz3VzG_5KuUYGGifuI Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:05:42 -0000 SGkgR2VvcmdlLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdlb3Jn ZSwgV2VzIFttYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbV0NCj4gU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDIwLCAyMDE0IDE6NDcgQU0NCj4gVG86IE1hY2ggQ2hlbjsgZHJhZnQtZ2Vv cmdlLW1wbHMtaXB2Ni1vbmx5LWdhcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogZHJhZnQtZ2VvcmdlLW1wbHMtaXB2Ni1vbmx5LWdhcC0wNC50eHQNCj4gDQo+ IEFkZGluZyBNUExTIFdHLCBzb21lIHJlc3BvbnNlcyBiZWxvdywgYW5kIEnigJltIHN1cmUgbXkg Y28tYXV0aG9ycyB3aWxsIGNoaW1lDQo+IGluIGFzIHdlbGwuIFRoYW5rcyBmb3IgdGhlIHJldmll dyENCg0KWW91IGFyZSB3ZWxjb21lIQ0KDQo+IA0KPiBXZXMgR2VvcmdlDQo+IA0KPiANCj4gT24g Mi8xOS8xNCwgMjoyMyBBTSwgIk1hY2ggQ2hlbiIgPG1hY2guY2hlbkBodWF3ZWkuY29tPiB3cm90 ZToNCj4gDQo+ID5TcGVjaWZpYyBjb21tZW50czoNCj4gPg0KPiA+MS4gU2VjdGlvbiAzLjINCj4g Pg0KPiA+SUdQIHVzZWQgZm9yIGxhYmVsIG1hcHBpbmcgaXMgcHJvcG9zZWQgYnkgU2VnbWVudCBy b3V0aW5nLCB0aGVyZSBtYXkNCj4gPm5lZWQgYSBzdWIgc2VjdGlvbiBmb3IgdGhpcy4NCj4gDQo+ IFdHXSBJIGJlbGlldmUgd2XigJlsbCBuZWVkIHRvIG1ha2Ugc3VyZSB0aGUgZm9sa3MgaW4gU1BS SU5HIGFyZSBjb25zaWRlcmluZw0KPiBJUHY2LW9ubHkgb3BlcmF0aW9uIGFuZCBwdXQgYSBtb3Jl IGdlbmVyaWMgbm90ZSB0aGF0IGRyYWZ0IHRlY2hub2xvZ2llcyAobGlrZQ0KPiBFVlBOIGFuZCBT ZWdtZW50IFJvdXRpbmcpIGFyZSBub3QgaW4gc2NvcGUgZm9yIHRoZSBnYXAgYW5hbHlzaXMgKHNl ZSBteQ0KPiBwcmV2aW91cyBvbi1saXN0IHJlc3BvbnNlKQ0KDQpPSy4NCg0KPiA+DQo+ID4yLiBT ZWN0aW9uIDMuMi4zLjEuDQo+ID4NCj4gPjEpIFRvIGdpdmUgYSBjb21wcmVoZW5zaXZlIGludHJv ZHVjdGlvbiBvZiBURSBsaW5rIGFkdmVydGlzZW1lbnQsIGl0DQo+ID5tYXkgbmVlZCB0byBtZW50 aW9uIElHUCBleHRlbnNpb25zIGZvciBpbnRlci1BUyBURSBsaW5rIGFkdmVydGlzZW1lbnQNCj4g PihSRkM1MzE2IGFuZCBSRkM1MzkyKS4NCj4gPg0KPiA+MikuIEJHUC1MUyBtYXkgbmVlZCB0byBi ZSBtZW50aW9uZWQgc29tZXdoZXJlDQo+ID4NCj4gPjMuIFNlY3Rpb24gMy4zLjMuICBNUExTLVRQ DQo+ID4NCj4gPiIgIE1QTFMtVFAgZG9lcyBub3QgcmVxdWlyZSBJUCAoc2VlIHNlY3Rpb24gMiBv ZiBSRkMgNTkyMSBbUkZDNTkyMV0pIGFuZA0KPiA+ICAgc2hvdWxkIG5vdCBiZSBhZmZlY3RlZCBi eSBvcGVyYXRpb24gb24gYW4gSVB2Ni1vbmx5IG5ldHdvcmsuDQo+ID4gICBUaGVyZWZvcmUgdGhp cyBpcyBjb25zaWRlcmVkIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC4NCj4gPg0KPiA+ ICAgR2FwOiBOb25lLg0KPiA+Ig0KPiA+SSBhbSBub3Qgc3VyZSB0aGUgYWJvdmUgc3RhdGVtZW50 IGlzIGFjY3VyYXRlLCBNUExTLVRQIGNhbiBydW4gd2l0aG91dA0KPiA+SVAsIGl0IGFsc28gY2Fu IHJ1biB3aXRoIElQLiBJTUhPLCB0aGVyZSBzaG91bGQgYmUgc29tZSBnYXBzIG5lZWQgdG8NCj4g PnNvbG92ZWQgaW4gY2FzZSBvZiBJUHY2LW9ubHkgbmV0d29yay4gQXMgSSBrbm93LCB0aGVyZSBp cyBhdCBsZWFzdCBvbmUNCj4gPmdhcCBuZWVkIHRvIGJlIG1lbnRpb25lZC4NCj4gPlJGQzYzNzAs IHNlY29uZCBwYXJhIG9mIHNlY3Rpb24gNCAgc3RhdGVzOg0KPiA+ICJUaGUgTm9kZV9JRCBpcyBh IHVuaXF1ZSAzMi1iaXQgdmFsdWUgYXNzaWduZWQgYnkgdGhlDQo+ID4gICBvcGVyYXRvciB3aXRo aW4gdGhlIHNjb3BlIG9mIGEgR2xvYmFsX0lELiINCj4gPg0KPiA+QW5kIHRoZW4gc2VjdGlvbiA1 LjMgTWFwcGluZyB0byBSU1ZQIFNpZ25hbGluZywgd2hlcmUNCj4gPg0KPiA+ICAgICAgKiAgRXh0 ZW5kZWQgVHVubmVsX0lEID0gQTEtTm9kZV9JRA0KPiA+ICAgICAgKiAgVHVubmVsIFNlbmRlciBB ZGRyZXNzID0gQTEtTm9kZV9JRCBBbmQgaW4gUkZDMzIwOSwgc2VjdGlvbg0KPiA+NC42LjEuMi4g TFNQX1RVTk5FTF9JUHY2IFNlc3Npb24gT2JqZWN0IGlzIGRlZmluZWQuIFNvLCBpbiBJUHY2LW9u bHkNCj4gPm5ldHdvcmssIGl0IG9idmlvdXNseSB0aGF0IEV4dGVuZGVkIFR1bm5lbF9JRCBhbmQg VHVubmVsIFNlbmRlciBBZGRyZXNzDQo+ID5jYW5ub3QgYmUgbWFwcGVkIHRvIE5vZGVfSUQgYW55 bW9yZS4NCj4gDQo+IFdHXSBUaGVyZeKAmXMgYSByZWxhdGVkIGRpc2N1c3Npb24gaGFwcGVuaW5n IGluIElEUi92Nm9wcyByaWdodCBub3cNCj4gKGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9zZWFyY2gvP3E9QkdQK0lkZW50aWZpZXImcWRyPXcmZl9saXN0PWlkDQo+IHImZ2J0PTEg c3RhcnRpbmcgMTQgRmViKSByZXNwb25kaW5nIHRvIGEgcHJvcG9zYWwgdG8gbWFrZSBCR1AgUm91 dGVyIElEIGENCj4gMTI4IGJpdCBmaWVsZCBiZWNhdXNlIG9mIHRoZSBsYWNrIG9mIGRpcmVjdCBt YXBwaW5nIGJldHdlZW4gdGhlIDMyIGJpdCBmaWVsZCBhbmQgYQ0KPiBwb3RlbnRpYWxseSAxMjgg Yml0IGFkZHJlc3Mgb24gYW4gSVB2Ni1vbmx5IGRldmljZS4gU28gZmFyLCB0aGVyZSBoYXMgYmVl bg0KPiBzaWduaWZpY2FudCBmZWVkYmFjayBmcm9tIG9wZXJhdG9ycyB0aGF0IGluIHRoZSBjYXNl IHdoZXJlIHRoZXNlIGFyZSBzaW1wbHkgZmllbGRzDQo+IHRoYXQgY29udGFpbiBhbiBhcmJpdHJh cnkgMzIgYml0IHZhbHVlIHdob3NlIG9ubHkgcmVxdWlyZW1lbnQgaXMgdGhhdCBpdCBpcyB1bmlx dWUNCj4gYWNyb3NzIHNvbWUgc2NvcGUsIHdlIG5lZWQgdG8gYmUgY2xlYXIgdGhhdCB0aGUgbGlu ayBiZXR3ZWVuIHRoYXQgZmllbGTigJlzIHZhbHVlDQo+IGFuZCBhbnkgcGFydGljdWxhciBJUHY0 IGFkZHJlc3MgaXMgbWVyZWx5IGJ5IGNvbnZlbnRpb24sIG5vdCBieSBwcm90b2NvbCBuZWNlc3Np dHksDQo+IGFuZCB0aGVyZWZvcmUgdGhlIHNvbHV0aW9uIGluIGFuIElQdjYtb25seSBuZXR3b3Jr IG1heSBzaW1wbHkgYmUgdG8gbm90ZSB0aGF0IGluDQo+IG9yZGVyIGZvciB0aGlzIHRvIHdvcmss IHRoZSBvcGVyYXRvciBtdXN0IGhhdmUgYSBtZXRob2QgdG8gZGVyaXZlIGEgdW5pcXVlIHZhbHVl LA0KPiBlaXRoZXIgbWFudWFsbHkvcHJvZ3JhbW1hdGljYWxseSBhc3NpZ25lZCBhdCBwcm92aXNp b25pbmcgdGltZSwgb3IgdmlhIHNvbWUgc29ydA0KPiBvZiBtYXBwaW5nIGZyb20gYW4gSVB2NiBh ZGRyZXNzIHByZXNlbnQgb24gdGhlIGJveC4gSeKAmW0gaW5jbGluZWQgdG8gaGFuZGxlIHRoaXMN Cj4gcG90ZW50aWFsIGdhcCBpbiB0aGUgc2FtZSB3YXksIHNpbmNlIHRoZSBwcm9ibGVtIGFuZCBk aXNjdXNzaW9uIGluIElEUiBpcyBpbiBubw0KPiB3YXkgc3BlY2lmaWMgdG8gQkdQLCBidXQgSSB0 aGluayBpdOKAmXMgc29tZXRoaW5nIHRoYXQgd2UgbmVlZCB0byBkaXNjdXNzIGluIHRoaXMNCj4g c3BlY2lmaWMgY29udGV4dCAtIEkuZS4gZG9lcyBpdCBicmVhayBhbnl0aGluZyBpZiB0aGUgdmFs dWUgaXMgYXJiaXRyYXJ5IGFuZCBub3QgbGlua2VkDQo+IHRvIGFuIElQIGFkZHJlc3MgcHJlc2Vu dCBvbiB0aGUgZGV2aWNlPw0KDQpZZXMsIEkgbm90aWNlZCB0aGF0IGRpc2N1c3Npb24gYW5kIGFt IGZpbmUgd2l0aCB0aGUgMzItYml0IFJvdXRlciBJRC4gDQoNCkFzIGl0cyBjdXJyZW50IGRlZmlu aXRpb24sIHRoZSBOb2RlX0lEIGlzIGFscmVhZHkgYW4gYXJiaXRyYXJ5IDMyLWJpdCB2YWx1ZSB0 aGF0IGlzIHVuaXF1ZSB3aXRoaW4gdGhlIHNjb3BlIGl0IHVzZWQuIFRoZSBwcm9ibGVtIGhlcmUg aXMgdGhhdCBob3cgdG8gaWRlbnRpZnkgYW4gSVB2NiBMU1Agd2l0aCB0aGUgY3VycmVudCBNUExT LVRQIGlkZW50aWZpZXIgZGVmaW5pdGlvbi4NCg0KU2VjdGlvbiA1LjMuIG9mIFJGQzYzNzAsIDJu ZCBwYXJhZ3JhcGgsIGl0IHNheXM6IA0KICAgIkdNUExTIFs1XSBpcyBiYXNlZCBvbiBSU1ZQLVRF IFsyXS4gIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBtYXBwaW5nDQogICBmcm9tIGFuIE1QTFMt VFAgTFNQX0lEIHRvIFJTVlAtVEUuICBBdCB0aGlzIHRpbWUsIFJTVlAtVEUgaGFzIHlldCB0bw0K ICAgYmUgZXh0ZW5kZWQgdG8gYWNjb21tb2RhdGUgR2xvYmFsX0lEcy4gIFRodXMsIGEgbWFwcGlu ZyBpcyBvbmx5IG1hZGUNCiAgIGZvciB0aGUgbmV0d29yayB1bmlxdWUgZm9ybSBvZiB0aGUgTFNQ X0lEIGFuZCBhc3N1bWVzIHRoYXQgdGhlDQogICBvcGVyYXRvciBoYXMgY2hvc2VuIHRvIGRlcml2 ZSBpdHMgTm9kZV9JRHMgZnJvbSB2YWxpZCBJUHY0IGFkZHJlc3Nlcy4iDQoNCkluIGFuIElQdjYg b25seSBuZXR3b3JrLCB0aGVyZSBzaG91bGQgYmUgbm8gc3VjaCBhbiB2YWxpZCBJUHY0IGFkZHJl c3MsIHNvIHNvbWUgdXBkYXRlcyBtYXkgbmVlZCBoZXJlLiANCg0KSW4gYWRkaXRpb24sIExTUF9U VU5ORUxfSVB2NiBTZXNzaW9uIE9iamVjdCB1c2UgSVB2NiBhZGRyZXNzZXMrdHVubmVsIElEK0xT UCBJRCB0byBpZGVudGlmeSBhbiBMU1AsIGl0IG5lZWRzIHRvIGV2YWx1YXRlIHdoZXRoZXIgIjMy LWJpdCBOb2RlX0lEICsgVHVubmVsIElEICsgTFNQIElEIiBpcyBzdWZmaWNpZW50IHRvIGlkZW50 aWZ5IGFuIElQdjYgTFNQLiBTZWVtcyBpdCdzIGZpbmUsIGJ1dCB0aGUgbWFwcGluZyBkZWZpbml0 aW9uIG1heSBuZWVkIHNvbWUgY2hhbmdlcyBvciBjbGFyaWZpY2F0aW9uLiANCg0KQmVzdCByZWdh cmRzLA0KTWFjaA0KIA0KPiANCj4gDQo+IA0K From nobody Wed Feb 19 18:17: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 A66A41A0280 for ; Wed, 19 Feb 2014 18:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COUrueUSu61r for ; Wed, 19 Feb 2014 18:17:42 -0800 (PST) Received: from the-host.seacom.mu (ge-0.ln-01-mba.ke.seacomnet.com [41.87.100.230]) by ietfa.amsl.com (Postfix) with ESMTP id 93DFE1A02CE for ; Wed, 19 Feb 2014 18:17:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from ) id 1WGJCU-0002sA-51; Thu, 20 Feb 2014 04:17:22 +0200 From: Mark Tinka Organization: SEACOM To: mpls@ietf.org Date: Thu, 20 Feb 2014 04:17:14 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; ) References: <52FF2006.7060900@pi.nu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2295464.YXt9c5QD8s"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201402200417.18412.mark.tinka@seacom.mu> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yVeRx_98gaZt4cXHpE6qbWZdjlU Cc: "draft-george-mpls-ipv6-only-gap@tools.ietf.org" Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mark.tinka@seacom.mu List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:17:43 -0000 --nextPart2295464.YXt9c5QD8s Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wednesday, February 19, 2014 07:47:26 PM George, Wes=20 wrote: > WG] There=E2=80=99s a related discussion happening in IDR/v6ops > right now > (https://mailarchive.ietf.org/arch/search/?q=3DBGP+Identif > ier&qdr=3Dw&f_list=3Did r&gbt=3D1 starting 14 Feb) responding > to a proposal to make BGP Router ID a 128 bit field > because of the lack of direct mapping between the 32 bit > field and a potentially 128 bit address on an IPv6-only > device. So far, there has been significant feedback from > operators that in the case where these are simply fields > that contain an arbitrary 32 bit value whose only > requirement is that it is unique across some scope, we > need to be clear that the link between that field=E2=80=99s > value and any particular IPv4 address is merely by > convention, not by protocol necessity, and therefore the > solution in an IPv6-only network may simply be to note > that in order for this to work, the operator must have a > method to derive a unique value, either > manually/programmatically assigned at provisioning time, > or via some sort of mapping from an IPv6 address present > on the box. I=E2=80=99m inclined to handle this potential gap in > the same way, since the problem and discussion in IDR is > in no way specific to BGP, but I think it=E2=80=99s something > that we need to discuss in this specific context - I.e. > does it break anything if the value is arbitrary and not > linked to an IP address present on the device? As you point out, today, operators have considered Router- ID's (be they for BGP or other routing protocols enabled on=20 a router) as an arbitrary 32-bit integer that looks like an=20 IPv4 address, but really isn't treated as one. In IPv6-only networks, today's routers still require a 32- bit Router-ID, and general practice is to hard-code this=20 into deployments for BGP and other routing protocols=20 (especially for single stack IPv6 routers). In the future, when the majority of new ISP's will be IPv6=20 single stack, I don't foresee this practice stopping. There=20 is sufficient RFC 1918 space for operators to use in order=20 uniquely deploy Router-ID's across their backbone. Having said that, I could foresee issues where different=20 single stack IPv6 routing domains interconnect, and there is=20 the potential for Router-ID clashing if sourced from RFC=20 1918 space. This could have an impact on the BGP Route=20 Selection algorithm and/or setup and maintenance of BGP=20 sessions. In this case, having a 128-bit Router-ID might be=20 a sure-fire simple way to guarantee Router-ID uniqueness=20 across inter-domain routing.=20 The other option would be for both routing domains to pre- agree on Router-ID's that do not clash, but this adds=20 complexity to both intra- and inter-domain routing. Mark. --nextPart2295464.YXt9c5QD8s Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJTBWWuAAoJEGcZuYTeKm+GUBcP/RQVS/K2pdpg9gZnAvvqYHcW ZZaogBJM0eVMUZLl0I9N+Ouo29/9BqpzKjgkWIyXij9rNFnsyhEbc6L0y2hE5GX6 R/3zdWiukgrXF5K4m5IUJvOOwaMPzBfHR/6dgRxmJXFyL6VPrbIC1BcYmzWbzbsg vjhiWp21o3wQte9EAWOmzd22QII6oGo50nvfjmBzu+ANXFC9QQpgsA6R6696kNtD /gtNk3anuBBct2df4plHsPcuj1QPzT2w1hU0prr2Od8YExhHb/zSqNphebg7m7kF Jh81Egop04d2uKe8/uuejT6n3fJ1m3MzP5mEhanaPyhfGNO93h/ZWj2FLqnkUIUA Bylfl3qp081KBRnWKq6/Hajhun+ahg405o8FLU7wFiikoU7LC8rB8v47cURmH2OP /nnoddvcfb4NOjWARk2oPyu8DYFlAyaEcR1yfVbAP7/nLKZP3SmUoog9VB12E72U UAEcxgG6z/wOIPlCMXXc7dTLFPSFNDqdqtwZcE6OmD3+vz9orf96/PX41Vj+D287 vl3UETRbVzNBe27ThcviAxkidonsyWqTw2QaiBFZhzxKq0NNmtQ3QcFAgGJNUuIx Z1Ics+pNq1JWvsWEbj9mYObebyRnJH0QGKoewQQPYpQgLg07wsA3kfI675M8yyEm +mjQlKQnBNlaPty7EE4b =wjKp -----END PGP SIGNATURE----- --nextPart2295464.YXt9c5QD8s-- From nobody Thu Feb 20 01:49: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 412C61A0063 for ; Thu, 20 Feb 2014 01:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5f0ripX2J1s for ; Thu, 20 Feb 2014 01:49:36 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 60B6C1A0069 for ; Thu, 20 Feb 2014 01:49:35 -0800 (PST) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D9DAB180145E; Thu, 20 Feb 2014 10:49:30 +0100 (CET) Message-ID: <5305CFAA.9010304@pi.nu> Date: Thu, 20 Feb 2014 10:49:30 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Lizhong Jin , mpls@ietf.org, stbryant@cisco.com References: <008f01cf2ddc$4a3bc5c0$deb35140$@gmail.com> In-Reply-To: <008f01cf2ddc$4a3bc5c0$deb35140$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lkBq56G_GG7-k_0zHOT8-Gu2hQw Cc: draft-ietf-mpls-special-purpose-labels@tools.ietf.org Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 20 Feb 2014 09:49:42 -0000 Lizhong, Is this the text you want. "Label 7 (when received) retains its meaning as ELI whether a regular special purpose label or an ESPL; this is because of backwards compatibility with existing implemented and deployed code and hardware that looks for the ELI without verifying if the previous label is XL or not. However, when an LSR insert an entropy label it MUST insert the ELI as a regular special purpose label, not as an ESPL." I think that this is equivalent to say: "When an LSR insert an entropy label it MUST insert the ELI as a regular special purpose label, not as an ESPL." Then we should also say that "Labels 0-15 in the ESPL space are reserved, and shall not be allocated". The case where we have "the risk" of finding Label value 7, when it is not a regular special purpose label disappears. OK, great I can live with that. However we are now looping of the same territory for the n-th time, we have tried to do this before and met strong opposition. /Loa On 2014-02-20 02:37, Lizhong Jin wrote: > I am happy to see the change to "MUST". That will simplify the dataplane > implementation. > > Regards > Lizhong > >> >> Message: 1 >> Date: Tue, 18 Feb 2014 16:59:32 +0000 >> From: Stewart Bryant >> To: Alia Atlas >> Cc: "mpls@ietf.org" , >> "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" >> >> Subject: Re: [mpls] Mail regarding >> draft-ietf-mpls-special-purpose-labels >> Message-ID: <53039174.1040807@cisco.com> >> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" >> >> Alia >> >> Maybe we are out of sync. >> >> I think that the text should say that L7 MUST be sent as a single label, > and >> MUST NOT be sent as a compound/extended label, and I think simplicity >> alone is sufficient justification. >> >> Stewart >> >> On 18/02/2014 14:55, Alia Atlas wrote: >>> Stewart, >>> >>> If you think that Loa's text is sufficiently strong about not sending >>> XL, ESPL, then I am fine with his text. >>> I was striving for more clarity on why the exception was made and >>> suggesting MUST rather than SHOULD. >>> >>> Loa's text says: >>> >>> ""Label 7 (when received) retains its meaning as ELI whether a >>>> >>>> regular special purpose label or an ESPL; this is because of >>>> backwards >>>> compatibility with existing implemented and deployed code >>>> and hardware >>>> that looks for the ELI without verifying if the previous label >>>> is XL or not. However, when an LSR insert an entropy label >>>> it SHOULD >>>> insert the ELI as a regular special purpose label, not as an >>>> ESPL." >>>> >>> This doesn't explain that bad traffic side-effects could happen, but I >>> think the wording for why the exception is there is clear. >>> >>> Alia >>> >>> >>> On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant >> > wrote: >>> >>> This has me worried. >>> >>> Assume that nothing implements ESPL yet, there is no reason why >>> all SPL implementations are not required to send L7 only as >>> a regular (single) SPL. As Loa says, this would be a useful >>> simplification, and one which I raised earlier with the authors. >>> >>> If that is the case, a parser will always get it right. >>> >>> The only problem I see is if a compound label is ever created >>> L15, Lx, <0..maxLabel> but one one has defined such an >>> Lx and to do so would be unwise. >>> >>> So I don't think Alia is correct in her proposed text change and >>> I have yet to see a valid technical reason for not accepting Loa's >>> proposed change. >>> >>> - Stewart >>> >>> >>> On 15/02/2014 17:09, Alia Atlas wrote: >>>> [+ietf] >>>> >>>> Loa, >>>> >>>> To clarify a bit better, what I'm trying to get clarified into >>>> the text is why the ELI value as an ESPL >>>> needs to be an exception (as the draft indicates). I believe it >>>> is because forbidding an ESPL of 7 >>>> can break some existing and deployed versions of RFC 6790 such >>>> that the transit traffic flows are affected. >>>> There may also be implementations of RFC 6790 that aren't affected. >>>> >>>> Regards, >>>> Alia >>>> >>>> >>>> On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas >>> > wrote: >>>> >>>> Loa, >>>> >>>> On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson >>> > wrote: >>>> >>>> Alia, >>>> >>>> Two comments on this. >>>> >>>> First a nit "An LSR wishing to insert an ...", LSR are >>>> boxes and can't >>>> wish anything for themselves, a Simple change would be >>>> "When an LSR >>>> insert..." >>>> >>>> Actually the same is true for the current text and should >>>> be changed the >>>> same way. >>>> >>>> >>>> [Alia] Sure - I took the original text and modified it. >>>> >>>> Second, and this is maybe more tricky - the reason given >>>> "simplify the >>>> data plane implementation" is not true and might even be >>>> wrong. >>>> The reason put always using the ELI as a "regular special >>>> purpose label" >>>> is backwards compatibility. >>>> I would claim that the treatment of the ELI is an (well >>>> motivated) >>>> exception, but exceptions always mean that things get >>>> more complicated. >>>> >>>> >>>> [Alia] There were three purposes to my suggested text change. >>>> First, to specify that >>>> an LSR MUST NOT insert the ELI as an ESPL. Second, to say >>>> that a receiving LSR >>>> MAY choose to not discard a packet with the ELI as an ESPL. >>>> Third, I wanted to see >>>> a clearer justification for why this exception is worth making. >>>> >>>> [Alia] Since the whole draft is about a data-plane change, >>>> what we've been putting in doesn't >>>> really articulate the full problem. Prelim text would around >>>> that would be better as: >>>> >>>> "ELI is an exception because each LSR examines the whole >>>> label stack to see if the ELI >>>> appears; pre-existing implementations of [Entropy-Label] do >>>> this examination without verifying >>>> that the label above the ELI is not XL. If a packet used an >>>> ESPL of 7 and that did not mean >>>> ELI, then when that packet transited deployed LSRs, which >>>> implement [Entropy-Label] and not this document, >>>> the meaning of the ESPL would be misinterpreted. Such a >>>> misinterpretation could result in poor traffic behavior >>>> (large flows, >>>> reordered flows, etc.) depending on the label after the ESPL >>>> of 7. It is to avoid such issues that ELI is defined as an >>>> exception >>>> that can appear as an regular special label or as an ESPL >>>> with the same value of 7." >>>> What do you think? >>>> >>>> Alia >>>> >>>> I don't want to propose a final text,but something along >>>> these lines: >>>> >>>> >>>> "Label 7 (when received) retains its meaning as ELI whether > a >>>> regular special purpose label or an ESPL; this is >>>> because of backwards >>>> compatibility with existing implemented and deployed >>>> code and hardware >>>> that looks for the ELI without verifying if the previous >>>> label >>>> is XL or not. However, when an LSR insert an entropy >>>> label it SHOULD >>>> insert the ELI as a regular special purpose label, not >>>> as an ESPL." >>>> >>>> /Loa >>>> >>>> >>>> On 2014-02-15 10:52, Alia Atlas wrote: >>>> >>>> Adrian and others, >>>> >>>> Having reviewed the 05 of this draft and this thread, >>>> I have the >>>> following suggestions. Other than these, I'm quite >>>> happy with how this >>>> draft has improved. >>>> >>>> a) In Sec 3.1, the following paragraph could be >>>> updated from: >>>> >>>> "Label 7 (when received) retains its meaning as ELI >>>> whether a >>>> regular special purpose label or an ESPL; this >>>> simplifies a transit >>>> LSR's task of looking for entropy labels since it may >>>> just look for >>>> label 7 and need not verify that the previous label >>>> in the stack is not >>>> the XL 15. However, an LSR wishing to insert an >>>> entropy label SHOULD >>>> insert label 7 as a regular special purpose label, >>>> not as an ESPL." >>>> >>>> >>>> to: >>>> >>>> >>>> "An LSR wishing to insert an entropy label MUST >>>> insert label value 7 (meaning ELI) as a regular >>>> special purpose >>>> >>>> label and not as an ESPL.Value 7 MUST NOT be sent as >>>> an ESPL in the data plane. However, to simplify >>>> >>>> >>>> the data plane implementation for Entropy Labels, an >>>> implementation MAY >>>> >>>> interpret an ESPL of 7 as meaning ELI and, unlike for >>>> values 0-6 and 8-15, an implementation >>>> >>>> MAY choose to not treat the packet as malformedand >>>> thus discard it. The data plane simplification thus >>>> enabled >>>> >>>> >>>> is the ability to determine if any label value is 7 >>>> without needing to verify that the previous label in >>>> the stack is not the XL value of 15." >>>> >>>> >>>> b)In Sec 3.2: "An RFC with at least Informational >>>> status is required." How is this different from >>>> IETF Review in RFC 5226? Do BCPs count? What is "at >>>> least Informational status"? >>>> >>>> >>>> >>>> On the concern about Pervasive Monitoring, the only >>>> advantage that (XL, >>>> ESPL) offers is that the labels wouldn't (eventually) >>>> be hashed for >>>> load-balancing. Otherwise, the label stack offers >>>> the ability for >>>> meta-data already where only the receiver would need >>>> to understand it. >>>> Consistent paths are very useful, but there are >>>> other ways of doing >>>> this already - with the most trivial being just using >>>> label 15. I have >>>> a hard time seeing this as a new attack vector (but >>>> I'm not >>>> professionally paranoid yet). >>>> >>>> Alia >>>> >>>> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel >>>> >>>> >>> >> wrote: >>>> >>>> [snip] >>>> >>>> > >> XL The Extension Label that indicates >>>> that an extended special >>>> > >> purpose label follows. >>>> > >> >>>> > >> ESPL An Extended Special Purpose Label. >>>> > >> >>>> > >> Something that I think would be worthwhile >>>> clarifying right at the >>>> > >> front is that a label is an ESPL IFF it is >>>> preceded by an XL. >>>> > >> It might even be worth noting that really >>>> we have a new label >>>> type: >>>> > >> a label couple in which the first label >>>> defines the type of the >>>> > >> second label and neither are of any use as >>>> individual labels. >>>> > > I can see how you would see this as a new >>>> label type. Maybe >>>> "compound" >>>> > > rather than "couple". >>>> > > However, I am not convinced that it is new >>>> that one label leads >>>> to the >>>> semantics >>>> > > of the next (for example the entropy label). >>>> > > What is more, I am not sure that there will >>>> be more than this >>>> instance of >>>> this >>>> > > type of tight coupling. >>>> > > So I would rather leave this point out. >>>> > I can foresee other cases where we might use >>>> label pairs to >>>> mitigate the >>>> > 20bit limit. I am sure it has been discussed, >>>> so creating the >>>> reference >>>> > might be useful. Just because this was not >>>> done in EL, does not >>>> mean that >>>> > we should not set down the concept here. >>>> > >>>> > However I agree compound would be a better term. >>>> > >>>> > > >>>> > > But as to clarifying ESPL: yes. >>>> > > The XP definition is, I think, clear. >>>> > > How about... >>>> > > >>>> > > ESPL An Extended Special Purpose Label. A >>>> Special Purpose Label >>>> that >>>> > > is placed in the label stack after the >>>> Extension Label. >>>> > >>>> > Yes. Indeed it MUST be placed be placed there, >>>> however the definition >>>> > above is fine. >>>> >>>> OK, I updated to... >>>> >>>> ESPL An Extended Special Purpose Label. A >>>> Special Purpose Label that >>>> is placed in the label stack after the >>>> Extension Label. The >>>> combination of XL and ESPL might be regarded as a >>>> new form of >>>> "compound label" comprising more than >>>> one consecutive entry in >>>> the label stack. >>>> >>>> ..to cover your other point as well. >>>> >>>> > >> ====== >>>> > >> >>>> > >> I think that the draft will need to provide >>>> some guidance >>>> > >> on when to allocate a 0..15 and when to >>>> allocate an ESPL. >>>> > >> >>>> > >> I imagine that a 0..15 should only be used >>>> when it can be shown >>>> > >> that the extra stack space of forwarding >>>> time is burdensome >>>> > >> but that is a question that the WG should >>>> explicitly consider. >>>> > > We discussed this at some point on the MPLS >>>> list (many >>>> centuries ago, I >>>> think) >>>> > > and reached no conclusion. >>>> > > The primary purpose of the XL is to handle >>>> the time when 0..15 >>>> is depleted. >>>> > > You're right that we could encourage people >>>> to start using >>>> ESPLs now before >>>> > > 0..15 is depleted. But it is hard to make >>>> the case for >>>> requiring it when >>>> there >>>> > > is still some of 0..15 available and the >>>> rate of burn is not so >>>> high. >>>> > > >>>> > > We could put in some text like... >>>> > > >>>> > > When allocating a new Special Purpose Label, >>>> protocol designers >>>> should >>>> > > consider whether they could, instead, use an >>>> Extended Special >>>> Purpose >>>> > > Label. Doing so would help to preserve the >>>> scarce resources of >>>> Special >>>> > > Purpose Labels for use in cases where >>>> minimizing the label >>>> stack size is >>>> > > particularly important. >>>> > >>>> > That would be useful text. >>>> >>>> Added as new section 3.1.2 with slight tweak to >>>> wording. >>>> >>>> [snip] >>>> >>>> > >> 6. [RFC6790] says that special purpose >>>> labels MUST NOT be >>>> used for >>>> > >> load balancing. The same logic applies >>>> to extended special >>>> > >> purpose labels (ESPLs). Thus, this >>>> document specifies >>>> that ESPLs >>>> > >> MUST NOT be used for load balancing. It >>>> is noted that >>>> existing >>>> > >> implementations may violate this, as >>>> they do not look >>>> for the XL >>>> > >> and thus for ESPLs. The consequence is >>>> that if ESPLs >>>> are used in >>>> > >> some packets of a flow, these packets >>>> may be delivered on >>>> > >> different paths and so could be >>>> re-ordered. However, it is >>>> > >> important to specify the correct >>>> behavior for future >>>> > >> implementations, hence the use of "MUST >>>> NOT". >>>> > >> >>>> > >> I would suggest that most implementations >>>> do violate this. I would >>>> > >> also suggest that it seems unlikely that >>>> you will get to the point >>>> > >> where it is not violated in the foreseeable >>>> future. >>>> > > I can't tell whether there is an action here >>>> for us. >>>> > > There are two "violations" that exist: >>>> > > 1. Some implementations violate 6790. Not >>>> sure what we can do about >>>> > > that in this document. Note that the entropy >>>> label can help >>>> with this >>>> > > but only to a limited extent since the >>>> implementations that >>>> violate 6790 >>>> > > probably also fail to recognise the entropy >>>> label. >>>> > > 2. Implementations that conform to 6790 will >>>> understand that >>>> the XL is >>>> > > a special purpose label and will not use it >>>> to load balance. >>>> But they will >>>> > > not necessarily understand that the next >>>> label is an ESPL that >>>> must be >>>> > > skipped as well. Again, there is nothing we >>>> can do about this >>>> except to >>>> > > note it (done) and possibly to use the EL >>>> further up the stack. >>>> > >>>> > My point was that the may in "It is noted that >>>> existing >>>> implementations may >>>> > violate this" was a little soft. Most >>>> implementations, except the >>>> latest >>>> > designs of maybe as few as a single vendor, >>>> would certainly >>>> violate this. >>>> > >>>> > Also of course you are making a statement of >>>> fact and not of >>>> permission >>>> > so I think it may be more precise to say: >>>> > >>>> > It is noted that most existing >>>> > implementations currently violate this, as >>>> they do not look for >>>> the XL >>>> > and thus for ESPLs. >>>> >>>> OK. >>>> >>>> I've gone with... >>>> >>>> It is noted that existing >>>> implementations would violate this, as they do not >>>> recognise XL >>>> as anything other than a single Special >>>> Purpose Label and will >>>> not expect an ESPL to follow. >>>> >>>> [snip] >>>> >>>> > >> Label 7 (when received) retains its >>>> meaning as ELI whether >>>> a regular >>>> > >> special purpose label or an ESPL; this >>>> simplifies a transit >>>> LSR's >>>> > >> task of looking for entropy labels since >>>> it may just look >>>> for label 7 >>>> > >> and need not verify that the previous >>>> label in the stack is >>>> not the >>>> > >> XL 15. However, an LSR wishing to insert >>>> an entropy label >>>> SHOULD >>>> > >> insert label 7 as a regular special >>>> purpose label, not as >>>> an ESPL. >>>> > >> >>>> > >> Why is this not a MUST! There is no ESPL in >>>> the wild running an >>>> > >> alternate behaviour, so why not simply >>>> mandate this? >>>> > > If this was a MUST then there would be no >>>> case for handling >>>> Label 7 after >>>> XL. >>>> > > There was some concern I believe that >>>> implementations might >>>> have a path that >>>> > > puts them on to XL insertion processing and >>>> then consider what >>>> to do next. >>>> At >>>> > > that point they might decide that label 7 is >>>> needed. >>>> > > >>>> > > It seems esoteric, but I couldn't see a >>>> reason to prohibit it. >>>> > > >>>> > > Maybe "MUST NOT include" and "SHOULD process >>>> when received" are >>>> > > compatible. >>>> > > >>>> > > Part of me hates the idea of this change >>>> just because I don't >>>> want another >>>> > > working group last call before we can move >>>> forward. How >>>> important is it? >>>> > >>>> > The reason to be stricter at the TX is that >>>> the forwarding path >>>> can be >>>> > simpler at the RX. I cannot see how you would >>>> get to the point of >>>> putting >>>> > in L15 and then saying "you know I need to put >>>> in L7" >>>> particularly as no >>>> > other 0..15 is allowed. >>>> > Normally I would think that you would put in >>>> the compound label >>>> as a pair >>>> > and that is a good reason to use the compound >>>> label concept. >>>> > >>>> > Also I see no reason for the inconsistency >>>> between L7 and all of the >>>> > other L0..L15 cases. >>>> > >>>> > So I think that it's OK, but probably silly to >>>> allow L0..L15, but >>>> to allow >>>> > the exception of just L7 just complicates >>>> things without good cause. >>>> >>>> I'm not in a position to argue on this one as the >>>> debate and text >>>> were driven by >>>> others. >>>> >>>> I believe that the claim was that allowing L7 to >>>> be inserted >>>> anywhere made >>>> processing it easier not harder at the receiver. >>>> Note that {XL,7} would be an error case in your >>>> way of looking at >>>> things so the >>>> receiver should (must?) not process it. >>>> But the claim was that h/w will simply search the >>>> stack for L7 so >>>> that allowing >>>> {L7} and {XL, L7} to be treated in the same way >>>> made life easier for >>>> the h/w. >>>> >>>> Bottom line, however, seems to be that you have a >>>> preference for >>>> doing it one >>>> way, and the WG has a preference for doing it a >>>> different way. How >>>> to resolve >>>> that? >>>> >>>> Given the posting deadline, I've not made any >>>> change for this. We >>>> can continue >>>> to discuss. >>>> >>>> > >> ======== >>>> > >> >>>> > >> 3.2. Process for Retiring Special Purpose >>>> Labels >>>> >>>> [snip] >>>> >>>> > >> Secondly I think the timescales are >>>> ridiculously optimistic. >>>> To get >>>> > >> a label out of circulation in 24 months >>>> seems most unlikely. Also >>>> > >> 6 month checks is a lot of work. >>>> > >> >>>> > >> A more realistic schedule would be to poll >>>> at 12month >>>> intervals until >>>> > >> such time as it is determined that >>>> reallocation would do not >>>> harm and >>>> > >> then give a further 12 months notice. >>>> > > Erm, that's what the text says, I think... >>>> > > >>>> > > 12 months after the RFC deprecating the >>>> label value is >>>> published, >>>> > > an IETF-wide survey may be conducted to >>>> determine if the >>>> > > deprecated label value is still in use. >>>> > > >>>> > > The "may" in that means that the earliest >>>> you can "poll" is 12 >>>> months after >>>> the >>>> > > deprecation RFC is published (noting that >>>> the RFC won't even >>>> get published >>>> > > until lots of discussion and consensus to >>>> deprecate). >>>> > > Then, *if* the poll response is OK, and then >>>> not earlier than >>>> 24 months >>>> after >>>> > > the deprecation RFC is published, >>>> publication can be requested >>>> for a new RFC >>>> > > (which means that the WG has already reached >>>> consensus, and that a >>>> > > subsequent IETF last call will be held). >>>> > > >>>> > > Frankly, I think that this process is only >>>> likely to be >>>> executed for SPLs >>>> that >>>> > > are allocated "in error", because other >>>> stuff will probably be >>>> in the field. >>>> Can >>>> > > you think of a label that was allocated in >>>> error? I can :-) >>>> > >>>> > This seems like a lot of text to specify in >>>> detail something we >>>> would never >>>> > run. In protocols, including this type of >>>> protocol, the fewer >>>> words used to >>>> > describe the rarely executed exception path >>>> the better. >>>> >>>> The case was considered worthy of inclusion >>>> because the SPL range is >>>> so small. >>>> If any SPL can be reclaimed at some future time >>>> it will be very >>>> valuable and so >>>> a mechanism needs to be documented against that >>>> happy day. >>>> >>>> [snip] >>>> > >> =========== >>>> [snip] >>>> > >> However that brings me to >>>> > >> suggest that you probably need to write an >>>> OPs section and >>>> > >> you might want to think about the PM >>>> implications of the extra >>>> > >> metatdata in the packets. >>>> > > >>>> > > What OPS issues had you in mind that need to >>>> be addressed? I am >>>> a fan of OPS >>>> > > sections, but not a fan of empty OPS >>>> sections, and when we >>>> looked through >>>> > > RFC 6123 (which is my favourite crib for >>>> what to describe wrt >>>> manageability) >>>> we >>>> > > didn't see anything that has changed from >>>> pre-existing MPLS. >>>> > > >>>> > > What metadata are you talking about? Is an >>>> existing special >>>> purpose label >>>> > > metadata? If so, the PM issues are >>>> pre-existing. Is there >>>> something special >>>> > > introduced by this I-D that constitutes >>>> metadata? >>>> > >>>> > Well what follows an XL is certainly metadata, >>>> and one application is >>>> > certainly to introduce tags that would alert >>>> the PM devices to >>>> take an >>>> > interest. >>>> >>>> OK it is a form of metadata as existing SPLs are >>>> metadata. >>>> The XL alerts a DPI that an ESPL follows, and an >>>> SPL alerts the DPI >>>> that the SPL >>>> is there. >>>> What has changed? >>>> We could certainly sit down and write an I-D >>>> about the implications >>>> of using >>>> MPLS in an environment where PM might be present >>>> (BTW, I assume this is >>>> Pervasive Monitoring. Would be embarrassing to >>>> find you meant >>>> something else >>>> :-). I think such an I-D would discuss SPLs as >>>> indicative metadata >>>> and would >>>> then note that ESPLs are in the same category. >>>> Is *this* the I-D in which to have that discussion? >>>> >>>> [snip] >>>> >>>> I'll post the revised I-D in a few minutes and >>>> others can throw >>>> vegetables >>>> (rotten or otherwise). >>>> >>>> Adrian >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> > >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 >>>> 64 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > archive/web/mpls/attachments/20140218/27ab9440/attachment.html> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> ------------------------------ >> >> End of mpls Digest, Vol 118, Issue 73 >> ************************************* > > _______________________________________________ > 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 Thu Feb 20 02:16: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 201621A0072 for ; Thu, 20 Feb 2014 02:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 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, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, 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 xDP9QWQTLl9E for ; Thu, 20 Feb 2014 02:16:44 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 43FA61A007D for ; Thu, 20 Feb 2014 02:16:43 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so1721704pbc.27 for ; Thu, 20 Feb 2014 02:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=cVyslrvD7M2MxWqo7iUwRoQWVcoAQCLMAzvK7Rju2Uo=; b=mOdOCLz1sE0l0EMSGqejnJ/F+CTgGUCkktCKAi41rT/fv8qtYib+5XfYWgdvGswCVJ E8pnqVBwgDJg/z3tXsK+YunHpkGV6EWCJf3K7bxmQlmNd6UCJ6CEJtxsFRBvW4q3gdhi Pz4/eqOldeoj4QojzedQEBkr1ZAVea0/BolCkfqqEJi7WumKjUVqn4rq9Bh36HOh5pN9 YGxDnkzhRhE05x7iWmM+9p2Qi7tcoAKVA5olDdZxTJfQlLIzW/xBuKz+Vx3i4xG7PMNh 3fsBVtTV+eBLNf33RLEMeTie+oBkpWGkYLk/3uVdoJfzmLKyqZTGCOGq9e920QaLNb69 QbEw== X-Received: by 10.68.231.169 with SMTP id th9mr955014pbc.113.1392891399487; Thu, 20 Feb 2014 02:16:39 -0800 (PST) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id yz5sm22160486pac.9.2014.02.20.02.16.34 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Feb 2014 02:16:38 -0800 (PST) From: "Lizhong Jin" To: "'Loa Andersson'" , , References: <008f01cf2ddc$4a3bc5c0$deb35140$@gmail.com> <5305CFAA.9010304@pi.nu> In-Reply-To: <5305CFAA.9010304@pi.nu> Date: Thu, 20 Feb 2014 18:16:30 +0800 Message-ID: <00da01cf2e24$d64721c0$82d56540$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFQ1VCycwplCgIvb5zEeosotW6jRQIsYukYm6k6p6A= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FOqDXNrut6c5Vioow4yYEQGM5fY Cc: draft-ietf-mpls-special-purpose-labels@tools.ietf.org Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 20 Feb 2014 10:16:49 -0000 Hi Loa, The new text is OK for me. The discussion this time is great, and = finally we get new agreement. Lizhong > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 2014=C4=EA2=D4=C220=C8=D5 17:50 > To: Lizhong Jin; mpls@ietf.org; stbryant@cisco.com > Cc: draft-ietf-mpls-special-purpose-labels@tools.ietf.org > Subject: Re: [mpls] Mail regarding = draft-ietf-mpls-special-purpose-labels >=20 > Lizhong, >=20 > Is this the text you want. >=20 > "Label 7 (when received) retains its meaning as ELI whether a > regular special purpose label or an ESPL; this is because of > backwards compatibility with existing implemented and deployed code > and hardware that looks for the ELI without verifying if the = previous > label is XL or not. However, when an LSR insert an entropy label > it MUST insert the ELI as a regular special purpose label, not as > an ESPL." >=20 > I think that this is equivalent to say: >=20 > "When an LSR insert an entropy label it MUST insert the ELI as a > regular special purpose label, not as an ESPL." >=20 > Then we should also say that "Labels 0-15 in the ESPL space are = reserved, and > shall not be allocated". >=20 > The case where we have "the risk" of finding Label value 7, when it is = not a > regular special purpose label disappears. >=20 > OK, great I can live with that. >=20 > However we are now looping of the same territory for the n-th time, we > have tried to do this before and met strong opposition. >=20 > /Loa >=20 >=20 >=20 > On 2014-02-20 02:37, Lizhong Jin wrote: > > I am happy to see the change to "MUST". That will simplify the > > dataplane implementation. > > > > Regards > > Lizhong > > > >> > >> Message: 1 > >> Date: Tue, 18 Feb 2014 16:59:32 +0000 > >> From: Stewart Bryant > >> To: Alia Atlas > >> Cc: "mpls@ietf.org" , > >> "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" > >> > >> Subject: Re: [mpls] Mail regarding > >> draft-ietf-mpls-special-purpose-labels > >> Message-ID: <53039174.1040807@cisco.com> > >> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed" > >> > >> Alia > >> > >> Maybe we are out of sync. > >> > >> I think that the text should say that L7 MUST be sent as a single > >> label, > > and > >> MUST NOT be sent as a compound/extended label, and I think = simplicity > >> alone is sufficient justification. > >> > >> Stewart > >> > >> On 18/02/2014 14:55, Alia Atlas wrote: > >>> Stewart, > >>> > >>> If you think that Loa's text is sufficiently strong about not > >>> sending XL, ESPL, then I am fine with his text. > >>> I was striving for more clarity on why the exception was made and > >>> suggesting MUST rather than SHOULD. > >>> > >>> Loa's text says: > >>> > >>> ""Label 7 (when received) retains its meaning as ELI whether a > >>>> > >>>> regular special purpose label or an ESPL; this is = because of > >>>> backwards > >>>> compatibility with existing implemented and deployed = code > >>>> and hardware > >>>> that looks for the ELI without verifying if the = previous label > >>>> is XL or not. However, when an LSR insert an entropy = label > >>>> it SHOULD > >>>> insert the ELI as a regular special purpose label, not = as an > >>>> ESPL." > >>>> > >>> This doesn't explain that bad traffic side-effects could happen, = but > >>> I think the wording for why the exception is there is clear. > >>> > >>> Alia > >>> > >>> > >>> On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant = >>> > wrote: > >>> > >>> This has me worried. > >>> > >>> Assume that nothing implements ESPL yet, there is no reason = why > >>> all SPL implementations are not required to send L7 only as > >>> a regular (single) SPL. As Loa says, this would be a useful > >>> simplification, and one which I raised earlier with the = authors. > >>> > >>> If that is the case, a parser will always get it right. > >>> > >>> The only problem I see is if a compound label is ever created > >>> L15, Lx, <0..maxLabel> but one one has defined such an > >>> Lx and to do so would be unwise. > >>> > >>> So I don't think Alia is correct in her proposed text change = and > >>> I have yet to see a valid technical reason for not accepting Loa's > >>> proposed change. > >>> > >>> - Stewart > >>> > >>> > >>> On 15/02/2014 17:09, Alia Atlas wrote: > >>>> [+ietf] > >>>> > >>>> Loa, > >>>> > >>>> To clarify a bit better, what I'm trying to get clarified = into > >>>> the text is why the ELI value as an ESPL > >>>> needs to be an exception (as the draft indicates). I = believe it > >>>> is because forbidding an ESPL of 7 > >>>> can break some existing and deployed versions of RFC 6790 = such > >>>> that the transit traffic flows are affected. > >>>> There may also be implementations of RFC 6790 that aren't affected. > >>>> > >>>> Regards, > >>>> Alia > >>>> > >>>> > >>>> On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas = >>>> > wrote: > >>>> > >>>> Loa, > >>>> > >>>> On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson = >>>> > wrote: > >>>> > >>>> Alia, > >>>> > >>>> Two comments on this. > >>>> > >>>> First a nit "An LSR wishing to insert an ...", LSR = are > >>>> boxes and can't > >>>> wish anything for themselves, a Simple change would = be > >>>> "When an LSR > >>>> insert..." > >>>> > >>>> Actually the same is true for the current text and should > >>>> be changed the > >>>> same way. > >>>> > >>>> > >>>> [Alia] Sure - I took the original text and modified it. > >>>> > >>>> Second, and this is maybe more tricky - the reason = given > >>>> "simplify the > >>>> data plane implementation" is not true and might = even be > >>>> wrong. > >>>> The reason put always using the ELI as a "regular special > >>>> purpose label" > >>>> is backwards compatibility. > >>>> I would claim that the treatment of the ELI is an = (well > >>>> motivated) > >>>> exception, but exceptions always mean that things = get > >>>> more complicated. > >>>> > >>>> > >>>> [Alia] There were three purposes to my suggested text change. > >>>> First, to specify that > >>>> an LSR MUST NOT insert the ELI as an ESPL. Second, to = say > >>>> that a receiving LSR > >>>> MAY choose to not discard a packet with the ELI as an = ESPL. > >>>> Third, I wanted to see > >>>> a clearer justification for why this exception is worth making. > >>>> > >>>> [Alia] Since the whole draft is about a data-plane = change, > >>>> what we've been putting in doesn't > >>>> really articulate the full problem. Prelim text would around > >>>> that would be better as: > >>>> > >>>> "ELI is an exception because each LSR examines the whole > >>>> label stack to see if the ELI > >>>> appears; pre-existing implementations of [Entropy-Label] = do > >>>> this examination without verifying > >>>> that the label above the ELI is not XL. If a packet = used an > >>>> ESPL of 7 and that did not mean > >>>> ELI, then when that packet transited deployed LSRs, = which > >>>> implement [Entropy-Label] and not this document, > >>>> the meaning of the ESPL would be misinterpreted. Such a > >>>> misinterpretation could result in poor traffic behavior > >>>> (large flows, > >>>> reordered flows, etc.) depending on the label after the = ESPL > >>>> of 7. It is to avoid such issues that ELI is defined as = an > >>>> exception > >>>> that can appear as an regular special label or as an = ESPL > >>>> with the same value of 7." > >>>> What do you think? > >>>> > >>>> Alia > >>>> > >>>> I don't want to propose a final text,but something = along > >>>> these lines: > >>>> > >>>> > >>>> "Label 7 (when received) retains its meaning as ELI > >>>> whether > > a > >>>> regular special purpose label or an ESPL; this is > >>>> because of backwards > >>>> compatibility with existing implemented and = deployed > >>>> code and hardware > >>>> that looks for the ELI without verifying if the previous > >>>> label > >>>> is XL or not. However, when an LSR insert an = entropy > >>>> label it SHOULD > >>>> insert the ELI as a regular special purpose label, = not > >>>> as an ESPL." > >>>> > >>>> /Loa > >>>> > >>>> > >>>> On 2014-02-15 10:52, Alia Atlas wrote: > >>>> > >>>> Adrian and others, > >>>> > >>>> Having reviewed the 05 of this draft and this thread, > >>>> I have the > >>>> following suggestions. Other than these, I'm = quite > >>>> happy with how this > >>>> draft has improved. > >>>> > >>>> a) In Sec 3.1, the following paragraph could be > >>>> updated from: > >>>> > >>>> "Label 7 (when received) retains its meaning as = ELI > >>>> whether a > >>>> regular special purpose label or an ESPL; this > >>>> simplifies a transit > >>>> LSR's task of looking for entropy labels since = it may > >>>> just look for > >>>> label 7 and need not verify that the previous = label > >>>> in the stack is not > >>>> the XL 15. However, an LSR wishing to insert an > >>>> entropy label SHOULD > >>>> insert label 7 as a regular special purpose = label, > >>>> not as an ESPL." > >>>> > >>>> > >>>> to: > >>>> > >>>> > >>>> "An LSR wishing to insert an entropy label MUST > >>>> insert label value 7 (meaning ELI) as a regular > >>>> special purpose > >>>> > >>>> label and not as an ESPL.Value 7 MUST NOT be = sent as > >>>> an ESPL in the data plane. However, to simplify > >>>> > >>>> > >>>> the data plane implementation for Entropy = Labels, an > >>>> implementation MAY > >>>> > >>>> interpret an ESPL of 7 as meaning ELI and, = unlike for > >>>> values 0-6 and 8-15, an implementation > >>>> > >>>> MAY choose to not treat the packet as = malformedand > >>>> thus discard it. The data plane simplification = thus > >>>> enabled > >>>> > >>>> > >>>> is the ability to determine if any label value = is 7 > >>>> without needing to verify that the previous = label in > >>>> the stack is not the XL value of 15." > >>>> > >>>> > >>>> b)In Sec 3.2: "An RFC with at least = Informational > >>>> status is required." How is this different = from > >>>> IETF Review in RFC 5226? Do BCPs count? What is = "at > >>>> least Informational status"? > >>>> > >>>> > >>>> > >>>> On the concern about Pervasive Monitoring, the = only > >>>> advantage that (XL, > >>>> ESPL) offers is that the labels wouldn't (eventually) > >>>> be hashed for > >>>> load-balancing. Otherwise, the label stack = offers > >>>> the ability for > >>>> meta-data already where only the receiver would = need > >>>> to understand it. > >>>> Consistent paths are very useful, but there = are > >>>> other ways of doing > >>>> this already - with the most trivial being just using > >>>> label 15. I have > >>>> a hard time seeing this as a new attack vector = (but > >>>> I'm not > >>>> professionally paranoid yet). > >>>> > >>>> Alia > >>>> > >>>> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel > >>>> > >>>> >>>> >> wrote: > >>>> > >>>> [snip] > >>>> > >>>> > >> XL The Extension Label that = indicates > >>>> that an extended special > >>>> > >> purpose label follows. > >>>> > >> > >>>> > >> ESPL An Extended Special Purpose = Label. > >>>> > >> > >>>> > >> Something that I think would be = worthwhile > >>>> clarifying right at the > >>>> > >> front is that a label is an ESPL IFF = it is > >>>> preceded by an XL. > >>>> > >> It might even be worth noting that = really > >>>> we have a new label > >>>> type: > >>>> > >> a label couple in which the first = label > >>>> defines the type of the > >>>> > >> second label and neither are of any = use as > >>>> individual labels. > >>>> > > I can see how you would see this as a = new > >>>> label type. Maybe > >>>> "compound" > >>>> > > rather than "couple". > >>>> > > However, I am not convinced that it is = new > >>>> that one label leads > >>>> to the > >>>> semantics > >>>> > > of the next (for example the entropy label). > >>>> > > What is more, I am not sure that there = will > >>>> be more than this > >>>> instance of > >>>> this > >>>> > > type of tight coupling. > >>>> > > So I would rather leave this point out. > >>>> > I can foresee other cases where we might = use > >>>> label pairs to > >>>> mitigate the > >>>> > 20bit limit. I am sure it has been = discussed, > >>>> so creating the > >>>> reference > >>>> > might be useful. Just because this was = not > >>>> done in EL, does not > >>>> mean that > >>>> > we should not set down the concept here. > >>>> > > >>>> > However I agree compound would be a = better term. > >>>> > > >>>> > > > >>>> > > But as to clarifying ESPL: yes. > >>>> > > The XP definition is, I think, clear. > >>>> > > How about... > >>>> > > > >>>> > > ESPL An Extended Special Purpose Label. = A > >>>> Special Purpose Label > >>>> that > >>>> > > is placed in the label stack after the > >>>> Extension Label. > >>>> > > >>>> > Yes. Indeed it MUST be placed be placed there, > >>>> however the definition > >>>> > above is fine. > >>>> > >>>> OK, I updated to... > >>>> > >>>> ESPL An Extended Special Purpose Label. = A > >>>> Special Purpose Label that > >>>> is placed in the label stack after = the > >>>> Extension Label. The > >>>> combination of XL and ESPL might be regarded as = a > >>>> new form of > >>>> "compound label" comprising more = than > >>>> one consecutive entry in > >>>> the label stack. > >>>> > >>>> ..to cover your other point as well. > >>>> > >>>> > >> =3D=3D=3D=3D=3D=3D > >>>> > >> > >>>> > >> I think that the draft will need to provide > >>>> some guidance > >>>> > >> on when to allocate a 0..15 and when = to > >>>> allocate an ESPL. > >>>> > >> > >>>> > >> I imagine that a 0..15 should only be = used > >>>> when it can be shown > >>>> > >> that the extra stack space of = forwarding > >>>> time is burdensome > >>>> > >> but that is a question that the WG = should > >>>> explicitly consider. > >>>> > > We discussed this at some point on the = MPLS > >>>> list (many > >>>> centuries ago, I > >>>> think) > >>>> > > and reached no conclusion. > >>>> > > The primary purpose of the XL is to = handle > >>>> the time when 0..15 > >>>> is depleted. > >>>> > > You're right that we could encourage = people > >>>> to start using > >>>> ESPLs now before > >>>> > > 0..15 is depleted. But it is hard to = make > >>>> the case for > >>>> requiring it when > >>>> there > >>>> > > is still some of 0..15 available and = the > >>>> rate of burn is not so > >>>> high. > >>>> > > > >>>> > > We could put in some text like... > >>>> > > > >>>> > > When allocating a new Special Purpose Label, > >>>> protocol designers > >>>> should > >>>> > > consider whether they could, instead, = use an > >>>> Extended Special > >>>> Purpose > >>>> > > Label. Doing so would help to preserve = the > >>>> scarce resources of > >>>> Special > >>>> > > Purpose Labels for use in cases where > >>>> minimizing the label > >>>> stack size is > >>>> > > particularly important. > >>>> > > >>>> > That would be useful text. > >>>> > >>>> Added as new section 3.1.2 with slight tweak = to > >>>> wording. > >>>> > >>>> [snip] > >>>> > >>>> > >> 6. [RFC6790] says that special = purpose > >>>> labels MUST NOT be > >>>> used for > >>>> > >> load balancing. The same logic = applies > >>>> to extended special > >>>> > >> purpose labels (ESPLs). Thus, this > >>>> document specifies > >>>> that ESPLs > >>>> > >> MUST NOT be used for load = balancing. It > >>>> is noted that > >>>> existing > >>>> > >> implementations may violate this, = as > >>>> they do not look > >>>> for the XL > >>>> > >> and thus for ESPLs. The = consequence is > >>>> that if ESPLs > >>>> are used in > >>>> > >> some packets of a flow, these = packets > >>>> may be delivered on > >>>> > >> different paths and so could be > >>>> re-ordered. However, it is > >>>> > >> important to specify the correct > >>>> behavior for future > >>>> > >> implementations, hence the use of = "MUST > >>>> NOT". > >>>> > >> > >>>> > >> I would suggest that most = implementations > >>>> do violate this. I would > >>>> > >> also suggest that it seems unlikely = that > >>>> you will get to the point > >>>> > >> where it is not violated in the foreseeable > >>>> future. > >>>> > > I can't tell whether there is an action here > >>>> for us. > >>>> > > There are two "violations" that exist: > >>>> > > 1. Some implementations violate 6790. = Not > >>>> sure what we can do about > >>>> > > that in this document. Note that the entropy > >>>> label can help > >>>> with this > >>>> > > but only to a limited extent since the > >>>> implementations that > >>>> violate 6790 > >>>> > > probably also fail to recognise the = entropy > >>>> label. > >>>> > > 2. Implementations that conform to 6790 will > >>>> understand that > >>>> the XL is > >>>> > > a special purpose label and will not = use it > >>>> to load balance. > >>>> But they will > >>>> > > not necessarily understand that the = next > >>>> label is an ESPL that > >>>> must be > >>>> > > skipped as well. Again, there is = nothing we > >>>> can do about this > >>>> except to > >>>> > > note it (done) and possibly to use the = EL > >>>> further up the stack. > >>>> > > >>>> > My point was that the may in "It is noted that > >>>> existing > >>>> implementations may > >>>> > violate this" was a little soft. Most > >>>> implementations, except the > >>>> latest > >>>> > designs of maybe as few as a single = vendor, > >>>> would certainly > >>>> violate this. > >>>> > > >>>> > Also of course you are making a statement = of > >>>> fact and not of > >>>> permission > >>>> > so I think it may be more precise to say: > >>>> > > >>>> > It is noted that most existing > >>>> > implementations currently violate this, = as > >>>> they do not look for > >>>> the XL > >>>> > and thus for ESPLs. > >>>> > >>>> OK. > >>>> > >>>> I've gone with... > >>>> > >>>> It is noted that existing > >>>> implementations would violate this, as they do = not > >>>> recognise XL > >>>> as anything other than a single = Special > >>>> Purpose Label and will > >>>> not expect an ESPL to follow. > >>>> > >>>> [snip] > >>>> > >>>> > >> Label 7 (when received) retains its > >>>> meaning as ELI whether > >>>> a regular > >>>> > >> special purpose label or an ESPL; = this > >>>> simplifies a transit > >>>> LSR's > >>>> > >> task of looking for entropy labels = since > >>>> it may just look > >>>> for label 7 > >>>> > >> and need not verify that the previous > >>>> label in the stack is > >>>> not the > >>>> > >> XL 15. However, an LSR wishing to = insert > >>>> an entropy label > >>>> SHOULD > >>>> > >> insert label 7 as a regular special > >>>> purpose label, not as > >>>> an ESPL. > >>>> > >> > >>>> > >> Why is this not a MUST! There is no = ESPL in > >>>> the wild running an > >>>> > >> alternate behaviour, so why not simply > >>>> mandate this? > >>>> > > If this was a MUST then there would be = no > >>>> case for handling > >>>> Label 7 after > >>>> XL. > >>>> > > There was some concern I believe that > >>>> implementations might > >>>> have a path that > >>>> > > puts them on to XL insertion processing = and > >>>> then consider what > >>>> to do next. > >>>> At > >>>> > > that point they might decide that label = 7 is > >>>> needed. > >>>> > > > >>>> > > It seems esoteric, but I couldn't see a > >>>> reason to prohibit it. > >>>> > > > >>>> > > Maybe "MUST NOT include" and "SHOULD process > >>>> when received" are > >>>> > > compatible. > >>>> > > > >>>> > > Part of me hates the idea of this = change > >>>> just because I don't > >>>> want another > >>>> > > working group last call before we can = move > >>>> forward. How > >>>> important is it? > >>>> > > >>>> > The reason to be stricter at the TX is = that > >>>> the forwarding path > >>>> can be > >>>> > simpler at the RX. I cannot see how you = would > >>>> get to the point of > >>>> putting > >>>> > in L15 and then saying "you know I need = to put > >>>> in L7" > >>>> particularly as no > >>>> > other 0..15 is allowed. > >>>> > Normally I would think that you would put = in > >>>> the compound label > >>>> as a pair > >>>> > and that is a good reason to use the = compound > >>>> label concept. > >>>> > > >>>> > Also I see no reason for the = inconsistency > >>>> between L7 and all of the > >>>> > other L0..L15 cases. > >>>> > > >>>> > So I think that it's OK, but probably = silly to > >>>> allow L0..L15, but > >>>> to allow > >>>> > the exception of just L7 just complicates > >>>> things without good cause. > >>>> > >>>> I'm not in a position to argue on this one = as the > >>>> debate and text > >>>> were driven by > >>>> others. > >>>> > >>>> I believe that the claim was that allowing = L7 to > >>>> be inserted > >>>> anywhere made > >>>> processing it easier not harder at the = receiver. > >>>> Note that {XL,7} would be an error case in = your > >>>> way of looking at > >>>> things so the > >>>> receiver should (must?) not process it. > >>>> But the claim was that h/w will simply = search the > >>>> stack for L7 so > >>>> that allowing > >>>> {L7} and {XL, L7} to be treated in the same = way > >>>> made life easier for > >>>> the h/w. > >>>> > >>>> Bottom line, however, seems to be that you = have a > >>>> preference for > >>>> doing it one > >>>> way, and the WG has a preference for doing = it a > >>>> different way. How > >>>> to resolve > >>>> that? > >>>> > >>>> Given the posting deadline, I've not made = any > >>>> change for this. We > >>>> can continue > >>>> to discuss. > >>>> > >>>> > >> =3D=3D=3D=3D=3D=3D=3D=3D > >>>> > >> > >>>> > >> 3.2. Process for Retiring Special = Purpose > >>>> Labels > >>>> > >>>> [snip] > >>>> > >>>> > >> Secondly I think the timescales are > >>>> ridiculously optimistic. > >>>> To get > >>>> > >> a label out of circulation in 24 = months > >>>> seems most unlikely. Also > >>>> > >> 6 month checks is a lot of work. > >>>> > >> > >>>> > >> A more realistic schedule would be to = poll > >>>> at 12month > >>>> intervals until > >>>> > >> such time as it is determined that > >>>> reallocation would do not > >>>> harm and > >>>> > >> then give a further 12 months notice. > >>>> > > Erm, that's what the text says, I = think... > >>>> > > > >>>> > > 12 months after the RFC deprecating the > >>>> label value is > >>>> published, > >>>> > > an IETF-wide survey may be conducted to > >>>> determine if the > >>>> > > deprecated label value is still in use. > >>>> > > > >>>> > > The "may" in that means that the = earliest > >>>> you can "poll" is 12 > >>>> months after > >>>> the > >>>> > > deprecation RFC is published (noting = that > >>>> the RFC won't even > >>>> get published > >>>> > > until lots of discussion and consensus = to > >>>> deprecate). > >>>> > > Then, *if* the poll response is OK, and then > >>>> not earlier than > >>>> 24 months > >>>> after > >>>> > > the deprecation RFC is published, > >>>> publication can be requested > >>>> for a new RFC > >>>> > > (which means that the WG has already reached > >>>> consensus, and that a > >>>> > > subsequent IETF last call will be = held). > >>>> > > > >>>> > > Frankly, I think that this process is = only > >>>> likely to be > >>>> executed for SPLs > >>>> that > >>>> > > are allocated "in error", because other > >>>> stuff will probably be > >>>> in the field. > >>>> Can > >>>> > > you think of a label that was allocated = in > >>>> error? I can :-) > >>>> > > >>>> > This seems like a lot of text to specify = in > >>>> detail something we > >>>> would never > >>>> > run. In protocols, including this type of > >>>> protocol, the fewer > >>>> words used to > >>>> > describe the rarely executed exception = path > >>>> the better. > >>>> > >>>> The case was considered worthy of inclusion > >>>> because the SPL range is > >>>> so small. > >>>> If any SPL can be reclaimed at some future = time > >>>> it will be very > >>>> valuable and so > >>>> a mechanism needs to be documented against = that > >>>> happy day. > >>>> > >>>> [snip] > >>>> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>> [snip] > >>>> > >> However that brings me to > >>>> > >> suggest that you probably need to = write an > >>>> OPs section and > >>>> > >> you might want to think about the PM > >>>> implications of the extra > >>>> > >> metatdata in the packets. > >>>> > > > >>>> > > What OPS issues had you in mind that = need to > >>>> be addressed? I am > >>>> a fan of OPS > >>>> > > sections, but not a fan of empty OPS > >>>> sections, and when we > >>>> looked through > >>>> > > RFC 6123 (which is my favourite crib = for > >>>> what to describe wrt > >>>> manageability) > >>>> we > >>>> > > didn't see anything that has changed = from > >>>> pre-existing MPLS. > >>>> > > > >>>> > > What metadata are you talking about? Is = an > >>>> existing special > >>>> purpose label > >>>> > > metadata? If so, the PM issues are > >>>> pre-existing. Is there > >>>> something special > >>>> > > introduced by this I-D that constitutes > >>>> metadata? > >>>> > > >>>> > Well what follows an XL is certainly metadata, > >>>> and one application is > >>>> > certainly to introduce tags that would = alert > >>>> the PM devices to > >>>> take an > >>>> > interest. > >>>> > >>>> OK it is a form of metadata as existing SPLs = are > >>>> metadata. > >>>> The XL alerts a DPI that an ESPL follows, = and an > >>>> SPL alerts the DPI > >>>> that the SPL > >>>> is there. > >>>> What has changed? > >>>> We could certainly sit down and write an I-D > >>>> about the implications > >>>> of using > >>>> MPLS in an environment where PM might be = present > >>>> (BTW, I assume this is > >>>> Pervasive Monitoring. Would be embarrassing = to > >>>> find you meant > >>>> something else > >>>> :-). I think such an I-D would discuss SPLs = as > >>>> indicative metadata > >>>> and would > >>>> then note that ESPLs are in the same = category. > >>>> Is *this* the I-D in which to have that discussion? > >>>> > >>>> [snip] > >>>> > >>>> I'll post the revised I-D in a few minutes = and > >>>> others can throw > >>>> vegetables > >>>> (rotten or otherwise). > >>>> > >>>> Adrian > >>>> > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> > > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >>>> > >>>> -- > >>>> > >>>> > >>>> Loa Andersson email: = loa@mail01.huawei.com > >>>> > >>>> Senior MPLS Expert loa@pi.nu > >>>> Huawei Technologies (consultant) phone: +46 739 = 81 21 > >>>> 64 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >> > >> > >> -- > >> For corporate legal information go to: > >> > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > >> -------------- next part -------------- An HTML attachment was > >> scrubbed... > >> URL: >> archive/web/mpls/attachments/20140218/27ab9440/attachment.html> > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> ------------------------------ > >> > >> End of mpls Digest, Vol 118, Issue 73 > >> ************************************* > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From vladimir.shchutskiy@fastmatchfx.com Wed Feb 19 17:31: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 B57BF1A0606 for ; Wed, 19 Feb 2014 17:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id As0HGCJ5wA1Z for ; Wed, 19 Feb 2014 17:31:45 -0800 (PST) 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 962491A0423 for ; Wed, 19 Feb 2014 17:31:42 -0800 (PST) Received: from BLUPR06MB145.namprd06.prod.outlook.com (10.242.190.12) by BLUPR06MB145.namprd06.prod.outlook.com (10.242.190.12) with Microsoft SMTP Server (TLS) id 15.0.878.16; Thu, 20 Feb 2014 01:31:37 +0000 Received: from BLUPR06MB145.namprd06.prod.outlook.com ([169.254.5.37]) by BLUPR06MB145.namprd06.prod.outlook.com ([169.254.5.250]) with mapi id 15.00.0878.008; Thu, 20 Feb 2014 01:31:37 +0000 From: Vladimir Shchutskiy To: "mpls@ietf.org" Thread-Topic: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQHPIjut270tDLb2ukyCu7UnvpR9bpq9b9Gv Date: Thu, 20 Feb 2014 01:31:37 +0000 Message-ID: <20fccb6eaa984bf28f4f14d6fdee5aa5@BLUPR06MB145.namprd06.prod.outlook.com> References: <52F1DA2C.2070007@pi.nu> In-Reply-To: <52F1DA2C.2070007@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.68.150.163] x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(377454003)(41584004)(252514010)(94946001)(87936001)(86362001)(93516002)(94316002)(74662001)(74876001)(2656002)(74706001)(74502001)(47446002)(63696002)(54316002)(81542001)(81342001)(50986001)(65816001)(80022001)(76482001)(53806001)(54356001)(47736001)(66066001)(95416001)(87266001)(31966008)(93136001)(47976001)(49866001)(4396001)(80976001)(85306002)(69226001)(85852003)(81816001)(95666001)(16236675002)(56776001)(56816005)(90146001)(79102001)(33646001)(46102001)(77982001)(59766001)(51856001)(74366001)(92566001)(74316001)(19580395003)(83072002)(19580405001)(81686001)(83322001)(77096001)(76796001)(76576001)(76786001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB145; H:BLUPR06MB145.namprd06.prod.outlook.com; CLIP:72.68.150.163; FPR:FEDEC799.AED2D9CE.C0F6ADDB.6E0D0A1.203F0; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_20fccb6eaa984bf28f4f14d6fdee5aa5BLUPR06MB145namprd06pro_" MIME-Version: 1.0 X-OriginatorOrg: fastmatchfx.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/toEDYcG1w5UoOwdBRDSJ9Nz8Ou4 X-Mailman-Approved-At: Thu, 20 Feb 2014 13:46:33 -0800 Subject: Re: [mpls] wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:35:01 -0000 --_000_20fccb6eaa984bf28f4f14d6fdee5aa5BLUPR06MB145namprd06pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the draft. I agree with authors that financial networks more depend on PIM-SM shared = tree forwarding only topology than any other one. Financial networks are= built with clearly predefined source and receiver locations and traffic pa= ths in mind. In my practice, challenges to application development caused = by original design switching from shared "(*,G)" to source tree "(S,G)" al= ways outweighed any other infrastructure benefits. Thus we place RP in betw= een source and receivers while designing financial networks and we prefer= to never switch from "(*,G)" tree. That alone would make me support the proposed draft since I believe linkin= g "(*,G)" tree to MP-LSP should be welcomed by financial community . I al= so agree that IGMP/MLD Proxying will find its own happy engineer in the fi= nancial networks in many implementations. And I do support the authors in s= uggesting that Anycast RP became the preferred way in the financial industr= y. Best Regards, Vladimir Shchutskiy. IT Infrastructure FastMatch, Inc. 55 Water Street, 50th Floor New York, NY 10041 Phone: +1 (347) 201-2223 Fax: +1 (646) 304-1708 Hotline: +1-(212) 201-7319 ________________________________ From: loa@pi.nu Sent: Wednesday, February 05, 2014 1:29 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; martin.vigoureux@alcatel-luc= ent.com; draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org Subject: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildcard-enco= ding Working Group, This is to start a two week poll on adopting draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. Please note that we have identified an overlap between this document and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp to cover this. There are no IPR claims against this document. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. This poll ends February 19, 2014. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --_000_20fccb6eaa984bf28f4f14d6fdee5aa5BLUPR06MB145namprd06pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the draft.

I agree with authors that  financial networks more depend on PIM-SM shared tree forwarding only  = topology than any other one.  = Financial  networks are built with clearly predefined source and receiver locations and traffic paths in mind.  = In my practice, challenges to appli= cation development caused by original design switching from share= d "(*,G)" to source tree "(S,G)"  always outweighed any other infrastructure benefits. Thus we place RP in between source and rece= ivers  while designing financi= al  networks and we prefer to never switch from  "= (*,G)" tree.

That alone would  make me support the proposed draft si= nce I believe linking "(*,G)" tree to  MP-LSP  sho= uld be welcomed by financial communit= y . I also agree that IGMP/MLD= Proxying will  find its own happy engineer in the financial networks in m= any implementations. And I do&= nbsp;support the authors in suggesting that Anycast RP became the preferred= way in the financial industry. 


Best Regards,

Vladimir Shchutskiy.

IT Infrastructure

FastMatch, Inc.

55 Water Street, 50th Floor

New York, NY 10041

Phone: +1 (347) 201-2223

Fax:  +1 (646) 304-1708

Hotline: +1-(212) 201-7319

From: loa@pi.nu <loa= @pi.nu>
Sent: Wednesday, February 05, 2014 1:29 AM
To: mpls@ietf.org; mpls-chairs@tools.ietf.org; martin.vigoureux@alca= tel-lucent.com; draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ie= tf.org
Subject: wg adoption poll on draft-wijnands-mpls-mldp-in-band-wildca= rd-encoding
 
Working Group,

This is to start a two week poll on adopting
draft-wijnands-mpls-mldp-in-band-wildcard-encoding as an MPLS working
group document.

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

Please note that we have identified an overlap between this document
and draft-rekhter-mpls-pim-sm-over-mldp. The intention is to leave this
document unchanged and add text to draft-rekhter-mpls-pim-sm-over-mldp
to cover this.

There are no IPR claims against this document.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.

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

This poll ends February 19, 2014.

/Loa
(mpls wg co-chair)
--


Loa Andersson          &n= bsp;            = ; email: loa@mail01.huawei.com
Senior MPLS Expert         &nb= sp;            =     loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739= 81 21 64
--_000_20fccb6eaa984bf28f4f14d6fdee5aa5BLUPR06MB145namprd06pro_-- From Frank.Huo@telus.com Thu Feb 20 13:28: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 359081A030E for ; Thu, 20 Feb 2014 13:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 1W7ltlOJGlEk for ; Thu, 20 Feb 2014 13:28:18 -0800 (PST) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id EFC501A0306 for ; Thu, 20 Feb 2014 13:28:17 -0800 (PST) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:MIME-Version; b=phO6ShgBR8i0CZjipDNkJ3oEJwFmlJr5kEWDOaGiWhThGRXafsO7bRsM /DGIbpM/+DzLMC2hjSAe8JeHT5j07A304bL29rwe5XKAd6s3Gp3xIlakC MUE90mr564rk+kbY//7l4H1+ofiC68HwqL5QZJ2C1GbAcUC1WL30ItzoI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFACxyBlOOP4Bq/2dsb2JhbABZgkIjITilKps8gREWdIIsLSYmEgEIDWsmAQQODYd9Ac1KF44zMYMrgRQEiUiVV4s1g0s X-IronPort-AV: E=Sophos;i="4.97,514,1389744000"; d="scan'208,217";a="300063390" Received: from unknown (HELO WP40058.corp.ads) ([142.63.128.106]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 20 Feb 2014 21:28:12 +0000 Received: from wp40067.corp.ads ([::1]) by WP40058.corp.ads ([2002:8e3f:806a::8e3f:806a]) with mapi; Thu, 20 Feb 2014 16:28:12 -0500 From: Frank Huo To: "mpls@ietf.org" Date: Thu, 20 Feb 2014 16:28:11 -0500 Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: Ac8ugn7oroKF8D7FQQyKcNMTSj8u3w== Message-ID: <71A79FD20B9FC948B657284408C1310316B38AFAB7@WP40067.corp.ads> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: multipart/alternative; boundary="_000_71A79FD20B9FC948B657284408C1310316B38AFAB7WP40067corpad_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/T_BNWuU1F4Zs-hTnilt4jULClYI X-Mailman-Approved-At: Thu, 20 Feb 2014 13:46:53 -0800 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 20 Feb 2014 21:29:23 -0000 --_000_71A79FD20B9FC948B657284408C1310316B38AFAB7WP40067corpad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Supported Frank Huo TELUS Communications Inc. --_000_71A79FD20B9FC948B657284408C1310316B38AFAB7WP40067corpad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Supported

 

Fran= k Huo

TELUS C= ommunications Inc.

 

= --_000_71A79FD20B9FC948B657284408C1310316B38AFAB7WP40067corpad_-- From nobody Fri Feb 21 04:02: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 B80031A0537 for ; Fri, 21 Feb 2014 04:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 pLzD0B77Lbup for ; Fri, 21 Feb 2014 04:02:09 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 940DB1A0528 for ; Fri, 21 Feb 2014 04:02:09 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1LC24Co028230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Feb 2014 06:02:05 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1LC23oA004824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Feb 2014 13:02:03 +0100 Received: from [135.244.227.64] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 21 Feb 2014 13:02:03 +0100 Message-ID: <53074039.4030409@alcatel-lucent.com> Date: Fri, 21 Feb 2014 13:02:01 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZVmaUE4r_Djv-yDUWx8adX9GcrE Subject: [mpls] IETF89 - MPLS - Agenda available - Please send your presentation material X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 21 Feb 2014 12:02:12 -0000 All, the draft agenda is on-line: http://www.ietf.org/proceedings/89/agenda/agenda-89-mpls Please have a look at it. Final agenda is due on Feb 24th. You still have a bit of time to send me slots requests. Speakers, please start sending me your presentation material, and please do so before March the 3rd. Thank you. Martin From yfan02@gmail.com Thu Feb 20 18:06:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5A11A03C3 for ; Thu, 20 Feb 2014 18:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 sjN-O6blUvtA for ; Thu, 20 Feb 2014 18:06:44 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 83C211A03C2 for ; Thu, 20 Feb 2014 18:06:44 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id q200so4153594ykb.8 for ; Thu, 20 Feb 2014 18:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xyCSEUzRALak7lJJM+9IpLbLrAEsX/auzkjCtktbqMo=; b=RvEVpDCNsD23ynjKGjFnhDXzRRfB1j0/zDtoRBK4tC/0W9LT91zVrwj4c7OgzsLTSp kOT656BCM9vD1Qv3lKbo/XEfpy9xAL4t+Q/P/k10/7jzxqfgQ44Xxt6fmuheNM4kfNGw D7jmncyppnBe0T9515oMeqJX+WMYQTCdf4PJPR/xaLjPyBeYrqAKLZr7wZaUWSZ2VFDv 1JqJ/dJHHdFCPQZTymmG7vcKf9N4vtl+nmouLcmyy8JCLHg5QuhaEI47UC3uxH+IshG1 BLhwe2C/jzAbFMTgaWJSd1XkdX00mWpEVFxedJgCbcCAdPnkdsi6YKC8mCGr10b/YGg4 HXqw== MIME-Version: 1.0 X-Received: by 10.236.119.141 with SMTP id n13mr7812587yhh.136.1392948400705; Thu, 20 Feb 2014 18:06:40 -0800 (PST) Received: by 10.170.94.70 with HTTP; Thu, 20 Feb 2014 18:06:40 -0800 (PST) Date: Thu, 20 Feb 2014 21:06:40 -0500 Message-ID: From: Yanhe Fan To: mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf3005df789d656b04f2e112d5 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aM-eZ9Lzuk0QWwV2XJgQpUZv3yw X-Mailman-Approved-At: Fri, 21 Feb 2014 06:45:53 -0800 Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 21 Feb 2014 02:08:19 -0000 --20cf3005df789d656b04f2e112d5 Content-Type: text/plain; charset=ISO-8859-1 Support. Thanks, Yanhe Fan >This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-11 >as an MPLS working group document. Since many of us will be in transit to the >IETF approximately two weeks from now, I will extent the poll by one week (so >that it will be a three week poll). >Please send your comments (support/not support) to the mpls working group >mailing list (mpls@ietf.org). >This poll will end Friday March 7, 2014. Note that this is the Friday of the IETF, >and thus we will each need to plan our review of the document and response >around our travel plans and IETF activities. >Thanks, Ross --20cf3005df789d656b04f2e112d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.

Thanks,
Y= anhe Fan



>This is to start a poll on adopting draft-chen-m= pls-p2mp-egress-protection-11

>as an MPLS working group documen= t. Since many of us will be in transit to the

>IETF approximately two weeks from= now, I will extent the poll by one week (so

>that it will be a three week poll). <= u>

=A0=

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

>mailing list (mpls@ietf.org).<= /u>

=A0

>This poll will end Friday March 7, 2014. Note that this is the= Friday of the IETF,

>and thus we will each need to plan ou= r review of the document and response

>around our travel plans and IETF activities. <= /span>

=A0

>Thanks, Ross=

=A0

--20cf3005df789d656b04f2e112d5-- From nobody Fri Feb 21 07:17: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 E37771A0282 for ; Fri, 21 Feb 2014 07:17:21 -0800 (PST) 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_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 8Vf7YMeTH2GJ for ; Fri, 21 Feb 2014 07:17:19 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id CD1021A01AB for ; Fri, 21 Feb 2014 07:17:18 -0800 (PST) Received: from DB3PRD0411HT004.eurprd04.prod.outlook.com (157.56.253.53) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.0.883.10; Fri, 21 Feb 2014 15:17:13 +0000 Message-ID: <003a01cf2f17$4eede300$4001a8c0@gateway.2wire.net> From: t.petch To: References: <201401302106.s0UL6tln065171@maildrop2.v6ds.occnc.com> Date: Fri, 21 Feb 2014 15:05:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.53] X-ClientProxiedBy: AM3PR07CA009.eurprd07.prod.outlook.com (10.242.16.49) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Forefront-PRVS: 01294F875B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(52604005)(377454003)(199002)(189002)(13464003)(85306002)(81542001)(61296002)(14496001)(84392001)(50466002)(94946001)(88136002)(93136001)(46102001)(49866001)(47736001)(19580405001)(83322001)(59766001)(87266001)(87976001)(90146001)(80976001)(83072002)(56816005)(44736004)(92566001)(74876001)(4396001)(50226001)(87286001)(74706001)(47976001)(31966008)(51856001)(89996001)(47446002)(74502001)(77982001)(85852003)(19580395003)(33646001)(50986001)(74662001)(23756003)(81342001)(44716002)(76796001)(76482001)(47776003)(76786001)(42186004)(53806001)(62236002)(93516002)(54316002)(92726001)(63696002)(66066001)(80022001)(69226001)(65816001)(95666003)(62966002)(95416001)(77156001)(93916002)(94316002)(77096001)(86362001)(74366001)(56776001)(79102001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB062; H:DB3PRD0411HT004.eurprd04.prod.outlook.com; CLIP:157.56.253.53; FPR:FC5BC215.ACC687FD.7BD91D77.88E7F56D.2043D; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/krtogejkCh0MOaTZ0UiR8ePwKFo Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 21 Feb 2014 15:17:22 -0000 Curtis I just finished reading this - and see that the IESG have approved it. Ah well, perhaps the RFC Editor will be interested. s.1 /advise/advice/ CC-CV Connectivity Check and Connectivity Verification we have used Continuity Check elsewhere (e.g. mpls-tp-oam-framework) s2.3 "For example, an on-chip buffer capable of handling 4K packets of 64 bytes in length, or 256KB, corresponds to 2 msec on a 10 Mb/s" My maths is hopeless. 4K packets of 64byte is 256Kbyte which is 2048Kbit on a 10Mbit/s link is 2048K divided by 10M/s which is '2mS' - why do I keep getting 200mS or 2dS? s2.4.5.1 5) /closest to the bottom of stack/closer to the bottom of stack/ s2.6.4 we have used Continuity Check elsewhere (e.g. mpls-tp-oam-framework) s3 This is quite cryptic where no references are given, e.g. Q40 for Pseudowire OAM, MPLS-TP OAM, Layer-2 OAM Interworking Tom Petch ----- Original Message ----- From: "Curtis Villamizar" To: "t.petch" Cc: ; Sent: Thursday, January 30, 2014 9:06 PM > > In message <00ce01cf1de4$45fb9ba0$4001a8c0@gateway.2wire.net> > "t.petch" writes: > > > Curtis > > > > MP2MP Multipoint to Point ? > > Multipoint to multipoint. Ie: capable of supporting <*,G> though > possibly for a policy constrained value of "*". Some chips can do it > but I'm not sure what routers can do (whether software supports it) > and if so if anyone deploys MP2MP. At least some P2MP for > distribution of stuff like video, maybe a lot but I don't know. > Plenty of MP2P since LDP is inherently MP2P. > > > I would like the first sentence of the Abstract to start the > > Introduction - otherwise there is no intended audience (and I tend to > > skip Abstracts when I know I am going to be interested in a document). > > The intended audience is in the intro later on in Section 1.4 ("Target > Audience"). > > > And is that second clause for Operators eg > > a basis for operators to evaluate forwarding implementations. > > It is meant for both operators and system designers. System designers > (ie: people working for router vendors that buy off the shelf silicon) > need to pick a forwarding chip long before operators are evaluating. > See Section 1.4. > > In the case of forwarding the "implementor" is designing a chip. The > "system designer" is using it in a product. The operator is (we hope) > trying to find out what if any bad decisions were made in an > evaluation to determine what effect any shortcomings would have before > deploying and finding out the hard way. > > > (more to follow - the I-D is big and my reading is slow:-( > > No problem. Thanks for taking a look. > > > Tom Petch > > Curtis > From nobody Fri Feb 21 10:08: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 05E031A0558 for ; Fri, 21 Feb 2014 10:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJsgwAdaG3PT for ; Fri, 21 Feb 2014 10:08:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE421A0557 for ; Fri, 21 Feb 2014 10:08:22 -0800 (PST) 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 BDV28226; Fri, 21 Feb 2014 18:08:18 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 18:08:00 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 18:08:17 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 10:08:04 -0800 From: Roberttao To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPLqmOP3aQrURbE0i43S0d3in185rAAicQ Date: Fri, 21 Feb 2014 18:08:03 +0000 Message-ID: <9E378A6551FE484FA7759260D56BD5FE17E93A97@SJCEML701-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.122] Content-Type: multipart/alternative; boundary="_000_9E378A6551FE484FA7759260D56BD5FE17E93A97SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4PC_a7hBLoOjk2y662BWtsgFibc Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 21 Feb 2014 18:08:25 -0000 --_000_9E378A6551FE484FA7759260D56BD5FE17E93A97SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. /Robert --_000_9E378A6551FE484FA7759260D56BD5FE17E93A97SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

/Robert<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:Calibri"> 

--_000_9E378A6551FE484FA7759260D56BD5FE17E93A97SJCEML701CHMchi_-- From nobody Fri Feb 21 11:53: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 1B5301A054A for ; Fri, 21 Feb 2014 11:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 QwYBC2KspnaF for ; Fri, 21 Feb 2014 11:53:24 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6789E1A014C for ; Fri, 21 Feb 2014 11:53:24 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s1LJom0A017943; Fri, 21 Feb 2014 14:50:49 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402211950.s1LJom0A017943@maildrop2.v6ds.occnc.com> To: "t.petch" From: Curtis Villamizar In-reply-to: Your message of "Fri, 21 Feb 2014 15:05:59 +0000." <003a01cf2f17$4eede300$4001a8c0@gateway.2wire.net> Date: Fri, 21 Feb 2014 14:50:48 -0500 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bbuQeUHMkJYQBAYnyyeXx6dsHqo Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:53:27 -0000 In message <003a01cf2f17$4eede300$4001a8c0@gateway.2wire.net> "t.petch" writes: > Curtis > > I just finished reading this - and see that the IESG have approved it. > Ah well, perhaps the RFC Editor will be interested. Approved with discussion so there will be some change before it hits the editor queue. It is up to the responsible AD to approve and further change. > s.1 /advise/advice/ Ooops - yeah. > CC-CV Connectivity Check and Connectivity Verification > we have used Continuity Check elsewhere (e.g. mpls-tp-oam-framework) I'm not sure what you are asking me to change. > s2.3 > > "For example, an on-chip buffer capable of handling 4K packets > of 64 bytes in length, or 256KB, corresponds to 2 msec on a 10 Mb/s" > > My maths is hopeless. 4K packets of 64byte is 256Kbyte which is > 2048Kbit on a 10Mbit/s link is 2048K divided by 10M/s which is '2mS' - > why do I keep getting 200mS or 2dS? Oops -- 2048*10^3 bits / 10*10^6 bits/sec = 204.8 * 10^-6 sec ~= 200 * 10^-3 sec (200 msec). I'll have to mention this on one of the IESG threads in which this was brought up. > s2.4.5.1 5) > /closest to the bottom of stack/closer to the bottom of stack/ I meant closest. The fat-pw label is at the very bottom. The most entropy is at the very bottom. At least one chip today can search for BOS, and use the bottom N (for very small value of N). > s2.6.4 > we have used Continuity Check elsewhere (e.g. mpls-tp-oam-framework) Less demanding uses of CC don't dictate the hardware assist requirements if you mean on-demand CC. Not sure what you are getting at. > s3 > This is quite cryptic where no references are given, e.g. Q40 for > Pseudowire OAM, MPLS-TP OAM, Layer-2 OAM Interworking Ask the prior three questions (what is supported, performance limits, consequence of exceeding performance limits) for each of those types of OAM. There is a reference to Section 2.6.2 where MPLS OAM is described, though perhaps it should be to 2.6. > Tom Petch Thanks, Curtis > ----- Original Message ----- > From: "Curtis Villamizar" > To: "t.petch" > Cc: ; > Sent: Thursday, January 30, 2014 9:06 PM > > > > > In message <00ce01cf1de4$45fb9ba0$4001a8c0@gateway.2wire.net> > > "t.petch" writes: > > > > > Curtis > > > > > > MP2MP Multipoint to Point ? > > > > Multipoint to multipoint. Ie: capable of supporting <*,G> though > > possibly for a policy constrained value of "*". Some chips can do it > > but I'm not sure what routers can do (whether software supports it) > > and if so if anyone deploys MP2MP. At least some P2MP for > > distribution of stuff like video, maybe a lot but I don't know. > > Plenty of MP2P since LDP is inherently MP2P. > > > > > I would like the first sentence of the Abstract to start the > > > Introduction - otherwise there is no intended audience (and I tend > to > > > skip Abstracts when I know I am going to be interested in a > document). > > > > The intended audience is in the intro later on in Section 1.4 ("Target > > Audience"). > > > > > And is that second clause for Operators eg > > > a basis for operators to evaluate forwarding implementations. > > > > It is meant for both operators and system designers. System designers > > (ie: people working for router vendors that buy off the shelf silicon) > > need to pick a forwarding chip long before operators are evaluating. > > See Section 1.4. > > > > In the case of forwarding the "implementor" is designing a chip. The > > "system designer" is using it in a product. The operator is (we hope) > > trying to find out what if any bad decisions were made in an > > evaluation to determine what effect any shortcomings would have before > > deploying and finding out the hard way. > > > > > (more to follow - the I-D is big and my reading is slow:-( > > > > No problem. Thanks for taking a look. > > > > > Tom Petch > > > > Curtis From nobody Sat Feb 22 02:54: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 94A361A03F2 for ; Sat, 22 Feb 2014 02:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 OXvRq1nJP5zg for ; Sat, 22 Feb 2014 02:54:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C15E91A03D3 for ; Sat, 22 Feb 2014 02:54:14 -0800 (PST) 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 BBJ72914; Sat, 22 Feb 2014 10:54:09 +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; Sat, 22 Feb 2014 10:53:46 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 10:54:07 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 18:54:04 +0800 From: "Zengxinzong (Paul)" To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+Zq7LvvQgAW6XEA= Importance: high X-Priority: 1 Date: Sat, 22 Feb 2014 10:54:03 +0000 Message-ID: <54B334E2F9AB214C80ABE154F4E754792AF527BE@nkgeml507-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.80.203] Content-Type: multipart/alternative; boundary="_000_54B334E2F9AB214C80ABE154F4E754792AF527BEnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0YQKLncd48923Nht8HIF2Pr40lk Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Feb 2014 10:54:17 -0000 --_000_54B334E2F9AB214C80ABE154F4E754792AF527BEnkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. ---------------------------------------------------------------------------= ------------------------------------------- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 4:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_54B334E2F9AB214C80ABE154F4E754792AF527BEnkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 = ;

----------= ---------------------------------------------------------------------------= ---------------------------------

From: mpls [mailto= :mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll = on adopting draft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group= document. Since this call will continue through the

IETF meeting in London, = I will extent the poll by one week (so that it will be a

three week poll).

 =

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

mailing list (mpls@ietf.org).

 =

This poll will end Tuesd= ay March 11, 2014. This is of course the Tuesday after

the IETF.

 =

Thanks, Ross<= /span>

 =

 = ;

--_000_54B334E2F9AB214C80ABE154F4E754792AF527BEnkgeml507mbschi_-- From nobody Sat Feb 22 05:25:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5923A1A004E for ; Sat, 22 Feb 2014 05:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NC5WIwAuTGd for ; Sat, 22 Feb 2014 05:25:40 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCCA1A002B for ; Sat, 22 Feb 2014 05:25:40 -0800 (PST) Received: from [192.168.0.106] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4BFFF180156A; Sat, 22 Feb 2014 14:25:35 +0100 (CET) Message-ID: <5308A54F.6030302@pi.nu> Date: Sat, 22 Feb 2014 14:25:35 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <52F08ED9.5050509@pi.nu> In-Reply-To: <52F08ED9.5050509@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/W-zC3Anr5QiLyyHTnLnXmVCiyB0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-te-mib@tools.ietf.org" Subject: [mpls] poll ended - the outcome is undecided - Re: seeking consensus on making draft-ietf-mpls-tp-te-mib read-only X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 22 Feb 2014 13:25:43 -0000 Working Group, This poll has ended. The working group chairs discussed the outcome and found that it is "undecided". In part this is because the question was not asked clearly enough. We tried to ask a specific question on draft-ietf-mpls-tp-te-mib, and as substantial part of the responses are on a more general question. We have decided to bring this discussion to the mpls wg meeting in London, and hope that we will get help with introduction and managing the discussion from the OPS Area AD. /Loa On 2014-02-04 07:55, Loa Andersson wrote: > Working Group, > > We have just recalled draft-ietf-mpls-tp-te-mib from the IESG to the > working group for more work. We have a series of comments that are > mostly for clarification. However the main reason for recalling the > document is that there is one point where we need to confirm working > group consensus. > > The IETF, the working group and the MIB Doctors are today very reluctant > to produce read-write MIB modules. The current draft is read-write for a > few objects, this is based on a consensus call for an earlier > discussion, however the consensus call was not clear. It can be taken > to mean both that we want to go with read-write objects and that we > want to see read-only. Is it clear that it has been interpreted > differently by different individuals. > > The authors and chairs have discussed the issue and we have a rough > consensus that we want the MIB module(s) to be read-only. > > We therefore are asking the working group if this is OK for the MIB > module(s) in the current document. Please indicate Support or Oppose > for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only. > > Please send your comments to the working group mailing list before > February 18, 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 Sun Feb 23 04:32: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 B9A5F1A04B7 for ; Sun, 23 Feb 2014 04:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yttbkg0QaobU for ; Sun, 23 Feb 2014 04:32:46 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id AA39E1A04B3 for ; Sun, 23 Feb 2014 04:32:42 -0800 (PST) Received: from [192.168.0.109] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8DE57180145E; Sun, 23 Feb 2014 13:32:37 +0100 (CET) Message-ID: <5309EA66.9020609@pi.nu> Date: Sun, 23 Feb 2014 13:32:38 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.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/4_wmFlFlniOuWd8AIx148Q9pr0E Cc: "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" Subject: [mpls] two working group document poll closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 12:32:45 -0000 Working Group, the polls to see if we have consensus to adopt draft-wijnands-mpls-mldp-in-band-wildcard-encoding and draft-rekhter-mpls-pim-sm-over-mldp are closed. We have two new working group documents, could the authors please post the documents as: draft-ietf-mpls-mldp-in-band-wildcard-encoding and draft-ietf-mpls-pim-sm-over-mldp as soon as the cut-off for the London meeting is lifted. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Feb 24 11:18:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86B71A025A for ; Mon, 24 Feb 2014 11:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 m-UsUa0Yso6y for ; Mon, 24 Feb 2014 11:18:02 -0800 (PST) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB161A024E for ; Mon, 24 Feb 2014 11:18:01 -0800 (PST) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: MIME-Version; b=tq6+BaPIwx59Dwmnu6W84WgNqsCyaOL6KiALmbQ9GLQ/briN9rAVCvrE Ht/Gh063pHcv8upaDtoFvOKqRsb0yvLCfyfTvFmy1ftVHJjhjEhNYIEKB V937rK/rCUIrF7IE5TvcczFs8HczasrGsZ4LUOnmmVKGUbbvUR2siZGqD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAH2aC1OOP4Bq/2dsb2JhbABZgkIjITulbZtzgR0WdIIlAQEFLSYbCxACAQgNBAQBASgHMhQJCAIEDgUIh30BxgwXjhAjMQYBgySBFASJSJVcizeDSw X-IronPort-AV: E=Sophos;i="4.97,536,1389744000"; d="scan'208,217";a="300889828" Received: from unknown (HELO WP40058.corp.ads) ([142.63.128.106]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 24 Feb 2014 19:18:00 +0000 Received: from wp40067.corp.ads ([::1]) by WP40058.corp.ads ([2002:8e3f:806a::8e3f:806a]) with mapi; Mon, 24 Feb 2014 14:17:54 -0500 From: Boris Zhang To: "mpls@ietf.org" Date: Mon, 24 Feb 2014 14:17:53 -0500 Thread-Topic: Please support INgress Protection Draft Thread-Index: AQHPMQZ3tutTbs/OjEKxCOcosVFrT5rEx/+Q Message-ID: <3CC752382EB88F48ADAC4AF9F478A153169295F7B5@WP40067.corp.ads> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C419FA@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C419FA@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: multipart/alternative; boundary="_000_3CC752382EB88F48ADAC4AF9F478A153169295F7B5WP40067corpad_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sAIIXJhLFsE5g2FWp8Za_4bgmyM Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Please support INgress Protection Draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 24 Feb 2014 19:18:05 -0000 --_000_3CC752382EB88F48ADAC4AF9F478A153169295F7B5WP40067corpad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support ! Boris Zhang TELUS INC. From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: February 23, 2014 09:17 PM To: Boris Zhang Subject: Please support INgress Protection Draft Importance: High Hi Boris, Can you help support our Ingress Protection draft as a contributor? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 4:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_3CC752382EB88F48ADAC4AF9F478A153169295F7B5WP40067corpad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support !=

 <= /p>

Boris Zhang

TELUS INC.

 

Fr= om: Huaimo Chen [mailto:huaimo.chen@huawei.com]
Sent= : February 23, 2014 09:17 PM
To: Boris Zhang
Subject: Please support INgress Protection Draft
Importance: High<= /o:p>

 

Hi Boris,

 

Can you help support= our Ingress Protection draft as a contributor?

 

Best Regards,

Huaimo

<= p class=3DMsoNormal>From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protect= ion-11

 

This is to= start a poll on adopting draft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working gro= up document. Since this call will continue through the

IETF meeting in London, I will extent the poll= by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will en= d Tuesday March 11, 2014. This is of course the Tuesday after

the IETF.

<= div>

 

Thanks, Ross

 

 

= --_000_3CC752382EB88F48ADAC4AF9F478A153169295F7B5WP40067corpad_-- From nobody Mon Feb 24 14:28: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 D3E6A1A02E4; Mon, 24 Feb 2014 14:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG7mapAbAJ-i; Mon, 24 Feb 2014 14:28:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF841A02FB; Mon, 24 Feb 2014 14:28:42 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140224222842.6878.2186.idtracker@ietfa.amsl.com> Date: Mon, 24 Feb 2014 14:28:42 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/XwAOBVEGEsWlZo6r10IjtIw0NkA Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-psc-itu-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 22:28:45 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators Author(s) : J. Ryoo, et al Filename : draft-ietf-mpls-tp-psc-itu Pages : 37 Date : 2014-02-24 This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-psc-itu-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-psc-itu"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-24142842.I-D@ietf.org> --NextPart-- From nobody Mon Feb 24 15:16: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 1F09D1A0223; Mon, 24 Feb 2014 15:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 5RTcOb6CtCsU; Mon, 24 Feb 2014 15:16:36 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1391A01D5; Mon, 24 Feb 2014 15:16:36 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-1b-530bd2d4f737 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A9.92.11484.4D2DB035; Tue, 25 Feb 2014 00:16:36 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 18:16:34 -0500 From: Gregory Mirsky To: "Rakesh Gandhi (rgandhi)" , Lizhong Jin , Frederic Jounay , "Tarek Saad (tsaad)" , "Mike Taillon (mtaillon)" , "Zafar Ali (zali)" , Manav Bhatia , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt Thread-Index: AQHPIOaJqiIMOAEGrkS5EKB7Vxg2IpqjnT0AgADCvJCAINagAP//8aFg Date: Mon, 24 Feb 2014 23:16:34 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B771F3F@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B75E003@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHT/fKJe5gg1Ub9CyezLnBYnF8+gQW ixWnnzFbzLl3j9Xi1tKVrBZblxxnspja1MFm8enETyaL1zu+sjtwerQ+28vqMeX3RlaPnbPu snssWfKTyePGVsUA1igum5TUnMyy1CJ9uwSujG2v/zAXPFOpOHfnM1sD40a5LkZODgkBE4kv R/6wQdhiEhfurQeyuTiEBI4wSsw5/IwVwlnOKHF06x9mkCo2ASOJFxt72EESIgLXmST2ndnN BJJgFpCSuHurixHEFhZIlOi/cZYVxBYRSJJY+Ps/O4TtJjHl0QqwdSwCqhLPjv8C6+UV8JU4 t2gyWI2QQJHEpedbwHo5BfQlFv9tAatnBDrv+6k1ULvEJW49mc8EcbaAxJI955khbFGJl4// sULYihL7+qezQ9TrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFl FSNHaXFqWW66keEmRmAsHpNgc9zBuOCT5SFGaQ4WJXHeL2+dg4QE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwTvixz39tgm7Qv3xuCcukY5m6b1Y8KOQ9+eSh0kmeL3Uy8d0/bm898Kjnh3nE v82KfQVrj6vLrgvRl9pt0fF7WVdE6fr8+4s7u7xmpqYFzEj3DFjTM/f1bD9u7YPSFUdKOi5e e9A7+5qqQLUYI6+16uYbNyJPtx45zcPH5v9kdiC/6L2SjzxLlFiKMxINtZiLihMB+maC3ZMC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/P5RQhOLZMoRf9R-NJRjyoAnDZT4 Cc: CCAMP Subject: Re: [mpls] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 23:16:39 -0000 Hi Rakesh, I understand motivation of authors. Applicability of RFC 4090 to bi-directi= onal co-routed LSP was discussed as part of MPLS-TP survivability framework= (RFC 6372). I think that we've agreed that applicability of RFC 4090 is li= mited to link protection and segment protection should be recommended as pr= oviding more generic coverage. Have authors considered bringing discussion = and presenting the proposal to MPLS WG? Hope you wouldn't mind me adding MPLS WG to the discussion. Regards, Greg -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]=20 Sent: Monday, February 24, 2014 2:58 PM To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike = Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia Cc: CCAMP Subject: Re: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-ls= p-fastreroute-03.txt Hi Greg, Thank you for your comments. As you know, proposed draft addresses the two issues (state timeout and byp= ass assignment) where FRR [RFC4090] is used for GMPLS packet tunnels. Motivations for using FRR here is that it is widely deployed in the packet = MPLS-TE network today and can leverage all existing FRR detection and resto= ration mechanisms and not have to deploy new protocol such as PSC [RFC6378]= for protection switchover co-ordination. Thanks, Rakesh On 2014-02-03 9:40 PM, "Gregory Mirsky" wrote: >Hi Rakesh, et. al, >since bi-directional co-routed LSP is MPLS-TP construct I believe that=20 >if local node protection is indeed required it should not use RFC 4090=20 >signaling but use ASSOCIATION object as described in Section 2.3 RFC=20 >6689 and RFC 6378 MPLS-TP Linear Protection instead. > > Regards, > Greg > >-----Original Message----- >From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rakesh Gandhi >(rgandhi) >Sent: Monday, February 03, 2014 5:52 AM >To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike=20 >Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Zafar Ali (zali);=20 >Mike Taillon (mtaillon); Tarek Saad (tsaad); Frederic JOUNAY; Manav=20 >Bhatia >Cc: CCAMP >Subject: Re: [CCAMP] New Version Notification for=20 >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt > >Hi WG, > >New revision of the published draft contains following updates: > >- Remove unidirectional bypass LSP (as per previous comments) >- Fix syntax of the BYPASS_ASSIGNMENT object. >- Misc editorial cleanup. > > >Please provide your review comments. > >Thanks, >Rakesh > >=20 > >On 2014-02-03 8:44 AM, "internet-drafts@ietf.org" > wrote: > >> >>A new version of I-D, >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>has been successfully submitted by Rakesh Gandhi and posted to the=20 >>IETF repository. >> >>Name: draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>Revision: 03 >>Title: Extensions to Resource Reservation Protocol For Fast Reroute of >>Bidirectional Co-routed Traffic Engineering LSPs >>Document date: 2014-02-03 >>Group: Individual Submission >>Pages: 12 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-tsaad-ccamp-rsvpte-bidir-lsp >>- >>fas >>treroute-03.txt >>Status: =20 >>https://datatracker.ietf.org/doc/draft-tsaad-ccamp-rsvpte-bidir-lsp-fa >>s >>tre >>route/ >>Htmlized: =20 >>http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastrero >>u >>te- >>03 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-tsaad-ccamp-rsvpte-bidir-lsp-fa >>s >>tre >>route-03 >> >>Abstract: >> This document defines Resource Reservation Protocol - Traffic >> Engineering (RSVP-TE) signaling extensions to support Fast Reroute >> (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. These >> extensions enable the re-direction of bidirectional traffic and >> signaling onto bypass tunnels that ensure co-routedness of data and >> signaling paths in the forward and reverse directions after FRR. In >> addition, the RSVP-TE signaling extensions allow the coordination of >> bypass tunnel assignment protecting a common facility in both forward >> and reverse directions prior to or post failure occurrence. >> >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>The IETF Secretariat >> > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From nobody Mon Feb 24 15:55: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 39C271A0349; Mon, 24 Feb 2014 15:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 q0gDASbq0b8I; Mon, 24 Feb 2014 15:55:43 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 202721A0347; Mon, 24 Feb 2014 15:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5753; q=dns/txt; s=iport; t=1393286143; x=1394495743; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aZzOV7GfVvgt3KvtRIlUB/yL9kwkzjTeZYiFhQQGpRw=; b=dAi2LobBWvBHxK33R/xh/fsFGsr8y18sCE77/Qj75aYaun5ayd/uq4uM 9kudD7oyAeykbn4zbsvlipBspZi6lf5glSgxXa47Z5RhgIuuYJasSZfol RaMKVeASk6A7aMk5hOrhWSPetGAmQURXT2Zl7ixkAqOHxDq49epsYDhXA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFAM/bC1OtJV2a/2dsb2JhbABZgwY7UQbBNIEaFnSCJQEBAQQBAQE3NAkCDAYBCBEEAQEBHgkuCxQJCAIEAQ0FCYd8CAXGGReODFgHBoQyBJg0gTKQdYFvgT6BaEI X-IronPort-AV: E=Sophos;i="4.97,537,1389744000"; d="scan'208";a="306243719" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 24 Feb 2014 23:55:30 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1ONtUnt011595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 23:55:30 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.22]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 17:55:29 -0600 From: "Rakesh Gandhi (rgandhi)" To: Gregory Mirsky , Lizhong Jin , Frederic Jounay , "Tarek Saad (tsaad)" , "Mike Taillon (mtaillon)" , "Zafar Ali (zali)" , Manav Bhatia , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt Thread-Index: AQHPIOaJqiIMOAEGrkS5EKB7Vxg2IpqjnT0AgADCvJCAINagAP//8aFggAAehIA= Date: Mon, 24 Feb 2014 23:55:29 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B771F3F@eusaamb103.ericsson.se> 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: [10.86.246.246] 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/VHOIstFvMHPGh8kVS9V8l07wJUo Cc: CCAMP Subject: Re: [mpls] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 23:55:45 -0000 Hi Greg, Two issues being addressed in this draft apply equally to the link protection case when using [RFC4090]: 1. bypass assignment co-ordination and 2. sending Resv (from upstream PLR) over reverse bypass to avoid state timeout. For NNHOP bypass, this just corrects the asymmetry of co-routed LSP forward and reverse paths. FYI, this draft was originally published to MPLS WG but then moved to CCAMP WG. Not sure which is the right WG for this work. BTW, [RFC4873] does not state that one can not use [RFC4090] with GMPLS signalling. Pleas see [RFC4873] Section 2: " When [RFC4090] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the ASSOCIATION object defined in [RFC4872]. " This draft simply addresses the gaps when using [RFC4090] for GMPLS packet LSPs. Thanks, Rakesh On 2014-02-24 6:16 PM, "Gregory Mirsky" wrote: >Hi Rakesh, >I understand motivation of authors. Applicability of RFC 4090 to >bi-directional co-routed LSP was discussed as part of MPLS-TP >survivability framework (RFC 6372). I think that we've agreed that >applicability of RFC 4090 is limited to link protection and segment >protection should be recommended as providing more generic coverage. Have >authors considered bringing discussion and presenting the proposal to >MPLS WG? >Hope you wouldn't mind me adding MPLS WG to the discussion. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Monday, February 24, 2014 2:58 PM >To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia >Cc: CCAMP >Subject: Re: New Version Notification for >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt > >Hi Greg, > >Thank you for your comments. > >As you know, proposed draft addresses the two issues (state timeout and >bypass assignment) where FRR [RFC4090] is used for GMPLS packet tunnels. > >Motivations for using FRR here is that it is widely deployed in the >packet MPLS-TE networks today and can leverage all existing FRR detection >and restoration mechanisms and not have to deploy new protocol such as >PSC [RFC6378] for protection switchover co-ordination. > >Thanks, >Rakesh > > > > >On 2014-02-03 9:40 PM, "Gregory Mirsky" >wrote: > >>Hi Rakesh, et. al, >>since bi-directional co-routed LSP is MPLS-TP construct I believe that >>if local node protection is indeed required it should not use RFC 4090 >>signaling but use ASSOCIATION object as described in Section 2.3 RFC >>6689 and RFC 6378 MPLS-TP Linear Protection instead. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rakesh Gandhi >>(rgandhi) >>Sent: Monday, February 03, 2014 5:52 AM >>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike >>Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Zafar Ali (zali); >>Mike Taillon (mtaillon); Tarek Saad (tsaad); Frederic JOUNAY; Manav >>Bhatia >>Cc: CCAMP >>Subject: Re: [CCAMP] New Version Notification for >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >> >>Hi WG, >> >>New revision of the published draft contains following updates: >> >>- Remove unidirectional bypass LSP (as per previous comments) >>- Fix syntax of the BYPASS_ASSIGNMENT object. >>- Misc editorial cleanup. >> >> >>Please provide your review comments. >> >>Thanks, >>Rakesh >> >>=20 >> >>On 2014-02-03 8:44 AM, "internet-drafts@ietf.org" >> wrote: >> >>> >>>A new version of I-D, >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>>has been successfully submitted by Rakesh Gandhi and posted to the >>>IETF repository. >>> >>>Name: draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>>Revision: 03 >>>Title: Extensions to Resource Reservation Protocol For Fast Reroute of >>>Bidirectional Co-routed Traffic Engineering LSPs >>>Document date: 2014-02-03 >>>Group: Individual Submission >>>Pages: 12 >>>URL: =20 >>>http://www.ietf.org/internet-drafts/draft-tsaad-ccamp-rsvpte-bidir-lsp >>>- >>>fas >>>treroute-03.txt >>>Status: =20 >>>https://datatracker.ietf.org/doc/draft-tsaad-ccamp-rsvpte-bidir-lsp-fa >>>s >>>tre >>>route/ >>>Htmlized: =20 >>>http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastrero >>>u >>>te- >>>03 >>>Diff: =20 >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-tsaad-ccamp-rsvpte-bidir-lsp-fa >>>s >>>tre >>>route-03 >>> >>>Abstract: >>> This document defines Resource Reservation Protocol - Traffic >>> Engineering (RSVP-TE) signaling extensions to support Fast Reroute >>> (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. These >>> extensions enable the re-direction of bidirectional traffic and >>> signaling onto bypass tunnels that ensure co-routedness of data and >>> signaling paths in the forward and reverse directions after FRR. In >>> addition, the RSVP-TE signaling extensions allow the coordination of >>> bypass tunnel assignment protecting a common facility in both forward >>> and reverse directions prior to or post failure occurrence. >>> >>> >>> =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. >>> >>>The IETF Secretariat >>> >> >>_______________________________________________ >>CCAMP mailing list >>CCAMP@ietf.org >>https://www.ietf.org/mailman/listinfo/ccamp > From nobody Mon Feb 24 16:05:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DAE1A0367; Mon, 24 Feb 2014 16:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 YYPWG4IdKUZW; Mon, 24 Feb 2014 16:05:11 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4841A0353; Mon, 24 Feb 2014 16:05:11 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-ed-530bde367b56 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A6.14.11484.63EDB035; Tue, 25 Feb 2014 01:05:10 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 19:05:08 -0500 From: Gregory Mirsky To: "Rakesh Gandhi (rgandhi)" , Lizhong Jin , Frederic Jounay , "Tarek Saad (tsaad)" , "Mike Taillon (mtaillon)" , "Zafar Ali (zali)" , Manav Bhatia , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt Thread-Index: AQHPIOaJqiIMOAEGrkS5EKB7Vxg2IpqjnT0AgADCvJCAINagAP//8aFggAAehID//+/34A== Date: Tue, 25 Feb 2014 00:05:08 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B771FB6@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B771F3F@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPrK7ZPe5gg2Nn1SyezLnBYnF8+gQW ixWnnzFbzLl3j9Xi1tKVrBZblxxnspja1MFm8enETyaL1zu+sjtwerQ+28vqMeX3RlaPnbPu snssWfKTyePGVsUA1igum5TUnMyy1CJ9uwSujG+3TzAVTDeuWP/oL1sD4xKtLkZODgkBE4nj 59ezQdhiEhfugdhcHEICRxglOp+uY4FwljNKbO97xAxSxSZgJPFiYw87SEJE4DqTxL4zu5lA EswCUhJ3b3UxgtjCAokS/TfOsoLYIgJJEgt//2eHsMMkPs/5BjSVg4NFQFVi40ewmbwCvhL/ J0wGKxcSKJJY8fUM2EWcAvoSz65vAIszAl33/dQaqFXiEreezGeCuFpAYsme88wQtqjEy8f/ WCFsRYl9/dPZIep1JBbs/sQGYWtLLFv4GmqvoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKK kaO0OLUsN93IcBMjMBKPSbA57mBc8MnyEKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWlOanF hxiZODilGhjnrsmaZyf2eMen0MNd6spNbUzXHmRPXt5l6WyxvqY7XStt688e848BgVuPNbj5 XN+5vDFfSmXv4YkBMqqvywxX2ndZ/0tzmuocfnF6o1JrZmdXmlv6yUCP+xw+sfL+tYta40wj f7krfN54VJE3Rv8eb8vPCX9y9PmvrGm4+m3HFCOWrq7E+0osxRmJhlrMRcWJAGqpAr6SAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/W7dMaYZl3QPTxXE5DpF_e6pCnrU Cc: CCAMP Subject: Re: [mpls] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.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, 25 Feb 2014 00:05:14 -0000 Hi Rakesh, for the NNHOP bypass you'll not have truly local protection. One would eith= er have to monitor segment between Upstream and Downstream PLRs or use some= sort of PSC between the two. In any of these cases, Segment protection bas= ed on RFC 6378 offers the solution.=20 Regards, Greg -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]=20 Sent: Monday, February 24, 2014 3:55 PM To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike = Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org Cc: CCAMP Subject: Re: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-ls= p-fastreroute-03.txt Hi Greg, Two issues being addressed in this draft apply equally to the link protecti= on case when using [RFC4090]: 1. bypass assignment co-ordination and 2. sending Resv (from upstream PLR) over reverse bypass to avoid state time= out. For NNHOP bypass, this just corrects the asymmetry of co-routed LSP forward= and reverse paths. FYI, this draft was originally published to MPLS WG but then moved to CCAMP= WG. Not sure which is the right WG for this work. BTW, [RFC4873] does not state that one can not use [RFC4090] with GMPLS sig= nalling. Pleas see [RFC4873] Section 2: " When [RFC4090] isn't being used, the association between segment recovery L= SPs with other LSPs is indicated using the ASSOCIATION object defined in [= RFC4872]. " This draft simply addresses the gaps when using [RFC4090] for GMPLS packet = LSPs. Thanks, Rakesh On 2014-02-24 6:16 PM, "Gregory Mirsky" wrote: >Hi Rakesh, >I understand motivation of authors. Applicability of RFC 4090 to=20 >bi-directional co-routed LSP was discussed as part of MPLS-TP=20 >survivability framework (RFC 6372). I think that we've agreed that=20 >applicability of RFC 4090 is limited to link protection and segment=20 >protection should be recommended as providing more generic coverage.=20 >Have authors considered bringing discussion and presenting the proposal=20 >to MPLS WG? >Hope you wouldn't mind me adding MPLS WG to the discussion. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Monday, February 24, 2014 2:58 PM >To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad);=20 >Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia >Cc: CCAMP >Subject: Re: New Version Notification for=20 >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt > >Hi Greg, > >Thank you for your comments. > >As you know, proposed draft addresses the two issues (state timeout and=20 >bypass assignment) where FRR [RFC4090] is used for GMPLS packet tunnels. > >Motivations for using FRR here is that it is widely deployed in the=20 >packet MPLS-TE networks today and can leverage all existing FRR=20 >detection and restoration mechanisms and not have to deploy new=20 >protocol such as PSC [RFC6378] for protection switchover co-ordination. > >Thanks, >Rakesh > > > > >On 2014-02-03 9:40 PM, "Gregory Mirsky" >wrote: > >>Hi Rakesh, et. al, >>since bi-directional co-routed LSP is MPLS-TP construct I believe that=20 >>if local node protection is indeed required it should not use RFC 4090=20 >>signaling but use ASSOCIATION object as described in Section 2.3 RFC >>6689 and RFC 6378 MPLS-TP Linear Protection instead. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rakesh Gandhi >>(rgandhi) >>Sent: Monday, February 03, 2014 5:52 AM >>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad);=20 >>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Zafar Ali=20 >>(zali); Mike Taillon (mtaillon); Tarek Saad (tsaad); Frederic JOUNAY;=20 >>Manav Bhatia >>Cc: CCAMP >>Subject: Re: [CCAMP] New Version Notification for=20 >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >> >>Hi WG, >> >>New revision of the published draft contains following updates: >> >>- Remove unidirectional bypass LSP (as per previous comments) >>- Fix syntax of the BYPASS_ASSIGNMENT object. >>- Misc editorial cleanup. >> >> >>Please provide your review comments. >> >>Thanks, >>Rakesh >> >>=20 >> >>On 2014-02-03 8:44 AM, "internet-drafts@ietf.org" >> wrote: >> >>> >>>A new version of I-D, >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>>has been successfully submitted by Rakesh Gandhi and posted to the=20 >>>IETF repository. >>> >>>Name: draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>>Revision: 03 >>>Title: Extensions to Resource Reservation Protocol For Fast Reroute of >>>Bidirectional Co-routed Traffic Engineering LSPs >>>Document date: 2014-02-03 >>>Group: Individual Submission >>>Pages: 12 >>>URL: =20 >>>http://www.ietf.org/internet-drafts/draft-tsaad-ccamp-rsvpte-bidir-ls >>>p >>>- >>>fas >>>treroute-03.txt >>>Status: =20 >>>https://datatracker.ietf.org/doc/draft-tsaad-ccamp-rsvpte-bidir-lsp-f >>>a >>>s >>>tre >>>route/ >>>Htmlized: =20 >>>http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastrer >>>o >>>u >>>te- >>>03 >>>Diff: =20 >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-tsaad-ccamp-rsvpte-bidir-lsp-f >>>a >>>s >>>tre >>>route-03 >>> >>>Abstract: >>> This document defines Resource Reservation Protocol - Traffic >>> Engineering (RSVP-TE) signaling extensions to support Fast Reroute >>> (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. These >>> extensions enable the re-direction of bidirectional traffic and >>> signaling onto bypass tunnels that ensure co-routedness of data and >>> signaling paths in the forward and reverse directions after FRR. In >>> addition, the RSVP-TE signaling extensions allow the coordination of >>> bypass tunnel assignment protecting a common facility in both forward >>> and reverse directions prior to or post failure occurrence. >>> >>> >>> =20 >>> =20 >>> >>> >>>Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >> >>_______________________________________________ >>CCAMP mailing list >>CCAMP@ietf.org >>https://www.ietf.org/mailman/listinfo/ccamp > From nobody Mon Feb 24 16:34: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 78B871A0238; Mon, 24 Feb 2014 16:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 Zvt8ETdDWGfY; Mon, 24 Feb 2014 16:34:09 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE341A0200; Mon, 24 Feb 2014 16:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6944; q=dns/txt; s=iport; t=1393288449; x=1394498049; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=I+FVRZJgXEwPh3IWpClGqZRWGAkyZMPJkKVIa9Z8bB4=; b=OyeZjbME3Wdsj7CpeLOoz+6uHaHqd3RYr77CsUMQfYv2IOkTpzPFYOkX 9SsaAzGhMwxvwQKxfr67uoqG0uQ/TywTjmnWlfJt0eQrZOw7egdF8T6vl 3TqSKQui9SDnTbIyFKvUWQr/t636Ix3xGTXMdbg7wjxsMsgeqZAJo5xMJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusaAFTkC1OtJXG9/2dsb2JhbABZgWwEAYEVO1EGwTKBGhZ0giUBAQEEAQEBNzQJAgwGAQgRBAEBAR4JLgsUCQgCBAENBQkSh2oIBcYeF44MWAcGhDIEmDSBMpB1gW+BPoFoQg X-IronPort-AV: E=Sophos;i="4.97,537,1389744000"; d="scan'208";a="306316023" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 25 Feb 2014 00:34:08 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1P0Y8wZ024365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 00:34:08 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.22]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 18:34:08 -0600 From: "Rakesh Gandhi (rgandhi)" To: Gregory Mirsky , Lizhong Jin , Frederic Jounay , "Tarek Saad (tsaad)" , "Mike Taillon (mtaillon)" , "Zafar Ali (zali)" , Manav Bhatia , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt Thread-Index: AQHPIOaJqiIMOAEGrkS5EKB7Vxg2IpqjnT0AgADCvJCAINagAP//8aFggAAehID//+/34IAAGtSA Date: Tue, 25 Feb 2014 00:34:07 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B771FB6@eusaamb103.ericsson.se> 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: [10.86.246.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <8029BDB07C991241A32A17C3579C0C36@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zlLpLj7I65U5X-Q1i3DZQOvTHfo Cc: CCAMP Subject: Re: [mpls] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.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, 25 Feb 2014 00:34:12 -0000 Hi Gert, Not sure why IETF would abondan widely deployed protocol [RFC4090] and associated technology for bidirectional Packet LSPs. I like to hear comments from the WGs. Thanks, Rakesh On 2014-02-24 7:05 PM, "Gregory Mirsky" wrote: >Hi Rakesh, >for the NNHOP bypass you'll not have truly local protection. One would >either have to monitor segment between Upstream and Downstream PLRs or >use some sort of PSC between the two. In any of these cases, Segment >protection based on RFC 6378 offers the solution. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Monday, February 24, 2014 3:55 PM >To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org >Cc: CCAMP >Subject: Re: New Version Notification for >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt > >Hi Greg, > >Two issues being addressed in this draft apply equally to the link >protection case when using [RFC4090]: > >1. bypass assignment co-ordination and >2. sending Resv (from upstream PLR) over reverse bypass to avoid state >timeout. > >For NNHOP bypass, this just corrects the asymmetry of co-routed LSP >forward and reverse paths. > >FYI, this draft was originally published to MPLS WG but then moved to >CCAMP WG. Not sure which is the right WG for this work. > >BTW, [RFC4873] does not state that one can not use [RFC4090] with GMPLS >signalling. Pleas see [RFC4873] Section 2: >" >When [RFC4090] isn't being used, the association between segment recovery >LSPs with other LSPs is indicated using the ASSOCIATION object defined >in [RFC4872]. " > > >This draft simply addresses the gaps when using [RFC4090] for GMPLS >packet LSPs. > >Thanks, >Rakesh > > > >On 2014-02-24 6:16 PM, "Gregory Mirsky" >wrote: > >>Hi Rakesh, >>I understand motivation of authors. Applicability of RFC 4090 to >>bi-directional co-routed LSP was discussed as part of MPLS-TP >>survivability framework (RFC 6372). I think that we've agreed that >>applicability of RFC 4090 is limited to link protection and segment >>protection should be recommended as providing more generic coverage. >>Have authors considered bringing discussion and presenting the proposal >>to MPLS WG? >>Hope you wouldn't mind me adding MPLS WG to the discussion. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >>Sent: Monday, February 24, 2014 2:58 PM >>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia >>Cc: CCAMP >>Subject: Re: New Version Notification for >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >> >>Hi Greg, >> >>Thank you for your comments. >> >>As you know, proposed draft addresses the two issues (state timeout and >>bypass assignment) where FRR [RFC4090] is used for GMPLS packet tunnels. >> >>Motivations for using FRR here is that it is widely deployed in the >>packet MPLS-TE networks today and can leverage all existing FRR >>detection and restoration mechanisms and not have to deploy new >>protocol such as PSC [RFC6378] for protection switchover co-ordination. >> >>Thanks, >>Rakesh >> >> >> >> >>On 2014-02-03 9:40 PM, "Gregory Mirsky" >>wrote: >> >>>Hi Rakesh, et. al, >>>since bi-directional co-routed LSP is MPLS-TP construct I believe that >>>if local node protection is indeed required it should not use RFC 4090 >>>signaling but use ASSOCIATION object as described in Section 2.3 RFC >>>6689 and RFC 6378 MPLS-TP Linear Protection instead. >>> >>> Regards, >>> Greg >>> >>>-----Original Message----- >>>From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rakesh Gandhi >>>(rgandhi) >>>Sent: Monday, February 03, 2014 5:52 AM >>>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Zafar Ali >>>(zali); Mike Taillon (mtaillon); Tarek Saad (tsaad); Frederic JOUNAY; >>>Manav Bhatia >>>Cc: CCAMP >>>Subject: Re: [CCAMP] New Version Notification for >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>> >>>Hi WG, >>> >>>New revision of the published draft contains following updates: >>> >>>- Remove unidirectional bypass LSP (as per previous comments) >>>- Fix syntax of the BYPASS_ASSIGNMENT object. >>>- Misc editorial cleanup. >>> >>> >>>Please provide your review comments. >>> >>>Thanks, >>>Rakesh >>> >>>=20 >>> >>>On 2014-02-03 8:44 AM, "internet-drafts@ietf.org" >>> wrote: >>> >>>> >>>>A new version of I-D, >>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>>>has been successfully submitted by Rakesh Gandhi and posted to the >>>>IETF repository. >>>> >>>>Name: draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>>>Revision: 03 >>>>Title: Extensions to Resource Reservation Protocol For Fast Reroute of >>>>Bidirectional Co-routed Traffic Engineering LSPs >>>>Document date: 2014-02-03 >>>>Group: Individual Submission >>>>Pages: 12 >>>>URL: =20 >>>>http://www.ietf.org/internet-drafts/draft-tsaad-ccamp-rsvpte-bidir-ls >>>>p >>>>- >>>>fas >>>>treroute-03.txt >>>>Status: =20 >>>>https://datatracker.ietf.org/doc/draft-tsaad-ccamp-rsvpte-bidir-lsp-f >>>>a >>>>s >>>>tre >>>>route/ >>>>Htmlized: =20 >>>>http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastrer >>>>o >>>>u >>>>te- >>>>03 >>>>Diff: =20 >>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-tsaad-ccamp-rsvpte-bidir-lsp-f >>>>a >>>>s >>>>tre >>>>route-03 >>>> >>>>Abstract: >>>> This document defines Resource Reservation Protocol - Traffic >>>> Engineering (RSVP-TE) signaling extensions to support Fast Reroute >>>> (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. >>>>These >>>> extensions enable the re-direction of bidirectional traffic and >>>> signaling onto bypass tunnels that ensure co-routedness of data and >>>> signaling paths in the forward and reverse directions after FRR. In >>>> addition, the RSVP-TE signaling extensions allow the coordination of >>>> bypass tunnel assignment protecting a common facility in both >>>>forward >>>> and reverse directions prior to or post failure occurrence. >>>> >>>> >>>> =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. >>>> >>>>The IETF Secretariat >>>> >>> >>>_______________________________________________ >>>CCAMP mailing list >>>CCAMP@ietf.org >>>https://www.ietf.org/mailman/listinfo/ccamp >> > From nobody Mon Feb 24 17:32: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 777A81A0380; Mon, 24 Feb 2014 17:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oLQSb9T-nhZk; Mon, 24 Feb 2014 17:32:40 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 938191A0369; Mon, 24 Feb 2014 17:32:40 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-4d-530bf2b0001f Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 70.D5.11484.0B2FB035; Tue, 25 Feb 2014 02:32:33 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 20:32:31 -0500 From: Gregory Mirsky To: "Rakesh Gandhi (rgandhi)" , Lizhong Jin , Frederic Jounay , "Tarek Saad (tsaad)" , "Mike Taillon (mtaillon)" , "Zafar Ali (zali)" , Manav Bhatia , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt Thread-Index: AQHPIOaJqiIMOAEGrkS5EKB7Vxg2IpqjnT0AgADCvJCAINagAP//8aFggAAehID//+/34IAAGtSA///+skA= Date: Tue, 25 Feb 2014 01:32:31 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B772054@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B771FB6@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B772054eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyuXRPgu7GT9zBBttvsVg8mXODxeL49Aks FitOP2O2mHPvHqvFraUrWS22LjnOZDG1qYPN4tOJn0wWr3d8ZXfg9Gh9tpfVY8rvjaweO2fd ZfdYsuQnk8eNrYoBrFFcNimpOZllqUX6dglcGZs+7mcuuLKZseLyr/AGxpdzGLsYOTkkBEwk Ns85zQphi0lcuLeerYuRi0NI4AijxPrzc5khnOWMEt8ftzKBVLEJGEm82NjDDpIQEbjOJLHv zG6wBLOAlMTdW11gY4UFEiX6b5wFGysikCSx8Pd/dhh77pTVQDYHB4uAqsSdudkgJq+Ar8Tn n14gppBAkcSc2WDFnAL6EodPPmYDsRmBbvt+ag3UInGJW0/mM0HcLCCxZM95ZghbVOLl439Q vyhK7Oufzg5Rny9x/uBJsDm8AoISJ2c+YZnAKDoLyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1 M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQLj9pgEm+MOxgWfLA8xSnOwKInzfnnrHCQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBMdp/kdGX0kI/u4bk8opTpvaxbL69Cz/+KXB8o/96ldeu JfJpqx4Xb9K5x6rwUFNMb8ryVQav2y2d+iO641+WCQR9q1108vRNjR3cU068KdusuvDjhod7 IpskVGMj9abHHvhUfWjlm63MH1o0HyxukS/9+2z3trhPSoVaexuULHlXJ/aHWq9nUmIpzkg0 1GIuKk4EAGIPwpOpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eDe1VXdXEbonNga-Orc__Aqx1Uw Cc: CCAMP Subject: Re: [mpls] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.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, 25 Feb 2014 01:32:44 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B772054eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rakesh, I don't see this as "abandon" RFC 4090 but rather clarify its applicability= for bi-directional co-routed LSP case. More comments from both WGs certainly are most welcome and appreciated. Regards, Greg -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Monday, February 24, 2014 4:34 PM To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike = Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org Cc: CCAMP Subject: Re: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-ls= p-fastreroute-03.txt Hi Gert, Not sure why IETF would abondan widely deployed protocol [RFC4090] and asso= ciated technology for bidirectional Packet LSPs. I like to hear comments fr= om the WGs. Thanks, Rakesh On 2014-02-24 7:05 PM, "Gregory Mirsky" > wrote: >Hi Rakesh, >for the NNHOP bypass you'll not have truly local protection. One would >either have to monitor segment between Upstream and Downstream PLRs or >use some sort of PSC between the two. In any of these cases, Segment >protection based on RFC 6378 offers the solution. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Monday, February 24, 2014 3:55 PM >To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org >Cc: CCAMP >Subject: Re: New Version Notification for >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt > >Hi Greg, > >Two issues being addressed in this draft apply equally to the link >protection case when using [RFC4090]: > >1. bypass assignment co-ordination and >2. sending Resv (from upstream PLR) over reverse bypass to avoid state >timeout. > >For NNHOP bypass, this just corrects the asymmetry of co-routed LSP >forward and reverse paths. > >FYI, this draft was originally published to MPLS WG but then moved to >CCAMP WG. Not sure which is the right WG for this work. > >BTW, [RFC4873] does not state that one can not use [RFC4090] with GMPLS >signalling. Pleas see [RFC4873] Section 2: >" >When [RFC4090] isn't being used, the association between segment >recovery LSPs with other LSPs is indicated using the ASSOCIATION >object defined in [RFC4872]. " > > >This draft simply addresses the gaps when using [RFC4090] for GMPLS >packet LSPs. > >Thanks, >Rakesh > > > >On 2014-02-24 6:16 PM, "Gregory Mirsky" > >wrote: > >>Hi Rakesh, >>I understand motivation of authors. Applicability of RFC 4090 to >>bi-directional co-routed LSP was discussed as part of MPLS-TP >>survivability framework (RFC 6372). I think that we've agreed that >>applicability of RFC 4090 is limited to link protection and segment >>protection should be recommended as providing more generic coverage. >>Have authors considered bringing discussion and presenting the >>proposal to MPLS WG? >>Hope you wouldn't mind me adding MPLS WG to the discussion. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >>Sent: Monday, February 24, 2014 2:58 PM >>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia >>Cc: CCAMP >>Subject: Re: New Version Notification for >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >> >>Hi Greg, >> >>Thank you for your comments. >> >>As you know, proposed draft addresses the two issues (state timeout >>and bypass assignment) where FRR [RFC4090] is used for GMPLS packet tunne= ls. >> >>Motivations for using FRR here is that it is widely deployed in the >>packet MPLS-TE networks today and can leverage all existing FRR >>detection and restoration mechanisms and not have to deploy new >>protocol such as PSC [RFC6378] for protection switchover co-ordination. >> >>Thanks, >>Rakesh >> >> >> >> >>On 2014-02-03 9:40 PM, "Gregory Mirsky" > >>wrote: >> >>>Hi Rakesh, et. al, >>>since bi-directional co-routed LSP is MPLS-TP construct I believe >>>that if local node protection is indeed required it should not use >>>RFC 4090 signaling but use ASSOCIATION object as described in Section >>>2.3 RFC >>>6689 and RFC 6378 MPLS-TP Linear Protection instead. >>> >>> Regards, >>> Greg >>> >>>-----Original Message----- >>>From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rakesh >>>Gandhi >>>(rgandhi) >>>Sent: Monday, February 03, 2014 5:52 AM >>>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Zafar Ali >>>(zali); Mike Taillon (mtaillon); Tarek Saad (tsaad); Frederic JOUNAY; >>>Manav Bhatia >>>Cc: CCAMP >>>Subject: Re: [CCAMP] New Version Notification for >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>> >>>Hi WG, >>> >>>New revision of the published draft contains following updates: >>> >>>- Remove unidirectional bypass LSP (as per previous comments) >>>- Fix syntax of the BYPASS_ASSIGNMENT object. >>>- Misc editorial cleanup. >>> >>> >>>Please provide your review comments. >>> >>>Thanks, >>>Rakesh >>> >>> >>> >>>On 2014-02-03 8:44 AM, "internet-drafts@ietf.org" >>>> wrote: >>> >>>> >>>>A new version of I-D, >>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>>>has been successfully submitted by Rakesh Gandhi and posted to the >>>>IETF repository. >>>> >>>>Name: draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>>>Revision: 03 >>>>Title: Extensions to Resource Reservation Protocol For Fas= t Reroute of >>>>Bidirectional Co-routed Traffic Engineering LSPs >>>>Document date: 2014-02-03 >>>>Group: Individual Submission >>>>Pages: 12 >>>>URL: >>>>http://www.ietf.org/internet-drafts/draft-tsaad-ccamp-rsvpte-bidir-l >>>>s >>>>p >>>>- >>>>fas >>>>treroute-03.txt >>>>Status: >>>>https://datatracker.ietf.org/doc/draft-tsaad-ccamp-rsvpte-bidir-lsp- >>>>f >>>>a >>>>s >>>>tre >>>>route/ >>>>Htmlized: >>>>http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastre >>>>r >>>>o >>>>u >>>>te- >>>>03 >>>>Diff: >>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-tsaad-ccamp-rsvpte-bidir-lsp- >>>>f >>>>a >>>>s >>>>tre >>>>route-03 >>>> >>>>Abstract: >>>> This document defines Resource Reservation Protocol - Traffic >>>> Engineering (RSVP-TE) signaling extensions to support Fast Reroute >>>> (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. >>>>These >>>> extensions enable the re-direction of bidirectional traffic and >>>> signaling onto bypass tunnels that ensure co-routedness of data and >>>> signaling paths in the forward and reverse directions after FRR. In >>>> addition, the RSVP-TE signaling extensions allow the coordination of >>>> bypass tunnel assignment protecting a common facility in both >>>>forward >>>> and reverse directions prior to or post failure occurrence. >>>> >>>> >>>> >>>> >>>> >>>> >>>>Please note that it may take a couple of minutes from the time of >>>>submission until the htmlized version and diff are available at >>>>tools.ietf.org. >>>> >>>>The IETF Secretariat >>>> >>> >>>_______________________________________________ >>>CCAMP mailing list >>>CCAMP@ietf.org >>>https://www.ietf.org/mailman/listinfo/ccamp >> > --_000_7347100B5761DC41A166AC17F22DF1121B772054eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rakesh,
I don't see this as "abandon" RFC 4090 but rather clarify it= s applicability for bi-directional co-routed LSP case.
More comments from both WGs certainly are most welcome and appreciated= .
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rakesh Gandhi (rgandhi) [mailto:= rgandhi@cisco.com]
Sent: Monday, February 24, 2014 4:34 PM
To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike = Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org
Cc: CCAMP
Subject: Re: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-ls= p-fastreroute-03.txt
 
Hi Gert,
 
Not sure why IETF would abondan widely deployed protocol [RFC4090] and= associated technology for bidirectional Packet LSPs. I like to hear commen= ts from the WGs.
 
Thanks,
Rakesh
 
 
On 2014-02-24 7:05 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
wrote:
 
>Hi Rakesh,
>for the NNHOP bypass you'll not have truly local protection. One w= ould
>either have to monitor segment between Upstream and Downstream PLR= s or
>use some sort of PSC between the two. In any of these cases, Segme= nt
>protection based on RFC 6378 offers the solution.
>
>       Regards,
>           =     Greg
>
>-----Original Message-----
>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
>Sent: Monday, February 24, 2014 3:55 PM
>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaa= d);
>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org
>Cc: CCAMP
>Subject: Re: New Version Notification for
>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>
>Hi Greg,
>
>Two issues being addressed in this draft apply equally to the link=
>protection case when using [RFC4090]:
>
>1. bypass assignment co-ordination and
>2. sending Resv (from upstream PLR) over reverse bypass to avoid s= tate
>timeout.
>
>For NNHOP bypass, this just corrects the asymmetry of co-routed LS= P
>forward and reverse paths.
>
>FYI, this draft was originally published to MPLS WG but then moved= to
>CCAMP WG. Not sure which is the right WG for this work.
>
>BTW, [RFC4873] does not state that one can not use [RFC4090] with = GMPLS
>signalling. Pleas see [RFC4873] Section 2:
>"
>When [RFC4090] isn't being used, the association between segment <= /div>
>recovery LSPs with other LSPs is indicated using the ASSOCIATION&n= bsp;
>object defined in [RFC4872]. "
>
>
>This draft simply addresses the gaps when using [RFC4090] for GMPL= S
>packet LSPs.
>
>Thanks,
>Rakesh
>
>
>
>On 2014-02-24 6:16 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
>wrote:
>
>>Hi Rakesh,
>>I understand motivation of authors. Applicability of RFC 4090 = to
>>bi-directional co-routed LSP was discussed as part of MPLS-TP =
>>survivability framework (RFC 6372). I think that we've agreed = that
>>applicability of RFC 4090 is limited to link protection and se= gment
>>protection should be recommended as providing more generic cov= erage.
>>Have authors considered bringing discussion and presenting the=
>>proposal to MPLS WG?
>>Hope you wouldn't mind me adding MPLS WG to the discussion.
>>
>>      Regards,
>>          &n= bsp;   Greg
>>
>>-----Original Message-----
>>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
>>Sent: Monday, February 24, 2014 2:58 PM
>>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (= tsaad);
>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia
>>Cc: CCAMP
>>Subject: Re: New Version Notification for
>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>>
>>Hi Greg,
>>
>>Thank you for your comments.
>>
>>As you know, proposed draft addresses the two issues (state ti= meout
>>and bypass assignment) where FRR [RFC4090] is used for GMPLS p= acket tunnels.
>>
>>Motivations for using FRR here is that it is widely deployed i= n the
>>packet MPLS-TE networks today and can leverage all existing FR= R
>>detection and restoration mechanisms and not have to deploy ne= w
>>protocol such as PSC [RFC6378] for protection switchover co-or= dination.
>>
>>Thanks,
>>Rakesh
>>
>>
>>
>>
>>On 2014-02-03 9:40 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>=
>>wrote:
>>
>>>Hi Rakesh, et. al,
>>>since bi-directional co-routed LSP is MPLS-TP construct I = believe
>>>that if local node protection is indeed required it should= not use
>>>RFC 4090 signaling but use ASSOCIATION object as described= in Section
>>>2.3 RFC
>>>6689 and RFC 6378 MPLS-TP Linear Protection instead.
>>>
>>>     Regards,
>>>         &nbs= p;   Greg
>>>
>>>-----Original Message-----
>>>From: CCAMP [mai= lto:ccamp-bounces@ietf.org] On Behalf Of Rakesh
>>>Gandhi
>>>(rgandhi)
>>>Sent: Monday, February 03, 2014 5:52 AM
>>>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad = (tsaad);
>>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Z= afar Ali
>>>(zali); Mike Taillon (mtaillon); Tarek Saad (tsaad); Frede= ric JOUNAY;
>>>Manav Bhatia
>>>Cc: CCAMP
>>>Subject: Re: [CCAMP] New Version Notification for
>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>>>
>>>Hi WG,
>>>
>>>New revision of the published draft contains following upd= ates:
>>>
>>>- Remove unidirectional bypass LSP (as per previous commen= ts)
>>>- Fix syntax of the BYPASS_ASSIGNMENT object.
>>>- Misc editorial cleanup.
>>>
>>>
>>>Please provide your review comments.
>>>
>>>Thanks,
>>>Rakesh
>>>
>>>
>>>
>>>On 2014-02-03 8:44 AM, "internet-drafts@ietf.org"
>>>
>>>>
>>>>A new version of I-D,
>>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt<= /div>
>>>>has been successfully submitted by Rakesh Gandhi and p= osted to the
>>>>IETF repository.
>>>>
>>>>Name:        &= nbsp;      draft-tsaad-ccamp-rsvpte-bidir-lsp-fast= reroute
>>>>Revision:   03
>>>>Title:        =       Extensions to Resource Reservation Protocol = For Fast Reroute of
>>>>Bidirectional Co-routed Traffic Engineering LSPs
>>>>Document date:      2014-02-0= 3
>>>>Group:        =       Individual Submission
>>>>Pages:        =       12
>>>>URL:        &n= bsp; 
>>>>s
>>>>p
>>>>-
>>>>fas
>>>>treroute-03.txt
>>>>Status:       
>>>>f
>>>>a
>>>>s
>>>>tre
>>>>route/
>>>>Htmlized:     
>>>>r
>>>>o
>>>>u
>>>>te-
>>>>03
>>>>Diff:        &= nbsp;
>>>>f
>>>>a
>>>>s
>>>>tre
>>>>route-03
>>>>
>>>>Abstract:
>>>>   This document defines Resource Reservatio= n Protocol - Traffic
>>>>   Engineering (RSVP-TE) signaling extension= s to support Fast Reroute
>>>>   (FRR) of bidirectional co-routed Traffic = Engineering (TE) LSPs.
>>>>These
>>>>   extensions enable the re-direction of bid= irectional traffic and
>>>>   signaling onto bypass tunnels that ensure= co-routedness of data and
>>>>   signaling paths in the forward and revers= e directions after FRR. In
>>>>   addition, the RSVP-TE signaling extension= s allow the coordination of
>>>>   bypass tunnel assignment protecting a com= mon facility in both
>>>>forward
>>>>   and reverse directions prior to or post f= ailure occurrence.
>>>>
>>>>
>>>>         =      
>>>>       
>>>>
>>>>
>>>>Please note that it may take a couple of minutes from = the time of
>>>>submission until the htmlized version and diff are ava= ilable at
>>>>tools.ietf.org.
>>>>
>>>>The IETF Secretariat
>>>>
>>>
>>>_______________________________________________
>>>CCAMP mailing list
>>
>
 
 
 --_000_7347100B5761DC41A166AC17F22DF1121B772054eusaamb103erics_-- From nobody Mon Feb 24 18:11:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF12E1A03A7; Mon, 24 Feb 2014 18:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 AYlWu6FblSWU; Mon, 24 Feb 2014 18:11:41 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AA8711A03C5; Mon, 24 Feb 2014 18:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26180; q=dns/txt; s=iport; t=1393294300; x=1394503900; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=YuKL1G7zS4wIWpYp0NI2kUqmFInaZVjBPG6BpetCIws=; b=gdqCFW9gQoo2Jt3x+kKuU9Vwhzam54rVTms+GW+Bai+8vq6N/fZcySF9 AgtlkHTTwJ580GqwaCJ4gQ6xh3d3TWx9HtT6bpEktSmIJcT9cD/OX05fL KFrG1tEKXpnjvv6IOiR3DBJoH5O/igPcY9SRP6DVux6hnJX+6UJTcBss7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEGAIT7C1OtJXG8/2dsb2JhbABZgkJEO1EGuGaIWIEfFnSCJQEBAQMBAQEBKkEJAgUHBgEIEQMBAQEBIAcoBgsUCQgCBAENBQkSh1YDCQgIBb9EDYZxF4xPgT1HDQQHBgOELwSWR4FtgTKLLoVHgW+BPoFoQg X-IronPort-AV: E=Sophos;i="4.97,538,1389744000"; d="scan'208,217";a="306062466" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 25 Feb 2014 02:11:38 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1P2Bc8t007298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 02:11:38 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.22]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 20:11:38 -0600 From: "Rakesh Gandhi (rgandhi)" To: Gregory Mirsky , Lizhong Jin , Frederic Jounay , "Tarek Saad (tsaad)" , "Mike Taillon (mtaillon)" , "Zafar Ali (zali)" , Manav Bhatia , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt Thread-Index: AQHPIOaJqiIMOAEGrkS5EKB7Vxg2IpqjnT0AgADCvJCAINagAP//8aFggAAehID//+/34IAAGtSA///+skAAA5FlAA== Date: Tue, 25 Feb 2014 02:11:37 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B772054@eusaamb103.ericsson.se> 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: [10.86.246.246] Content-Type: multipart/alternative; boundary="_000_CF3165E91CADArgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CrIxlAKbgTgP5rTvbMG5T3qCY0Y Cc: CCAMP Subject: Re: [mpls] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.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, 25 Feb 2014 02:11:45 -0000 --_000_CF3165E91CADArgandhiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Greg. From: Gregory Mirsky > Date: Monday, 24 February, 2014 8:32 PM To: Rakesh Gandhi >, "Lizhong c= om>" >, "frederic.jounay@or= ange.ch" >, "Tarek Saad (tsaad)" >, "=3DSMTP:mtaillon@cisco. com" >, Zafar Ali >, = "manav.bhatia@alcatel-lucent.com" <= manav.bhatia@alcatel-lucent.com>, "= mpls@ietf.org" > Cc: CCAMP > Subject: RE: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-ls= p-fastreroute-03.txt Hi Rakesh, I don't see this as "abandon" RFC 4090 but rather clarify its applicability= for bi-directional co-routed LSP case. More comments from both WGs certainly are most welcome and appreciated. Regards, Greg -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Monday, February 24, 2014 4:34 PM To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike = Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org Cc: CCAMP Subject: Re: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-ls= p-fastreroute-03.txt Hi Gert, Not sure why IETF would abondan widely deployed protocol [RFC4090] and asso= ciated technology for bidirectional Packet LSPs. I like to hear comments fr= om the WGs. Thanks, Rakesh On 2014-02-24 7:05 PM, "Gregory Mirsky" > wrote: >Hi Rakesh, >for the NNHOP bypass you'll not have truly local protection. One would >either have to monitor segment between Upstream and Downstream PLRs or >use some sort of PSC between the two. In any of these cases, Segment >protection based on RFC 6378 offers the solution. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Monday, February 24, 2014 3:55 PM >To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org >Cc: CCAMP >Subject: Re: New Version Notification for >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt > >Hi Greg, > >Two issues being addressed in this draft apply equally to the link >protection case when using [RFC4090]: > >1. bypass assignment co-ordination and >2. sending Resv (from upstream PLR) over reverse bypass to avoid state >timeout. > >For NNHOP bypass, this just corrects the asymmetry of co-routed LSP >forward and reverse paths. > >FYI, this draft was originally published to MPLS WG but then moved to >CCAMP WG. Not sure which is the right WG for this work. > >BTW, [RFC4873] does not state that one can not use [RFC4090] with GMPLS >signalling. Pleas see [RFC4873] Section 2: >" >When [RFC4090] isn't being used, the association between segment >recovery LSPs with other LSPs is indicated using the ASSOCIATION >object defined in [RFC4872]. " > > >This draft simply addresses the gaps when using [RFC4090] for GMPLS >packet LSPs. > >Thanks, >Rakesh > > > >On 2014-02-24 6:16 PM, "Gregory Mirsky" > >wrote: > >>Hi Rakesh, >>I understand motivation of authors. Applicability of RFC 4090 to >>bi-directional co-routed LSP was discussed as part of MPLS-TP >>survivability framework (RFC 6372). I think that we've agreed that >>applicability of RFC 4090 is limited to link protection and segment >>protection should be recommended as providing more generic coverage. >>Have authors considered bringing discussion and presenting the >>proposal to MPLS WG? >>Hope you wouldn't mind me adding MPLS WG to the discussion. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >>Sent: Monday, February 24, 2014 2:58 PM >>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia >>Cc: CCAMP >>Subject: Re: New Version Notification for >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >> >>Hi Greg, >> >>Thank you for your comments. >> >>As you know, proposed draft addresses the two issues (state timeout >>and bypass assignment) where FRR [RFC4090] is used for GMPLS packet tunne= ls. >> >>Motivations for using FRR here is that it is widely deployed in the >>packet MPLS-TE networks today and can leverage all existing FRR >>detection and restoration mechanisms and not have to deploy new >>protocol such as PSC [RFC6378] for protection switchover co-ordination. >> >>Thanks, >>Rakesh >> >> >> >> >>On 2014-02-03 9:40 PM, "Gregory Mirsky" > >>wrote: >> >>>Hi Rakesh, et. al, >>>since bi-directional co-routed LSP is MPLS-TP construct I believe >>>that if local node protection is indeed required it should not use >>>RFC 4090 signaling but use ASSOCIATION object as described in Section >>>2.3 RFC >>>6689 and RFC 6378 MPLS-TP Linear Protection instead. >>> >>> Regards, >>> Greg >>> >>>-----Original Message----- >>>From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rakesh >>>Gandhi >>>(rgandhi) >>>Sent: Monday, February 03, 2014 5:52 AM >>>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); >>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Zafar Ali >>>(zali); Mike Taillon (mtaillon); Tarek Saad (tsaad); Frederic JOUNAY; >>>Manav Bhatia >>>Cc: CCAMP >>>Subject: Re: [CCAMP] New Version Notification for >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>> >>>Hi WG, >>> >>>New revision of the published draft contains following updates: >>> >>>- Remove unidirectional bypass LSP (as per previous comments) >>>- Fix syntax of the BYPASS_ASSIGNMENT object. >>>- Misc editorial cleanup. >>> >>> >>>Please provide your review comments. >>> >>>Thanks, >>>Rakesh >>> >>> >>> >>>On 2014-02-03 8:44 AM, "internet-drafts@ietf.org" >>>> wrote: >>> >>>> >>>>A new version of I-D, >>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt >>>>has been successfully submitted by Rakesh Gandhi and posted to the >>>>IETF repository. >>>> >>>>Name: draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>>>Revision: 03 >>>>Title: Extensions to Resource Reservation Protocol For Fas= t Reroute of >>>>Bidirectional Co-routed Traffic Engineering LSPs >>>>Document date: 2014-02-03 >>>>Group: Individual Submission >>>>Pages: 12 >>>>URL: >>>>http://www.ietf.org/internet-drafts/draft-tsaad-ccamp-rsvpte-bidir-l >>>>s >>>>p >>>>- >>>>fas >>>>treroute-03.txt >>>>Status: >>>>https://datatracker.ietf.org/doc/draft-tsaad-ccamp-rsvpte-bidir-lsp- >>>>f >>>>a >>>>s >>>>tre >>>>route/ >>>>Htmlized: >>>>http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastre >>>>r >>>>o >>>>u >>>>te- >>>>03 >>>>Diff: >>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-tsaad-ccamp-rsvpte-bidir-lsp- >>>>f >>>>a >>>>s >>>>tre >>>>route-03 >>>> >>>>Abstract: >>>> This document defines Resource Reservation Protocol - Traffic >>>> Engineering (RSVP-TE) signaling extensions to support Fast Reroute >>>> (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. >>>>These >>>> extensions enable the re-direction of bidirectional traffic and >>>> signaling onto bypass tunnels that ensure co-routedness of data and >>>> signaling paths in the forward and reverse directions after FRR. In >>>> addition, the RSVP-TE signaling extensions allow the coordination of >>>> bypass tunnel assignment protecting a common facility in both >>>>forward >>>> and reverse directions prior to or post failure occurrence. >>>> >>>> >>>> >>>> >>>> >>>> >>>>Please note that it may take a couple of minutes from the time of >>>>submission until the htmlized version and diff are available at >>>>tools.ietf.org. >>>> >>>>The IETF Secretariat >>>> >>> >>>_______________________________________________ >>>CCAMP mailing list >>>CCAMP@ietf.org >>>https://www.ietf.org/mailman/listinfo/ccamp >> > --_000_CF3165E91CADArgandhiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <86618667E4302842993A58A47E31D1C7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Greg.

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Monday, 24 February, 2014 8:3= 2 PM
To: Rakesh Gandhi <rgandhi@cisco.com>, "Lizhong com>&qu= ot; <lizho.jin@gmail.com>,= "frederic.jounay@orange.= ch" <frederic.jounay@orange.ch= >, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "=3DSMTP:mtaillon@cisco. com" <<= a href=3D"mailto:mtaillon@cisco.com">mtaillon@cisco.com>, Zafar Ali = <zali@cisco.com>, "manav.bhatia@alca= tel-lucent.com" <manav.bhatia@alcatel-lucent.com>, "mpls@ietf.org" <mpls= @ietf.org>
Cc: CCAMP <ccamp@ietf.org>
Subject: RE: New Version Notificati= on for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt

Hi Rakesh,
I don't see this as "abandon" RFC 4090 but rather clarify it= s applicability for bi-directional co-routed LSP case.
More comments from both WGs certainly are most welcome and appreciated= .
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rakesh Gandhi (rgandhi) [mailto:= rgandhi@cisco.com]
Sent: Monday, February 24, 2014 4:34 PM
To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad); Mike = Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org
Cc: CCAMP
Subject: Re: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-ls= p-fastreroute-03.txt
 
Hi Gert,
 
Not sure why IETF would abondan widely deployed protocol [RFC4090] and= associated technology for bidirectional Packet LSPs. I like to hear commen= ts from the WGs.
 
Thanks,
Rakesh
 
 
On 2014-02-24 7:05 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
wrote:
 
>Hi Rakesh,
>for the NNHOP bypass you'll not have truly local protection. One w= ould
>either have to monitor segment between Upstream and Downstream PLR= s or
>use some sort of PSC between the two. In any of these cases, Segme= nt
>protection based on RFC 6378 offers the solution.
>
>       Regards,
>           =     Greg
>
>-----Original Message-----
>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
>Sent: Monday, February 24, 2014 3:55 PM
>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaa= d);
>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; mpls@ietf.org
>Cc: CCAMP
>Subject: Re: New Version Notification for
>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>
>Hi Greg,
>
>Two issues being addressed in this draft apply equally to the link=
>protection case when using [RFC4090]:
>
>1. bypass assignment co-ordination and
>2. sending Resv (from upstream PLR) over reverse bypass to avoid s= tate
>timeout.
>
>For NNHOP bypass, this just corrects the asymmetry of co-routed LS= P
>forward and reverse paths.
>
>FYI, this draft was originally published to MPLS WG but then moved= to
>CCAMP WG. Not sure which is the right WG for this work.
>
>BTW, [RFC4873] does not state that one can not use [RFC4090] with = GMPLS
>signalling. Pleas see [RFC4873] Section 2:
>"
>When [RFC4090] isn't being used, the association between segment <= /div>
>recovery LSPs with other LSPs is indicated using the ASSOCIATION&n= bsp;
>object defined in [RFC4872]. "
>
>
>This draft simply addresses the gaps when using [RFC4090] for GMPL= S
>packet LSPs.
>
>Thanks,
>Rakesh
>
>
>
>On 2014-02-24 6:16 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
>wrote:
>
>>Hi Rakesh,
>>I understand motivation of authors. Applicability of RFC 4090 = to
>>bi-directional co-routed LSP was discussed as part of MPLS-TP =
>>survivability framework (RFC 6372). I think that we've agreed = that
>>applicability of RFC 4090 is limited to link protection and se= gment
>>protection should be recommended as providing more generic cov= erage.
>>Have authors considered bringing discussion and presenting the=
>>proposal to MPLS WG?
>>Hope you wouldn't mind me adding MPLS WG to the discussion.
>>
>>      Regards,
>>          &n= bsp;   Greg
>>
>>-----Original Message-----
>>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
>>Sent: Monday, February 24, 2014 2:58 PM
>>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (= tsaad);
>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia
>>Cc: CCAMP
>>Subject: Re: New Version Notification for
>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>>
>>Hi Greg,
>>
>>Thank you for your comments.
>>
>>As you know, proposed draft addresses the two issues (state ti= meout
>>and bypass assignment) where FRR [RFC4090] is used for GMPLS p= acket tunnels.
>>
>>Motivations for using FRR here is that it is widely deployed i= n the
>>packet MPLS-TE networks today and can leverage all existing FR= R
>>detection and restoration mechanisms and not have to deploy ne= w
>>protocol such as PSC [RFC6378] for protection switchover co-or= dination.
>>
>>Thanks,
>>Rakesh
>>
>>
>>
>>
>>On 2014-02-03 9:40 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>=
>>wrote:
>>
>>>Hi Rakesh, et. al,
>>>since bi-directional co-routed LSP is MPLS-TP construct I = believe
>>>that if local node protection is indeed required it should= not use
>>>RFC 4090 signaling but use ASSOCIATION object as described= in Section
>>>2.3 RFC
>>>6689 and RFC 6378 MPLS-TP Linear Protection instead.
>>>
>>>     Regards,
>>>         &nbs= p;   Greg
>>>
>>>-----Original Message-----
>>>From: CCAMP [mai= lto:ccamp-bounces@ietf.org] On Behalf Of Rakesh
>>>Gandhi
>>>(rgandhi)
>>>Sent: Monday, February 03, 2014 5:52 AM
>>>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad = (tsaad);
>>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Z= afar Ali
>>>(zali); Mike Taillon (mtaillon); Tarek Saad (tsaad); Frede= ric JOUNAY;
>>>Manav Bhatia
>>>Cc: CCAMP
>>>Subject: Re: [CCAMP] New Version Notification for
>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>>>
>>>Hi WG,
>>>
>>>New revision of the published draft contains following upd= ates:
>>>
>>>- Remove unidirectional bypass LSP (as per previous commen= ts)
>>>- Fix syntax of the BYPASS_ASSIGNMENT object.
>>>- Misc editorial cleanup.
>>>
>>>
>>>Please provide your review comments.
>>>
>>>Thanks,
>>>Rakesh
>>>
>>>
>>>
>>>On 2014-02-03 8:44 AM, "internet-drafts@ietf.org"
>>>
>>>>
>>>>A new version of I-D,
>>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt<= /div>
>>>>has been successfully submitted by Rakesh Gandhi and p= osted to the
>>>>IETF repository.
>>>>
>>>>Name:        &= nbsp;      draft-tsaad-ccamp-rsvpte-bidir-lsp-fast= reroute
>>>>Revision:   03
>>>>Title:        =       Extensions to Resource Reservation Protocol = For Fast Reroute of
>>>>Bidirectional Co-routed Traffic Engineering LSPs
>>>>Document date:      2014-02-0= 3
>>>>Group:        =       Individual Submission
>>>>Pages:        =       12
>>>>URL:        &n= bsp; 
>>>>s
>>>>p
>>>>-
>>>>fas
>>>>treroute-03.txt
>>>>Status:       
>>>>f
>>>>a
>>>>s
>>>>tre
>>>>route/
>>>>Htmlized:     
>>>>r
>>>>o
>>>>u
>>>>te-
>>>>03
>>>>Diff:        &= nbsp;
>>>>f
>>>>a
>>>>s
>>>>tre
>>>>route-03
>>>>
>>>>Abstract:
>>>>   This document defines Resource Reservatio= n Protocol - Traffic
>>>>   Engineering (RSVP-TE) signaling extension= s to support Fast Reroute
>>>>   (FRR) of bidirectional co-routed Traffic = Engineering (TE) LSPs.
>>>>These
>>>>   extensions enable the re-direction of bid= irectional traffic and
>>>>   signaling onto bypass tunnels that ensure= co-routedness of data and
>>>>   signaling paths in the forward and revers= e directions after FRR. In
>>>>   addition, the RSVP-TE signaling extension= s allow the coordination of
>>>>   bypass tunnel assignment protecting a com= mon facility in both
>>>>forward
>>>>   and reverse directions prior to or post f= ailure occurrence.
>>>>
>>>>
>>>>         =      
>>>>       
>>>>
>>>>
>>>>Please note that it may take a couple of minutes from = the time of
>>>>submission until the htmlized version and diff are ava= ilable at
>>>>tools.ietf.org.
>>>>
>>>>The IETF Secretariat
>>>>
>>>
>>>_______________________________________________
>>>CCAMP mailing list
>>
>
 
 
--_000_CF3165E91CADArgandhiciscocom_-- From nobody Mon Feb 24 22:52:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627541A032A for ; Mon, 24 Feb 2014 22:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 16WSJYc0DKOx for ; Mon, 24 Feb 2014 22:52:45 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 031451A0328 for ; Mon, 24 Feb 2014 22:52:44 -0800 (PST) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 25 Feb 2014 15:52:42 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Tue, 25 Feb 2014 15:52:39 +0900 From: "Ryoo, Jeong-dong" To: "mpls@ietf.org" Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-tp-psc-itu-03.txt Thread-Index: AQHPMa/t3u3CVHOZ7Eq0JzScLF+0FprFiGii Date: Tue, 25 Feb 2014 06:52:38 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA9E6@SMTP2.etri.info> References: <20140224222842.6878.2186.idtracker@ietfa.amsl.com> In-Reply-To: <20140224222842.6878.2186.idtracker@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA9E6SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gdkRXjPDKj6gwKpGnOJXrhsj7Aw Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-tp-psc-itu-03.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, 25 Feb 2014 06:52:48 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA9E6SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZWFyIE1QTFMgV0cuDQoNCkEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LWlldGYtbXBscy10 cC1wc2MtaXR1IGRyYWZ0IGhhcyBiZWVuIHBvc3RlZC4NCg0KVGhpcyB2ZXJzaW9uIGFkZHJlc3Nl cyB0aGUgY29tbWVudHMgcmFpc2VkIGR1cmluZyB0aGUgSUVURiBMQy4NCg0KVGhlIGNoYW5nZXMg bWFkZSBpbiB0aGlzIHZlcnNpb24gaW5jbHVkZSB0aGUgZm9sbG93aW5nczoNCg0KLSAgICAgICBC ZWhhdmlvciBvZiBlcXVhbCBwcmlvcml0eSByZXF1ZXN0cyAoTVMgYW5kIFNEKSBpcyByZXdyaXR0 ZW4gZm9yIGJldHRlciBjbGFyaXR5IChidXQgdGhlIGJlaGF2aW9yIGl0c2VsZiBkb2VzIG5vdCBj aGFuZ2UgZnJvbSBpdHMgb3JpZ2luYWwgaW50ZW50aW9uKS4NCg0KLSAgICAgICDigJxTZWN1cml0 eSBDb25zaWRlcmF0aW9uc+KAnSBzZWN0aW9uIGhhcyBiZWVuIGNoYW5nZWQgdG8gcmVmbGVjdCBz ZWN1cml0eSByZXZpZXcgY29tbWVudHMuDQoNCi0gICAgICAg4oCcSUFOQSBDb25zaWRlcmF0aW9u c+KAnSBzZWN0aW9uIGhhcyBiZWVuIGNoYW5nZWQgdG8gcmVmbGVjdCBJQU5BIHJldmlldyBjb21t ZW50cy4NCg0KLSAgICAgICBPdGhlciBtaW5vciBlZGl0b3JpYWwgZW5oYW5jZW1lbnRzLg0KDQpJ ZiB3ZSBuZWVkIHRvIHRha2UgY2FyZSBvZiBhbnl0aGluZyByZWxhdGVkIHRvIHRoaXMgZHJhZnQs IHBsZWFzZSBsZXQgdXMga25vdy4NCg0KVGhhbmsgYWxsIHRoZSBwZW9wbGUgd2hvIGNvbW1lbnRl ZC4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tIDogIkludGVybmV0LURyYWZ0c0BpZXRmLm9yZyIgPEludGVybmV0 LURyYWZ0c0BpZXRmLm9yZz4NClNlbnQgOiAyMDE0LTAyLTI1IDA3OjI5OjQ4ICggKzA5OjAwICkN ClRvIDogaS1kLWFubm91bmNlQGlldGYub3JnIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpDYyA6 IG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0IDogW21wbHNdIEktRCBBQ1RJ T046ZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDMudHh0DQoNCkEgbmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE11bHRpcHJvdG9jb2wgTGFi ZWwgU3dpdGNoaW5nIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNClRpdGxlIDogTVBMUyBU cmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgTGluZWFyIFByb3RlY3Rpb24gdG8gTWF0Y2ggdGhl IE9wZXJhdGlvbmFsIEV4cGVjdGF0aW9ucyBvZiBTREgsIE9UTiBhbmQgRXRoZXJuZXQgVHJhbnNw b3J0IE5ldHdvcmsgT3BlcmF0b3JzDQpBdXRob3IocykgOiBKLiBSeW9vLCBldCBhbA0KRmlsZW5h bWUgOiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dQ0KUGFnZXMgOiAzNw0KRGF0ZSA6IDIwMTQt MDItMjQNCg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYWx0ZXJuYXRlIG1lY2hhbmlzbXMgdG8g cGVyZm9ybSBzb21lIG9mIHRoZQ0KZnVuY3Rpb25zIG9mIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUg KE1QTFMtVFApIGxpbmVhciBwcm90ZWN0aW9uDQpkZWZpbmVkIGluIFJGQyA2Mzc4LCBhbmQgYWxz byBkZWZpbmVzIGFkZGl0aW9uYWwgbWVjaGFuaXNtcy4gVGhlDQpwdXJwb3NlIG9mIHRoZXNlIGFs dGVybmF0ZSBhbmQgYWRkaXRpb25hbCBtZWNoYW5pc21zIGlzIHRvIHByb3ZpZGUNCm9wZXJhdG9y IGNvbnRyb2wgYW5kIGV4cGVyaWVuY2UgdGhhdCBtb3JlIGNsb3NlbHkgbW9kZWxzIHRoZSBiZWhh dmlvcg0Kb2YgbGluZWFyIHByb3RlY3Rpb24gc2VlbiBpbiBvdGhlciB0cmFuc3BvcnQgbmV0d29y a3MuDQoNClRoaXMgZG9jdW1lbnQgYWxzbyBpbnRyb2R1Y2VzIGNhcGFiaWxpdGllcyBhbmQgbW9k ZXMgZm9yIGxpbmVhcg0KcHJvdGVjdGlvbi4gQSBjYXBhYmlsaXR5IGlzIGFuIGluZGl2aWR1YWwg YmVoYXZpb3IsIGFuZCBhIG1vZGUgaXMgYQ0KcGFydGljdWxhciBjb21iaW5hdGlvbiBvZiBjYXBh YmlsaXRpZXMuIFR3byBtb2RlcyBhcmUgZGVmaW5lZCBpbg0KdGhpcyBkb2N1bWVudDogUHJvdGVj dGlvbiBTdGF0ZSBDb29yZGluYXRpb24gKFBTQykgbW9kZSBhbmQgQXV0b21hdGljDQpQcm90ZWN0 aW9uIFN3aXRjaGluZyAoQVBTKSBtb2RlLg0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUg YmVoYXZpb3Igb2YgdGhlIFBTQyBwcm90b2NvbCBpbmNsdWRpbmcNCnByaW9yaXR5IGxvZ2ljIGFu ZCBzdGF0ZSBtYWNoaW5lIHdoZW4gYWxsIHRoZSBjYXBhYmlsaXRpZXMgYXNzb2NpYXRlZA0Kd2l0 aCB0aGUgQVBTIG1vZGUgYXJlIGVuYWJsZWQuDQoNClRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMg NjM3OCBpbiB0aGF0IHRoZSBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQNCm1ldGhvZCBkZWZpbmVk IGhlcmUgaXMgYW4gYWRkaXRpb24gdG8gdGhhdCBkb2N1bWVudC4NCg0KQSBVUkwgZm9yIHRoaXMg SW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMy50eHQNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCg0KQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBN SU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxs eSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCkludGVybmV0LURyYWZ0Lg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA9E6SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48YnI+DQo8L2Rpdj4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5EZWFyIE1QTFMgV0cu PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjog MGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUgZHJhZnQgaGFzIGJlZW4gcG9zdGVk LjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46 IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPjwvZm9udD48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9 IkxJTkUtSEVJR0hUOiAxNXB0OyBNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPlRoaXMgdmVy c2lvbiBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJhaXNlZCBkdXJpbmcgdGhlIElFVEYgTEMuPC9m b250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNt IDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+VGhlIGNoYW5n ZXMgbWFkZSBpbiB0aGlzIHZlcnNpb24gaW5jbHVkZSB0aGUgZm9sbG93aW5nczo8L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0 OyBNQVJHSU46IDBjbSAwY20gMTBwdCAzOHB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMGdkOyBt c28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj4NCjxzcGFu IHN0eWxlPSJtc28tYXNjaWktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAn 66eR7J2AIOqzoOuUlSc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSciIGxh bmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+PGZvbnQgZmFjZT0i66eR 7J2AIOqzoOuUlSI+LTwvZm9udD48c3BhbiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9t YW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5CZWhh dmlvciBvZiBlcXVhbCBwcmlvcml0eSByZXF1ZXN0cyAoTVMgYW5kIFNEKSBpcyByZXdyaXR0ZW4g Zm9yIGJldHRlciBjbGFyaXR5IChidXQgdGhlIGJlaGF2aW9yIGl0c2VsZiBkb2VzIG5vdCBjaGFu Z2UgZnJvbSBpdHMgb3JpZ2luYWwgaW50ZW50aW9uKS4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBURVhULUlOREVOVDogLTE4cHQ7IE1BUkdJTjogMGNt IDBjbSAxMHB0IDM4cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAwZ2Q7IG1zby1saXN0OiBsMCBs ZXZlbDEgbGZvMSIgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9Im1zby1h c2NpaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogJ+unkeydgCDqs6DrlJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SV JzsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJyIgbGFuZz0iRU4tVVMiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4t PC9mb250PjxzcGFuIHN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPuKAnFNlY3VyaXR5IENvbnNp ZGVyYXRpb25z4oCdIHNlY3Rpb24gaGFzIGJlZW4gY2hhbmdlZCB0byByZWZsZWN0IHNlY3VyaXR5 IHJldmlldyBjb21tZW50cy4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0OyBURVhULUlOREVOVDogLTE4cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IDM4cHQ7 IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAwZ2Q7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9Im1zby1hc2NpaS1mb250LWZhbWls eTogJ+unkeydgCDqs6DrlJUnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ+unkeydgCDqs6Dr lJUnOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJzsgbXNvLWJpZGktZm9u dC1mYW1pbHk6ICfrp5HsnYAg6rOg65SVJyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDogSWdub3JlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tPC9mb250PjxzcGFuIHN0 eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPuKAnElBTkEgQ29uc2lkZXJhdGlvbnPigJ0gc2VjdGlv biBoYXMgYmVlbiBjaGFuZ2VkIHRvIHJlZmxlY3QgSUFOQSByZXZpZXcgY29tbWVudHMuPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IFRFWFQtSU5ERU5UOiAt MThwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQgMzhwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDBn ZDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+DQo8 c3BhbiBzdHlsZT0ibXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiAn66eR7J2AIOqzoOuUlSc7IG1zby1oYW5zaS1mb250LWZhbWls eTogJ+unkeydgCDqs6DrlJUnOyBtc28tYmlkaS1mb250LWZhbWlseTogJ+unkeydgCDqs6DrlJUn IiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPi08L2ZvbnQ+PHNwYW4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3 IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ T3RoZXIgbWlub3IgZWRpdG9yaWFsIGVuaGFuY2VtZW50cy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PC9mb250Pjwvc3Bh bj48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsg TUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5JZiB3ZSBuZWVkIHRvIHRha2UgY2FyZSBvZiBh bnl0aGluZyByZWxhdGVkIHRvIHRoaXMgZHJhZnQsIHBsZWFzZSBsZXQgdXMga25vdy48L2ZvbnQ+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNt IDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLr p5HsnYAg6rOg65SVIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdDsgTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5UaGFuayBhbGwgdGhl IHBlb3BsZSB3aG8gY29tbWVudGVkLg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PHNwYW4gbGFuZz0i RU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPjwvZm9udD48L3NwYW4+PC9mb250Pjwv c3Bhbj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQ7IE1BUkdJTjogMGNt IDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+QmVzdCByZWdhcmRzLDwvZm9udD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxzcGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMTE1JTsg Rk9OVC1GQU1JTFk6ICfrp5HsnYAg6rOg65SVJzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1m b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0 OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0LXRoZW1lLWZv bnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNv LWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgbGFuZz0i RU4tVVMiPjxzcGFuIHN0eWxlPSJMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1TSVpFOiAxMHB0OyBt c28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtc2l6 ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJlYXN0 LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1s YXRpbjsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1T QSIgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L3NwYW4+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+PHNwYW4gc3R5bGU9IkxJTkUtSEVJR0hUOiAxMTUlOyBGT05ULUZB TUlMWTogJ+unkeydgCDqs6DrlJUnOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1h c2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlu b3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS10 aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiBsYW5nPSJFTi1VUyI+ SmVvbmctZG9uZzwvc3Bhbj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZxdW90O0ludGVybmV0LURyYWZ0c0BpZXRmLm9yZyZx dW90OyAmbHQ7SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnJmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+ MjAxNC0wMi0yNSAwNzoyOTo0OCAoICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPmktZC1h bm5vdW5jZUBpZXRmLm9yZyAmbHQ7aS1kLWFubm91bmNlQGlldGYub3JnJmd0Ozxicj4NCjxiPkNj IDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dCA6IDwvYj5bbXBsc10gSS1EIEFDVElPTjpkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMy50 eHQ8YnI+DQo8YnI+DQpBIG5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgV29ya2luZyBH cm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQpUaXRsZSA6IE1QTFMgVHJhbnNwb3J0IFByb2Zp bGUgKE1QTFMtVFApIExpbmVhciBQcm90ZWN0aW9uIHRvIE1hdGNoIHRoZSBPcGVyYXRpb25hbCBF eHBlY3RhdGlvbnMgb2YgU0RILCBPVE4gYW5kIEV0aGVybmV0IFRyYW5zcG9ydCBOZXR3b3JrIE9w ZXJhdG9yczxicj4NCkF1dGhvcihzKSA6IEouIFJ5b28sIGV0IGFsPGJyPg0KRmlsZW5hbWUgOiBk cmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dTxicj4NClBhZ2VzIDogMzcgPGJyPg0KRGF0ZSA6IDIw MTQtMDItMjQgPGJyPg0KPGJyPg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYWx0ZXJuYXRlIG1l Y2hhbmlzbXMgdG8gcGVyZm9ybSBzb21lIG9mIHRoZTxicj4NCmZ1bmN0aW9ucyBvZiBNUExTIFRy YW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBsaW5lYXIgcHJvdGVjdGlvbjxicj4NCmRlZmluZWQg aW4gUkZDIDYzNzgsIGFuZCBhbHNvIGRlZmluZXMgYWRkaXRpb25hbCBtZWNoYW5pc21zLiBUaGU8 YnI+DQpwdXJwb3NlIG9mIHRoZXNlIGFsdGVybmF0ZSBhbmQgYWRkaXRpb25hbCBtZWNoYW5pc21z IGlzIHRvIHByb3ZpZGU8YnI+DQpvcGVyYXRvciBjb250cm9sIGFuZCBleHBlcmllbmNlIHRoYXQg bW9yZSBjbG9zZWx5IG1vZGVscyB0aGUgYmVoYXZpb3I8YnI+DQpvZiBsaW5lYXIgcHJvdGVjdGlv biBzZWVuIGluIG90aGVyIHRyYW5zcG9ydCBuZXR3b3Jrcy48YnI+DQo8YnI+DQpUaGlzIGRvY3Vt ZW50IGFsc28gaW50cm9kdWNlcyBjYXBhYmlsaXRpZXMgYW5kIG1vZGVzIGZvciBsaW5lYXI8YnI+ DQpwcm90ZWN0aW9uLiBBIGNhcGFiaWxpdHkgaXMgYW4gaW5kaXZpZHVhbCBiZWhhdmlvciwgYW5k IGEgbW9kZSBpcyBhPGJyPg0KcGFydGljdWxhciBjb21iaW5hdGlvbiBvZiBjYXBhYmlsaXRpZXMu IFR3byBtb2RlcyBhcmUgZGVmaW5lZCBpbjxicj4NCnRoaXMgZG9jdW1lbnQ6IFByb3RlY3Rpb24g U3RhdGUgQ29vcmRpbmF0aW9uIChQU0MpIG1vZGUgYW5kIEF1dG9tYXRpYzxicj4NClByb3RlY3Rp b24gU3dpdGNoaW5nIChBUFMpIG1vZGUuPGJyPg0KPGJyPg0KVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgdGhlIGJlaGF2aW9yIG9mIHRoZSBQU0MgcHJvdG9jb2wgaW5jbHVkaW5nPGJyPg0KcHJpb3Jp dHkgbG9naWMgYW5kIHN0YXRlIG1hY2hpbmUgd2hlbiBhbGwgdGhlIGNhcGFiaWxpdGllcyBhc3Nv Y2lhdGVkPGJyPg0Kd2l0aCB0aGUgQVBTIG1vZGUgYXJlIGVuYWJsZWQuPGJyPg0KPGJyPg0KVGhp cyBkb2N1bWVudCB1cGRhdGVzIFJGQyA2Mzc4IGluIHRoYXQgdGhlIGNhcGFiaWxpdHkgYWR2ZXJ0 aXNlbWVudDxicj4NCm1ldGhvZCBkZWZpbmVkIGhlcmUgaXMgYW4gYWRkaXRpb24gdG8gdGhhdCBk b2N1bWVudC48YnI+DQo8YnI+DQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8YnI+ DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAt cHNjLWl0dS0wMy50eHQ8YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy88YnI+DQo8YnI+DQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBh IE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyPGJyPg0KaW1wbGVtZW50YXRpb24gdG8gYXV0b21h dGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8YnI+DQpJbnRlcm5ldC1E cmFmdC48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA9E6SMTP2etriinfo_-- From nobody Tue Feb 25 02:13: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 91A751A0427 for ; Tue, 25 Feb 2014 02:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 DsIdp7tcg5UG for ; Tue, 25 Feb 2014 02:13:41 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBD31A0688 for ; Tue, 25 Feb 2014 02:13:41 -0800 (PST) Received: from mail54-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 10:13:40 +0000 Received: from mail54-va3 (localhost [127.0.0.1]) by mail54-va3-R.bigfish.com (Postfix) with ESMTP id F03B048004F for ; Tue, 25 Feb 2014 10:13:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.25; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(z579ehz9371Ic85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh18c673h1de097hz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2184h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail54-va3: domain of sprint.com designates 144.230.168.25 as permitted sender) client-ip=144.230.168.25; envelope-from=Wan.W.Chen@sprint.com; helo=plsasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail54-va3 (localhost.localdomain [127.0.0.1]) by mail54-va3 (MessageSwitch) id 1393323217667136_8127; Tue, 25 Feb 2014 10:13:37 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.238]) by mail54-va3.bigfish.com (Postfix) with ESMTP id 932DD460047 for ; Tue, 25 Feb 2014 10:13:37 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Feb 2014 10:13:37 +0000 Received: from PLSWEH04.ad.sprint.com (plsweh04.corp.sprint.com [144.226.251.22]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s1PADa4e006497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Feb 2014 04:13:36 -0600 Received: from pdawm09a.ad.sprint.com ([169.254.1.99]) by PLSWEH04.ad.sprint.com ([144.226.251.22]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 04:13:36 -0600 From: "Chen, Walter W [NTK]" To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+Zq7LvvQgAW6XECABOKz0A== Date: Tue, 25 Feb 2014 10:13:34 +0000 Message-ID: <3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFC7@PDAWM09A.ad.sprint.com> References: <54B334E2F9AB214C80ABE154F4E754792AF527BE@nkgeml507-mbs.china.huawei.com> In-Reply-To: <54B334E2F9AB214C80ABE154F4E754792AF527BE@nkgeml507-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.91.92] Content-Type: multipart/alternative; boundary="_000_3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFC7PDAWM09Aadsprin_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JXIsOny1f0k-Kx4lnhcE6e6vQPQ Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 25 Feb 2014 10:13:43 -0000 --_000_3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFC7PDAWM09Aadsprin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. ---------------------------------------------------------------------------= ------------------------------------------- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 4:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFC7PDAWM09Aadsprin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

-----------------------= ---------------------------------------------------------------------------= --------------------

From: mpls [= mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dr= aft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sin= ce this call will continue through the

IETF meeting in London, I will extent = the poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).=

 

This poll will end Tuesday March 11, 2= 014. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFC7PDAWM09Aadsprin_-- From nobody Tue Feb 25 02:16: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 202471A0680 for ; Tue, 25 Feb 2014 02:16:54 -0800 (PST) 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 srfgICq50XfT for ; Tue, 25 Feb 2014 02:16:52 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id C00F11A041C for ; Tue, 25 Feb 2014 02:16:51 -0800 (PST) Received: from mail107-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 10:16:50 +0000 Received: from mail107-am1 (localhost [127.0.0.1]) by mail107-am1-R.bigfish.com (Postfix) with ESMTP id 757AEE018B for ; Tue, 25 Feb 2014 10:16:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.57; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(z579ehz9371Ic85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1033IL8275dh18c673h1de097hz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2184h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail107-am1: domain of sprint.com designates 144.229.32.57 as permitted sender) client-ip=144.229.32.57; envelope-from=Wan.W.Chen@sprint.com; helo=pdaasdm2.corp.sprint.com ; p.sprint.com ; Received: from mail107-am1 (localhost.localdomain [127.0.0.1]) by mail107-am1 (MessageSwitch) id 1393323409207677_30561; Tue, 25 Feb 2014 10:16:49 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.226]) by mail107-am1.bigfish.com (Postfix) with ESMTP id 2FCEB20236 for ; Tue, 25 Feb 2014 10:16:49 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Feb 2014 10:16:48 +0000 Received: from PLSWEH05.ad.sprint.com (plsweh05.corp.sprint.com [144.226.251.23]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s1PAGjZn014209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Feb 2014 04:16:46 -0600 Received: from pdawm09a.ad.sprint.com ([169.254.1.99]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 04:16:45 -0600 From: "Chen, Walter W [NTK]" To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: Ac8rrOPj/bUreZyfmECVop6KMCBBQAGZcD6A Date: Tue, 25 Feb 2014 10:16:45 +0000 Message-ID: <3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFE5@PDAWM09A.ad.sprint.com> References: <54B334E2F9AB214C80ABE154F4E754792AF524BF@nkgeml507-mbs.china.huawei.com> In-Reply-To: <54B334E2F9AB214C80ABE154F4E754792AF524BF@nkgeml507-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.91.92] Content-Type: multipart/alternative; boundary="_000_3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFE5PDAWM09Aadsprin_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LncBzuYnPLmGyOS7OSOLNxXbfWo Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 25 Feb 2014 10:16:54 -0000 --_000_3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFE5PDAWM09Aadsprin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support ---------------------------------------------------------------------------= ------------------------------------------ From: mpls [mailto:mpls-bounces at ietf.org] On Behalf Of Ross Callon Sent: Friday, February 14, 2014 3:46 AM To: mpls at ietf.org Cc: mpls-chairs at tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFE5PDAWM09Aadsprin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Supp= ort

-----------= ---------------------------------------------------------------------------= -------------------------------

 From: mpls [mailto:mpls-bounces a= t ietf.org] On Behalf Of Ross Callon
Sent: Friday, February 14, 2014 3:46 AM
To: mpls at ietf.org
Cc: mpls-chairs at tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is = to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-11

as an MP= LS working group document. Since many of us will be in transit to the

IETF app= roximately two weeks from now, I will extent the poll by one week (so

that it = will be a three week poll).

 

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

mailing = list (mpls at ietf.org).

 

This pol= l will end Friday March 7, 2014. Note that this is the Friday of the IETF,

and thus= we will each need to plan our review of the document and response

around o= ur travel plans and IETF activities.

 

Thanks, = Ross

 

 

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_3C8AE8669FCBF34BAF8C074E440DEF9B04D8BFE5PDAWM09Aadsprin_-- From nobody Tue Feb 25 08:45: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 093861A0735; Tue, 25 Feb 2014 08:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glhYaQySKiDP; Tue, 25 Feb 2014 08:45:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2321A0218; Tue, 25 Feb 2014 08:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140225164502.12544.21557.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2014 08:45:02 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/e2zUxqrTuWD9xMz_tfNi8moYino Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-use-cases-and-design-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: Tue, 25 Feb 2014 16:45:06 -0000 --NextPart 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 Applicability; Use Cases and Design Author(s) : L. Fang, et al Filename : draft-ietf-mpls-tp-use-cases-and-design Pages : 15 Date : March 5, 2013 This document provides the applicability of Multiprotocol Label Switching Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-use-cases-and-design-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-use-cases-and-design"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-03-05084159.I-D@ietf.org> --NextPart-- From nobody Wed Feb 26 04:24:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF35E1A026D; Wed, 26 Feb 2014 04:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxUmg8IydlOZ; Wed, 26 Feb 2014 04:24:31 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A1FBD1A02AC; Wed, 26 Feb 2014 04:24:30 -0800 (PST) Received: from [192.168.0.98] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 60261180145E; Wed, 26 Feb 2014 13:24:28 +0100 (CET) Message-ID: <530DDCFD.2010104@pi.nu> Date: Wed, 26 Feb 2014 13:24:29 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: internet-drafts@ietf.org, IETF-IESG via RT References: <20140225164502.12544.21557.idtracker@ietfa.amsl.com> In-Reply-To: <20140225164502.12544.21557.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/b1L43T76kR4hqut38CMRsV_K8Ck Cc: mpls@ietf.org, "" Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-tp-use-cases-and-design-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 12:24:35 -0000 Folks, I'm not sure why this mail went out - the document was published as RFC 6965 in August 2013. /Loa On 2014-02-25 17:45, Internet-Drafts@ietf.org wrote: > A new Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : MPLS-TP Applicability; Use Cases and Design > Author(s) : L. Fang, et al > Filename : draft-ietf-mpls-tp-use-cases-and-design > Pages : 15 > Date : March 5, 2013 > > This document provides the applicability of Multiprotocol Label > Switching Transport Profile (MPLS-TP) with use case studies and > network design considerations. The use cases include Metro Ethernet > access and aggregation transport, Mobile backhaul, and packet optical > transport. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-use-cases-and-design-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- 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 Feb 26 13:06: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 D858B1A0733 for ; Wed, 26 Feb 2014 13:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 LHC1RxOGHrs9 for ; Wed, 26 Feb 2014 13:06:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF131A072D for ; Wed, 26 Feb 2014 13:06:02 -0800 (PST) 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 BEA09386; Wed, 26 Feb 2014 21:05:56 +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, 26 Feb 2014 21:05:43 +0000 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, 26 Feb 2014 21:05:54 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML702-CHM.china.huawei.com ([169.254.4.61]) with mapi id 14.03.0158.001; Wed, 26 Feb 2014 13:05:51 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQAa29QMy3TZQUa/WtY1/4nJhZqzrkuAgACQewD//3ofgIAAorWAgACRYBCAAJS4gP//efAQgACQkACABBKvEIAA5R6A//98zgAAJPv+gAA/PIxg Date: Wed, 26 Feb 2014 21:05:50 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C44BFD@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7627DE@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C3802F@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B76E8F7@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C3827B@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B76EAC8@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B76EAC8@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.204] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C44BFDSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/z_mAFGyl869cL3JD5Y7eM6B_8R4 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 26 Feb 2014 21:06:11 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C44BFDSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Tuesday, February 18, 2014 2:23 AM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, the proposal in question does not and, what I really consider the problem, = cannot go beyond absolutely same continuity monitoring as for RFC 4090. Yo= u change interpretation of LoC between R3 and L1 and call it "egress failur= e" even though it could be just link failure. [Huaimo] Can you elaborate more on your question? And to add to my concern is the fact that the proposal does not protect L1-= CE link. But egress and the access link can be protected at the service lay= er if the protection domain set between CE nodes. That will provide true eg= ress protection. [Huaimo] The protection of the link between egress L1 and CE1 seems not req= uire any RSVP-TE extensions. It should be out scope of the draft. Because of these considerations I believe that the proposed approach is lim= ited, not practical and offers solution to a problem that already been solv= ed. [Huaimo] Regarding to your statement "a problem that already been solved.",= can you give more details about the existing solution in your mind? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, February 17, 2014 2:09 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, Can you give more details about your question? It seems that the FRR defined in RFC 4090 does not have a requirement that = there MUST be a clearly distinguishable detection of a transit node failure= for people to use it for protecting the transit node failure. Egress prot= ection just follows this. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Monday, February 17, 2014 4:34 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, without clearly distinguishable detection of Egress Failure error FRR and p= roposed mechanics are mutually exclusive at PLR (R3 in Fig.1). Hence, I thi= nk that there's a question of which protection mechanism takes precedence w= hen both been signaled. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, February 17, 2014 8:04 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, The egress protection draft follows most of the behaviors defined in RF= C 4090. Regarding to using link protection and/or node protection on the u= pstream node of an egress as PLR, it follows that defined in RFC 4090. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:42 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, AFAIK, you can use either link or node protection, not both at the same PLR= . If you believe otherwise, please illustrate with RSVP signaling scenario. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 9:16 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, For a transit node of an LSP and the link between the transit node and = the upstream node of the transit node, can we use both the link protection = define in RFC 4090 for protecting the link and the node protection defined = in RFC 4090 for protecting the transit node? If so, will this kind of deplo= yment lead to unpredictable results? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:04 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C44BFDSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

Thanks for your comments!

My answers/explanations are inline below.

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Tuesday, February 18, 2014 2:23 AM
To: Huaimo Chen; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

the proposal in question = does not and, what I really consider the problem, cannot go  beyond ab= solutely same continuity monitoring as for RFC 4090. You change interpretation of LoC between R3 and L1 and call it “egress failure&= #8221; even though it could be just link failure.

 <= /p>

[Huaimo] Can you elaborat= e more on your question?

 <= /p>

And to add to my concern = is the fact that the proposal does not protect L1-CE link. But egress and t= he access link can be protected at the service layer if the protection domain set between CE nodes. That will provide true egress = protection.

 <= /p>

[Huaimo] The protection o= f the link between egress L1 and CE1 seems not require any RSVP-TE extensio= ns. It should be out scope of the draft.

 <= /p>

Because of these consider= ations I believe that the proposed approach is limited, not practical and o= ffers solution to a problem that already been solved.

 <= /p>

[Huaimo] Regarding to you= r statement “a problem that already been solved.”, can you give= more details about the existing solution in your mind?

 <= /p>

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Monday, February 17, 2014 2:09 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

Can you give more details about your question?

It seems that the FRR defined in RFC 4090 does not have a requirement th= at there MUST be a clearly distinguishable detection of a transit node failure for people to use it for protecting the transit node = failure.  Egress protection just follows this.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Monday, February 17, 2014 4:34 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

without clearly distingui= shable detection of Egress Failure error FRR and proposed mechanics are mut= ually exclusive at PLR (R3 in Fig.1). Hence, I think that there’s a question of which protection mechanism takes precedence wh= en both been signaled.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Monday, February 17, 2014 8:04 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    The eg= ress protection draft follows most of the behaviors defined in RFC 4090. Re= garding to using  link protection and/or node protection on the upstre= am node of an egress as PLR, it follows that defined in RFC 4090.<= /span>

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:42 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

AFAIK, you can use either= link or node protection, not both at the same PLR. If you believe otherwis= e, please illustrate with RSVP signaling scenario.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 9:16 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    For a = transit node of an LSP and the link between the transit node and the upstre= am node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC= 4090 for protecting the transit node? If so, will this kind of deployment = lead to unpredictable results?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_5316A0AB3C851246A7CA5758973207D445C44BFDSJCEML701CHMchi_-- From nobody Wed Feb 26 13:25: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 A56411A02B0 for ; Wed, 26 Feb 2014 13:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 iaQikv-HW0wI for ; Wed, 26 Feb 2014 13:25:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 545A11A0254 for ; Wed, 26 Feb 2014 13:25:35 -0800 (PST) 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 BEA10491; Wed, 26 Feb 2014 21:25:32 +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, 26 Feb 2014 21:24:51 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Feb 2014 21:25:02 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML703-CHM.china.huawei.com ([169.254.5.78]) with mapi id 14.03.0158.001; Wed, 26 Feb 2014 13:24:47 -0800 From: Huaimo Chen To: Gregory Mirsky , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLOVtqgfFa0b99EWP8q5G+WGaYprIEuDw Date: Wed, 26 Feb 2014 21:24:47 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.204] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C44C19SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VJYimkQ2JgvD0WtqFfvhlNzGmh0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 26 Feb 2014 21:25:40 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C44C19SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, It seems that your reason for do not support is not persuasive. Regarding to your statement "The only viable case presented in sectio= n 3.3 where CE is monitoring access link to the ingress. This is well-known= case, e.g. Ethernet First Mile, and can be addressed in many different way= s already." , can you provide details on one of many different ways in your= mind that provides protections of the ingress of an MPLS TE LSP? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, February 18, 2014 3:10 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 do not support Proposed solution cannot offer complete protection as in its root is miscon= ception that running multiple CC sessions between two nodes can help with d= etecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable ca= se presented in section 3.3 where CE is monitoring access link to the ingre= ss. This is well-known case, e.g. Ethernet First Mile, and can be addressed= in many different ways already. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 1:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_5316A0AB3C851246A7CA5758973207D445C44C19SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

= It seems that your reason for do not support = is not persuasive.

    &= nbsp;Regarding to  your statement “The only viable case presented in section 3.3 where CE is monitoring access link to the ingress. This is wel= l-known case, e.g. Ethernet First Mile, and can be addressed in many differ= ent ways already.” , can you provide details on one of many different ways in your mind that pr= ovides protections of  the ingress of an MPLS TE LSP?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, February 18, 2014 3:10 PM
To: Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

do not support=

 <= /p>

Proposed solution cannot = offer complete protection as in its root is misconception that running mult= iple CC sessions between two nodes can help with detecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable case prese= nted in section 3.3 where CE is monitoring access link to the ingress. This= is well-known case, e.g. Ethernet First Mile, and can be addressed in many= different ways already.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 1:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_5316A0AB3C851246A7CA5758973207D445C44C19SJCEML701CHMchi_-- From nobody Wed Feb 26 13:33: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 09FF51A01E1 for ; Wed, 26 Feb 2014 13:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RG7C8HpvEkyj for ; Wed, 26 Feb 2014 13:33:20 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 284C71A0131 for ; Wed, 26 Feb 2014 13:33:20 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-33-530e5d9e1400 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DD.F6.11484.E9D5E035; Wed, 26 Feb 2014 22:33:19 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 16:33:10 -0500 From: Gregory Mirsky To: Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPMzlOPONsyGCkJEGjFiKTLoq0ZprIDE7w Date: Wed, 26 Feb 2014 21:33:09 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B772EBBeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPrO78WL5gg59n9C22Pr3CaPH90hIW i1tLV7Ja/F1xhcWBxaPlyFtWjyVLfjJ5XG+6yu7x5fJntgCWKC6blNSczLLUIn27BK6M37vf MRdsbGGsOL93K1sD46fSLkZODgkBE4kPHcsYIWwxiQv31rN1MXJxCAkcYZT4tfw7I4SznFHi 3LK7zCBVbAJGEi829rCD2CICeRLNz/eDdTML2ErceXINzBYWCJLY2b2AEaImWGLRncMsELaR xJc3s4A2cHCwCKhKTJ0rDmLyCvhKHG9lhlj1lFFiSf9GsFZOgTCJ14/vsoHYjEDHfT+1hgli lbjErSfzmSCOFpBYsuc8M4QtKvHy8T9WCFtJYtLSc6wQ9fkSHR92gM3hFRCUODnzCcsERtFZ SEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XIUVqcWpabbmS4iREYf8ck 2Bx3MC74ZHmIUZqDRUmc98tb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjE3XVp16sMgs 1WmtddvWYKn1qyrShPjb+pWDQxYGJ7e65H9x/Pt7osa8m3cSJyfOXac1e17Wv7sLhX7d1N/U JfVA94I9b/LKSQ5XDz/6nvbj346HPCtWHPg5Zc2bd1dNfhprTnZdPk/8/Z/Lqj3T0riK4jye ta2vDu9Inv+Z1aX+r/ic6w4f4q4rsRRnJBpqMRcVJwIAH6xir40CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dMbzLKX1CiVjILsHLS7JjFkY5ws Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 26 Feb 2014 21:33:26 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B772EBBeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, I don't consider WG poll as a contest in art of persuasion. I've merely pro= vided my technical opinion. As for your question, my opinion is protection of ingress LSR, and egress L= SR for that matter, is outside of scope of server LSP and can be easily add= ressed for client layer. And in my opinion MPLS WG should not spend more ti= me discussing standardization of attempts to solve these. Though it may be = reasonable to preserve them as Experimental. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Wednesday, February 26, 2014 1:25 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 Hi Greg, It seems that your reason for do not support is not persuasive. Regarding to your statement "The only viable case presented in sectio= n 3.3 where CE is monitoring access link to the ingress. This is well-known= case, e.g. Ethernet First Mile, and can be addressed in many different way= s already." , can you provide details on one of many different ways in your= mind that provides protections of the ingress of an MPLS TE LSP? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, February 18, 2014 3:10 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 do not support Proposed solution cannot offer complete protection as in its root is miscon= ception that running multiple CC sessions between two nodes can help with d= etecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable ca= se presented in section 3.3 where CE is monitoring access link to the ingre= ss. This is well-known case, e.g. Ethernet First Mile, and can be addressed= in many different ways already. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 1:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B772EBBeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

I don’t consider WG= poll as a contest in art of persuasion. I’ve merely provided my tech= nical opinion.

As for your question, my = opinion is protection of ingress LSR, and egress LSR for that matter, is ou= tside of scope of server LSP and can be easily addressed for client layer. And in my opinion MPLS WG should not spend more time dis= cussing standardization of attempts to solve these. Though it may be reason= able to preserve them as Experimental.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Wednesday, February 26, 2014 1:25 PM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

Hi Greg,

 <= /p>

= It seems that your reason for do not support = is not persuasive.

    &= nbsp;Regarding to  your statement “The only viable case presente= d in section 3.3 where CE is monitoring access link to the ingress. This is= well-known case, e.g. Ethernet First Mile, and can be addressed in many different ways alre= ady.” , can you provide details on one of many different ways in your= mind that provides protections of  the ingress of an MPLS TE LSP?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, February 18, 2014 3:10 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

do not support=

 <= /p>

Proposed solution cannot = offer complete protection as in its root is misconception that running mult= iple CC sessions between two nodes can help with detecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable case prese= nted in section 3.3 where CE is monitoring access link to the ingress. This= is well-known case, e.g. Ethernet First Mile, and can be addressed in many= different ways already.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 1:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_7347100B5761DC41A166AC17F22DF1121B772EBBeusaamb103erics_-- From nobody Wed Feb 26 13:38: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 7D70F1A020B for ; Wed, 26 Feb 2014 13:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXvTtybTLSIa for ; Wed, 26 Feb 2014 13:38:13 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D3F3D1A01E1 for ; Wed, 26 Feb 2014 13:38:12 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-82-530e5ebf80d9 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EE.25.12743.FBE5E035; Wed, 26 Feb 2014 22:38:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 16:38:10 -0500 From: Gregory Mirsky To: Huaimo Chen , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 Thread-Index: AQHPKQQErWTRsEe5IUeaVctZClaFmpqztzjwgABYTAD//8I4UIABeH2A//+s7mCAAFt5gP//srUQAJ4JFYAAANNy4AAL5VqAAAhkdJABugnzAAAJasYg Date: Wed, 26 Feb 2014 21:38:10 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B772ED5@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B762063@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37048@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762122@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37096@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7621B6@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C37563@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B762774@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C375EF@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7627DE@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C3802F@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B76E8F7@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C3827B@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B76EAC8@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44BFD@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C44BFD@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B772ED5eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPoO7+OL5gg2lLzC22Pr3CaPH90hIW i1tLV7Ja/F1xhcWBxaPlyFtWjyVLfjJ5XG+6yu7x5fJntgCWKC6blNSczLLUIn27BK6MmVOn MRXca2SpmHrzMEsD4/tTzF2MHBwSAiYSe95kdjFyApliEhfurWfrYuTiEBI4wiix58diVghn OaPEtzubGUGq2ASMJF5s7GEHsUUE8iSan+8HizML2ErceXINzBYWCJSY3nqNDaImSGLJjQcs IINEBJqABnWsYwFJsAioSnzdsBZsEK+Ar0TXtzZ2iG1HOST6Wv6AFXEKhEls6GlmBrEZge77 fmoNE8Q2cYlbT+YzQdwtILFkz3lmCFtU4uXjf6wQtpLEpKXnWCHq8yVWbjjADLFMUOLkzCcs ExhFZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqRwSZG YBQek2DT3cG456XlIUZpDhYlcd4vb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAKeRvl 1F27uVNmZbfPH6lTlzZLTa34V8xTt9txX1fAlEsNv6ccYji8KHnf3qUnj75J5npW6njeQNs4 sdbUY+eTtS2pj74v+tfhOHe57eZ/gi2zbG28YxpXNe+sanA1Xf34bYXTHLZXp9iFUjMCj+Qa hl6TZW+JdjywvPJvvmdANku80pRk1odKLMUZiYZazEXFiQBPuJcrkAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZSea7KHw_6ye1W2D3bmpzNkqmr4 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 26 Feb 2014 21:38:20 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B772ED5eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, I think that I've provided sufficient information to why I consider this pr= oposal is outside of WG interest already. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Wednesday, February 26, 2014 1:06 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, Thanks for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Tuesday, February 18, 2014 2:23 AM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, the proposal in question does not and, what I really consider the problem, = cannot go beyond absolutely same continuity monitoring as for RFC 4090. Yo= u change interpretation of LoC between R3 and L1 and call it "egress failur= e" even though it could be just link failure. [Huaimo] Can you elaborate more on your question? And to add to my concern is the fact that the proposal does not protect L1-= CE link. But egress and the access link can be protected at the service lay= er if the protection domain set between CE nodes. That will provide true eg= ress protection. [Huaimo] The protection of the link between egress L1 and CE1 seems not req= uire any RSVP-TE extensions. It should be out scope of the draft. Because of these considerations I believe that the proposed approach is lim= ited, not practical and offers solution to a problem that already been solv= ed. [Huaimo] Regarding to your statement "a problem that already been solved.",= can you give more details about the existing solution in your mind? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, February 17, 2014 2:09 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, Can you give more details about your question? It seems that the FRR defined in RFC 4090 does not have a requirement that = there MUST be a clearly distinguishable detection of a transit node failure= for people to use it for protecting the transit node failure. Egress prot= ection just follows this. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Monday, February 17, 2014 4:34 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, without clearly distinguishable detection of Egress Failure error FRR and p= roposed mechanics are mutually exclusive at PLR (R3 in Fig.1). Hence, I thi= nk that there's a question of which protection mechanism takes precedence w= hen both been signaled. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, February 17, 2014 8:04 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, The egress protection draft follows most of the behaviors defined in RF= C 4090. Regarding to using link protection and/or node protection on the u= pstream node of an egress as PLR, it follows that defined in RFC 4090. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:42 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, AFAIK, you can use either link or node protection, not both at the same PLR= . If you believe otherwise, please illustrate with RSVP signaling scenario. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 9:16 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, For a transit node of an LSP and the link between the transit node and = the upstream node of the transit node, can we use both the link protection = define in RFC 4090 for protecting the link and the node protection defined = in RFC 4090 for protecting the transit node? If so, will this kind of deplo= yment lead to unpredictable results? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, February 14, 2014 12:04 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, thank you for references to the document. I'd point that without demonstrat= ing that node R3 can differentiate link [R3,L1] failure from failure of egr= ess node L1 use of both FRR and egress protection may lead to unpredictable= results among which unnecessary use of egress protection vs. FRR might be = the least of problem. Scope of a protection domain is determined by end poi= nts of continuity monitoring OAM. One is obvious - R3. If you place another= one at L1, then it is no different from FRR scenario that protects [R3-L1]= and failure of link [L1-CE] is not being monitored, thus it is unprotected= by the proposed mechanism. If the second CC OAM end point place at CE to m= onitor link [L1-CE] as well, then, IMHO, there are clear security concerns. Again, I believe that this problem being already solved at client layer and= server layer has to do nothing. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, February 14, 2014 8:46 AM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, In section 1.2 "Egress Local Protection with FRR" of the draft, we state "T= he egress nodes of the LSP can be locally protected via the egress local p= rotection. All the links and the intermediate nodes of the LSP can be loca= lly protected through using the FRR." The link between the egress node and= the upstream node of the egress is one of all the links of the LSP. Its fa= ilure can be protected by the link protection. In section 5.2.1 of the draft, we state "When the PLR detects the failure o= f the primary egress, it MUST switch the packets from the primary LSP to th= e backup LSP to the backup egress. ... ". Here the PLR is the upstream node= of the primary egress. In section 5.2.2 of the draft, we state "When the PLR detects the failure o= f the primary egress, it redirects the packets from the primary LSP into th= e backup LSP to backup egress ...". Here the PLR is the upstream node of th= e primary egress. It seems that the draft does not make any suggestion as you mentioned. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 6:32 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, since the RFC 4090 is local protection the scope of fault detection mechani= sm is link OAM. There are two interpretations of link failure that are supp= orted by two modes: * link protection * node protection Are you suggesting that interpretation of a failure of immediate link as eg= ress node failure is efficient and preferable to Service OAM? Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:59 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, FRR defined in RFC 4090 has been used for transit node protection. Do y= ou know any method that is used by FRR and can tell/distinguish different f= ailures reliably? Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, February 13, 2014 4:49 PM To: Huaimo Chen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Huaimo, I believe that any protection mechanism is based on assumption that fault i= t protects from can be detected. Otherwise, when the protection mechanism w= ill be triggered? If there's no proof that particular failure can be distin= guished for other failure scenarios, then I don't find enough justification= for additional complexity of protection scheme. Especially when the proble= m can be solved by other technical means. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Thursday, February 13, 2014 1:39 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 Hi Greg, It seems that your reason "The draft lacks to demonstrate that claimed goal= , egress LSR failure, can be reliably detected." for do not support is not = persuasive. In our draft, there is not any claimed goal, egress LSR failure, can be rel= iably detected. We have FRR defined in RFC 4090, which can be used for transit node protect= ion. MUST we have/describe a method (in RFC 4090) that can reliably detect= the transit LSR failure? Basically, the objective of egress protection is to make sure that the data= traffic flows to its destination in the case that the egress fails. It is = nice to have a method to detect the egress failure and clearly identify the= failure as egress failure. It seems that it is not a MUST for us to have t= his kind of method. As long as the data traffic flows to its destination th= rough the use of egress protection when the egress fails or some related fa= ilures occur, it should be OK. Best regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, February 13, 2014 4:11 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protectio= n-11 do not support The draft lacks to demonstrate that claimed goal, egress LSR failure, can b= e reliably detected. Thus benefits of local protection for server layer LSP= vs. client layer protection (Service OAM) are questionable, at best. Witho= ut that this is exercise in extending RSVP-TE. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Thursday, February 13, 2014 11:46 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11 This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-= 11 as an MPLS working group document. Since many of us will be in transit to t= he IETF approximately two weeks from now, I will extent the poll by one week (= so that it will be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Friday March 7, 2014. Note that this is the Friday of th= e IETF, and thus we will each need to plan our review of the document and response around our travel plans and IETF activities. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B772ED5eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

I think that I’ve p= rovided sufficient information to why I consider this proposal is outside o= f WG interest already.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Wednesday, February 26, 2014 1:06 PM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

Thanks for your comments!

My answers/explanations are inline below.

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Tuesday, February 18, 2014 2:23 AM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

the proposal in question = does not and, what I really consider the problem, cannot go  beyond ab= solutely same continuity monitoring as for RFC 4090. You change interpretation of LoC between R3 and L1 and call it “egress failure&= #8221; even though it could be just link failure.

 <= /p>

[Huaimo] Can you elaborat= e more on your question?

 <= /p>

And to add to my concern = is the fact that the proposal does not protect L1-CE link. But egress and t= he access link can be protected at the service layer if the protection domain set between CE nodes. That will provide true egress = protection.

 <= /p>

[Huaimo] The protection o= f the link between egress L1 and CE1 seems not require any RSVP-TE extensio= ns. It should be out scope of the draft.

 <= /p>

Because of these consider= ations I believe that the proposed approach is limited, not practical and o= ffers solution to a problem that already been solved.

 <= /p>

[Huaimo] Regarding to you= r statement “a problem that already been solved.”, can you give= more details about the existing solution in your mind?

 <= /p>

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Monday, February 17, 2014 2:09 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

Can you give more details about your question?

It seems that the FRR defined in RFC 4090 does not have a requirement th= at there MUST be a clearly distinguishable detection of a transit node failure for people to use it for protecting the transit node = failure.  Egress protection just follows this.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Monday, February 17, 2014 4:34 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

without clearly distingui= shable detection of Egress Failure error FRR and proposed mechanics are mut= ually exclusive at PLR (R3 in Fig.1). Hence, I think that there’s a question of which protection mechanism takes precedence wh= en both been signaled.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Monday, February 17, 2014 8:04 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    The eg= ress protection draft follows most of the behaviors defined in RFC 4090. Re= garding to using  link protection and/or node protection on the upstre= am node of an egress as PLR, it follows that defined in RFC 4090.<= /span>

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:42 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

AFAIK, you can use either= link or node protection, not both at the same PLR. If you believe otherwis= e, please illustrate with RSVP signaling scenario.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 9:16 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

    For a = transit node of an LSP and the link between the transit node and the upstre= am node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC= 4090 for protecting the transit node? If so, will this kind of deployment = lead to unpredictable results?

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

thank you for references = to the document. I’d point that without demonstrating that node R3 ca= n differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results= among which unnecessary use of egress protection vs. FRR might be the leas= t of problem. Scope of a protection domain is determined by end points of c= ontinuity monitoring OAM. One is obvious – R3. If you place another one at L1, then it is no differen= t from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is no= t being monitored, thus it is unprotected by the proposed mechanism. If the= second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concern= s.

Again, I believe that thi= s problem being already solved at client layer and server layer has to do n= othing.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 <= /p>

In section 1.2 “Egress Local Protection with FRR” of the dra= ft, we state “The egress nodes of the LSP can be locally protected vi= a the egress  local protection.  All the links and the intermediate nodes= of the LSP can be locally protected through using th= e FRR.”  The link between the = egress node and the upstream node of the egress is one of all the links of the LSP. It= s failure can be protected by the link protection.

 

In section 5.2.1 of the draft, we state “When the PLR detects the failure of the primary egress= , it MUST switch the packets from the pri= mary LSP to the backup LSP to the backup egress. … ”. Here the PLR = is the upstream node of the primary egress.

 

In section 5.2.2 of the draft, we state “When the PLR detects the failure of the primary egress= , it redirects the packets from the prima= ry LSP into the backup LSP to backup egress …”. Here the PLR is t= he upstream node of the primary egress.

 <= /p>

    It see= ms that the draft does not make any suggestion as you mentioned.=

 <= /p>

Best Regards,<= /span>

Huaimo<= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

since the RFC 4090 is loc= al protection the scope of fault detection mechanism is link OAM. There are= two interpretations of link failure that are supported by two modes:

·      = ;   link protection

·      = ;   node protection

Are you suggesting that i= nterpretation of a failure of immediate link as egress node failure is effi= cient and preferable to Service OAM?

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Greg,

 

    FRR defin= ed in RFC 4090 has been used for transit node protection. Do you know any m= ethod that is used by FRR and can tell/distinguish different failures relia= bly?

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; mpls@= ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi Huaimo,

I believe that any protec= tion mechanism is based on assumption that fault it protects from can be de= tected. Otherwise, when the protection mechanism will be triggered? If there’s no proof that particular failure can be distin= guished for other failure scenarios, then I don’t find enough justifi= cation for additional complexity of protection scheme. Especially when the = problem can be solved by other technical means.

 <= /p>

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

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

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

Hi= Greg,

 

= It seems that your reason “<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected.” for do not support is not persuas= ive.

=  

= In our draft, there is not any claimed goal, egress LSR failure, can be reliabl= y detected.

 

= We have FRR defined in RFC 4090, which can be us= ed for transit node protection. MUST we  have/describe a method (in RF= C 4090) that can reliably detect the transit LSR failure?

=  

= Basically, the objective of egress protection is= to make sure that the data traffic flows to its destination in the case th= at the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as = egress failure. It seems that it is not a MUST for us to have this kind of = method. As long as the data traffic flows to its destination through the us= e of egress protection when the egress fails or some related failures occur, it should be OK.

 <= /p>

Best regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; mpls@ietf.org<= br> Cc: mpls-chairs@tools.= ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-pr= otection-11

 

do not support=

 <= /p>

The draft lacks to demons= trate that claimed goal, egress LSR failure, can be reliably detected. Thus= benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that thi= s is exercise in extending RSVP-TE.

 <= /p>

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

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

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protec= tion-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-egress-protection-11

as an MPLS working group document. Sinc= e many of us will be in transit to the

IETF approximately two weeks from now, = I will extent the poll by one week (so

that it will be a three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Friday March 7, 2014= . Note that this is the Friday of the IETF,

and thus we will each need to plan our = review of the document and response

around our travel plans and IETF activi= ties.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B772ED5eusaamb103erics_-- From nobody Wed Feb 26 14:47: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 161B61A06D9 for ; Wed, 26 Feb 2014 14:47:49 -0800 (PST) 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 dofV1mfyi1hK for ; Wed, 26 Feb 2014 14:47:46 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id BC6501A06BD for ; Wed, 26 Feb 2014 14:47:45 -0800 (PST) Received: from mail11-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Wed, 26 Feb 2014 22:47:43 +0000 Received: from mail11-am1 (localhost [127.0.0.1]) by mail11-am1-R.bigfish.com (Postfix) with ESMTP id E2579A0236; Wed, 26 Feb 2014 22:47:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz9371Ic85fhe0eah4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch9a9j1155h) Received-SPF: pass (mail11-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=yshen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(164054003)(377454003)(189002)(199002)(81342001)(92566001)(19300405004)(49866001)(33646001)(93516002)(18717965001)(86362001)(83322001)(94316002)(19580405001)(93136001)(81542001)(19580395003)(76796001)(83072002)(74876001)(87266001)(74366001)(85852003)(47736001)(69226001)(47976001)(2656002)(87936001)(4396001)(56816005)(76786001)(90146001)(1941001)(16236675002)(51856001)(76482001)(15975445006)(74662001)(81816001)(59766001)(66066001)(46102001)(19609705001)(54356001)(95666003)(77982001)(56776001)(95416001)(94946001)(31966008)(74706001)(50986001)(76576001)(85306002)(80976001)(74316001)(65816001)(15202345003)(81686001)(79102001)(47446002)(80022001)(63696002)(74502001)(53806001)(54316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB630; H:BY2PR05MB728.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:3834759D.1CD09DF5.11F9BDCF.14EEDE2C.20162; PTR:InfoNoRecords; MX:1; A:1; LANG:; Received: from mail11-am1 (localhost.localdomain [127.0.0.1]) by mail11-am1 (MessageSwitch) id 1393454850895272_15031; Wed, 26 Feb 2014 22:47:30 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.237]) by mail11-am1.bigfish.com (Postfix) with ESMTP id CCC4414006A; Wed, 26 Feb 2014 22:47:30 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 26 Feb 2014 22:47:15 +0000 Received: from BY2PR05MB630.namprd05.prod.outlook.com (10.141.218.13) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Wed, 26 Feb 2014 22:47:01 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB630.namprd05.prod.outlook.com (10.141.218.13) with Microsoft SMTP Server (TLS) id 15.0.883.10; Wed, 26 Feb 2014 22:46:59 +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.0883.010; Wed, 26 Feb 2014 22:46:59 +0000 From: Yimin Shen To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+ZrIMLHQ Date: Wed, 26 Feb 2014 22:46:58 +0000 Message-ID: <3ef2def0d98f4a44a2b51039c7f2e6b8@BY2PR05MB728.namprd05.prod.outlook.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-forefront-prvs: 0134AD334F Content-Type: multipart/alternative; boundary="_000_3ef2def0d98f4a44a2b51039c7f2e6b8BY2PR05MB728namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_tAQ_pkFeEu6PPYhrW5Ij6ibcDY Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 26 Feb 2014 22:47:50 -0000 --_000_3ef2def0d98f4a44a2b51039c7f2e6b8BY2PR05MB728namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support (as a co-author) Thanks, /Yimin From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 4:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_3ef2def0d98f4a44a2b51039c7f2e6b8BY2PR05MB728namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support (as a co-author)<= o:p>

 <= /p>

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_3ef2def0d98f4a44a2b51039c7f2e6b8BY2PR05MB728namprd05pro_-- From nobody Wed Feb 26 15:50:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF851A022C for ; Wed, 26 Feb 2014 15:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KQPbH5TODEm for ; Wed, 26 Feb 2014 15:50:12 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DD4191A01E0 for ; Wed, 26 Feb 2014 15:50:11 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id f73so1898577yha.17 for ; Wed, 26 Feb 2014 15:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eK/3Vsfr78zXbqKjks9l5ibtth2f4DdT9Qpl/ROCK8A=; b=A6qDRU7o5kcKG3duzzB9dUecuK2DdxTb0bqVfwhScc2njqzZCEaPKgSUR+onF6FtIS M8fyfiDlxiRocA41We3aBR2TO6cIhr+dP+eJmIOdGb9gL5TB2V7TKdtc2eltodkhOZpR KPl+Gpmr5NZolXyuQ4uGN+WTLiWD6jObFLzvO7naO58xYS75ixeFwsVHSo5EpgvNZS8a wJdTa3hyRwuSAiFBDCzNoavy8U2Tdcxj+kZxW0nWxpt9Tyyx7IW1WIXJS3TAEuJPF7qm uTBCMFCZXwhxQqF3C59/HsB9f1qiYzDNmQklAgnaLmebwezFMsUoIC1H4bBtI5UM8s0b moUw== MIME-Version: 1.0 X-Received: by 10.236.152.36 with SMTP id c24mr5858943yhk.118.1393458610419; Wed, 26 Feb 2014 15:50:10 -0800 (PST) Received: by 10.170.194.140 with HTTP; Wed, 26 Feb 2014 15:50:10 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> Date: Wed, 26 Feb 2014 18:50:10 -0500 Message-ID: From: Alia Atlas To: Gregory Mirsky Content-Type: multipart/alternative; boundary=20cf3040e96e7bbc5b04f357ddce Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wJk_fPW7HvT5mPoNrUkC3vZS4D4 Cc: Ross Callon , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 26 Feb 2014 23:50:18 -0000 --20cf3040e96e7bbc5b04f357ddce Content-Type: text/plain; charset=ISO-8859-1 I do support this draft as a good starting place for a working group document. It still needs work - I'd love to see discussion of the two approaches described in it - but I think it is a good place to start. Greg, the concern about distinguishing between link and node failure is interesting. There are four different approaches in the draft because there can be different deployment scenarios which make each valid. When considering the different cases, the concern is always whether the traffic might be duplicated or not. Obviously, if the traffic source decides, then no duplication is possible. If the backup ingress can determine that there is no functional path from the ingress, then that is a different case where traffic duplication can be avoided. If the potential merge point does stream selection (as is done with MoFRR), then that allows yet other decision points. Different deployment scenarios are the key here. We did actually go down the road of how one would need to set up BFD sessions to verify failure - but that is also deployment-specific and got rather lengthy. Alia On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky wrote: > Hi Huaimo, > > I don't consider WG poll as a contest in art of persuasion. I've merely > provided my technical opinion. > > As for your question, my opinion is protection of ingress LSR, and egress > LSR for that matter, is outside of scope of server LSP and can be easily > addressed for client layer. And in my opinion MPLS WG should not spend more > time discussing standardization of attempts to solve these. Though it may > be reasonable to preserve them as Experimental. > > > > Regards, > > Greg > > > > *From:* Huaimo Chen [mailto:huaimo.chen@huawei.com] > *Sent:* Wednesday, February 26, 2014 1:25 PM > *To:* Gregory Mirsky; Ross Callon; mpls@ietf.org > *Cc:* mpls-chairs@tools.ietf.org > *Subject:* RE: [mpls] Poll for Adoption > draft-chen-mpls-p2mp-ingress-protection-11 > > > > Hi Greg, > > > > It seems that your reason for do not support is not persuasive. > > Regarding to your statement "The only viable case presented in > section 3.3 where CE is monitoring access link to the ingress. This is > well-known case, e.g. Ethernet First Mile, and can be addressed in many > different ways already." , can you provide details on one of many different > ways in your mind that provides protections of the ingress of an MPLS TE > LSP? > > > > Best Regards, > > Huaimo > > *From:* mpls [mailto:mpls-bounces@ietf.org ] *On > Behalf Of *Gregory Mirsky > *Sent:* Tuesday, February 18, 2014 3:10 PM > *To:* Ross Callon; mpls@ietf.org > *Cc:* mpls-chairs@tools.ietf.org > *Subject:* Re: [mpls] Poll for Adoption > draft-chen-mpls-p2mp-ingress-protection-11 > > > > do not support > > > > Proposed solution cannot offer complete protection as in its root is > misconception that running multiple CC sessions between two nodes can help > with detecting failure of a node (sections 3.1, 3.2, and 3.4). The only > viable case presented in section 3.3 where CE is monitoring access link to > the ingress. This is well-known case, e.g. Ethernet First Mile, and can be > addressed in many different ways already. > > > > Regards, > > Greg > > > > *From:* mpls [mailto:mpls-bounces@ietf.org ] *On > Behalf Of *Ross Callon > *Sent:* Monday, February 17, 2014 1:09 PM > *To:* mpls@ietf.org > *Cc:* mpls-chairs@tools.ietf.org > *Subject:* [mpls] Poll for Adoption > draft-chen-mpls-p2mp-ingress-protection-11 > > > > This is to start a poll on adopting > draft-chen-mpls-p2mp-ingress-protection-11 > > as an MPLS working group document. Since this call will continue through > the > > IETF meeting in London, I will extent the poll by one week (so that it > will be a > > three week poll). > > > > Please send your comments (support/not support) to the mpls working group > > mailing list (mpls@ietf.org). > > > > This poll will end Tuesday March 11, 2014. This is of course the Tuesday > after > > the IETF. > > > > Thanks, Ross > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --20cf3040e96e7bbc5b04f357ddce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I do support this draft as a good starting place for a wor= king group document.  It still needs work - I'd love to see discus= sion of the two approaches described in it - but I think it is a good place= to start.

Greg, the concern about distinguishing between link and node= failure is interesting.  There are four different approaches in the d= raft because there can be different deployment scenarios which make each va= lid.  When considering the different cases, the concern is always whet= her the traffic might be duplicated or not.  Obviously, if the traffic= source decides, then no duplication is possible.  If the backup ingre= ss can determine that there is no functional path from the ingress, then th= at is a different case where traffic duplication can be avoided.  If t= he potential merge point does stream selection (as is done with MoFRR), the= n that allows yet other decision points.   Different deployment scenar= ios are the key here.    We did actually go down the road of how = one would need to set up BFD sessions to verify failure - but that is also = deployment-specific and got rather lengthy.

Alia


On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Huaimo,<= /span>

I don’t consider WG= poll as a contest in art of persuasion. I’ve merely provided my tech= nical opinion.

As for your question, my = opinion is protection of ingress LSR, and egress LSR for that matter, is ou= tside of scope of server LSP and can be easily addressed for client layer. And in my opinion MPLS WG should not spend more time dis= cussing standardization of attempts to solve these. Though it may be reason= able to preserve them as Experimental.

 

    &= nbsp;           Regards,<= u>

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

 

From: Huaimo C= hen [mailto:hua= imo.chen@huawei.com]
Sent: Wednesday, February 26, 2014 1:25 PM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: = mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

Hi Greg,

 

It seems that your reason for do not support is not persuasive= .

    &= nbsp;Regarding to  your statement “The only viable case presente= d in section 3.3 where CE is monitoring access link to the ingress. This is= well-known case, e.g. Ethernet First Mile, and can be addressed in many different ways alre= ady.” , can you provide details on one of many different ways in your= mind that provides protections of  the ingress of an MPLS TE LSP?

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounce= s@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, February 18, 2014 3:10 PM
To: Ross Callon; = mpls@ietf.org
Cc: = mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

do not support<= /u>

 

Proposed solution cannot = offer complete protection as in its root is misconception that running mult= iple CC sessions between two nodes can help with detecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable case prese= nted in section 3.3 where CE is monitoring access link to the ingress. This= is well-known case, e.g. Ethernet First Mile, and can be addressed in many= different ways already.

 

    &= nbsp;           Regards,<= u>

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

 

From: mpls [mailto:mpls-bounce= s@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 1:09 PM
To: mpls@ietf.org=
Cc: = mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 


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


--20cf3040e96e7bbc5b04f357ddce-- From nobody Wed Feb 26 16:25: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 A75B91A070D for ; Wed, 26 Feb 2014 16:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.276 X-Spam-Level: X-Spam-Status: No, score=0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_GIF_UNO_LARGO=2.176, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MZtssVvyLP9 for ; Wed, 26 Feb 2014 16:25:07 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2581C1A02CD for ; Wed, 26 Feb 2014 16:25:07 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-fc-530e85dd9767 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4E.CB.12743.DD58E035; Thu, 27 Feb 2014 01:25:02 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 19:25:04 -0500 From: Gregory Mirsky To: Alia Atlas Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPM01/87IUTaK2v0iiw2Xi2FDUfZrIOjeg Date: Thu, 27 Feb 2014 00:25:03 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B77304D@eusaamb103.ericsson.se> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/related; boundary="_004_7347100B5761DC41A166AC17F22DF1121B77304Deusaamb103erics_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUyuXRPrO69Vr5ggyVbmS0+PbzEbLH16RVG i++XlrBY3Fq6ktXi74orLA6sHjtn3WX3aDnyltVjyZKfTB7Xm66ye3y5/JktgDWKyyYlNSez LLVI3y6BK2Nv+z62gu3TmCt6l61na2Bc8Yupi5GTQ0LARGL73X3MELaYxIV769m6GLk4hASO MEq8v3eaHcJZzijRtfMOK0gVm4CRxIuNPUAJDg4RASWJqS+FQWqYBVYzSnx93McGUiMsECRx 5OcPsKkiAsESl65chrKNJN6/P8EM0ssioCqx/0YqSJhXwFdi0qR/TBC7PjBJ3Pm1jB0kwSkQ KDHx2DmwSxmBrvt+ag2YzSwgLnHryXyoD0QkHl48zQZhi0q8fPyPFcJWkpi09BwrxHHdjBKv PixhgtgmKHFy5hOWCYyis5DMmoWsbhaSOoiifImLN14zQdg6Egt2f2KDsLUlli18zQxjnznw mAlTXEdi86WdUHMUJdo6Z0MtW8YosXJCF9zQtdefscEUTel+yL6AkXcVI0dpcWpZbrqRwSZG YLI4JsGmu4Nxz0vLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcFNSx it/xRZtThUKYxYc1G3W/Plzy5oNF1LE/Uscc1v2W73IuUvlpf7xM79Ye6dP5hl1ScQtueAfG pWz/6aum3v6v6b/Ul31OTHJsyxJv27XkvLe44hy35Ib5vX1+n53auTX5ZRpePP+c/0DTseFq 1R/V/jXZOyVu54tI8zWs+LpzXmTjhyglluKMREMt5qLiRABDqgZx5AIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/n0l6BfcR0J6HgGWaIqml24Swfnw Cc: Ross Callon , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 27 Feb 2014 00:25:12 -0000 --_004_7347100B5761DC41A166AC17F22DF1121B77304Deusaamb103erics_ Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B77304Deusaamb103erics_" --_000_7347100B5761DC41A166AC17F22DF1121B77304Deusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alia, the problem with stream selection by a transient LSR on the LSP is that acc= ess links between CE and redundant PEs would not be monitored. Thus I see s= uch scenario of little value as it is no different from "classical" RFC 409= 0. I believe that protection domain has the same scope, boundaries as OAM d= omain and that defines limits of what can be protected. To protect ingress,= and egress for that point, domain must encompass CEs. Ethernet Service OAM= (CFM/Y.1731) got it well through MD/MEG Levels in, for example, this pictu= re: [Relationship Among MEPs, MIPs, and Maintenance Domain Levels] Regards, Greg From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, February 26, 2014 3:50 PM To: Gregory Mirsky Cc: Huaimo Chen; Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 I do support this draft as a good starting place for a working group docume= nt. It still needs work - I'd love to see discussion of the two approaches= described in it - but I think it is a good place to start. Greg, the concern about distinguishing between link and node failure is int= eresting. There are four different approaches in the draft because there c= an be different deployment scenarios which make each valid. When consideri= ng the different cases, the concern is always whether the traffic might be = duplicated or not. Obviously, if the traffic source decides, then no dupli= cation is possible. If the backup ingress can determine that there is no f= unctional path from the ingress, then that is a different case where traffi= c duplication can be avoided. If the potential merge point does stream sel= ection (as is done with MoFRR), then that allows yet other decision points.= Different deployment scenarios are the key here. We did actually go d= own the road of how one would need to set up BFD sessions to verify failure= - but that is also deployment-specific and got rather lengthy. Alia On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky > wrote: Hi Huaimo, I don't consider WG poll as a contest in art of persuasion. I've merely pro= vided my technical opinion. As for your question, my opinion is protection of ingress LSR, and egress L= SR for that matter, is outside of scope of server LSP and can be easily add= ressed for client layer. And in my opinion MPLS WG should not spend more ti= me discussing standardization of attempts to solve these. Though it may be = reasonable to preserve them as Experimental. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Wednesday, February 26, 2014 1:25 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 Hi Greg, It seems that your reason for do not support is not persuasive. Regarding to your statement "The only viable case presented in sectio= n 3.3 where CE is monitoring access link to the ingress. This is well-known= case, e.g. Ethernet First Mile, and can be addressed in many different way= s already." , can you provide details on one of many different ways in your= mind that provides protections of the ingress of an MPLS TE LSP? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, February 18, 2014 3:10 PM To: Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 do not support Proposed solution cannot offer complete protection as in its root is miscon= ception that running multiple CC sessions between two nodes can help with d= etecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable ca= se presented in section 3.3 where CE is monitoring access link to the ingre= ss. This is well-known case, e.g. Ethernet First Mile, and can be addressed= in many different ways already. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 1:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF1121B77304Deusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alia,

the problem with stream s= election by a transient LSR on the LSP is that access links between CE and = redundant PEs would not be monitored. Thus I see such scenario of little value as it is no different from “classical” RFC 409= 0. I believe that protection domain has the same scope, boundaries as OAM d= omain and that defines limits of what can be protected. To protect ingress,= and egress for that point, domain must encompass CEs. Ethernet Service OAM (CFM/Y.1731) got it well through MD/MEG Levels i= n, for example, this picture:

3D"Relationship

 <= /p>

 <= /p>

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

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

 <= /p>

From: Alia Atl= as [mailto:akatlas@gmail.com]
Sent: Wednesday, February 26, 2014 3:50 PM
To: Gregory Mirsky
Cc: Huaimo Chen; Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.= org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

I do support this draft as a good starting place for= a working group document.  It still needs work - I'd love to see disc= ussion of the two approaches described in it - but I think it is a good pla= ce to start.

 

Greg, the concern about distinguishing between link = and node failure is interesting.  There are four different approaches = in the draft because there can be different deployment scenarios which make= each valid.  When considering the different cases, the concern is always whether the traffic might be duplicated or no= t.  Obviously, if the traffic source decides, then no duplication is p= ossible.  If the backup ingress can determine that there is no functio= nal path from the ingress, then that is a different case where traffic duplication can be avoided.  If the pote= ntial merge point does stream selection (as is done with MoFRR), then that = allows yet other decision points.   Different deployment scenarios are= the key here.    We did actually go down the road of how one would need to set up BFD sessions to verify failure - = but that is also deployment-specific and got rather lengthy.

 

Alia

 

On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky <= gregory.mi= rsky@ericsson.com> wrote:

Hi Huaimo,

I don’t consider WG poll as a con= test in art of persuasion. I’ve merely provided my technical opinion.=

As for your question, my opinion is pro= tection of ingress LSR, and egress LSR for that matter, is outside of scope of server LSP and can be easily addressed for client laye= r. And in my opinion MPLS WG should not spend more time discussing standard= ization of attempts to solve these. Though it may be reasonable to preserve= them as Experimental.

 

      &nb= sp;         Regards,

      &nb= sp;            =              Gr= eg

 

From: Huaimo Chen [mailto:huaimo.chen@huawe= i.com]
Sent: Wednesday, February 26, 2014 1:25 PM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: = mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

Hi Greg,

 

It seems that your reason for do not support = is not persuasive.

     Regarding= to  your statement “The only viable case presented in section 3= .3 where CE is monitoring access link to the ingress. This is well-known case, e.g. Ethernet First M= ile, and can be addressed in many different ways already.” , can you = provide details on one of many different ways in your mind that provides pr= otections of  the ingress of an MPLS TE LSP?

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf.org= ] On Behalf Of Gregory Mirsky
Sent: Tuesday, February 18, 2014 3:10 PM
To: Ross Callon; = mpls@ietf.org
Cc: = mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

do not support

 

Proposed solution cannot offer complete= protection as in its root is misconception that running multiple CC sessions between two nodes can help with detecting failure of a node (s= ections 3.1, 3.2, and 3.4). The only viable case presented in section 3.3 w= here CE is monitoring access link to the ingress. This is well-known case, = e.g. Ethernet First Mile, and can be addressed in many different ways already.

 

      &nb= sp;         Regards,

      &nb= sp;            =              Gr= eg

 

From: mpls [mailto:mpls-bounces@ietf.org= ] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 1:09 PM
To: mpls@ietf.org=
Cc: = mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting draft-chen-mpls-p= 2mp-ingress-protection-11

as an MPLS working group document. Since this call wi= ll continue through the

IETF meeting in London, I will extent the poll by one= week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 2014. This is of= course the Tuesday after

the IETF.

 

Thanks, Ross

 

 


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

 

--_000_7347100B5761DC41A166AC17F22DF1121B77304Deusaamb103erics_-- --_004_7347100B5761DC41A166AC17F22DF1121B77304Deusaamb103erics_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=18335; creation-date="Thu, 27 Feb 2014 00:25:03 GMT"; modification-date="Thu, 27 Feb 2014 00:25:03 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhlAOCAcQQAP///8zM/8zMzJmZ/5mZmWZm/2ZmzGZmmWZmZjMz/zMzzDMzmTMzMwAA/wAA zAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA ABAALAAAAACUA4IBAAX/ICSOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2yy0REAyEoCogqMomwrjLHgrACLNUsCahU/dRvs3vz8EMBABzdXpyKHsian6MPgBwh1OL KZOGMQgPcQwPhSyVPwIPZ6IlnI2nNQSZX5k9ny9xaQwqBLN2pKi5uj2hgZgMgzuvLAKbDwyFoaMm gbvOL72sCDDDPc0ppiS1MKF1YDDZQMox4c/meg+HoZE45S6q7BDb3Ljn9vcnYSMA+jvXL2EA8JuG TsY/fPcY2ILQDWA8aw9pLWyBgKCIUALr0FFEQM66QQA6rqFTZkxJbZUE/4TU+CCkoIt0BK1xCSBb yY0QXHZCqOWbtlkkO9oRChNNmUkfc4oUAUDlJ2Pxah3VsxLn0XE0VV7sGIwhV55gs6jqyrBlU5qG XuZ0OqajxzBrlhY9VDNuPYxfGcZsOkLktZsz5XqtFnZOuYp6mY5cWkzMVnVo8w7WE5NEoJNrqwYr Oe8oX451DhYU0exXqweoVSrc1HZ1pmPZTMuBre7YatKbkJFazVqebYU5Xe8sTEW0sloKW/nOjftY r01mUHPil9wk7J2i5bkmSHvb8024q5dNPkjVarLE0zP5YoLTd1vPW47n5HoWVAiymy8sNvrib1u1 pEbKLwqZYd5t1PUW3/9w6jUxDzMeibLgfeYp9x9visAGoDGWuWZGL5yYciBw3w1Imwju+DfCZfI1 JKIt36gyBiYzTtMQRhAcQ9Y6wZmhoCi1lGdKM9Rpp8hEDUqRIicylqVSOj1C0Fss+HHXmgjfhGJR Cdk16SIwRiImJZBgNtkPYtdkl+SaQmTHohn8+EgQYlqWBdKQH8o31pgMVnkLnM3AU5aTZfkI6Czz bCOmmGw68SCXEfrpJ5GmuDhNTTZOB2WcvrGjUHlAWTgGpbMsKmGl8qU4KGlqQEkCnv6FtOGR8liE TI7s4DgpQcqI2Y2u31xTU6NK7sTkQpctFEs/WuFnC6x26gqhLCtGJ8f/NteoImldOQazTTroESuu D262Ggxi8hmJ42fclmYRlP2Y8Eg5wE7TGZkjpAOsfXIMW1Gf4xrxqGWR/kuwbyOgO9sa7ilrIJJS 8upeuhOfy2+Gta44hjsqjSOlGZhkwvDGdRxLq5G8QZdjJx5jG+k/E/c1y3+qBmyEaHU9GMiIwAkL BmrPkpwvHfVASi2rK9NqkygwE80bkKhRafPUNzBabcu6Pb2qdsaMami1H59QzK23yGzkoDq3ajbN RB+jFtUCI7nRX6e6PUigC307MoplXHj2wXx7HLPSIzH99NfoEA22V72ZEo7JZ2MrBklCl63INHTj d8jgRupLUrhwD2E1/8JpS0V52M6qMY/jJSuOQpfIRhfXzIVrPvSvJDHFSkSh947CwHW1LIZ7uY+z zpNeox52dkmVIPzZx8WONa6Ue4vJlr6LUzSakV7eCt5r772y6bkPrDznnOutIlynP+odLjvbKjvq 0Z+8DXtYzn/LuYgfJ3HlweoX2bI3hD2tyF4LaVhfEJeN1SVvUB6blhcSWDmXYQx/3LKJGJQFMQJ6 0D+FeB//ksaQTJ0saeDjm/LyFRFgPUxFHmtGbC4WnGLY5YNBcFVO4HUtpt2wGTHUXzYUyJG/HRCG uGAdlmioLfzZDlNtgRKP4HEjKEFJKo9AoP1CFcXKoSNTD1RGN+ZVo/+mHEM7M+ogDnmgEJPQqFNG qkmeEAfEM+IKjVncmgS1ccWg0SpIxTjVjIaEAIHoY1PxWiMOMQEnQdWpIQEZyKqCRMaIEWoexkHG 6b54SfjsxkBQqogZEXWrb4jSWYr0gaCK5KymgOeUwSJIHSs3xCfN0YikmQ6dklij8eARPA1pEkOM ocOQFQg/0pGlKYwJqi1mCDULc95rXJU537zGJMYAzphSk0og8EM6ZAsQN62pnGwBTVBTAtogImi0 CXZNhWczBiaeqaBsCkmd3VxjyKDpn/sME59YkWeMriidNYhGFdJBzS1Cdi1P0hOI2bQFMa1T0Hzy YJ9gKkvU6sZNR0r/J5okFFEyT7gie26tUvKEEdBIgVAdwsQEOKFMHc7yUmg0awUxxcNOYmKRnFqU FzkFJFmawiCrgKRZPp0BTXHKMi/mlKg/XSNUC+LTpFLmIjWlA+hiYNUSfMYOZehpU6PKg6nuo6rJ mElXT2DWMwCMKs5znV62ag9E8o6sQTAfKhJVNLz6VUXmsOtff7oo7KVnRHQdrCvU2IiaJOeuiu0m O3WB2MhK1jY1K4xnLEuEtTZWMJwl61efsdnQKvIqpk2talfL2ta69rWwja1sZ0vb2tr2trjNrW53 y9ve+va3wA2ucIdL3OIa97jITa5yl8vc5jr3udCNrnSnS93qWve6/2saW8q2y93uere7hj3td8dL XvKGF4flTa96MeRXQKz3vd99KwGRA9/6bheyvXOvffc7wCfYkHIADrCAB0zgoDD2g/8tsIIXPGC9 4pB4DI5whPtq0ctI+MIK7m83v4DhDg9Yaoq0sIdHTAcNN6EYAkmxilfM4ha72MX8+SmKX0zjGts4 xvk0i413zOMUUzifyOixkG1sYkV+YchIdjGI1xjkJDs5xUVewoyf7GQc53PKVEaylVOp4ywj+cfd bLKXhxxlHB55zENeMnpVgmYhlzkJWG7zjQ/swTjLmcZbVmSX71xjMKdSzHym8Zs9eOZA01jNHwS0 oVs86CPYedEqzv+zeCH9Ykk/mNIv9nOI2YzpFTc6e4XudIoR7UFFi/rTRXg0pi2NQ1VTmtUe3LOo h+VXU3ca1b0L9axJTUBbYxrXbgDGrFMM6zoLe9iu/KmsRa1pJnN62MCGm65Fzevs+ZrS0Q6CqyFd bAJue9Hd9t2yO93sNSPbkPIFdSHPXW3fXRvS2RbHsYcdbt9929D1Dt24MV3uRD971vG22bQ73e7e vXvRAffBvQOd79AtnM8Np9q+Kd3vUv/71On23cAxXfDQHdzQCefFvGcdcao9/M4lt9nEIV3xXl/8 1hnP9bqR3XG4fTzQIefByeWccpvtvM09H9fKF91ya7/81zEP3cb/KV1zqt2czznfwc/RHPRxTX3M VSfW0A1ddHcfHdtJl/bMh930qT39zlHXwdW9nHVirT3LbWfT1gPddYN/Hd5hp9rSIV12m51dzmnP wdupHHc2Df7JhU/S3Plcd4/fHeF5n9reF933gP29zYHHweGrTGdvj1zUiW/Q4u/ceJs/HuSRF/jY d41fx5+bH6l3QQAGQPva2/72BlhAAXbP+94XYABIDoDvh1+A3N/++LYnDvKXP4DcE7/3AUDyAJ7f e+Mz3/YBCMvsr397B1Cf98H/Pu8dwP3kq2f75af9Agwg/vCLvwDrT/8A0iN/2itAAeKP/pDfX4D7 yz/7CIF+6bd+/+03ZML3fvGXfjQwAA3QgA74gBAYgRKYAEhWABJ4gRj4gAlAHAmQgR4ogQWAZB34 gSTYgPMHFgFQgioYfCpYgg2Sgi34gSwYgx6YHjTogfonZDeYgQCIDzC4gxI4g0AYgQs4hBFIgftn hBC4gYUxgkrYgCE4ZE74hCfIEz/4hA0ghFj4gljogFr4hDbYhQ2Qgz0mhmNohWb4hUq4gBTIgA5I gTDIYimIhCnGgHTYYwXQhhoIAHG4YnO4YnbIgXr4hnzYgHLYAHcIAAwYhUKWAIPYgHBoiH6IiIDY AFUYgFkIABAoEA1IhpyYiXUoiUKWgp/ohZo4hiwmigLhhlwYff9TCHwdyIgp1oFkGAAdyIKu+ICw 2ACyKBC0qGK22AA2GIIW6IDESIkrZoGyKHyoOGS8CADFCIXQiIwqpozAaIE9eA8pmIsOuIueeIqV CIo9to0A8Irl2IwqpoqK2IBsWIrPGId56IiOSInySIyJuGN56I4hCI/yOI8UWI/QyIRh4Yj6WIhZ GI/ySI+OSIy9uGMEeYrSyI/9qJAJQIyX6IOZ6IRI2IkD0I8jGJAVOXviyGOkeI6Q+Imz55GGGI8F IJKtOI2mGIu2OJFj2JGOOAAlOYqoGI0ZyYszmZA1KY84KYzE8YxuaILT+I8q2ZIAmQDfaGNGqYtJ WY5L+ZMh6JT/aBh9POmLQUmTINmSDIiLMCmJtGiTQPmVLjkDHcmHToiTcTiFJ6mLa7l/cNiWAfCW RwiRltiRgsiW3XiXhgiXlCiXDWljBBmMJgiYWSiYFCiXF6mNWciMUBh9nciTXuiEITiSO0aKkumT p9iZD2iSz0iU6bGNiomIudiSEgia5YiLp+mU56iaEciaAhkWnhmazNiYESiblfmUNXabXpibemmM Vyh82WgPpvmDsEmLlhmYxqiJrqmcuQial/mcpBkDazl9XjiUi5mXD8iUFdiG0aiIeLmEesmUfamd hsidokmI3yl8Iiie21mee/iej4mcWcidNfmZzdmdccmC5OmA/7PHn0GokZrYisBnjLvImw9Im7iY oFC4oFcooFtZm2Dhk4jplMIJgsXZkkiGoSOooRaomxDIoMaZlRDKi97Yn6LZmA8Kkb93jtTpnHHZ jrLplLLZnnFJofdoY/l4o8ZJo/XJo30JpDnKmHp5gPEJjTCIo/TpnhR6n+dAipm5kgQagaKpmgBa pQd5pZuImSnYii1ZjPApk6sZjS5qgGM4ppUZmxName45jNsXoRu6m1dYjr5JYz5Je3Q6osM5maGJ lZhonGR6lWtaoMSpmTa2jWy6pjLKomB6nTCwlllogrvXhyrWgXB4l67YozWWj5VqiZeqjue4qXdJ lX0ZqtOXo/8rpql8yKnlWJg1RpCqOqqa6aqc6opSag6kiKM+qZueWIyveqoWCKC+Cp6dmIyGmKvT KKa/Z4jd2YswmKvRF5ZqeoBuCJ2xOIljyKwMKKdO2Ym+eo8Reark6IxMOa3jmorvaK5nOKi7l63d GazLCqvFeq3xCq0yqqyRaa+S+gKUyoy2mKMIGaLQyHuuSpeaKLAhuZI0SYG9p6mpyrAE+7AHu3vb KoWNSbESOY+UGLGWqH2L+azTB6xm6bGKiLCkuqgjy4Al+5kn+5GrmofseH5rGq5aKpMq2a29t7I1 xqg426u/SpN32bP/ihA+2Z0L66c7O6a8l6zoKrRLS5Ee67T/u9eJWZmHKZizXXmWM/uR+Bq08xqz 66myR9sClPp7jXmk3mmeCquia/ukO6qBqaq2msi25rmbSwq3dyu3gwmBu/oMvRquM+mlgYqlakqV 20irh4qlgimmi6mdbnqmiKuTzFiOkmums9mcciqqz1qnJfqmefpiSbuqDAi67zmbWRu5xcqciLqJ +Mq68wqpRKiWjYmji+i3JEqIb4u7SeufQ0q3TXi7wpe7Qgql37m3vou3wduNInuOrfm3Mwq8pqiT 0Hu7hludEAi50xeMk7u5lTuOh9q9t6i5EDijnft72om6iXq+H6qa6ouNfsqhqguvouq9ruu44UuS 48uUs/u6/w/YjsuqjLr7p55KY6AamQR8vHP7hqmqwL+ro3+bvBoLjszIvMjrvCjYnThph9nLwIr6 sxwsksBKu9trsxdMmdH6po0bmrHroc7JoBRau4WRtHV5qLvbvg36vn8YjOwLqOe7ujD8v/oLu5ZL wOCYv19Kw9ipmxJar7k6wbwrZAn8xP0axTmMiA9sxcPKqVIsjRWMlJrbxYCZxYHrDEJ7jMBKrfi7 v5sZrVPZiWxcvkxcGIxKidm6rdQqv27MssKZx+3KqXx8wjUsm4opnNRqvO4btXIMp6Z6l4rcoKs7 iDI6x9TrszR2x5RMi5YswWxYjBUJicVIfIjYnAf8YnkIyv+qDIXDV8pHKIir7Mq82MqhXKLxGcu1 TMq1rIsiS7MVqamjPHyxKJgs6MvGzMq+N8x13MsjSLO8CMzJ/Mx9LMLOXM3QDLLOHMBFmcujfM09 u8sC+qHcDIXe/LTgjLWYaM3kPMvRnM3VK77qLM3Ep8yEjJ1ieMou1p9AaKEIIZhDKKs05s9AeMa7 wMJDqIZGyIViiNBDGIZdOLouZobHOaVpqKZiWIRdiM8tps87yM/4INA7CNAvBtI3SNC6YNBAyNBA qNBdqNI76NBYCNEtJtFouNAW3YUYjYUazWIcfYMefQ8kTYMi7WJBHYMmnQsovYMufYMsjYVLTYMw /YQyza7/D13TLX3TW6iW91yB98yBYjjULVbULXjUqJDUN/jUMdjUT4jWLRjVSjjVK0bTmGjTOnnR Wp3RXJ3RXt2FYM1iYq2CZH0KZk2DbK2Caq2Ehe2CRSmGcJ2OjG3VTo3VYHjXOp3XOr3XWNjXrSqG gd0Igx2DiU2Ch22Eof2Bbm2EjZ1ico2RdC2+di0DR/mEO82vl92EXy2CnC2yrc2/r00cn92CpV2D i/3QH/rYc33VdY3TlC3bli3bmP2Emp2pub3Bu/3GvW3HFZ3cWV3DjF3cVX3cka3dkw3bW52Eem3b fI3bXdjZjPDbKyjZa2iz1c2y180TEu3dMQ3Zaw3fCb3c/0o429XY1eid2eqNheztB+5dgsGdgaN9 0Pzd0MMd0/gt1fqN2A++0v4duh0pyjI8xXiYgWAZorb6ygPOoRteyh0Oxo0I4inJ4QZ94H2Q1AmA k6o84wLt0jMumb984stM3ReY49GYh+o5zZmcgUBujDOuz6dtn0j+rKs54XZ6lKkc25IM3kdI46Js 4xeI41heylougTmtt7TnpgaZl+YNgooooWW+hM9ty2Muk2tOwSt+gSH45p754ro9gWk+lXd54xfe hsDnp31+gQ2Ox4Fer/qs0oAOk6+q5BEegTR+yJB8gantjpBunNM66atZ4YQ45oKOmET+Yii96J8u 0GF+vv/FyKeG+uPNjeomuIgS7MAl7up7+YwgHd2ziIGSqeqxboJ5DuluqJoQm4Eqzac2PJZgLt8S aOw5SuVG7NrLHuxx6OzazN16PoICm9SV/qeEiO3YqO2c/uqAOuwYWOzS/rEMnuEn2cxbK+Ot3u2A muIOqABuUe/2fu/4nu/6vu/83u/8rgCszu6/S+cFbp4CL+8NSO/+vvAM3/AOn+8HoOugTJXc7sLi 3aATz7gY+PAc3/Eez+8RT+kZf8nPztuUS48k/4Afv/Is//AYyJt8Or3h7Ix0/oMx39MH0PI6v/P1 HvInr5QV/84mD74KGfQ1S9567p4IT40fnvRxufQKz/P/Ur/zAO/0g7n0uM6VVh+3GRj1U//1He/z RbyYWVzy1g3AFO+BYL/2LC/2S+ycvY7Jol7uTni9Gcj2eO/yNZ+oMg+1Orj3gNr3DZDzeV/4EE/3 l1n2Fg/tY5/26Y70bTuaSw/gKabPJJqZk9/myIv5SZ31vX75fZuBMM4HKD2Wjl/uF276Gk/oyo6l 40nHqH/xXvj6Ke+ASz7wN8+DUK7Dua/r4X6QiW/0IVzkW/76im/76r6S4j757z77yy/jmu/8tY71 Bb+JqR7Jy/7rgBvsmnj8cu9iKM3s3S/8hS7+ILz4Q7/90nj+yG/tkS+wPb3tGEii8M+Dv2/+3j/8 c3+B//gPAkAzkmUDoam6roNZFkFRAEkTv2UC8L3/9wq5UWxWuwWGowSr6XxCo9Ip1DYs0mw4JQ3o 9Vlz2ON2OKCi0+q1KjnczWSNnXL0vQPcOXhxLqqzBQoONum98Mk1HCnhfRmaIAophuUQWl6i1QUM JNCMJA4FNHppcno2gOYEYLK2QjzqAMQJ0dWNAsGSRPrVnbC5KA3wSBYAv93+SJoNExnvuUKzUr4I yzbXdSHzTJtUEztTR4sL5pJ0ASeUk2j3qN/woLv7jtMHup+TBHCXsPPcw+fbR6IewTS9ROkbMUCZ qn5/lCC0slBTwYqFsAGcI8/hPwDxegUC12vkjn4MR/+StKiyiUCUYhy2dNltJc1XMl1yvImyJk8U 8nQq6vdTZ0+aQA86PEqxaL2hN3MqHRIy6h6HJ6nOYWoxJtBs2rjqPKO1KdYXUMsOHGvRqcyzaOep pfc2X9K5qOJGY4tTqF24aURSLcnuamC89MDe9IoMsUyxhl3pRekW7WOydieXrSyur6h+nDVjijwS M9apcwVrIxyVCehWjF0qvvUapePWhET3Ik3VNjTctvja5c2Kc925q4Tb66s7qum3qJGpVsoa+aDZ I2OPst6rNnU1vhkBn9v90vchy5WOH0Tcs93j6amUz3H+aHO0z29FPzr9fRrtGPv5Fwx/acRnVnhv DZj/3GUHUpagQe0V95Z7DjpRoAnzAVVfWfeNkh9Q+1FYhV3YNRKgGSFGYSE/DGaGInzKsViai1Gs x85nM66g4jox7vaLLgVQ0okNnRAxg5GxmPRjkEDOQYyRM+iA4xNhQAkDk0Te8CQlJOJB5UkzDOmk kZRwJ6VNS1RpDi2SdPLkheG1aQKUWLZ5ZAlmQqFHnFYSEaabK7KjZ5pF9tnkn2nhuQKfizKZ5Zgl dGajmnISY8WTjX6S6JmGUlponYMGFeiPX1ZqqJ2IqmEMDc4II8QWAcAKq0e6WGXOrCS0isQnsYpi DIiJhiEKQ6Jo4UYesVpDBEx0DUuGsbwm20CZUuqZ/wcM1tZCA7KGnLWDIdry8s62d2rKQrXfWjuJ uLJyC2e6yhqrxbEIkVsuCiu++Ykk8wpLF3t2PASwvnZAq8yE1NKKbrzr0rujqEu8K64d8o6L6l+2 GtLvq8rU4keS8EJqzca06mIvCsHeCnCxE5ujB5d3oOzMNrqqS4Qe0+JY7SLSYvtHGYoo0+3MCvVs Mz/KmNwGrTsLs/DP0QrNdLrOHm2xpisq08XANdOMSoTMKPtHIjuXcXDOS4fRNMtPB+2u1E5zi7SP Ni/iratupFJ3rXRbYTfNefeddLADuCzMylx3/PIXgxdONeIP4TxjtRN9Qni4P4MiNOWoWJ5txnIn vf/pDptvAjekbT/sB+mWq4s56PbyM4Axsou9bxgdR6pN7LMLs/XOuGs6ucGsO751qNoInw/xhxvf XAyUFyPHyOv0vTcS0BN+t/E1/4pnsFkoBP4WZLu8rL6LLOQ4+bjaW20xEOPg+ekOI0/r+37E7/Pn VpfrPjqymC4fqKsf/P43Puah4nXlOpoeZFA7lhntE18r2ynGRqUGBs9+Bgyg8YR2PzhwMIH8m4Kq ZACMhUgPb5xIQAJY57HBtOx+KNQe51jYQj0JToCU04f6gNSJTdgKQDqUBA8PJwsWPo99/aNVtlB4 OX0gcWdCa2L+bGZD8I0gdD5hos+c2DoodkKK7qL/ItyuuLPQ8SMdQ+Kh73yYRAn+axIJUeMDgYZE IGYqUdUi49rAiMXjIWOPXTwgEswYBuexUY40zF1CIPaxQv6hBimEoz9ul0N9vS8dXwRYD5yhOC98 L5NJUJ8PWNU+kiVkIVV8RzsYIjRU2ECVSciWD1KhRdGJIJVxWFstXekuWEprl63rZb1gR72JFKMW YytlyOJYA2Ryoo4/cIbZJIfKWAqTDMSkXyCvGUxCesWWc9MVFJMwSRFW5ZE4KKcIp3eISyaQDu9T n0A+CYTvydMF9DzREiEWzEms8mdvSh0dJlKDgKrjltX650FDOFAC8sKgP+yjEtBIPRwsRJm2C8XX /yaaUWkKpJouWqhEwamOV5bUocW8mNFU6YJzpgJJMGzpDF66SNV0z0zfg6Uc9vkSIQ5MHz01okAi N1KSxUCTCAUPQUWQ1CQsVSpaXOhTaVY8AzW1kFBV6QjNlEZFgFWjEHxB7pDxVRGIQKxcM4FIUURV oVoVgQ/tpj+ratKKjhMHMZADTHFqPb3CSgh9fQM85UA7iq71WkAV4WE3mVglZtCfipCdruRnnl9O 1gVRrcRUSZbZuHYNqxCthUc0y9UsJu2rpQuXBTnqTBusVq07Y2tkw1Va0AoUUKONJGXvKtU1lFBg 7cSbX9VprAe6ExKFddXUiHoF87WzuaDNgVHd6v9Zjc1Sf0zdrQS1Z1nOhm6hXqPhVed6C/FiF7Hg NSbLhOEC2Ya0ozx7L0hDUVtliuy0gDzvdfOr3hcgclcDS65MU9MyAQ93e1Ey2U6BhtjZKpYdDU6W T8PRz8tp97uipSuGjaZhEyjUs6fwrXwwO2L9WpRlOxhSfRvyWj+w2Hchva/PtOvYEmf1HREs70rR AJjVWM8+8ESLPX9gIuqeckGpQ1BnlQxRJpusRrprT23fgiGijNM+Qd7QkMtSZDDYpboh0hEnn9yg 8MJoyWdmr4QihJa2jjnNZm4RcO3CoUZ4SCc5ldKRX/DlHvR5Jhe2Mo+Y0+S5XPkmKW5zHN9cZbT/ JFomIbEhpStNaQdYutJ/hkemLY3pTms6aT4EdaU/DepqDIbUNjS1qsVMITCqmoWs7jRHYp2AWZNa obZedaxrHWtcgzp0u2ahAhSg6rLKJtbF3jWcXz3sW/daKLYGdqcJIgAGOCTbQLj2LVtxbW2Dmwfc 7vYlHhDucD+A3NBggADOrW12q/sSBECAu7ONAALEWxDsrrdD4D2Wb/ObHePOtyAAHnBkDJzgazD3 wbWRboVbYt8Nv4W/Ib6GeU/8Fve2eBoknnE8VJwpBv/4FxLOcSqMnOTbZsDJ08BwlX/h4S1fg8dh /oOQzzwKGLc5EDaecyjUnOc8wHlPUi50k//c/wlG5znSk76Clwu9BzJ3uhSCLnSiU10FO486D3ye dRVYnedYr8nSbd70r0Og7DA/e9ahzvWpo70JYbf52L++da57Pe5zh3ndV6J2lbM9638neeCd7vao wz3uK9i7yvtO9btHPe9oZzzJHW+RwX+88E7HfMY1//PDCz3xik8B5T9u+aRDXuiS/3rpM376gnB+ 4p7/eewbPvuZg57noh89BFo/8dfnPPU8X33Wfd9w4Nej9ge//cyVH3Dmnzz3Nt/96I1/cOS3XPg2 Jz7VrR9w7I/D+fyG/snFX2/yW1z6MKe+4r3Pb/BzXPsw577T3V9v+EfD/O5Gv8X1f27+K5z6qf8c ++ldu3Hd0AkA76WA/Kkc/SWd/bkb/kGD/4UbACocBYKbBeabAJIcAU6eAR6gBCocA5KcA/4cBJ6b CHobth0gAGhgvmGgtr2gunHgx3kg64Eg16lgvpHgx5lgzqFguO0gJsRgts2guhWhQxxht9Vgxt1g 8eVg1A2huvVgxv3gzAUhuE2hJSRhPyxht3WhwLGcAjbhxD1h90Xh1SWgAkJAFU7cFbZcFr7bGmpF GGrDF96SHSLcGPJeGTbcGdZfGoodHfKeGzYcHJ6cHGbbFhKCADwAA0BiJEriJFJiJVriJbJh2j3i JXJiJ3oiJLLhJn7iKJIiID4gKaLiJz4AIY7/HgGk4ityIr5VHyzS4iSuolq4oADo4i7yYi/2IgIg gC8K4zDqYibmIjEiIzAi4zIWowIy4zNCozBmogpEYzVGIwBkojX2IgMQgDb2Iu954y6uYjjqIjY6 CAHI4jTSBDqqYzu64zsCHSvCYzSYopmw4zwWxD3i4z7yY/vJYz+W2wimI0BCgz4S5EEipMIx4kHW o5QYZELK20BC5ERSZLksJEE2JI48ZEUGwkZy5EeC5IBcJEBm5Ix4ZEhSwUmi5EqyZGWMZD+WpIuo ZEs6wUzS5E3i5Eq8JD/GJIrYZE6iwE8C5VASJSvs5D72ZIgIZU4uZVE65VN23D8SZVJSSFPe/6RV QmVWauXiSeVQUuU5SmRWYuVWkiVUHiU+fmWCjCVLrmVZuiVQnuU8puWAtCVK1uVb4iVLxiU8ziV/ 3CVI/mVeCiZH7uU79uV7BCZHJuZgMiZCFqY7HmZ6LCZFTmZjWuY+PmY7RuZ4VCZEduZlgmY7ZqY6 bmZ3fCZCnmZoqibvjeY0liZ1pCZBxuZq0iYUbuVrIsds9qNu1mZvYmFXAiVuCgdv7iNx+uZxKiRw 5qRw8oZxzqNzImd0dltrZiJz2gZ0viN2Sud22gt1hqJAuqV2cud4mol3kiF4lqV4kud6ooh59iF6 kqV6sud8iqRy4qR1toZ8ZqJ+0md/Uod7jv8efoIGfyoggfrngYIGgCqegGqGgbZiWCJohBKcgsYd g1aGgyoehkrohhYFhaKdhT6GhqKdiHJoiaqEh34diBoGiWYdi5roi9IDirYdfG6li8LojbqCjFKd iuKFjaIehOJokLanfd4kj8aFj/4ckrKkACAAAwRjiBJpTUYpfeqo4dGoViqpXT7ivD0AkEppPdxi IHAjjlZp0hmpWmRp9nlpfwJAly6guaFBmI6DnNLcmiJomX7elYqlnc6nKz4dvrUbCjSjAKAjNjoi AZgjOq6hCwIAOzbqQCpqCuziQIYpocpiM6ZdAlqqOY7pjeJpzp3pWKTpyY0qRwKjE4SpnxL/gCi2 6QPcIgI8ops6IiQ+AKwygJtCgK3iKq3yIQTc4qreKss1aQqM4ybCaafC6Kfinp5CZalWJLI+3Rr6 aaeO6S06Ijauqgu66arim586oqYeK536aru5KQBwoyMKaro5KQqcKrSaqLK2XKhqhbNCHL1OpLsS q7SyXJeaIwq8KgIQazfCKbpqYhsCLArA27pG68BtnJueKpy2IcvhK4fCa/Qx61PaK0RKXjGmKsut aq3K4i0i67k+HMGiqy3iG76uIrBKYq4CLMlKorryqX9WLMfJK1NkLA/O7Hr6KdjhW8eiQKPC6s8m 4MgKbLoirZN+o8oSKrvxYsS2qSYu7c5S/+mUsuTNFkXOxpvWHuS3SuothmmTMuy+JmDPjqvJlmy6 zVsKbBzTDpyjdunBVurLUu181mz6XaxTcu1BQqKmKuy6zqqv4pu5Aqys/irLoS3Seu2qFm1YrmKb AiquNqksOunQ0S2ZWu1KYi0U/FhfeG7JoF2g8dN2mqur1uqbuuqwfuwjYuOtlq3pgivSFmwbmi7l Ou7rpu6bmuO1uSq29V7dhubn5lHSkZnwgsQldK7x2lnciS6SkWc5rgD0pkAuTm+gZmq/SoH0TgH1 QgGm0qfxNpvCFa/y/hYhJC/5ClnoCq+rCWn7bobwhi/BjS/6ghjy6gKlCS8LQULfWNoS4P/vgn3d NOivDvCv/9qQ87pvAlvEIQhwAc/B/9KW0+kJBPfFABOwAeNv//ZYc5RV84YMJRALK4FZWXEM87LV bIXw+BiZoClwC9eDgeQLOt1TBBNvEAWB59IAQ+TwC92wYjgDJhgDKBgOccgMj6GTji0BIRwsg51w ETuXQoAD+7rwFLOBgXAMD8gYroBD/CYIoQ6Cy5RPnukEuDBLuMjJHnVVqggQpPjKa1gwpMBKyxgx 4CRxIFzbEtvLNMSKHD+xGSsEFQOyK5gFHkmLKGSxZOVDd9KbgoTWz7xxLzwyEgRMHtBCwBzYGqOW JQSxDrtBNsBWJa/RZAEaW51CMM2xKwX/zho0qqsCb4LocSmnTx93zB8Hci1bgllQUIv58V2Uy8e2 8qY48h8IxiIR115lRMskwl5VshjsTyabLyb704oV8j/t8DwlBCHryw5Jc1L9LyiU8p45wSqbrha9 sjZXGGWVgBTb8jqzgFlI8yToMjoncrk4Yu8CLxhfyCe/AwtFUiSFEXOdsQz1wYr9bxm8s18IwibH Qtc0lLRQlkERwyPIQCahlbzUEiWBTVagHKya7pai40eDdEiL9EiTdEmb9EmjtEkrAClTtGPNcAko QErL9EzTdE3b9E3jdE7r9E7zdE/79E8DdVAL9VATtUm7MzTJ1gqXwAEUdVPbdEdvaZTi/3Ma4Y5g sRCsXDVDbwlc8VQl/0DYdNIGj1Mq0AEoyEBZa1JCLIJAnbVT6ZNcVc4BA3D2crTpcqNT4zVNr/Tp 5JNLj1oOxHReC/ZgE3ZhG/ZhI3ZiKzZiu/P7fFQbybUJMPVi5/WtdvSTTsFUXxQ+u5RLaTUMjBI/ i9AstwwFIzQHc/IRD1Vo+3MErbE+SFRoQbNypQGT2jU5kzIsxTYhCQg7+/aDUHVFw9dSaEqrsjL2 SoFm80IZ6JUqFQMy6cFsYVRNjbYluzaA2e/2GJYxWIPsvBQ6r7VEC0Es39j8PMMa2La4asorm7IN VBgC/3Z8Q4E7J1B2HbJ99XLqIndmX/8yFCOxQ2tEOSVEGUg3VMmOYC2znyVUdh9x74QLLTHXRsm2 9EhXbh0xbbPBHQtbbpPxe1uYfIN4E9C3e7GWhOO3pvQtIzP3IrC4FWBxULh2gXuMPpP2ddevJvtL JeFKHiTLNre4jY8NMGhTMlz4XKsyHpcLe0/Wg8WEOod4INP3Dg83RNAzknuHDWe0tqQM6+ARgW81 gsnBfWwVXuE4BnMDmOiALqi5/+4vm8+BmR9wJNdxALf5Ay+Bm3OFkz85FR/Cmr+5nf85lUvw/Ub2 qFwwoFtwA+M5/1YaoK/XIJwv/RaG+n6unu+5C4Mv1c2vpDszpHP654Jzy3kwC196iGf/+qB/uucC capXsAlXeqnv+anXMKsHB4PTOpdRuudaOqy7r6z/3KZzemjwyrATe7Eb+7Eje7Ine9wpe7MfO6+H uLNLO7RQHb9M+7Vj+7RD+7Zze7d7+7eDe7iL+7iTe7mb+7mje7qr+7qze7u7+7vDe7zL+7zTe73b +73je77r+77ze7/7+78DfMAL/MATfMEb/MEjfMIr/MIzfMM7/MNDfMRL/MRTfMVb/MVjPIiHdOYu ICt6MRp8fEdyfMaTPIiL4q3+srsSLMrFpHqX/MtDu5yabSMC4sqzgcvDfM7vuZyi66QGZTcKKh0+ bdopqsxFqqA2qtDLnKUivaQaqj7i/7zOS318y7zHWnauxiq+Dau/XlvkRuLD6WrIovzXBmWsSuyl qq3Zc/3Us/2Td6kuuiLAcqsmYqu5Je6YnmrvpZvXXquv+i7ZQy4EmCs6jiHGlWu1jnzbKz6OQvUi 92zeC27kt2vKyuKqGizpJSCukj3DCmzrdiMfNmziL/7ol6h696zRuuzvqn6lqmvMEm30pv0k/m6b rrLsRz3p476Qmv4Yor4rRu3qr+HJBuPTiiu6uuI3AqOqOu0ujmvuU3y2Q7+zu2P0K/t+B8LuByUf 3iLkHuyYdqrlry27vj417j0fsmPcA6r5jz85UD+yW786tn/8E7vzV8aoY8Wut5yvD/8C9kstCEAE A5UIQ5SoyAAC80DCI4g0dJflDAFPOkvhGDUf8Ier6ZbM5rIBjUqn1Oo04Mxqt9yu9wsOcxPWsvmM bgzE7Lb7DY/L5/S6/Y7Pa8npvt+6pic4+PZniDWXszSiQ/DwqGQDoCIE84AQY/MopLiT6fiIoHPS +HhZ0tlm+IdI6Poaxrc6ixYIe4ubq7vL20soSxtcZetbPCd81voqIDDpxczE7OzlEulUbYdspmzc PQesjUzsTV5ufo7uTZYQcAU+HABcEN8wH3B/TzaAHzAQNZ4uoA4q/absgzKgQAN2+BISFAhRC0F/ Ug6qUcjwnsMrETsy4UPvn8Iz80b/QilZj18+NfwoqvEIM6bMmd3WAZgC4B1BACYbBMiZsoBQoWTu Db2HkOY5KgCAQknQFEoAjDyFDnAahZtSc0yxQr3pk+rQq+C0biXHB2tYNAUAuFTDM+jQAkWnCkX6 8qzevXz7ZrGJU+cVt1G+kplXZWphoAC1vPB7p6vJtmAVQ6341idkb5KjUJZKFTPHzXYEIJj2JS0w xSSjZo2LmKBJqPpI276NG+1CsFGA0t3XU+pVz2RTJu7J+IsjUbkL4RzgEnrl0J7bSTHb3BVT6P+G r71cfXT2N5iEpIaiVjFdlFPs8WGoMPYV5LXH27+PHw5gKUCbSi87Dx8J+WbdfIsl/8XFC5DkBwZT bfX24He8qZEZdgxmg1OEDfA03W6iXXdhGKAQcd6Gqyn004DBzbNRAcAZJ9uBeYVIY4347dcbGYRR ON9GN/kGQEtS2WUPglko+AgJNkoUGD3sgGdZVS6qpdmSkTW5TjwdQjUWlRZa2YMpl1jzF3on+mSd hidNZV1C6gXZ0JBHtQlmnXbuhaOZJp40YViIsbNnSXMNGaeRTIwg5gMMLMpoo44+Cmmkkk5KaaWW XsoAUwlw5yKUVDUUXAMLYEpqqaaeimqqmnI6gKe7gUrFqKnOSmutpSaqKJkf6ZkViiaphRhYN6lH pFCEavTPncouC1OeezoFXq8b8v9I4HHDZAEAoqYQwUy33n4Lbrjijktuueaei66miE3larSAoAtv vPLOS2+94arbDrtb9knFAPb+C3DA81qSpHll7iktawiv6We+8RV4XagzMktxxbq5++x7EK/Fpo6H bQzatVsg+QBqdmpq4k3t8iuexWGgnJPK+yZj8QxJ6uqEahGvxSvDLjpErLX9ukx00bqkNZmwI3G3 85R6yrfz0F2AYvDJgfl00Mo0G/0Fyv20o/U2FmNCYokFPQXU2Woax1BRDwttENdyz42HgDwl0NZI TQnlJVUUETgXXTzHTQ0CzCmLct4eSrg13Uzyd1hcYZfxpZUrxMLnenj9dNeK1rn/RmzgbovseOmm Y85nkL9eFZdBI7FGjz38KLQR4coxS1CWWSKEEcgtnz6QOws52WbvjS8LjRiyzONfVvvsKIWLCFHk kOz40C5xY8Bvv71gOYaThvZyg58Y90+Q/3v3yUiMfrLmv6++GVS2X9H29GcFPwT3S5W/9yHvb7v8 CVBu/lsYAA1VOgBWjm4K7N/6Dli/AUrQaAWEYAATuL8Fzq2B8KugBd03wRBWzIMfnBgG76fB8WXQ gSWshQhfCMMYynCGNKyhDW+IwxzqcIc87KEPfwjEIApxiEQsohGPiMQkKnGJTGyiE58IxShKcYpU rKIVr4jFLGpxi1zsohe/CMYw/4pxjGQsoxnPiMY0qnGNbGyjG98IxzjKcY50rKMd74jHPOpxj3zs ox//CMhACnKQhCykIQ+JyEQqcpGMtA8BToAAnOWCAJJ8RtUaiclM+hATCEDUJeEggE9u4XJt4IEm T4lKHDoiEqusAyPCQEo2mDKVtKylCGMJAQaIoluUXEQvd5CtGoSSAJMwTdmG6QxeLuFy2epl8mRQ BAL8cpa2rKY1uZcKRjQKCRAgGzcV9QNHLIoGI5KBohY1CW0tMwUAYBQ5M9FNYrpTmPC8pj3vyTVq eiKXLWCBOek5CUVNomwreOXlCspNHRRUSYzIATkZSgJ94nOiFL2TRHmgS0+E8v9wJOJmJBYaJiUw 4pXrzKUQfNBNUWjzpDGQaEVfCtMLzcBkK9UBDRyFhBwYcxP+nCUPSKrQFJxznKEkgeGGME+XxnSp TM1NQk0gClLeNJLeSgIqqApSn8YAqJTAASW71ZSSdfSr0lBqU8+K1r2QQgdGyCVzfnq4Tlp1liC1 qj+5atK89oBEKMgEM7lVz7QKdrA0mUEkZbAoFdAAAEedQQ1aeQPH2iAFrzScC+pa0hHUYK0jYI5m uxnRwBJ2tKQVCMn6yc8kOQMU31QCJhS1yhmQoJ2hKAFeD2oKJQRBobk1Z2l/C9x0dGudz9xBM46k W+PqoLhdYG4TnBvc6ErXHLj/nK51r+uy6mJ3u9wFE3S7C97wine85C2vec+L3vSqVy8qaa973wvf +L43DvKtr3zfYN/8ttdkbNCvf/+rkvwAeMD+pS+B7YvfA8uXv2JQsIPnu96IkPCD4vtCZsiXAOeg MA4TtmCFbdNhCH64CxcGX4bdwME3hPiAI46wMVYMwBZvocThOLEqVqifFrrwRjo+g4y1QGNt2JgN KXYDjPf3Yxfz4sj3S7ITgoyMIYuhyG1gMv2cjKcemwHLTICyMKT8MhyrWMtl4LKSb7GOFVXQWNET HN5EV4/AgdANmWGzZ9w8ksCFCswNas+K8swHOKdPeSeRRwXxBgxEL0TPh5Ez/wKzk+b2rPnPaYaz nufchjpTetEncbQU+Nw1P4u6HoGeyztSuIdCR+/QgisMni3taTOf+RXOmt9OevKTyKmkLvjYkaxL UKHWSaVaaOp1ZkDtha7gpEMb4oew+ZdjAyqsDG15y1XiAyd88Poevs5PrSvIuesAadfF5jb14hBs XBNbJdB7ioZ70yfQ6c3ZwUH1wdLDvui1+9r1yPZK2H3uWaPj22hIEX+IbSC0PXoJpuFCsN/SlI/9 b3GFeTd6hP0ZnmEFalXSwmFTLe18eyZI4n5bjBRuQkhTvGeUa3fEYZTwxVW44TMeDMTXPZs+IbsL nUnd/za+scp9/N5nag3Ewv/N8YmD59cCFwTBG31qi9SjOEkf3J7E5whR6qBCUp+SxK2ulp1zYTvR 8Q5rvNKnymUd5PheSAIU3Z5coy1oJ9cT02fy9DhHvUBeh3nU7K6Ftdf8Ol2nunWmHXaLb4hpFGI2 2ge9iKfuKuRuh3v05P4qk8f86k0/B8Gz3TenDOjrm0/Ocy1RSWDPR/Rt+TriE614nhRoKo5fXtAT dLOcsVwx9I57i15U9denvDmf7zWAWI/wv3P+9AsafK+Q73r6fDr28qH9z20P+eXmvgk6S1ivPfd7 upe+Pp2/WLx1RL0Kueh1tJHLUITz9k3RieEEOxyQe8T+dbfq7VJ3N4qxNDz/rrIhdIE3Z4M/XPBa uTJ5bYcXHFcS1IMSgvJ+WBN/FnF3MvF56Yd/UtF+Eshm/VCB87dc9UdiG+gTHXh4+yd/UyB2W6Ap xCOAd1OAFdIFCVg2OtB9IdOAG/OAvBM6g0KB/CeC5VcTK/cseRZ0VjE8geJvFPETTREkAlIC2UIw BSNNV4iF0qQA8yE9gLJuUBiFU6AAWUiGZXiFqxIfreJ4YHhhB2CGWFiFsOUMOcgxFNF+1QEeOfEm QuITYBgSFxgTn4eEXOgPXqhrhfKETfGHU6gt2/KGV7iFEdOF7fCFUBgSUTCGj/iIaDh1MciGVOCG mhiHKDCHu4cidggsWmIm/3uIiH4ohUSoDkbYH++RdnRxE9KTfNIiNSKQgFb4iJHYK5eBi9FnBpmo iWaILxcRg/4Tio8Yh3JVAnTIe78iD/nydg7jd7p4QSqHMbOIcsF4i/6QixMXQbyYKCigicAIGsIo jsRYBsZ4jGSYjAmxjGbQjG/4jOYhjb7yPeERD4AifsqHabDYC59HiwYSD4oxjlaHaaaxLSW4Mwmp EDhnBi34ON/zI4tzdv6zQPVHJvs4OKl4EdITkNpYjvZhkN+og+wwkaQnkAjkkEkCkQnDkoFyeCJn kVkAM9NSj5TTBR65gGeiMCKZECSpeS85fAR5ND2Th4O4M9LxNL4zbQMpA/+vlXoQoH6NF5XkSAU5 6QRekzW1JzYjEwo4AxLSdzYYgxj2wI/Blz3expRKwzBP6R0LOZULF5NXmZVQaZNcyYKxVxRheX1j 6RhlqXtgF5gqaRxsuRZuSTpKWZBDkiV/AzZTuYdRGX/xx5ALtwPatQRZ2Raf445W4JVNgDJXUYhi 6ZNb8FkH03oIcXiMUWef0yEBkpmjs4soKZnDQ5nDU2/YJpopcZu4uY0jqHWq1zQk15ebOX3/Bzlw kZqDuZqBd4PcxycCEpv6MJsXFzK2mZnMCYiQOWbDpoi98YQXdnZ6EzlgGBd3mZSM6HAJ1zoUWQal yQQo0349aQVqx2A4+A//lggSTwgysbE52Mae/Jib4yELiVggQdI88qme/Xag4LkF2RKfUTOfo1kF 9nk+z5mfqrmfXEBMWyALrBOGaFKecTck3cme7fmW4hmZhfF2kDOjIoZu+8OhwbNh0fYUNbqOVtYH 4ekRieajJlKkSHaj95OjJUBlbECkJ3KkTQajMVoGtialcOBlwbCk+iNmRvZAFAaX8gOkfsB0WUoL W9qkhLYNIoc+QjqlqFOlYxqkSUo/aNqlVfalHhamcVpCZYqjikc+9naYlMOm5OOmb1oi9dlCfqqk gAo+gmqdFSmn4bOnpLmodNo+drqj41mfk7pjiIoLnqoNjFqnjhoOkDp5/2SWoCqnqqsqBmY6C5pK P6i6BKIqDqCKq7mqq7vKq73qq78KrMEqrMNKrMVqrMeKrMmqrMvKrM3qrM8KrdEqrdNKrdVqrdeK rdmqrdvKrd3qrd8KruEqruNKruVqrueKrumqruvKru3qru8Kr/Eqr/NKr/Vqr/eKr/mqr/vKr50n MP8KsAErsANLsAULLv26q1RlsAvLsA3rsA8rL/aHsIhKTC1qsReLsRmrsRvLsR3rsR8LsiErsiNL sh57nBNLkBVbsivLsi3rsi8LszHrsieLskSosjKLszmrszvLsztLszXbeTfbs0NLtEVrtET7s0Ar cEJ7tE3rtE8LtRubtP9Ke2ZMG7VXi7VZ27NTS7UuZrVaC7ZhK7Yiy7Vdu15W+0in0RSmEUnZYjhv q7Zw27YXaxrNAIV1e7GUNLbsybZwa7cZG0p8C7dfG0x7K7VmK55Wi3pNsbhxWDI+kChfy0lgOLkW q0t0q7ZXSzaN8rcYewLsubkw0AKWm7mCa7gWirhKqbibwLiQQFtyG1a6ZDgCZbFkA4YwULodO1NY +7kg27tQ+LtGALK7u7dlm7rntbqX6wMw0AwwYLG0S1trC7rMu7aKoramobJlxQyd1BSrBIWPZLfd wr3fO74u4LadC753K021O7p8e753G0nBy1jt206ngb132wziW7HeW7z/x5uylnsJLWBYi+W8LQq9 BbxYwKtL+wtJjHVOBHwa44S7NvO48zS/4DS67jS6Q5XA3kRMslXAlEu/1etO3TtUIxy8KADCGRzB ojsmpmC4xuu/5LW6juDAmNC8iaK2uRJKtDu3TXECjwTEndVOdkuKl4tO8+sCj9u7I+DA+UsDxLtY l8C49vu4Nqy8liXCg7vEFfsD7eTFKMwtDvkCaovELQzEAvy4/TvD5be6jgVJBKzDYRW5F3sCuztV 5lvF9cvHS+zHYAyFJfO7i/W3U1yxn6vFjOUD34vCJ2zFUKhLxCu/vUiKCezEZ1y9f8zGbdx0q2sE sivHz3tO5duin8st/y1wuTtFxZjsx3i8TcYUyM0wAovbwahcuiscwmncosQbyWs8ySNMvDPFyjNF vGMrw5wMXp6sSz+Aw9FrwCNsxy0At3w8JmXMx8pLzI/7A96ixGHFDGPiA81Qy31cvd8yvbu8xr2s wOcMhsEsVhF8vSVTzGJ7zMjMXcoMCc2cy4EMzexLhUccSekMz32czYyrskQwyLDszeGsy1o8Uwls GuzczgLN0N28zuw5zsMsz2tszPa8tADswIIsx4kizv1MBCJMx1XsWNmyygPdykx80ojcvg8FxFNs t5+70qZsxrl7x+BC0ZYlWxINvPYL0AS90adbzx59XZ4sTk9MWyS9vP/P27m9m8SX+1rLbM3YrM0V nFsWPdKG0wLjHNKEbAnQ3ItlSdFI8ssATMXXHM8pvclKHWGEC7XSoMeA+7d2jdfSi7F6vbadS7KA zbF+vddxLdfqRdenq9iLjbVJfdjRldiMLdmTjbSPPdeUjdmZbbSObdm/FdmaDdqhTbadjdiibdqn XbKcTdqj9dmo7dqvrdqrPVhWC1Z/Hb63Xdt0C9iE3c6CLba8fbThy7Lm3NcrG9uynVar28Gui8BQ DcCdS72kW9xYq7wW69sya9O6zbFx+LUJvMvXDYbHjdxnpdwV27hb7U65C8ltTcfXDdyaHLXVbcDg /bKEjLHyfd+Ziwn/dOu5/cye4j3eTJW8O0y9CNy++wzJSUyF3v3e1ZDJ+Pvdvb3bE863vi3feu3d dw3hfK3hDt7bFY2/f3vhFl66EO3efyu/FgvgAZ5KvTTLI9oEq4vTlxDKUd26Cw3J+w3EzcxaLFy/ pkBJMPzUo3sClhC3prDDCXjTqrXEodCiVj1OVNzVrOXFnFTkm7C4IX3SId3Mi5WAEezkFKze8h3F QL7QNJ7PTI6xK87immRZQuxPMQ7A+70cNU67QV3Et2s45r3SpPgC8gTmzfC53ovTpFgeLL3QK50r fKxZbr3EgG3VX2zDQdDFiA65lHToh365hG7Fgp7dhBzFkczHK63n/8D7ziwtziXdvPG75Wve5qTF V5EgWiLw3DQQxzlMx2Ki3lUsxA8t6Dnu6C+N406c0IF75oeMyhVbt+2byHuc0AydyCf9xd3cu6as 7IIcz6lu7Aydysyeu9zNy6dhyA3t3+H96qyNjtyyVodS652lz1uN5Pk9U0JsySfQ0kb90nAryDOd v2Cd3Uqc4e7ewKX+7F4uu0Fc0dVO5GGt79Z85v1u76tOhW+L35Fs17/7uf8u04d77oS1UYsCjXL+ 5CVD449k5+Ve6ghNTAS8wJis1fk+zcVuvd47zhkOSW8rtFAey9x+8G0r1grvA3Lr8Axd5gsMwfPL xaWO0rqs8dKM8v/d2/GkBVaBB9Ko9+6xu92n0Uk2He7BXtCLvLZaz+9O/PC6TIou0Entu+3Ozu/Q nrl6+/MLD8hAzLY7T9MLvelqn/O5a8M7TvQ37fQcH/VoNb9XeMdO4Mmv5dQGXrvQfRpNHc67a1he f9Rzb1kJTfY0D/jd3MtGvPdenepUWM4JL/dKrMWTzsQ2nflHT+pnD+wYbbefvvm9u/bmPvhoFfL7 JPLs6bxNffU2DvtK39Ysj7tEoNFLrMZEBfq4LO6bD8JePlRPLvY7vyg5jLs4DvTd/MDmbcFFzyha /8WhK/0tKk7DH/pKvBwW/d+3j/tV41K0fdsebtfATeHy/7376+D/em23Qoz2IEAIACCM5CkgRMme 5UuIZLnStwnTKXISNmqXGtJ+L4CsFKy5WIAeCnjTTZm7JTWpqpIIkC84LB6Ty+YzOq1es9vuNzwu n9Pr9js+r9/z+/4/YCAAA4PMD4MAmRMXY6PjI2Sk5CRlpeUlZqbjFpdX4CdoqOgoaanpKWqq6ior ncmI2aLmLG2t7S1u7uTRlGfrL3Cw8DBxsfEx8qqMCQIDAoCirvQ0dbX1NVKy9jZ3t/c3eLg4hBFh IgFDNPY6e7v7te+4/Dx9vf09vjEihED614O6dwIHEizoKF6+hAoXMmzoMGG5fegCGqxo8aI1hA83 cuzo8SPIPstU/zhLNEbWJl6SVGKExDLTS5eNXr2aGdOdxpA6d/Ls6dOhiViSnFkS8KAlJaO3lBY9 ygjBg6hRn3Ehyuimrpw/t3Lt6vWrqX4inKHLibKR1aROkUZiWsut2kbNdjxgmYMLXHhg9/Lt6/cv m0IQVnwBAPCkTRpp7wqpkrcx5JUvGaOYTBnF2imXL1NRupnX3cc05iqmyhmyaGpaAbNu7fr1RsKE +R0WcxaJVAYkiBqdijkqSqbN+kEF3kXqCARUHywnLjU4g6iIdkuvUpy55syKfZMorvsJIeNGi1Ml kHt0deHTR3/fzSI69kHPnD3vrb3aatj69/Pvnww8VM4IhlgVhf+UYCBRvD3w3jPmHaGUg4PUBV4J E86FToXP9CNhcu11R5VyT1CVFgkTGvXgfSEaxQI6IxAFFYtHjVehiy4Y2KJ8EE54A2k0qrigfBxS GOE6+fl3JJJJKhkKTUJZV1qQQMLgFokn7miVUj3WBeGF85mm3QwUYvngIjtiVsWOc2F5lJYipPkM VUEaWIOVKl3nW5q6Jfhlhe0YuSSggQo66B23IdEMdi8+UEiH7OEgFZR9pkVUXSvoZsOaVRyyKG4l OaZcdChmR5dhL1TaXklrkbbpM2ZWGBUXw9XkllJ7npnaNH8SuiuvvfJnCLAyUKQYWbYeClyPPWZo VaaTwtmipS7/8skjc4dEEV2cFZLlal60HmXmqaW5pWaxraLYTLbdedjnmcZ6dh9+vso7L72vgUdT UAQ+CmVJcSpn3mjZ6ijtmSGWyCJUIjqV6Q1SzgUFbjdgWKKoU+yI4ZxZomqCqj2slaATKgw8hbIU d6Gnl7fCq1q9Lbv88lYqqHEWUzNSekKIO3K7cMp91uyUUbrNGCS7NEhJCNETn3xcxTcwC+d3D5so o5RbAo0daanulm7JRNuaKa7S6Aoz2WWb/dBthGCLiKLhjWAetqPiRtyZTywqpWHLOcEwetjWBXd0 sgSttsBSpbco0ru5Dd7dLiAen9rMITK41UzzuK62ibtLNeYs/5/9OeihgyMAsNAMW4QTLviwwgsq 3NZ6TVgYgUMKkak0+wwqQIyDDaRrhm8UKM1+7+7JyZIEEqjXXhnteEmRA2OrszO26NVbfz0oYr1S 1ulsef9I19+/Qz325Zt/vhwDgmFY9+K7f/n7BJGPPv312x+Gcrb5Y1v8/WtmqP/idb8BErCAYUCH 2ojSvgAysIG5MiAEIyjBAzqwghYU2wQzqMHPITCBswEDAC8owhFGYn4bPCEKj2SEL5TDJCwkIQxj WMIU0rCGg9oHGAAiLBDKsIc+lJgNgyhE/5SFdMrphwsHg68lMrGJTnwiFKMoxSlSsYpWvCIWs6hF KCJgiF78YhxrSLcMfiSRjFs8IxrTqMY1srGNbAQjHOOonxAAADs= --_004_7347100B5761DC41A166AC17F22DF1121B77304Deusaamb103erics_-- From nobody Wed Feb 26 20:24: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 1FF751A0246 for ; Wed, 26 Feb 2014 20:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.177 X-Spam-Level: X-Spam-Status: No, score=0.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_GIF_UNO_LARGO=2.176, 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=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 WKIt4Chnq2sV for ; Wed, 26 Feb 2014 20:23:56 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 86B321A0711 for ; Wed, 26 Feb 2014 20:23:56 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id e16so872517qcx.27 for ; Wed, 26 Feb 2014 20:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LCJSn01D1ima+UFtoVwEkYGq4U3xE3H3bCY4P0x4CFM=; b=mA50z5rO3LAkWB7AGand2ZkFyCHKdz1O9FThyZ7YplNLJiSEltzlxsesgzvqPyyoFS HIoAlfln24+fzjmOt5lirNecndXzM8QXGNa9ZGGnnPmpDxKWIx5owjZ7pLG0ZVFA9K3F r/i2s6dTuuyO24JHZtDryI28hcZQ++Ugo5oJckd+CBaRosPhj4sfsYmnNR88QCvjmOcH ybnaMhg6KwsjIkT0dqc4f2KjktifPyz+dUcKrWjY9B2tj6rIpAUPo4ebqZD23OH4CTMC KxMXS0mXBl07lOZjhMhBBXzYT6s2lkHk+HdkiRGvhdvvBn+vy0I8qTBk1NfrC2/3ZSt+ pUvA== MIME-Version: 1.0 X-Received: by 10.140.22.39 with SMTP id 36mr4096725qgm.59.1393475034983; Wed, 26 Feb 2014 20:23:54 -0800 (PST) Received: by 10.229.3.8 with HTTP; Wed, 26 Feb 2014 20:23:54 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B77304D@eusaamb103.ericsson.se> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B77304D@eusaamb103.ericsson.se> Date: Wed, 26 Feb 2014 23:23:54 -0500 Message-ID: From: Ravi Torvi To: Gregory Mirsky Content-Type: multipart/related; boundary=001a11c153f676e30c04f35bb01d Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KmRCHfAluS7jQTI-8a7FgA0ODy8 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 27 Feb 2014 04:23:59 -0000 --001a11c153f676e30c04f35bb01d Content-Type: multipart/alternative; boundary=001a11c153f676e30904f35bb01c --001a11c153f676e30904f35bb01c Content-Type: text/plain; charset=ISO-8859-1 I support this draft as a co-author. Greg, Protection domain for classic FRR (for node protection) includes a PLR, MP., and Path that avoids failed node. Options listed in the draft does not stretch OAM domain beyond what FRR node protection would require. However, in some cases, responsibilities have been moved to MP. One of the option that Alia mentioned, involves a Transit LSP as merge point. Stream selection could be based on a layout of BFD sessions that involved merge point. IOW merge point need not switch stream if it is not explicitly detected by set of BFD sessions failure. Thanks, Ravi On Wednesday, February 26, 2014, Gregory Mirsky wrote: > Hi Alia, > > the problem with stream selection by a transient LSR on the LSP is that > access links between CE and redundant PEs would not be monitored. Thus I > see such scenario of little value as it is no different from "classical" > RFC 4090. I believe that protection domain has the same scope, boundaries > as OAM domain and that defines limits of what can be protected. To protect > ingress, and egress for that point, domain must encompass CEs. Ethernet > Service OAM (CFM/Y.1731) got it well through MD/MEG Levels in, for example, > this picture: > > [image: Relationship Among MEPs, MIPs, and Maintenance Domain Levels] > > > > > > Regards, > > Greg > > > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > > *Sent:* Wednesday, February 26, 2014 3:50 PM > *To:* Gregory Mirsky > *Cc:* Huaimo Chen; Ross Callon; mpls@ietf.org; > mpls-chairs@tools.ietf.org > *Subject:* Re: [mpls] Poll for Adoption > draft-chen-mpls-p2mp-ingress-protection-11 > > > > I do support this draft as a good starting place for a working group > document. It still needs work - I'd love to see discussion of the two > approaches described in it - but I think it is a good place to start. > > > > Greg, the concern about distinguishing between link and node failure is > interesting. There are four different approaches in the draft because > there can be different deployment scenarios which make each valid. When > considering the different cases, the concern is always whether the traffic > might be duplicated or not. Obviously, if the traffic source decides, then > no duplication is possible. If the backup ingress can determine that there > is no functional path from the ingress, then that is a different case where > traffic duplication can be avoided. If the potential merge point does > stream selection (as is done with MoFRR), then that allows yet other > decision points. Different deployment scenarios are the key here. We > did actually go down the road of how one would need to set up BFD sessions > to verify failure - but that is also deployment-specific and got rather > lengthy. > > > > Alia > > > > On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > > Hi Huaimo, > > I don't consider WG poll as a contest in art of persuasion. I've merely > provided my technical opinion. > > As for your question, my opinion is protection of ingress LSR, and egress > LSR for that matter, is outside of scope of server LSP and can be easily > addressed for client layer. And in my opinion MPLS WG should not spend more > time discussing standardization of attempts to solve these. Though it may > be reasonable to preserve them as Experimental. > > > > Regards, > > Greg > > > > *From:* Huaimo Chen [mailto:huaimo.chen@huawei.com] > *Sent:* Wednesday, February 26, 2014 1:25 PM > *To:* Gregory Mirsky; Ross Callon; mpls@ietf.org > *Cc:* mpls-chairs@tools.ietf.org > *Subject:* RE: [mpls] Poll for Adoption > draft-chen-mpls-p2mp-ingress-protection-11 > > > > Hi Greg, > > > > It seems that your reason for do not support is not persuasive. > > Regarding to your statement "The only viable case presented in > section 3.3 where CE is monitoring access link to the ingress. This is > well-known case, e.g. Ethernet First Mile, and can be addressed in many > different ways already." , can > -- http://www.google.com/profiles/pratiravi --001a11c153f676e30904f35bb01c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support this draft as a co-author. 
Greg,

Protection domain for classic FRR = (for node protection) includes a PLR,  MP., and Path that avoids faile= d node. 

Options listed in the draft does not stretch OAM domain beyond&n= bsp;what FRR node protection would require. However, in some cases,&nb= sp;responsibilities have been moved to MP.

One of the option that Alia mentioned, involves a Transit LSP as merg= e point. Stream selection could be based on a layout of BFD sessions that i= nvolved merge point.

IOW merge point need not switch stream if it is not exp= licitly detected by set of BFD sessions failure. 
=
Thanks,
Ravi




On Wednesday, February 26, 2014, Gregory Mirsky <gregory.mirsky@ericsson.com>= wrote:

Hi Alia,

the problem with stream s= election by a transient LSR on the LSP is that access links between CE and = redundant PEs would not be monitored. Thus I see such scenario of little value as it is no different from “classical” RFC 409= 0. I believe that protection domain has the same scope, boundaries as OAM d= omain and that defines limits of what can be protected. To protect ingress,= and egress for that point, domain must encompass CEs. Ethernet Service OAM (CFM/Y.1731) got it well through MD/MEG Levels i= n, for example, this picture:

3D"Relationship

 

 

    &= nbsp;           Regards,<= u>

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

 

From: Alia Atl= as [mailto:akatlas@gmail.com]
Sent: Wednesday, February 26, 2014 3:50 PM
To: Gregory Mirsky
Cc: Huaimo Chen; Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

I do support this draft as a good starting place for a working group doc= ument.  It still needs work - I'd love to see discussion of the tw= o approaches described in it - but I think it is a good place to start.<= /u>

 

Greg, the concern about distinguishing between link and node failure is = interesting.  There are four different approaches in the draft because= there can be different deployment scenarios which make each valid.  W= hen considering the different cases, the concern is always whether the traffic might be duplicated or no= t.  Obviously, if the traffic source decides, then no duplication is p= ossible.  If the backup ingress can determine that there is no functio= nal path from the ingress, then that is a different case where traffic duplication can be avoided.  If the pote= ntial merge point does stream selection (as is done with MoFRR), then that = allows yet other decision points.   Different deployment scenarios are= the key here.    We did actually go down the road of how one would need to set up BFD sessions to verify failure - = but that is also deployment-specific and got rather lengthy.<= /p>

 

Alia

 

On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky <gregory.mirsky@er= icsson.com> wrote:

Hi Huaimo,

I don’t consider WG poll as a contest i= n art of persuasion. I’ve merely provided my technical opinion.

As for your question, my opinion is protectio= n of ingress LSR, and egress LSR for that matter, is outside of scope of server LSP and can be easily addressed for client laye= r. And in my opinion MPLS WG should not spend more time discussing standard= ization of attempts to solve these. Though it may be reasonable to preserve= them as Experimental.

 

       &nb= sp;        Regards,=

       &nb= sp;            =             Greg

 

From: Huaimo Chen [mailto:huaim= o.chen@huawei.com]
Sent: Wednesday, February 26, 2014 1:25 PM
To: Gregory Mirsky; Ross Callon; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

Hi Greg,

 

It seems that your reason for do not support = is not persuasive.

     Regarding to &n= bsp;your statement “The only viable case presented in section 3.3 whe= re CE is monitoring access link to the ingress. This is well-known case, e.g. Ethernet First M= ile, and can be addressed in many different ways already.” , can



--
http://www.google.com/profiles/pratiravi
--001a11c153f676e30904f35bb01c-- --001a11c153f676e30c04f35bb01d Content-Type: image/gif; name="image001.gif" Content-Disposition: inline; filename="image001.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ffcb9bb2f1255af6_0.0.1 R0lGODlhlAOCAcQQAP///8zM/8zMzJmZ/5mZmWZm/2ZmzGZmmWZmZjMz/zMzzDMzmTMzMwAA/wAA zAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA ABAALAAAAACUA4IBAAX/ICSOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2yy0REAyEoCogqMomwrjLHgrACLNUsCahU/dRvs3vz8EMBABzdXpyKHsian6MPgBwh1OL KZOGMQgPcQwPhSyVPwIPZ6IlnI2nNQSZX5k9ny9xaQwqBLN2pKi5uj2hgZgMgzuvLAKbDwyFoaMm gbvOL72sCDDDPc0ppiS1MKF1YDDZQMox4c/meg+HoZE45S6q7BDb3Ljn9vcnYSMA+jvXL2EA8JuG TsY/fPcY2ILQDWA8aw9pLWyBgKCIUALr0FFEQM66QQA6rqFTZkxJbZUE/4TU+CCkoIt0BK1xCSBb yY0QXHZCqOWbtlkkO9oRChNNmUkfc4oUAUDlJ2Pxah3VsxLn0XE0VV7sGIwhV55gs6jqyrBlU5qG XuZ0OqajxzBrlhY9VDNuPYxfGcZsOkLktZsz5XqtFnZOuYp6mY5cWkzMVnVo8w7WE5NEoJNrqwYr Oe8oX451DhYU0exXqweoVSrc1HZ1pmPZTMuBre7YatKbkJFazVqebYU5Xe8sTEW0sloKW/nOjftY r01mUHPil9wk7J2i5bkmSHvb8024q5dNPkjVarLE0zP5YoLTd1vPW47n5HoWVAiymy8sNvrib1u1 pEbKLwqZYd5t1PUW3/9w6jUxDzMeibLgfeYp9x9visAGoDGWuWZGL5yYciBw3w1Imwju+DfCZfI1 JKIt36gyBiYzTtMQRhAcQ9Y6wZmhoCi1lGdKM9Rpp8hEDUqRIicylqVSOj1C0Fss+HHXmgjfhGJR Cdk16SIwRiImJZBgNtkPYtdkl+SaQmTHohn8+EgQYlqWBdKQH8o31pgMVnkLnM3AU5aTZfkI6Czz bCOmmGw68SCXEfrpJ5GmuDhNTTZOB2WcvrGjUHlAWTgGpbMsKmGl8qU4KGlqQEkCnv6FtOGR8liE TI7s4DgpQcqI2Y2u31xTU6NK7sTkQpctFEs/WuFnC6x26gqhLCtGJ8f/NteoImldOQazTTroESuu D262Ggxi8hmJ42fclmYRlP2Y8Eg5wE7TGZkjpAOsfXIMW1Gf4xrxqGWR/kuwbyOgO9sa7ilrIJJS 8upeuhOfy2+Gta44hjsqjSOlGZhkwvDGdRxLq5G8QZdjJx5jG+k/E/c1y3+qBmyEaHU9GMiIwAkL BmrPkpwvHfVASi2rK9NqkygwE80bkKhRafPUNzBabcu6Pb2qdsaMami1H59QzK23yGzkoDq3ajbN RB+jFtUCI7nRX6e6PUigC307MoplXHj2wXx7HLPSIzH99NfoEA22V72ZEo7JZ2MrBklCl63INHTj d8jgRupLUrhwD2E1/8JpS0V52M6qMY/jJSuOQpfIRhfXzIVrPvSvJDHFSkSh947CwHW1LIZ7uY+z zpNeox52dkmVIPzZx8WONa6Ue4vJlr6LUzSakV7eCt5r772y6bkPrDznnOutIlynP+odLjvbKjvq 0Z+8DXtYzn/LuYgfJ3HlweoX2bI3hD2tyF4LaVhfEJeN1SVvUB6blhcSWDmXYQx/3LKJGJQFMQJ6 0D+FeB//ksaQTJ0saeDjm/LyFRFgPUxFHmtGbC4WnGLY5YNBcFVO4HUtpt2wGTHUXzYUyJG/HRCG uGAdlmioLfzZDlNtgRKP4HEjKEFJKo9AoP1CFcXKoSNTD1RGN+ZVo/+mHEM7M+ogDnmgEJPQqFNG qkmeEAfEM+IKjVncmgS1ccWg0SpIxTjVjIaEAIHoY1PxWiMOMQEnQdWpIQEZyKqCRMaIEWoexkHG 6b54SfjsxkBQqogZEXWrb4jSWYr0gaCK5KymgOeUwSJIHSs3xCfN0YikmQ6dklij8eARPA1pEkOM ocOQFQg/0pGlKYwJqi1mCDULc95rXJU537zGJMYAzphSk0og8EM6ZAsQN62pnGwBTVBTAtogImi0 CXZNhWczBiaeqaBsCkmd3VxjyKDpn/sME59YkWeMriidNYhGFdJBzS1Cdi1P0hOI2bQFMa1T0Hzy YJ9gKkvU6sZNR0r/J5okFFEyT7gie26tUvKEEdBIgVAdwsQEOKFMHc7yUmg0awUxxcNOYmKRnFqU FzkFJFmawiCrgKRZPp0BTXHKMi/mlKg/XSNUC+LTpFLmIjWlA+hiYNUSfMYOZehpU6PKg6nuo6rJ mElXT2DWMwCMKs5znV62ag9E8o6sQTAfKhJVNLz6VUXmsOtff7oo7KVnRHQdrCvU2IiaJOeuiu0m O3WB2MhK1jY1K4xnLEuEtTZWMJwl61efsdnQKvIqpk2talfL2ta69rWwja1sZ0vb2tr2trjNrW53 y9ve+va3wA2ucIdL3OIa97jITa5yl8vc5jr3udCNrnSnS93qWve6/2saW8q2y93uere7hj3td8dL XvKGF4flTa96MeRXQKz3vd99KwGRA9/6bheyvXOvffc7wCfYkHIADrCAB0zgoDD2g/8tsIIXPGC9 4pB4DI5whPtq0ctI+MIK7m83v4DhDg9Yaoq0sIdHTAcNN6EYAkmxilfM4ha72MX8+SmKX0zjGts4 xvk0i413zOMUUzifyOixkG1sYkV+YchIdjGI1xjkJDs5xUVewoyf7GQc53PKVEaylVOp4ywj+cfd bLKXhxxlHB55zENeMnpVgmYhlzkJWG7zjQ/swTjLmcZbVmSX71xjMKdSzHym8Zs9eOZA01jNHwS0 oVs86CPYedEqzv+zeCH9Ykk/mNIv9nOI2YzpFTc6e4XudIoR7UFFi/rTRXg0pi2NQ1VTmtUe3LOo h+VXU3ca1b0L9axJTUBbYxrXbgDGrFMM6zoLe9iu/KmsRa1pJnN62MCGm65Fzevs+ZrS0Q6CqyFd bAJue9Hd9t2yO93sNSPbkPIFdSHPXW3fXRvS2RbHsYcdbt9929D1Dt24MV3uRD971vG22bQ73e7e vXvRAffBvQOd79AtnM8Np9q+Kd3vUv/71On23cAxXfDQHdzQCefFvGcdcao9/M4lt9nEIV3xXl/8 1hnP9bqR3XG4fTzQIefByeWccpvtvM09H9fKF91ya7/81zEP3cb/KV1zqt2czznfwc/RHPRxTX3M VSfW0A1ddHcfHdtJl/bMh930qT39zlHXwdW9nHVirT3LbWfT1gPddYN/Hd5hp9rSIV12m51dzmnP wdupHHc2Df7JhU/S3Plcd4/fHeF5n9reF933gP29zYHHweGrTGdvj1zUiW/Q4u/ceJs/HuSRF/jY d41fx5+bH6l3QQAGQPva2/72BlhAAXbP+94XYABIDoDvh1+A3N/++LYnDvKXP4DcE7/3AUDyAJ7f e+Mz3/YBCMvsr397B1Cf98H/Pu8dwP3kq2f75af9Agwg/vCLvwDrT/8A0iN/2itAAeKP/pDfX4D7 yz/7CIF+6bd+/+03ZML3fvGXfjQwAA3QgA74gBAYgRKYAEhWABJ4gRj4gAlAHAmQgR4ogQWAZB34 gSTYgPMHFgFQgioYfCpYgg2Sgi34gSwYgx6YHjTogfonZDeYgQCIDzC4gxI4g0AYgQs4hBFIgftn hBC4gYUxgkrYgCE4ZE74hCfIEz/4hA0ghFj4gljogFr4hDbYhQ2Qgz0mhmNohWb4hUq4gBTIgA5I gTDIYimIhCnGgHTYYwXQhhoIAHG4YnO4YnbIgXr4hnzYgHLYAHcIAAwYhUKWAIPYgHBoiH6IiIDY AFUYgFkIABAoEA1IhpyYiXUoiUKWgp/ohZo4hiwmigLhhlwYff9TCHwdyIgp1oFkGAAdyIKu+ICw 2ACyKBC0qGK22AA2GIIW6IDESIkrZoGyKHyoOGS8CADFCIXQiIwqpozAaIE9eA8pmIsOuIueeIqV CIo9to0A8Irl2IwqpoqK2IBsWIrPGId56IiOSInySIyJuGN56I4hCI/yOI8UWI/QyIRh4Yj6WIhZ GI/ySI+OSIy9uGMEeYrSyI/9qJAJQIyX6IOZ6IRI2IkD0I8jGJAVOXviyGOkeI6Q+Imz55GGGI8F IJKtOI2mGIu2OJFj2JGOOAAlOYqoGI0ZyYszmZA1KY84KYzE8YxuaILT+I8q2ZIAmQDfaGNGqYtJ WY5L+ZMh6JT/aBh9POmLQUmTINmSDIiLMCmJtGiTQPmVLjkDHcmHToiTcTiFJ6mLa7l/cNiWAfCW RwiRltiRgsiW3XiXhgiXlCiXDWljBBmMJgiYWSiYFCiXF6mNWciMUBh9nciTXuiEITiSO0aKkumT p9iZD2iSz0iU6bGNiomIudiSEgia5YiLp+mU56iaEciaAhkWnhmazNiYESiblfmUNXabXpibemmM Vyh82WgPpvmDsEmLlhmYxqiJrqmcuQial/mcpBkDazl9XjiUi5mXD8iUFdiG0aiIeLmEesmUfamd hsidokmI3yl8Iiie21mee/iej4mcWcidNfmZzdmdccmC5OmA/7PHn0GokZrYisBnjLvImw9Im7iY oFC4oFcooFtZm2Dhk4jplMIJgsXZkkiGoSOooRaomxDIoMaZlRDKi97Yn6LZmA8Kkb93jtTpnHHZ jrLplLLZnnFJofdoY/l4o8ZJo/XJo30JpDnKmHp5gPEJjTCIo/TpnhR6n+dAipm5kgQagaKpmgBa pQd5pZuImSnYii1ZjPApk6sZjS5qgGM4ppUZmxName45jNsXoRu6m1dYjr5JYz5Je3Q6osM5maGJ lZhonGR6lWtaoMSpmTa2jWy6pjLKomB6nTCwlllogrvXhyrWgXB4l67YozWWj5VqiZeqjue4qXdJ lX0ZqtOXo/8rpql8yKnlWJg1RpCqOqqa6aqc6opSag6kiKM+qZueWIyveqoWCKC+Cp6dmIyGmKvT KKa/Z4jd2YswmKvRF5ZqeoBuCJ2xOIljyKwMKKdO2Ym+eo8Reark6IxMOa3jmorvaK5nOKi7l63d GazLCqvFeq3xCq0yqqyRaa+S+gKUyoy2mKMIGaLQyHuuSpeaKLAhuZI0SYG9p6mpyrAE+7AHu3vb KoWNSbESOY+UGLGWqH2L+azTB6xm6bGKiLCkuqgjy4Al+5kn+5GrmofseH5rGq5aKpMq2a29t7I1 xqg426u/SpN32bP/ihA+2Z0L66c7O6a8l6zoKrRLS5Ee67T/u9eJWZmHKZizXXmWM/uR+Bq08xqz 66myR9sClPp7jXmk3mmeCquia/ukO6qBqaq2msi25rmbSwq3dyu3gwmBu/oMvRquM+mlgYqlakqV 20irh4qlgimmi6mdbnqmiKuTzFiOkmums9mcciqqz1qnJfqmefpiSbuqDAi67zmbWRu5xcqciLqJ +Mq68wqpRKiWjYmji+i3JEqIb4u7SeufQ0q3TXi7wpe7Qgql37m3vou3wduNInuOrfm3Mwq8pqiT 0Hu7hludEAi50xeMk7u5lTuOh9q9t6i5EDijnft72om6iXq+H6qa6ouNfsqhqguvouq9ruu44UuS 48uUs/u6/w/YjsuqjLr7p55KY6AamQR8vHP7hqmqwL+ro3+bvBoLjszIvMjrvCjYnThph9nLwIr6 sxwsksBKu9trsxdMmdH6po0bmrHroc7JoBRau4WRtHV5qLvbvg36vn8YjOwLqOe7ujD8v/oLu5ZL wOCYv19Kw9ipmxJar7k6wbwrZAn8xP0axTmMiA9sxcPKqVIsjRWMlJrbxYCZxYHrDEJ7jMBKrfi7 v5sZrVPZiWxcvkxcGIxKidm6rdQqv27MssKZx+3KqXx8wjUsm4opnNRqvO4btXIMp6Z6l4rcoKs7 iDI6x9TrszR2x5RMi5YswWxYjBUJicVIfIjYnAf8YnkIyv+qDIXDV8pHKIir7Mq82MqhXKLxGcu1 TMq1rIsiS7MVqamjPHyxKJgs6MvGzMq+N8x13MsjSLO8CMzJ/Mx9LMLOXM3QDLLOHMBFmcujfM09 u8sC+qHcDIXe/LTgjLWYaM3kPMvRnM3VK77qLM3Ep8yEjJ1ieMou1p9AaKEIIZhDKKs05s9AeMa7 wMJDqIZGyIViiNBDGIZdOLouZobHOaVpqKZiWIRdiM8tps87yM/4INA7CNAvBtI3SNC6YNBAyNBA qNBdqNI76NBYCNEtJtFouNAW3YUYjYUazWIcfYMefQ8kTYMi7WJBHYMmnQsovYMufYMsjYVLTYMw /YQyza7/D13TLX3TW6iW91yB98yBYjjULVbULXjUqJDUN/jUMdjUT4jWLRjVSjjVK0bTmGjTOnnR Wp3RXJ3RXt2FYM1iYq2CZH0KZk2DbK2Caq2Ehe2CRSmGcJ2OjG3VTo3VYHjXOp3XOr3XWNjXrSqG gd0Igx2DiU2Ch22Eof2Bbm2EjZ1ico2RdC2+di0DR/mEO82vl92EXy2CnC2yrc2/r00cn92CpV2D i/3QH/rYc33VdY3TlC3bli3bmP2Emp2pub3Bu/3GvW3HFZ3cWV3DjF3cVX3cka3dkw3bW52Eem3b fI3bXdjZjPDbKyjZa2iz1c2y180TEu3dMQ3Zaw3fCb3c/0o429XY1eid2eqNheztB+5dgsGdgaN9 0Pzd0MMd0/gt1fqN2A++0v4duh0pyjI8xXiYgWAZorb6ygPOoRteyh0Oxo0I4inJ4QZ94H2Q1AmA k6o84wLt0jMumb984stM3ReY49GYh+o5zZmcgUBujDOuz6dtn0j+rKs54XZ6lKkc25IM3kdI46Js 4xeI41heylougTmtt7TnpgaZl+YNgooooWW+hM9ty2Muk2tOwSt+gSH45p754ro9gWk+lXd54xfe hsDnp31+gQ2Ox4Fer/qs0oAOk6+q5BEegTR+yJB8gantjpBunNM66atZ4YQ45oKOmET+Yii96J8u 0GF+vv/FyKeG+uPNjeomuIgS7MAl7up7+YwgHd2ziIGSqeqxboJ5DuluqJoQm4Eqzac2PJZgLt8S aOw5SuVG7NrLHuxx6OzazN16PoICm9SV/qeEiO3YqO2c/uqAOuwYWOzS/rEMnuEn2cxbK+Ot3u2A muIOqABuUe/2fu/4nu/6vu/83u/8rgCszu6/S+cFbp4CL+8NSO/+vvAM3/AOn+8HoOugTJXc7sLi 3aATz7gY+PAc3/Eez+8RT+kZf8nPztuUS48k/4Afv/Is//AYyJt8Or3h7Ix0/oMx39MH0PI6v/P1 HvInr5QV/84mD74KGfQ1S9567p4IT40fnvRxufQKz/P/Ur/zAO/0g7n0uM6VVh+3GRj1U//1He/z RbyYWVzy1g3AFO+BYL/2LC/2S+ycvY7Jol7uTni9Gcj2eO/yNZ+oMg+1Orj3gNr3DZDzeV/4EE/3 l1n2Fg/tY5/26Y70bTuaSw/gKabPJJqZk9/myIv5SZ31vX75fZuBMM4HKD2Wjl/uF276Gk/oyo6l 40nHqH/xXvj6Ke+ASz7wN8+DUK7Dua/r4X6QiW/0IVzkW/76im/76r6S4j757z77yy/jmu/8tY71 Bb+JqR7Jy/7rgBvsmnj8cu9iKM3s3S/8hS7+ILz4Q7/90nj+yG/tkS+wPb3tGEii8M+Dv2/+3j/8 c3+B//gPAkAzkmUDoam6roNZFkFRAEkTv2UC8L3/9wq5UWxWuwWGowSr6XxCo9Ip1DYs0mw4JQ3o 9Vlz2ON2OKCi0+q1KjnczWSNnXL0vQPcOXhxLqqzBQoONum98Mk1HCnhfRmaIAophuUQWl6i1QUM JNCMJA4FNHppcno2gOYEYLK2QjzqAMQJ0dWNAsGSRPrVnbC5KA3wSBYAv93+SJoNExnvuUKzUr4I yzbXdSHzTJtUEztTR4sL5pJ0ASeUk2j3qN/woLv7jtMHup+TBHCXsPPcw+fbR6IewTS9ROkbMUCZ qn5/lCC0slBTwYqFsAGcI8/hPwDxegUC12vkjn4MR/+StKiyiUCUYhy2dNltJc1XMl1yvImyJk8U 8nQq6vdTZ0+aQA86PEqxaL2hN3MqHRIy6h6HJ6nOYWoxJtBs2rjqPKO1KdYXUMsOHGvRqcyzaOep pfc2X9K5qOJGY4tTqF24aURSLcnuamC89MDe9IoMsUyxhl3pRekW7WOydieXrSyur6h+nDVjijwS M9apcwVrIxyVCehWjF0qvvUapePWhET3Ik3VNjTctvja5c2Kc925q4Tb66s7qum3qJGpVsoa+aDZ I2OPst6rNnU1vhkBn9v90vchy5WOH0Tcs93j6amUz3H+aHO0z29FPzr9fRrtGPv5Fwx/acRnVnhv DZj/3GUHUpagQe0V95Z7DjpRoAnzAVVfWfeNkh9Q+1FYhV3YNRKgGSFGYSE/DGaGInzKsViai1Gs x85nM66g4jox7vaLLgVQ0okNnRAxg5GxmPRjkEDOQYyRM+iA4xNhQAkDk0Te8CQlJOJB5UkzDOmk kZRwJ6VNS1RpDi2SdPLkheG1aQKUWLZ5ZAlmQqFHnFYSEaabK7KjZ5pF9tnkn2nhuQKfizKZ5Zgl dGajmnISY8WTjX6S6JmGUlponYMGFeiPX1ZqqJ2IqmEMDc4II8QWAcAKq0e6WGXOrCS0isQnsYpi DIiJhiEKQ6Jo4UYesVpDBEx0DUuGsbwm20CZUuqZ/wcM1tZCA7KGnLWDIdry8s62d2rKQrXfWjuJ uLJyC2e6yhqrxbEIkVsuCiu++Ykk8wpLF3t2PASwvnZAq8yE1NKKbrzr0rujqEu8K64d8o6L6l+2 GtLvq8rU4keS8EJqzca06mIvCsHeCnCxE5ujB5d3oOzMNrqqS4Qe0+JY7SLSYvtHGYoo0+3MCvVs Mz/KmNwGrTsLs/DP0QrNdLrOHm2xpisq08XANdOMSoTMKPtHIjuXcXDOS4fRNMtPB+2u1E5zi7SP Ni/iratupFJ3rXRbYTfNefeddLADuCzMylx3/PIXgxdONeIP4TxjtRN9Qni4P4MiNOWoWJ5txnIn vf/pDptvAjekbT/sB+mWq4s56PbyM4Axsou9bxgdR6pN7LMLs/XOuGs6ucGsO751qNoInw/xhxvf XAyUFyPHyOv0vTcS0BN+t/E1/4pnsFkoBP4WZLu8rL6LLOQ4+bjaW20xEOPg+ekOI0/r+37E7/Pn VpfrPjqymC4fqKsf/P43Puah4nXlOpoeZFA7lhntE18r2ynGRqUGBs9+Bgyg8YR2PzhwMIH8m4Kq ZACMhUgPb5xIQAJY57HBtOx+KNQe51jYQj0JToCU04f6gNSJTdgKQDqUBA8PJwsWPo99/aNVtlB4 OX0gcWdCa2L+bGZD8I0gdD5hos+c2DoodkKK7qL/ItyuuLPQ8SMdQ+Kh73yYRAn+axIJUeMDgYZE IGYqUdUi49rAiMXjIWOPXTwgEswYBuexUY40zF1CIPaxQv6hBimEoz9ul0N9vS8dXwRYD5yhOC98 L5NJUJ8PWNU+kiVkIVV8RzsYIjRU2ECVSciWD1KhRdGJIJVxWFstXekuWEprl63rZb1gR72JFKMW YytlyOJYA2Ryoo4/cIbZJIfKWAqTDMSkXyCvGUxCesWWc9MVFJMwSRFW5ZE4KKcIp3eISyaQDu9T n0A+CYTvydMF9DzREiEWzEms8mdvSh0dJlKDgKrjltX650FDOFAC8sKgP+yjEtBIPRwsRJm2C8XX /yaaUWkKpJouWqhEwamOV5bUocW8mNFU6YJzpgJJMGzpDF66SNV0z0zfg6Uc9vkSIQ5MHz01okAi N1KSxUCTCAUPQUWQ1CQsVSpaXOhTaVY8AzW1kFBV6QjNlEZFgFWjEHxB7pDxVRGIQKxcM4FIUURV oVoVgQ/tpj+ratKKjhMHMZADTHFqPb3CSgh9fQM85UA7iq71WkAV4WE3mVglZtCfipCdruRnnl9O 1gVRrcRUSZbZuHYNqxCthUc0y9UsJu2rpQuXBTnqTBusVq07Y2tkw1Va0AoUUKONJGXvKtU1lFBg 7cSbX9VprAe6ExKFddXUiHoF87WzuaDNgVHd6v9Zjc1Sf0zdrQS1Z1nOhm6hXqPhVed6C/FiF7Hg NSbLhOEC2Ya0ozx7L0hDUVtliuy0gDzvdfOr3hcgclcDS65MU9MyAQ93e1Ey2U6BhtjZKpYdDU6W T8PRz8tp97uipSuGjaZhEyjUs6fwrXwwO2L9WpRlOxhSfRvyWj+w2Hchva/PtOvYEmf1HREs70rR AJjVWM8+8ESLPX9gIuqeckGpQ1BnlQxRJpusRrprT23fgiGijNM+Qd7QkMtSZDDYpboh0hEnn9yg 8MJoyWdmr4QihJa2jjnNZm4RcO3CoUZ4SCc5ldKRX/DlHvR5Jhe2Mo+Y0+S5XPkmKW5zHN9cZbT/ JFomIbEhpStNaQdYutJ/hkemLY3pTms6aT4EdaU/DepqDIbUNjS1qsVMITCqmoWs7jRHYp2AWZNa obZedaxrHWtcgzp0u2ahAhSg6rLKJtbF3jWcXz3sW/daKLYGdqcJIgAGOCTbQLj2LVtxbW2Dmwfc 7vYlHhDucD+A3NBggADOrW12q/sSBECAu7ONAALEWxDsrrdD4D2Wb/ObHePOtyAAHnBkDJzgazD3 wbWRboVbYt8Nv4W/Ib6GeU/8Fve2eBoknnE8VJwpBv/4FxLOcSqMnOTbZsDJ08BwlX/h4S1fg8dh /oOQzzwKGLc5EDaecyjUnOc8wHlPUi50k//c/wlG5znSk76Clwu9BzJ3uhSCLnSiU10FO486D3ye dRVYnedYr8nSbd70r0Og7DA/e9ahzvWpo70JYbf52L++da57Pe5zh3ndV6J2lbM9638neeCd7vao wz3uK9i7yvtO9btHPe9oZzzJHW+RwX+88E7HfMY1//PDCz3xik8B5T9u+aRDXuiS/3rpM376gnB+ 4p7/eewbPvuZg57noh89BFo/8dfnPPU8X33Wfd9w4Nej9ge//cyVH3Dmnzz3Nt/96I1/cOS3XPg2 Jz7VrR9w7I/D+fyG/snFX2/yW1z6MKe+4r3Pb/BzXPsw577T3V9v+EfD/O5Gv8X1f27+K5z6qf8c ++ldu3Hd0AkA76WA/Kkc/SWd/bkb/kGD/4UbACocBYKbBeabAJIcAU6eAR6gBCocA5KcA/4cBJ6b CHobth0gAGhgvmGgtr2gunHgx3kg64Eg16lgvpHgx5lgzqFguO0gJsRgts2guhWhQxxht9Vgxt1g 8eVg1A2huvVgxv3gzAUhuE2hJSRhPyxht3WhwLGcAjbhxD1h90Xh1SWgAkJAFU7cFbZcFr7bGmpF GGrDF96SHSLcGPJeGTbcGdZfGoodHfKeGzYcHJ6cHGbbFhKCADwAA0BiJEriJFJiJVriJbJh2j3i JXJiJ3oiJLLhJn7iKJIiID4gKaLiJz4AIY7/HgGk4ityIr5VHyzS4iSuolq4oADo4i7yYi/2IgIg gC8K4zDqYibmIjEiIzAi4zIWowIy4zNCozBmogpEYzVGIwBkojX2IgMQgDb2Iu954y6uYjjqIjY6 CAHI4jTSBDqqYzu64zsCHSvCYzSYopmw4zwWxD3i4z7yY/vJYz+W2wimI0BCgz4S5EEipMIx4kHW o5QYZELK20BC5ERSZLksJEE2JI48ZEUGwkZy5EeC5IBcJEBm5Ix4ZEhSwUmi5EqyZGWMZD+WpIuo ZEs6wUzS5E3i5Eq8JD/GJIrYZE6iwE8C5VASJSvs5D72ZIgIZU4uZVE65VN23D8SZVJSSFPe/6RV QmVWauXiSeVQUuU5SmRWYuVWkiVUHiU+fmWCjCVLrmVZuiVQnuU8puWAtCVK1uVb4iVLxiU8ziV/ 3CVI/mVeCiZH7uU79uV7BCZHJuZgMiZCFqY7HmZ6LCZFTmZjWuY+PmY7RuZ4VCZEduZlgmY7ZqY6 bmZ3fCZCnmZoqibvjeY0liZ1pCZBxuZq0iYUbuVrIsds9qNu1mZvYmFXAiVuCgdv7iNx+uZxKiRw 5qRw8oZxzqNzImd0dltrZiJz2gZ0viN2Sud22gt1hqJAuqV2cud4mol3kiF4lqV4kud6ooh59iF6 kqV6sud8iqRy4qR1toZ8ZqJ+0md/Uod7jv8efoIGfyoggfrngYIGgCqegGqGgbZiWCJohBKcgsYd g1aGgyoehkrohhYFhaKdhT6GhqKdiHJoiaqEh34diBoGiWYdi5roi9IDirYdfG6li8LojbqCjFKd iuKFjaIehOJokLanfd4kj8aFj/4ckrKkACAAAwRjiBJpTUYpfeqo4dGoViqpXT7ivD0AkEppPdxi IHAjjlZp0hmpWmRp9nlpfwJAly6guaFBmI6DnNLcmiJomX7elYqlnc6nKz4dvrUbCjSjAKAjNjoi AZgjOq6hCwIAOzbqQCpqCuziQIYpocpiM6ZdAlqqOY7pjeJpzp3pWKTpyY0qRwKjE4SpnxL/gCi2 6QPcIgI8ops6IiQ+AKwygJtCgK3iKq3yIQTc4qreKss1aQqM4ybCaafC6Kfinp5CZalWJLI+3Rr6 aaeO6S06Ijauqgu66arim586oqYeK536aru5KQBwoyMKaro5KQqcKrSaqLK2XKhqhbNCHL1OpLsS q7SyXJeaIwq8KgIQazfCKbpqYhsCLArA27pG68BtnJueKpy2IcvhK4fCa/Qx61PaK0RKXjGmKsut aq3K4i0i67k+HMGiqy3iG76uIrBKYq4CLMlKorryqX9WLMfJK1NkLA/O7Hr6KdjhW8eiQKPC6s8m 4MgKbLoirZN+o8oSKrvxYsS2qSYu7c5S/+mUsuTNFkXOxpvWHuS3SuothmmTMuy+JmDPjqvJlmy6 zVsKbBzTDpyjdunBVurLUu181mz6XaxTcu1BQqKmKuy6zqqv4pu5Aqys/irLoS3Seu2qFm1YrmKb AiquNqksOunQ0S2ZWu1KYi0U/FhfeG7JoF2g8dN2mqur1uqbuuqwfuwjYuOtlq3pgivSFmwbmi7l Ou7rpu6bmuO1uSq29V7dhubn5lHSkZnwgsQldK7x2lnciS6SkWc5rgD0pkAuTm+gZmq/SoH0TgH1 QgGm0qfxNpvCFa/y/hYhJC/5ClnoCq+rCWn7bobwhi/BjS/6ghjy6gKlCS8LQULfWNoS4P/vgn3d NOivDvCv/9qQ87pvAlvEIQhwAc/B/9KW0+kJBPfFABOwAeNv//ZYc5RV84YMJRALK4FZWXEM87LV bIXw+BiZoClwC9eDgeQLOt1TBBNvEAWB59IAQ+TwC92wYjgDJhgDKBgOccgMj6GTji0BIRwsg51w ETuXQoAD+7rwFLOBgXAMD8gYroBD/CYIoQ6Cy5RPnukEuDBLuMjJHnVVqggQpPjKa1gwpMBKyxgx 4CRxIFzbEtvLNMSKHD+xGSsEFQOyK5gFHkmLKGSxZOVDd9KbgoTWz7xxLzwyEgRMHtBCwBzYGqOW JQSxDrtBNsBWJa/RZAEaW51CMM2xKwX/zho0qqsCb4LocSmnTx93zB8Hci1bgllQUIv58V2Uy8e2 8qY48h8IxiIR115lRMskwl5VshjsTyabLyb704oV8j/t8DwlBCHryw5Jc1L9LyiU8p45wSqbrha9 sjZXGGWVgBTb8jqzgFlI8yToMjoncrk4Yu8CLxhfyCe/AwtFUiSFEXOdsQz1wYr9bxm8s18IwibH Qtc0lLRQlkERwyPIQCahlbzUEiWBTVagHKya7pai40eDdEiL9EiTdEmb9EmjtEkrAClTtGPNcAko QErL9EzTdE3b9E3jdE7r9E7zdE/79E8DdVAL9VATtUm7MzTJ1gqXwAEUdVPbdEdvaZTi/3Ma4Y5g sRCsXDVDbwlc8VQl/0DYdNIGj1Mq0AEoyEBZa1JCLIJAnbVT6ZNcVc4BA3D2crTpcqNT4zVNr/Tp 5JNLj1oOxHReC/ZgE3ZhG/ZhI3ZiKzZiu/P7fFQbybUJMPVi5/WtdvSTTsFUXxQ+u5RLaTUMjBI/ i9AstwwFIzQHc/IRD1Vo+3MErbE+SFRoQbNypQGT2jU5kzIsxTYhCQg7+/aDUHVFw9dSaEqrsjL2 SoFm80IZ6JUqFQMy6cFsYVRNjbYluzaA2e/2GJYxWIPsvBQ6r7VEC0Es39j8PMMa2La4asorm7IN VBgC/3Z8Q4E7J1B2HbJ99XLqIndmX/8yFCOxQ2tEOSVEGUg3VMmOYC2znyVUdh9x74QLLTHXRsm2 9EhXbh0xbbPBHQtbbpPxe1uYfIN4E9C3e7GWhOO3pvQtIzP3IrC4FWBxULh2gXuMPpP2ddevJvtL JeFKHiTLNre4jY8NMGhTMlz4XKsyHpcLe0/Wg8WEOod4INP3Dg83RNAzknuHDWe0tqQM6+ARgW81 gsnBfWwVXuE4BnMDmOiALqi5/+4vm8+BmR9wJNdxALf5Ay+Bm3OFkz85FR/Cmr+5nf85lUvw/Ub2 qFwwoFtwA+M5/1YaoK/XIJwv/RaG+n6unu+5C4Mv1c2vpDszpHP654Jzy3kwC196iGf/+qB/uucC capXsAlXeqnv+anXMKsHB4PTOpdRuudaOqy7r6z/3KZzemjwyrATe7Eb+7Eje7Ine9wpe7MfO6+H uLNLO7RQHb9M+7Vj+7RD+7Zze7d7+7eDe7iL+7iTe7mb+7mje7qr+7qze7u7+7vDe7zL+7zTe73b +73je77r+77ze7/7+78DfMAL/MATfMEb/MEjfMIr/MIzfMM7/MNDfMRL/MRTfMVb/MVjPIiHdOYu ICt6MRp8fEdyfMaTPIiL4q3+srsSLMrFpHqX/MtDu5yabSMC4sqzgcvDfM7vuZyi66QGZTcKKh0+ bdopqsxFqqA2qtDLnKUivaQaqj7i/7zOS318y7zHWnauxiq+Dau/XlvkRuLD6WrIovzXBmWsSuyl qq3Zc/3Us/2Td6kuuiLAcqsmYqu5Je6YnmrvpZvXXquv+i7ZQy4EmCs6jiHGlWu1jnzbKz6OQvUi 92zeC27kt2vKyuKqGizpJSCukj3DCmzrdiMfNmziL/7ol6h696zRuuzvqn6lqmvMEm30pv0k/m6b rrLsRz3p476Qmv4Yor4rRu3qr+HJBuPTiiu6uuI3AqOqOu0ujmvuU3y2Q7+zu2P0K/t+B8LuByUf 3iLkHuyYdqrlry27vj417j0fsmPcA6r5jz85UD+yW786tn/8E7vzV8aoY8Wut5yvD/8C9kstCEAE A5UIQ5SoyAAC80DCI4g0dJflDAFPOkvhGDUf8Ier6ZbM5rIBjUqn1Oo04Mxqt9yu9wsOcxPWsvmM bgzE7Lb7DY/L5/S6/Y7Pa8npvt+6pic4+PZniDWXszSiQ/DwqGQDoCIE84AQY/MopLiT6fiIoHPS +HhZ0tlm+IdI6Poaxrc6ixYIe4ubq7vL20soSxtcZetbPCd81voqIDDpxczE7OzlEulUbYdspmzc PQesjUzsTV5ufo7uTZYQcAU+HABcEN8wH3B/TzaAHzAQNZ4uoA4q/absgzKgQAN2+BISFAhRC0F/ Ug6qUcjwnsMrETsy4UPvn8Iz80b/QilZj18+NfwoqvEIM6bMmd3WAZgC4B1BACYbBMiZsoBQoWTu Db2HkOY5KgCAQknQFEoAjDyFDnAahZtSc0yxQr3pk+rQq+C0biXHB2tYNAUAuFTDM+jQAkWnCkX6 8qzevXz7ZrGJU+cVt1G+kplXZWphoAC1vPB7p6vJtmAVQ6341idkb5KjUJZKFTPHzXYEIJj2JS0w xSSjZo2LmKBJqPpI276NG+1CsFGA0t3XU+pVz2RTJu7J+IsjUbkL4RzgEnrl0J7bSTHb3BVT6P+G r71cfXT2N5iEpIaiVjFdlFPs8WGoMPYV5LXH27+PHw5gKUCbSi87Dx8J+WbdfIsl/8XFC5DkBwZT bfX24He8qZEZdgxmg1OEDfA03W6iXXdhGKAQcd6Gqyn004DBzbNRAcAZJ9uBeYVIY4347dcbGYRR ON9GN/kGQEtS2WUPglko+AgJNkoUGD3sgGdZVS6qpdmSkTW5TjwdQjUWlRZa2YMpl1jzF3on+mSd hidNZV1C6gXZ0JBHtQlmnXbuhaOZJp40YViIsbNnSXMNGaeRTIwg5gMMLMpoo44+Cmmkkk5KaaWW XsoAUwlw5yKUVDUUXAMLYEpqqaaeimqqmnI6gKe7gUrFqKnOSmutpSaqKJkf6ZkViiaphRhYN6lH pFCEavTPncouC1OeezoFXq8b8v9I4HHDZAEAoqYQwUy33n4Lbrjijktuueaei66miE3larSAoAtv vPLOS2+94arbDrtb9knFAPb+C3DA81qSpHll7iktawiv6We+8RV4XagzMktxxbq5++x7EK/Fpo6H bQzatVsg+QBqdmpq4k3t8iuexWGgnJPK+yZj8QxJ6uqEahGvxSvDLjpErLX9ukx00bqkNZmwI3G3 85R6yrfz0F2AYvDJgfl00Mo0G/0Fyv20o/U2FmNCYokFPQXU2Woax1BRDwttENdyz42HgDwl0NZI TQnlJVUUETgXXTzHTQ0CzCmLct4eSrg13Uzyd1hcYZfxpZUrxMLnenj9dNeK1rn/RmzgbovseOmm Y85nkL9eFZdBI7FGjz38KLQR4coxS1CWWSKEEcgtnz6QOws52WbvjS8LjRiyzONfVvvsKIWLCFHk kOz40C5xY8Bvv71gOYaThvZyg58Y90+Q/3v3yUiMfrLmv6++GVS2X9H29GcFPwT3S5W/9yHvb7v8 CVBu/lsYAA1VOgBWjm4K7N/6Dli/AUrQaAWEYAATuL8Fzq2B8KugBd03wRBWzIMfnBgG76fB8WXQ gSWshQhfCMMYynCGNKyhDW+IwxzqcIc87KEPfwjEIApxiEQsohGPiMQkKnGJTGyiE58IxShKcYpU rKIVr4jFLGpxi1zsohe/CMYw/4pxjGQsoxnPiMY0qnGNbGyjG98IxzjKcY50rKMd74jHPOpxj3zs ox//CMhACnKQhCykIQ+JyEQqcpGMtA8BToAAnOWCAJJ8RtUaiclM+hATCEDUJeEggE9u4XJt4IEm T4lKHDoiEqusAyPCQEo2mDKVtKylCGMJAQaIoluUXEQvd5CtGoSSAJMwTdmG6QxeLuFy2epl8mRQ BAL8cpa2rKY1uZcKRjQKCRAgGzcV9QNHLIoGI5KBohY1CW0tMwUAYBQ5M9FNYrpTmPC8pj3vyTVq eiKXLWCBOek5CUVNomwreOXlCspNHRRUSYzIATkZSgJ94nOiFL2TRHmgS0+E8v9wJOJmJBYaJiUw 4pXrzKUQfNBNUWjzpDGQaEVfCtMLzcBkK9UBDRyFhBwYcxP+nCUPSKrQFJxznKEkgeGGME+XxnSp TM1NQk0gClLeNJLeSgIqqApSn8YAqJTAASW71ZSSdfSr0lBqU8+K1r2QQgdGyCVzfnq4Tlp1liC1 qj+5atK89oBEKMgEM7lVz7QKdrA0mUEkZbAoFdAAAEedQQ1aeQPH2iAFrzScC+pa0hHUYK0jYI5m uxnRwBJ2tKQVCMn6yc8kOQMU31QCJhS1yhmQoJ2hKAFeD2oKJQRBobk1Z2l/C9x0dGudz9xBM46k W+PqoLhdYG4TnBvc6ErXHLj/nK51r+uy6mJ3u9wFE3S7C97wine85C2vec+L3vSqVy8qaa973wvf +L43DvKtr3zfYN/8ttdkbNCvf/+rkvwAeMD+pS+B7YvfA8uXv2JQsIPnu96IkPCD4vtCZsiXAOeg MA4TtmCFbdNhCH64CxcGX4bdwME3hPiAI46wMVYMwBZvocThOLEqVqifFrrwRjo+g4y1QGNt2JgN KXYDjPf3Yxfz4sj3S7ITgoyMIYuhyG1gMv2cjKcemwHLTICyMKT8MhyrWMtl4LKSb7GOFVXQWNET HN5EV4/AgdANmWGzZ9w8ksCFCswNas+K8swHOKdPeSeRRwXxBgxEL0TPh5Ez/wKzk+b2rPnPaYaz nufchjpTetEncbQU+Nw1P4u6HoGeyztSuIdCR+/QgisMni3taTOf+RXOmt9OevKTyKmkLvjYkaxL UKHWSaVaaOp1ZkDtha7gpEMb4oew+ZdjAyqsDG15y1XiAyd88Poevs5PrSvIuesAadfF5jb14hBs XBNbJdB7ioZ70yfQ6c3ZwUH1wdLDvui1+9r1yPZK2H3uWaPj22hIEX+IbSC0PXoJpuFCsN/SlI/9 b3GFeTd6hP0ZnmEFalXSwmFTLe18eyZI4n5bjBRuQkhTvGeUa3fEYZTwxVW44TMeDMTXPZs+IbsL nUnd/za+scp9/N5nag3Ewv/N8YmD59cCFwTBG31qi9SjOEkf3J7E5whR6qBCUp+SxK2ulp1zYTvR 8Q5rvNKnymUd5PheSAIU3Z5coy1oJ9cT02fy9DhHvUBeh3nU7K6Ftdf8Ol2nunWmHXaLb4hpFGI2 2ge9iKfuKuRuh3v05P4qk8f86k0/B8Gz3TenDOjrm0/Ocy1RSWDPR/Rt+TriE614nhRoKo5fXtAT dLOcsVwx9I57i15U9denvDmf7zWAWI/wv3P+9AsafK+Q73r6fDr28qH9z20P+eXmvgk6S1ivPfd7 upe+Pp2/WLx1RL0Kueh1tJHLUITz9k3RieEEOxyQe8T+dbfq7VJ3N4qxNDz/rrIhdIE3Z4M/XPBa uTJ5bYcXHFcS1IMSgvJ+WBN/FnF3MvF56Yd/UtF+Eshm/VCB87dc9UdiG+gTHXh4+yd/UyB2W6Ap xCOAd1OAFdIFCVg2OtB9IdOAG/OAvBM6g0KB/CeC5VcTK/cseRZ0VjE8geJvFPETTREkAlIC2UIw BSNNV4iF0qQA8yE9gLJuUBiFU6AAWUiGZXiFqxIfreJ4YHhhB2CGWFiFsOUMOcgxFNF+1QEeOfEm QuITYBgSFxgTn4eEXOgPXqhrhfKETfGHU6gt2/KGV7iFEdOF7fCFUBgSUTCGj/iIaDh1MciGVOCG mhiHKDCHu4cidggsWmIm/3uIiH4ohUSoDkbYH++RdnRxE9KTfNIiNSKQgFb4iJHYK5eBi9FnBpmo iWaILxcRg/4Tio8Yh3JVAnTIe78iD/nydg7jd7p4QSqHMbOIcsF4i/6QixMXQbyYKCigicAIGsIo jsRYBsZ4jGSYjAmxjGbQjG/4jOYhjb7yPeERD4AifsqHabDYC59HiwYSD4oxjlaHaaaxLSW4Mwmp EDhnBi34ON/zI4tzdv6zQPVHJvs4OKl4EdITkNpYjvZhkN+og+wwkaQnkAjkkEkCkQnDkoFyeCJn kVkAM9NSj5TTBR65gGeiMCKZECSpeS85fAR5ND2Th4O4M9LxNL4zbQMpA/+vlXoQoH6NF5XkSAU5 6QRekzW1JzYjEwo4AxLSdzYYgxj2wI/Blz3expRKwzBP6R0LOZULF5NXmZVQaZNcyYKxVxRheX1j 6RhlqXtgF5gqaRxsuRZuSTpKWZBDkiV/AzZTuYdRGX/xx5ALtwPatQRZ2Raf445W4JVNgDJXUYhi 6ZNb8FkH03oIcXiMUWef0yEBkpmjs4soKZnDQ5nDU2/YJpopcZu4uY0jqHWq1zQk15ebOX3/Bzlw kZqDuZqBd4PcxycCEpv6MJsXFzK2mZnMCYiQOWbDpoi98YQXdnZ6EzlgGBd3mZSM6HAJ1zoUWQal yQQo0349aQVqx2A4+A//lggSTwgysbE52Mae/Jib4yELiVggQdI88qme/Xag4LkF2RKfUTOfo1kF 9nk+z5mfqrmfXEBMWyALrBOGaFKecTck3cme7fmW4hmZhfF2kDOjIoZu+8OhwbNh0fYUNbqOVtYH 4ekRieajJlKkSHaj95OjJUBlbECkJ3KkTQajMVoGtialcOBlwbCk+iNmRvZAFAaX8gOkfsB0WUoL W9qkhLYNIoc+QjqlqFOlYxqkSUo/aNqlVfalHhamcVpCZYqjikc+9naYlMOm5OOmb1oi9dlCfqqk gAo+gmqdFSmn4bOnpLmodNo+drqj41mfk7pjiIoLnqoNjFqnjhoOkDp5/2SWoCqnqqsqBmY6C5pK P6i6BKIqDqCKq7mqq7vKq73qq78KrMEqrMNKrMVqrMeKrMmqrMvKrM3qrM8KrdEqrdNKrdVqrdeK rdmqrdvKrd3qrd8KruEqruNKruVqrueKrumqruvKru3qru8Kr/Eqr/NKr/Vqr/eKr/mqr/vKr50n MP8KsAErsANLsAULLv26q1RlsAvLsA3rsA8rL/aHsIhKTC1qsReLsRmrsRvLsR3rsR8LsiErsiNL sh57nBNLkBVbsivLsi3rsi8LszHrsieLskSosjKLszmrszvLsztLszXbeTfbs0NLtEVrtET7s0Ar cEJ7tE3rtE8LtRubtP9Ke2ZMG7VXi7VZ27NTS7UuZrVaC7ZhK7Yiy7Vdu15W+0in0RSmEUnZYjhv q7Zw27YXaxrNAIV1e7GUNLbsybZwa7cZG0p8C7dfG0x7K7VmK55Wi3pNsbhxWDI+kChfy0lgOLkW q0t0q7ZXSzaN8rcYewLsubkw0AKWm7mCa7gWirhKqbibwLiQQFtyG1a6ZDgCZbFkA4YwULodO1NY +7kg27tQ+LtGALK7u7dlm7rntbqX6wMw0AwwYLG0S1trC7rMu7aKoramobJlxQyd1BSrBIWPZLfd wr3fO74u4LadC753K021O7p8e753G0nBy1jt206ngb132wziW7HeW7z/x5uylnsJLWBYi+W8LQq9 BbxYwKtL+wtJjHVOBHwa44S7NvO48zS/4DS67jS6Q5XA3kRMslXAlEu/1etO3TtUIxy8KADCGRzB ojsmpmC4xuu/5LW6juDAmNC8iaK2uRJKtDu3TXECjwTEndVOdkuKl4tO8+sCj9u7I+DA+UsDxLtY l8C49vu4Nqy8liXCg7vEFfsD7eTFKMwtDvkCaovELQzEAvy4/TvD5be6jgVJBKzDYRW5F3sCuztV 5lvF9cvHS+zHYAyFJfO7i/W3U1yxn6vFjOUD34vCJ2zFUKhLxCu/vUiKCezEZ1y9f8zGbdx0q2sE sivHz3tO5duin8st/y1wuTtFxZjsx3i8TcYUyM0wAovbwahcuiscwmncosQbyWs8ySNMvDPFyjNF vGMrw5wMXp6sSz+Aw9FrwCNsxy0At3w8JmXMx8pLzI/7A96ixGHFDGPiA81Qy31cvd8yvbu8xr2s wOcMhsEsVhF8vSVTzGJ7zMjMXcoMCc2cy4EMzexLhUccSekMz32czYyrskQwyLDszeGsy1o8Uwls GuzczgLN0N28zuw5zsMsz2tszPa8tADswIIsx4kizv1MBCJMx1XsWNmyygPdykx80ojcvg8FxFNs t5+70qZsxrl7x+BC0ZYlWxINvPYL0AS90adbzx59XZ4sTk9MWyS9vP/P27m9m8SX+1rLbM3YrM0V nFsWPdKG0wLjHNKEbAnQ3ItlSdFI8ssATMXXHM8pvclKHWGEC7XSoMeA+7d2jdfSi7F6vbadS7KA zbF+vddxLdfqRdenq9iLjbVJfdjRldiMLdmTjbSPPdeUjdmZbbSObdm/FdmaDdqhTbadjdiibdqn XbKcTdqj9dmo7dqvrdqrPVhWC1Z/Hb63Xdt0C9iE3c6CLba8fbThy7Lm3NcrG9uynVar28Gui8BQ DcCdS72kW9xYq7wW69sya9O6zbFx+LUJvMvXDYbHjdxnpdwV27hb7U65C8ltTcfXDdyaHLXVbcDg /bKEjLHyfd+Ziwn/dOu5/cye4j3eTJW8O0y9CNy++wzJSUyF3v3e1ZDJ+Pvdvb3bE863vi3feu3d dw3hfK3hDt7bFY2/f3vhFl66EO3efyu/FgvgAZ5KvTTLI9oEq4vTlxDKUd26Cw3J+w3EzcxaLFy/ pkBJMPzUo3sClhC3prDDCXjTqrXEodCiVj1OVNzVrOXFnFTkm7C4IX3SId3Mi5WAEezkFKze8h3F QL7QNJ7PTI6xK87immRZQuxPMQ7A+70cNU67QV3Et2s45r3SpPgC8gTmzfC53ovTpFgeLL3QK50r fKxZbr3EgG3VX2zDQdDFiA65lHToh365hG7Fgp7dhBzFkczHK63n/8D7ziwtziXdvPG75Wve5qTF V5EgWiLw3DQQxzlMx2Ki3lUsxA8t6Dnu6C+N406c0IF75oeMyhVbt+2byHuc0AydyCf9xd3cu6as 7IIcz6lu7Aydysyeu9zNy6dhyA3t3+H96qyNjtyyVodS652lz1uN5Pk9U0JsySfQ0kb90nAryDOd v2Cd3Uqc4e7ewKX+7F4uu0Fc0dVO5GGt79Z85v1u76tOhW+L35Fs17/7uf8u04d77oS1UYsCjXL+ 5CVD449k5+Ve6ghNTAS8wJis1fk+zcVuvd47zhkOSW8rtFAey9x+8G0r1grvA3Lr8Axd5gsMwfPL xaWO0rqs8dKM8v/d2/GkBVaBB9Ko9+6xu92n0Uk2He7BXtCLvLZaz+9O/PC6TIou0Entu+3Ozu/Q nrl6+/MLD8hAzLY7T9MLvelqn/O5a8M7TvQ37fQcH/VoNb9XeMdO4Mmv5dQGXrvQfRpNHc67a1he f9Rzb1kJTfY0D/jd3MtGvPdenepUWM4JL/dKrMWTzsQ2nflHT+pnD+wYbbefvvm9u/bmPvhoFfL7 JPLs6bxNffU2DvtK39Ysj7tEoNFLrMZEBfq4LO6bD8JePlRPLvY7vyg5jLs4DvTd/MDmbcFFzyha /8WhK/0tKk7DH/pKvBwW/d+3j/tV41K0fdsebtfATeHy/7376+D/em23Qoz2IEAIACCM5CkgRMme 5UuIZLnStwnTKXISNmqXGtJ+L4CsFKy5WIAeCnjTTZm7JTWpqpIIkC84LB6Ty+YzOq1es9vuNzwu n9Pr9js+r9/z+/4/YCAAA4PMD4MAmRMXY6PjI2Sk5CRlpeUlZqbjFpdX4CdoqOgoaanpKWqq6ior ncmI2aLmLG2t7S1u7uTRlGfrL3Cw8DBxsfEx8qqMCQIDAoCirvQ0dbX1NVKy9jZ3t/c3eLg4hBFh IgFDNPY6e7v7te+4/Dx9vf09vjEihED614O6dwIHEizoKF6+hAoXMmzoMGG5fegCGqxo8aI1hA83 cuzo8SPIPstU/zhLNEbWJl6SVGKExDLTS5eNXr2aGdOdxpA6d/Ls6dOhiViSnFkS8KAlJaO3lBY9 ygjBg6hRn3Ehyuimrpw/t3Lt6vWrqX4inKHLibKR1aROkUZiWsut2kbNdjxgmYMLXHhg9/Lt6/cv m0IQVnwBAPCkTRpp7wqpkrcx5JUvGaOYTBnF2imXL1NRupnX3cc05iqmyhmyaGpaAbNu7fr1RsKE +R0WcxaJVAYkiBqdijkqSqbN+kEF3kXqCARUHywnLjU4g6iIdkuvUpy55syKfZMorvsJIeNGi1Ml kHt0deHTR3/fzSI69kHPnD3vrb3aatj69/Pvnww8VM4IhlgVhf+UYCBRvD3w3jPmHaGUg4PUBV4J E86FToXP9CNhcu11R5VyT1CVFgkTGvXgfSEaxQI6IxAFFYtHjVehiy4Y2KJ8EE54A2k0qrigfBxS GOE6+fl3JJJJKhkKTUJZV1qQQMLgFokn7miVUj3WBeGF85mm3QwUYvngIjtiVsWOc2F5lJYipPkM VUEaWIOVKl3nW5q6Jfhlhe0YuSSggQo66B23IdEMdi8+UEiH7OEgFZR9pkVUXSvoZsOaVRyyKG4l OaZcdChmR5dhL1TaXklrkbbpM2ZWGBUXw9XkllJ7npnaNH8SuiuvvfJnCLAyUKQYWbYeClyPPWZo VaaTwtmipS7/8skjc4dEEV2cFZLlal60HmXmqaW5pWaxraLYTLbdedjnmcZ6dh9+vso7L72vgUdT UAQ+CmVJcSpn3mjZ6ijtmSGWyCJUIjqV6Q1SzgUFbjdgWKKoU+yI4ZxZomqCqj2slaATKgw8hbIU d6Gnl7fCq1q9Lbv88lYqqHEWUzNSekKIO3K7cMp91uyUUbrNGCS7NEhJCNETn3xcxTcwC+d3D5so o5RbAo0daanulm7JRNuaKa7S6Aoz2WWb/dBthGCLiKLhjWAetqPiRtyZTywqpWHLOcEwetjWBXd0 sgSttsBSpbco0ru5Dd7dLiAen9rMITK41UzzuK62ibtLNeYs/5/9OeihgyMAsNAMW4QTLviwwgsq 3NZ6TVgYgUMKkak0+wwqQIyDDaRrhm8UKM1+7+7JyZIEEqjXXhnteEmRA2OrszO26NVbfz0oYr1S 1ulsef9I19+/Qz325Zt/vhwDgmFY9+K7f/n7BJGPPv312x+Gcrb5Y1v8/WtmqP/idb8BErCAYUCH 2ojSvgAysIG5MiAEIyjBAzqwghYU2wQzqMHPITCBswEDAC8owhFGYn4bPCEKj2SEL5TDJCwkIQxj WMIU0rCGg9oHGAAiLBDKsIc+lJgNgyhE/5SFdMrphwsHg68lMrGJTnwiFKMoxSlSsYpWvCIWs6hF KCJgiF78YhxrSLcMfiSRjFs8IxrTqMY1srGNbAQjHOOonxAAADs= --001a11c153f676e30c04f35bb01d-- From nobody Wed Feb 26 22:06: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 057871A0701 for ; Wed, 26 Feb 2014 22:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.276 X-Spam-Level: X-Spam-Status: No, score=0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_GIF_UNO_LARGO=2.176, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OAwB7xBVQDC for ; Wed, 26 Feb 2014 22:06:09 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBF01A0706 for ; Wed, 26 Feb 2014 22:06:08 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-f4-530ed5d0de2f Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CF.62.11484.0D5DE035; Thu, 27 Feb 2014 07:06:08 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 01:06:06 -0500 From: Gregory Mirsky To: Ravi Torvi Thread-Topic: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPM01/87IUTaK2v0iiw2Xi2FDUfZrIOjeggACacgD//8e7IA== Date: Thu, 27 Feb 2014 06:06:05 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B773138@eusaamb103.ericsson.se> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B77304D@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/related; boundary="_004_7347100B5761DC41A166AC17F22DF1121B773138eusaamb103erics_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUyuXRPgu6Fq3zBBkseSVt8eniJ2eL7pSUs FreWrmS1mLA30eLviissDqweO2fdZfdYsuQnk8f1pqvsHl8uf2YLYInisklJzcksSy3St0vg ypi06wxTQdNrporNk88zNTA2XGTqYuTkkBAwkdj84SwLhC0mceHeerYuRi4OIYEjjBKdJ38y QTjLGSVOXfnPCFLFJmAk8WJjD3sXIweHiICKxJU/YiA1zAJLGSXmfulmBqkRFgiSOPLzB5gt IhAscenKZSjbSeLpqv/sIDaLgKrEqnfNYDN5BXwl1m56BbXsN7PE3RXrwRo4BQIlFs66AlbE CHTe91NrwM5mFhCXuPVkPtQLIhIPL55mg7BFJV4+/scKYStJzHl9jRnium5Gid2XmtkhtglK nJz5hGUCo+gsJLNmIaubhaQOoihfYvGmlawQto7Egt2f2CBsbYllC18zw9hnDjxmwhTXkdh8 aSfUHEWJts7ZUMuWMUqs7tgHVMQBVjT/rD1MzZTuh+wLGHlXMXKUFqeW5aYbGW5iBCaIYxJs jjsYF3yyPMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG2LIPB3jvTd37 reZTmI3nE2mxLyGclSYlO3Ve/IuPrOqdb9blf46z3zglbaetkRODqaY05/9fC+OKdHvEfkaE ZPEWMHzn4z81Ue0RXw63hfxSjnup/0QtIu7kvIhgDAwqzQos/HJNZPvXtTe2iQa5rNiycUaN X03yv1d9b5fNebV27eabE3KUWIozEg21mIuKEwFwxfBm3gIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UCAs8p0JzUEh7jYlgFvd-bYUenw Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 27 Feb 2014 06:06:13 -0000 --_004_7347100B5761DC41A166AC17F22DF1121B773138eusaamb103erics_ Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B773138eusaamb103erics_" --_000_7347100B5761DC41A166AC17F22DF1121B773138eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ravi, I think that we can try to find time next week for more detailed discussion= if authors and anyone else would be interested. In the meantime I'm still holding to my conclusions. Regards, Greg From: Ravi Torvi [mailto:pratiravi@gmail.com] Sent: Wednesday, February 26, 2014 8:24 PM To: Gregory Mirsky Cc: Alia Atlas; Ross Callon; mpls-chairs@tools.ietf.org; mpls@ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 I support this draft as a co-author. Greg, Protection domain for classic FRR (for node protection) includes a PLR, MP= ., and Path that avoids failed node. Options listed in the draft does not stretch OAM domain beyond what FRR nod= e protection would require. However, in some cases, responsibilities have b= een moved to MP. One of the option that Alia mentioned, involves a Transit LSP as merge poin= t. Stream selection could be based on a layout of BFD sessions that involve= d merge point. IOW merge point need not switch stream if it is not explicitly detected by = set of BFD sessions failure. Thanks, Ravi On Wednesday, February 26, 2014, Gregory Mirsky > wrote: Hi Alia, the problem with stream selection by a transient LSR on the LSP is that acc= ess links between CE and redundant PEs would not be monitored. Thus I see s= uch scenario of little value as it is no different from "classical" RFC 409= 0. I believe that protection domain has the same scope, boundaries as OAM d= omain and that defines limits of what can be protected. To protect ingress,= and egress for that point, domain must encompass CEs. Ethernet Service OAM= (CFM/Y.1731) got it well through MD/MEG Levels in, for example, this pictu= re: [Relationship Among MEPs, MIPs, and Maintenance Domain Levels] Regards, Greg From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, February 26, 2014 3:50 PM To: Gregory Mirsky Cc: Huaimo Chen; Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 I do support this draft as a good starting place for a working group docume= nt. It still needs work - I'd love to see discussion of the two approaches= described in it - but I think it is a good place to start. Greg, the concern about distinguishing between link and node failure is int= eresting. There are four different approaches in the draft because there c= an be different deployment scenarios which make each valid. When consideri= ng the different cases, the concern is always whether the traffic might be = duplicated or not. Obviously, if the traffic source decides, then no dupli= cation is possible. If the backup ingress can determine that there is no f= unctional path from the ingress, then that is a different case where traffi= c duplication can be avoided. If the potential merge point does stream sel= ection (as is done with MoFRR), then that allows yet other decision points.= Different deployment scenarios are the key here. We did actually go d= own the road of how one would need to set up BFD sessions to verify failure= - but that is also deployment-specific and got rather lengthy. Alia On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky > wrote: Hi Huaimo, I don't consider WG poll as a contest in art of persuasion. I've merely pro= vided my technical opinion. As for your question, my opinion is protection of ingress LSR, and egress L= SR for that matter, is outside of scope of server LSP and can be easily add= ressed for client layer. And in my opinion MPLS WG should not spend more ti= me discussing standardization of attempts to solve these. Though it may be = reasonable to preserve them as Experimental. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Wednesday, February 26, 2014 1:25 PM To: Gregory Mirsky; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protecti= on-11 Hi Greg, It seems that your reason for do not support is not persuasive. Regarding to your statement "The only viable case presented in sectio= n 3.3 where CE is monitoring access link to the ingress. This is well-known= case, e.g. Ethernet First Mile, and can be addressed in many different way= s already." , can -- http://www.google.com/profiles/pratiravi --_000_7347100B5761DC41A166AC17F22DF1121B773138eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ravi,

I think that we can try t= o find time next week for more detailed discussion if authors and anyone el= se would be interested.

In the meantime I’m= still holding to my conclusions.

 <= /p>

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

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

 <= /p>

From: Ravi Tor= vi [mailto:pratiravi@gmail.com]
Sent: Wednesday, February 26, 2014 8:24 PM
To: Gregory Mirsky
Cc: Alia Atlas; Ross Callon; mpls-chairs@tools.ietf.org; mpls@ietf.o= rg
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

I support this draft as a co-author. =

 

Greg,

 

Protection domain for classic FRR (for node pro= tection) includes a PLR,  MP., and Path that avoids failed node. =

 

Options listed in the draft does not stretch OAM dom= ain beyond what FRR node protection would require. However, in so= me cases, responsibilities have been moved to MP.

 

One of the option that Alia mentioned, involves a Tr= ansit LSP as merge point. Stream selection could be based on a layout of BF= D sessions that involved merge point.

 

IOW merge point need not switch stream if it is not = explicitly detected by set of BFD sessions failure. 

 

Thanks,

Ravi

 

 

 


On Wednesday, February 26, 2014, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Alia,

the problem with stream selection by a = transient LSR on the LSP is that access links between CE and redundant PEs would not be monitored. Thus I see such scenario of little v= alue as it is no different from “classical” RFC 4090. I believe= that protection domain has the same scope, boundaries as OAM domain and th= at defines limits of what can be protected. To protect ingress, and egress for that point, domain must encompass CEs. = Ethernet Service OAM (CFM/Y.1731) got it well through MD/MEG Levels in, for= example, this picture:

3D"Relationship

 

 

      &nb= sp;         Regards,

      &nb= sp;            =              Gr= eg

 

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Wednesday, February 26, 2014 3:50 PM
To: Gregory Mirsky
Cc: Huaimo Chen; Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

I do support this draft as a good starting place for a working group doc= ument.  It still needs work - I'd love to see discussion of the two ap= proaches described in it - but I think it is a good place to start.

 

Greg, the concern about distinguishing between link and node failure is = interesting.  There are four different approaches in the draft because= there can be different deployment scenarios which make each valid.  W= hen considering the different cases, the concern is always whether the traffic might be duplicated or not.  Obviously,= if the traffic source decides, then no duplication is possible.  If t= he backup ingress can determine that there is no functional path from the i= ngress, then that is a different case where traffic duplication can be avoided.  If the potential merge point doe= s stream selection (as is done with MoFRR), then that allows yet other deci= sion points.   Different deployment scenarios are the key here.  =  We did actually go down the road of how one would need to set up BFD sessions to verify failure - but that is also deploymen= t-specific and got rather lengthy.

 

Alia

 

On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:<= /o:p>

Hi Huaimo,

I don’t consider WG poll as a contest i= n art of persuasion. I’ve merely provided my technical opinion.

As for your question, my opinion is protectio= n of ingress LSR, and egress LSR for that matter, is outside of scope of se= rver LSP and can be easily addressed for client layer. And in my opinion MPLS WG should not spend more time discussing standardiz= ation of attempts to solve these. Though it may be reasonable to preserve t= hem as Experimental.

 

       &nb= sp;        Regards,

       &nb= sp;            =             Greg

 

From: Huaimo Chen [mailto:huaimo.chen@huawei.com]
Sent: Wednesday, February 26, 2014 1:25 PM
To: Gregory Mirsky; Ross Callon; mp= ls@ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-p= rotection-11

 

Hi Greg,

 

It seems that= your reason for do not support is not persuasive.

     Regarding to &n= bsp;your statement “The only viable case presented in section 3.3 whe= re CE is monitoring access link to the ingress. This is well-known case, e.= g. Ethernet First Mile, and can be addressed in many different ways already.” , can



--
http://www.google.com/= profiles/pratiravi

--_000_7347100B5761DC41A166AC17F22DF1121B773138eusaamb103erics_-- --_004_7347100B5761DC41A166AC17F22DF1121B773138eusaamb103erics_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=18335; creation-date="Thu, 27 Feb 2014 06:06:04 GMT"; modification-date="Thu, 27 Feb 2014 06:06:04 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhlAOCAcQQAP///8zM/8zMzJmZ/5mZmWZm/2ZmzGZmmWZmZjMz/zMzzDMzmTMzMwAA/wAA zAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA ABAALAAAAACUA4IBAAX/ICSOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2yy0REAyEoCogqMomwrjLHgrACLNUsCahU/dRvs3vz8EMBABzdXpyKHsian6MPgBwh1OL KZOGMQgPcQwPhSyVPwIPZ6IlnI2nNQSZX5k9ny9xaQwqBLN2pKi5uj2hgZgMgzuvLAKbDwyFoaMm gbvOL72sCDDDPc0ppiS1MKF1YDDZQMox4c/meg+HoZE45S6q7BDb3Ljn9vcnYSMA+jvXL2EA8JuG TsY/fPcY2ILQDWA8aw9pLWyBgKCIUALr0FFEQM66QQA6rqFTZkxJbZUE/4TU+CCkoIt0BK1xCSBb yY0QXHZCqOWbtlkkO9oRChNNmUkfc4oUAUDlJ2Pxah3VsxLn0XE0VV7sGIwhV55gs6jqyrBlU5qG XuZ0OqajxzBrlhY9VDNuPYxfGcZsOkLktZsz5XqtFnZOuYp6mY5cWkzMVnVo8w7WE5NEoJNrqwYr Oe8oX451DhYU0exXqweoVSrc1HZ1pmPZTMuBre7YatKbkJFazVqebYU5Xe8sTEW0sloKW/nOjftY r01mUHPil9wk7J2i5bkmSHvb8024q5dNPkjVarLE0zP5YoLTd1vPW47n5HoWVAiymy8sNvrib1u1 pEbKLwqZYd5t1PUW3/9w6jUxDzMeibLgfeYp9x9visAGoDGWuWZGL5yYciBw3w1Imwju+DfCZfI1 JKIt36gyBiYzTtMQRhAcQ9Y6wZmhoCi1lGdKM9Rpp8hEDUqRIicylqVSOj1C0Fss+HHXmgjfhGJR Cdk16SIwRiImJZBgNtkPYtdkl+SaQmTHohn8+EgQYlqWBdKQH8o31pgMVnkLnM3AU5aTZfkI6Czz bCOmmGw68SCXEfrpJ5GmuDhNTTZOB2WcvrGjUHlAWTgGpbMsKmGl8qU4KGlqQEkCnv6FtOGR8liE TI7s4DgpQcqI2Y2u31xTU6NK7sTkQpctFEs/WuFnC6x26gqhLCtGJ8f/NteoImldOQazTTroESuu D262Ggxi8hmJ42fclmYRlP2Y8Eg5wE7TGZkjpAOsfXIMW1Gf4xrxqGWR/kuwbyOgO9sa7ilrIJJS 8upeuhOfy2+Gta44hjsqjSOlGZhkwvDGdRxLq5G8QZdjJx5jG+k/E/c1y3+qBmyEaHU9GMiIwAkL BmrPkpwvHfVASi2rK9NqkygwE80bkKhRafPUNzBabcu6Pb2qdsaMami1H59QzK23yGzkoDq3ajbN RB+jFtUCI7nRX6e6PUigC307MoplXHj2wXx7HLPSIzH99NfoEA22V72ZEo7JZ2MrBklCl63INHTj d8jgRupLUrhwD2E1/8JpS0V52M6qMY/jJSuOQpfIRhfXzIVrPvSvJDHFSkSh947CwHW1LIZ7uY+z zpNeox52dkmVIPzZx8WONa6Ue4vJlr6LUzSakV7eCt5r772y6bkPrDznnOutIlynP+odLjvbKjvq 0Z+8DXtYzn/LuYgfJ3HlweoX2bI3hD2tyF4LaVhfEJeN1SVvUB6blhcSWDmXYQx/3LKJGJQFMQJ6 0D+FeB//ksaQTJ0saeDjm/LyFRFgPUxFHmtGbC4WnGLY5YNBcFVO4HUtpt2wGTHUXzYUyJG/HRCG uGAdlmioLfzZDlNtgRKP4HEjKEFJKo9AoP1CFcXKoSNTD1RGN+ZVo/+mHEM7M+ogDnmgEJPQqFNG qkmeEAfEM+IKjVncmgS1ccWg0SpIxTjVjIaEAIHoY1PxWiMOMQEnQdWpIQEZyKqCRMaIEWoexkHG 6b54SfjsxkBQqogZEXWrb4jSWYr0gaCK5KymgOeUwSJIHSs3xCfN0YikmQ6dklij8eARPA1pEkOM ocOQFQg/0pGlKYwJqi1mCDULc95rXJU537zGJMYAzphSk0og8EM6ZAsQN62pnGwBTVBTAtogImi0 CXZNhWczBiaeqaBsCkmd3VxjyKDpn/sME59YkWeMriidNYhGFdJBzS1Cdi1P0hOI2bQFMa1T0Hzy YJ9gKkvU6sZNR0r/J5okFFEyT7gie26tUvKEEdBIgVAdwsQEOKFMHc7yUmg0awUxxcNOYmKRnFqU FzkFJFmawiCrgKRZPp0BTXHKMi/mlKg/XSNUC+LTpFLmIjWlA+hiYNUSfMYOZehpU6PKg6nuo6rJ mElXT2DWMwCMKs5znV62ag9E8o6sQTAfKhJVNLz6VUXmsOtff7oo7KVnRHQdrCvU2IiaJOeuiu0m O3WB2MhK1jY1K4xnLEuEtTZWMJwl61efsdnQKvIqpk2talfL2ta69rWwja1sZ0vb2tr2trjNrW53 y9ve+va3wA2ucIdL3OIa97jITa5yl8vc5jr3udCNrnSnS93qWve6/2saW8q2y93uere7hj3td8dL XvKGF4flTa96MeRXQKz3vd99KwGRA9/6bheyvXOvffc7wCfYkHIADrCAB0zgoDD2g/8tsIIXPGC9 4pB4DI5whPtq0ctI+MIK7m83v4DhDg9Yaoq0sIdHTAcNN6EYAkmxilfM4ha72MX8+SmKX0zjGts4 xvk0i413zOMUUzifyOixkG1sYkV+YchIdjGI1xjkJDs5xUVewoyf7GQc53PKVEaylVOp4ywj+cfd bLKXhxxlHB55zENeMnpVgmYhlzkJWG7zjQ/swTjLmcZbVmSX71xjMKdSzHym8Zs9eOZA01jNHwS0 oVs86CPYedEqzv+zeCH9Ykk/mNIv9nOI2YzpFTc6e4XudIoR7UFFi/rTRXg0pi2NQ1VTmtUe3LOo h+VXU3ca1b0L9axJTUBbYxrXbgDGrFMM6zoLe9iu/KmsRa1pJnN62MCGm65Fzevs+ZrS0Q6CqyFd bAJue9Hd9t2yO93sNSPbkPIFdSHPXW3fXRvS2RbHsYcdbt9929D1Dt24MV3uRD971vG22bQ73e7e vXvRAffBvQOd79AtnM8Np9q+Kd3vUv/71On23cAxXfDQHdzQCefFvGcdcao9/M4lt9nEIV3xXl/8 1hnP9bqR3XG4fTzQIefByeWccpvtvM09H9fKF91ya7/81zEP3cb/KV1zqt2czznfwc/RHPRxTX3M VSfW0A1ddHcfHdtJl/bMh930qT39zlHXwdW9nHVirT3LbWfT1gPddYN/Hd5hp9rSIV12m51dzmnP wdupHHc2Df7JhU/S3Plcd4/fHeF5n9reF933gP29zYHHweGrTGdvj1zUiW/Q4u/ceJs/HuSRF/jY d41fx5+bH6l3QQAGQPva2/72BlhAAXbP+94XYABIDoDvh1+A3N/++LYnDvKXP4DcE7/3AUDyAJ7f e+Mz3/YBCMvsr397B1Cf98H/Pu8dwP3kq2f75af9Agwg/vCLvwDrT/8A0iN/2itAAeKP/pDfX4D7 yz/7CIF+6bd+/+03ZML3fvGXfjQwAA3QgA74gBAYgRKYAEhWABJ4gRj4gAlAHAmQgR4ogQWAZB34 gSTYgPMHFgFQgioYfCpYgg2Sgi34gSwYgx6YHjTogfonZDeYgQCIDzC4gxI4g0AYgQs4hBFIgftn hBC4gYUxgkrYgCE4ZE74hCfIEz/4hA0ghFj4gljogFr4hDbYhQ2Qgz0mhmNohWb4hUq4gBTIgA5I gTDIYimIhCnGgHTYYwXQhhoIAHG4YnO4YnbIgXr4hnzYgHLYAHcIAAwYhUKWAIPYgHBoiH6IiIDY AFUYgFkIABAoEA1IhpyYiXUoiUKWgp/ohZo4hiwmigLhhlwYff9TCHwdyIgp1oFkGAAdyIKu+ICw 2ACyKBC0qGK22AA2GIIW6IDESIkrZoGyKHyoOGS8CADFCIXQiIwqpozAaIE9eA8pmIsOuIueeIqV CIo9to0A8Irl2IwqpoqK2IBsWIrPGId56IiOSInySIyJuGN56I4hCI/yOI8UWI/QyIRh4Yj6WIhZ GI/ySI+OSIy9uGMEeYrSyI/9qJAJQIyX6IOZ6IRI2IkD0I8jGJAVOXviyGOkeI6Q+Imz55GGGI8F IJKtOI2mGIu2OJFj2JGOOAAlOYqoGI0ZyYszmZA1KY84KYzE8YxuaILT+I8q2ZIAmQDfaGNGqYtJ WY5L+ZMh6JT/aBh9POmLQUmTINmSDIiLMCmJtGiTQPmVLjkDHcmHToiTcTiFJ6mLa7l/cNiWAfCW RwiRltiRgsiW3XiXhgiXlCiXDWljBBmMJgiYWSiYFCiXF6mNWciMUBh9nciTXuiEITiSO0aKkumT p9iZD2iSz0iU6bGNiomIudiSEgia5YiLp+mU56iaEciaAhkWnhmazNiYESiblfmUNXabXpibemmM Vyh82WgPpvmDsEmLlhmYxqiJrqmcuQial/mcpBkDazl9XjiUi5mXD8iUFdiG0aiIeLmEesmUfamd hsidokmI3yl8Iiie21mee/iej4mcWcidNfmZzdmdccmC5OmA/7PHn0GokZrYisBnjLvImw9Im7iY oFC4oFcooFtZm2Dhk4jplMIJgsXZkkiGoSOooRaomxDIoMaZlRDKi97Yn6LZmA8Kkb93jtTpnHHZ jrLplLLZnnFJofdoY/l4o8ZJo/XJo30JpDnKmHp5gPEJjTCIo/TpnhR6n+dAipm5kgQagaKpmgBa pQd5pZuImSnYii1ZjPApk6sZjS5qgGM4ppUZmxName45jNsXoRu6m1dYjr5JYz5Je3Q6osM5maGJ lZhonGR6lWtaoMSpmTa2jWy6pjLKomB6nTCwlllogrvXhyrWgXB4l67YozWWj5VqiZeqjue4qXdJ lX0ZqtOXo/8rpql8yKnlWJg1RpCqOqqa6aqc6opSag6kiKM+qZueWIyveqoWCKC+Cp6dmIyGmKvT KKa/Z4jd2YswmKvRF5ZqeoBuCJ2xOIljyKwMKKdO2Ym+eo8Reark6IxMOa3jmorvaK5nOKi7l63d GazLCqvFeq3xCq0yqqyRaa+S+gKUyoy2mKMIGaLQyHuuSpeaKLAhuZI0SYG9p6mpyrAE+7AHu3vb KoWNSbESOY+UGLGWqH2L+azTB6xm6bGKiLCkuqgjy4Al+5kn+5GrmofseH5rGq5aKpMq2a29t7I1 xqg426u/SpN32bP/ihA+2Z0L66c7O6a8l6zoKrRLS5Ee67T/u9eJWZmHKZizXXmWM/uR+Bq08xqz 66myR9sClPp7jXmk3mmeCquia/ukO6qBqaq2msi25rmbSwq3dyu3gwmBu/oMvRquM+mlgYqlakqV 20irh4qlgimmi6mdbnqmiKuTzFiOkmums9mcciqqz1qnJfqmefpiSbuqDAi67zmbWRu5xcqciLqJ +Mq68wqpRKiWjYmji+i3JEqIb4u7SeufQ0q3TXi7wpe7Qgql37m3vou3wduNInuOrfm3Mwq8pqiT 0Hu7hludEAi50xeMk7u5lTuOh9q9t6i5EDijnft72om6iXq+H6qa6ouNfsqhqguvouq9ruu44UuS 48uUs/u6/w/YjsuqjLr7p55KY6AamQR8vHP7hqmqwL+ro3+bvBoLjszIvMjrvCjYnThph9nLwIr6 sxwsksBKu9trsxdMmdH6po0bmrHroc7JoBRau4WRtHV5qLvbvg36vn8YjOwLqOe7ujD8v/oLu5ZL wOCYv19Kw9ipmxJar7k6wbwrZAn8xP0axTmMiA9sxcPKqVIsjRWMlJrbxYCZxYHrDEJ7jMBKrfi7 v5sZrVPZiWxcvkxcGIxKidm6rdQqv27MssKZx+3KqXx8wjUsm4opnNRqvO4btXIMp6Z6l4rcoKs7 iDI6x9TrszR2x5RMi5YswWxYjBUJicVIfIjYnAf8YnkIyv+qDIXDV8pHKIir7Mq82MqhXKLxGcu1 TMq1rIsiS7MVqamjPHyxKJgs6MvGzMq+N8x13MsjSLO8CMzJ/Mx9LMLOXM3QDLLOHMBFmcujfM09 u8sC+qHcDIXe/LTgjLWYaM3kPMvRnM3VK77qLM3Ep8yEjJ1ieMou1p9AaKEIIZhDKKs05s9AeMa7 wMJDqIZGyIViiNBDGIZdOLouZobHOaVpqKZiWIRdiM8tps87yM/4INA7CNAvBtI3SNC6YNBAyNBA qNBdqNI76NBYCNEtJtFouNAW3YUYjYUazWIcfYMefQ8kTYMi7WJBHYMmnQsovYMufYMsjYVLTYMw /YQyza7/D13TLX3TW6iW91yB98yBYjjULVbULXjUqJDUN/jUMdjUT4jWLRjVSjjVK0bTmGjTOnnR Wp3RXJ3RXt2FYM1iYq2CZH0KZk2DbK2Caq2Ehe2CRSmGcJ2OjG3VTo3VYHjXOp3XOr3XWNjXrSqG gd0Igx2DiU2Ch22Eof2Bbm2EjZ1ico2RdC2+di0DR/mEO82vl92EXy2CnC2yrc2/r00cn92CpV2D i/3QH/rYc33VdY3TlC3bli3bmP2Emp2pub3Bu/3GvW3HFZ3cWV3DjF3cVX3cka3dkw3bW52Eem3b fI3bXdjZjPDbKyjZa2iz1c2y180TEu3dMQ3Zaw3fCb3c/0o429XY1eid2eqNheztB+5dgsGdgaN9 0Pzd0MMd0/gt1fqN2A++0v4duh0pyjI8xXiYgWAZorb6ygPOoRteyh0Oxo0I4inJ4QZ94H2Q1AmA k6o84wLt0jMumb984stM3ReY49GYh+o5zZmcgUBujDOuz6dtn0j+rKs54XZ6lKkc25IM3kdI46Js 4xeI41heylougTmtt7TnpgaZl+YNgooooWW+hM9ty2Muk2tOwSt+gSH45p754ro9gWk+lXd54xfe hsDnp31+gQ2Ox4Fer/qs0oAOk6+q5BEegTR+yJB8gantjpBunNM66atZ4YQ45oKOmET+Yii96J8u 0GF+vv/FyKeG+uPNjeomuIgS7MAl7up7+YwgHd2ziIGSqeqxboJ5DuluqJoQm4Eqzac2PJZgLt8S aOw5SuVG7NrLHuxx6OzazN16PoICm9SV/qeEiO3YqO2c/uqAOuwYWOzS/rEMnuEn2cxbK+Ot3u2A muIOqABuUe/2fu/4nu/6vu/83u/8rgCszu6/S+cFbp4CL+8NSO/+vvAM3/AOn+8HoOugTJXc7sLi 3aATz7gY+PAc3/Eez+8RT+kZf8nPztuUS48k/4Afv/Is//AYyJt8Or3h7Ix0/oMx39MH0PI6v/P1 HvInr5QV/84mD74KGfQ1S9567p4IT40fnvRxufQKz/P/Ur/zAO/0g7n0uM6VVh+3GRj1U//1He/z RbyYWVzy1g3AFO+BYL/2LC/2S+ycvY7Jol7uTni9Gcj2eO/yNZ+oMg+1Orj3gNr3DZDzeV/4EE/3 l1n2Fg/tY5/26Y70bTuaSw/gKabPJJqZk9/myIv5SZ31vX75fZuBMM4HKD2Wjl/uF276Gk/oyo6l 40nHqH/xXvj6Ke+ASz7wN8+DUK7Dua/r4X6QiW/0IVzkW/76im/76r6S4j757z77yy/jmu/8tY71 Bb+JqR7Jy/7rgBvsmnj8cu9iKM3s3S/8hS7+ILz4Q7/90nj+yG/tkS+wPb3tGEii8M+Dv2/+3j/8 c3+B//gPAkAzkmUDoam6roNZFkFRAEkTv2UC8L3/9wq5UWxWuwWGowSr6XxCo9Ip1DYs0mw4JQ3o 9Vlz2ON2OKCi0+q1KjnczWSNnXL0vQPcOXhxLqqzBQoONum98Mk1HCnhfRmaIAophuUQWl6i1QUM JNCMJA4FNHppcno2gOYEYLK2QjzqAMQJ0dWNAsGSRPrVnbC5KA3wSBYAv93+SJoNExnvuUKzUr4I yzbXdSHzTJtUEztTR4sL5pJ0ASeUk2j3qN/woLv7jtMHup+TBHCXsPPcw+fbR6IewTS9ROkbMUCZ qn5/lCC0slBTwYqFsAGcI8/hPwDxegUC12vkjn4MR/+StKiyiUCUYhy2dNltJc1XMl1yvImyJk8U 8nQq6vdTZ0+aQA86PEqxaL2hN3MqHRIy6h6HJ6nOYWoxJtBs2rjqPKO1KdYXUMsOHGvRqcyzaOep pfc2X9K5qOJGY4tTqF24aURSLcnuamC89MDe9IoMsUyxhl3pRekW7WOydieXrSyur6h+nDVjijwS M9apcwVrIxyVCehWjF0qvvUapePWhET3Ik3VNjTctvja5c2Kc925q4Tb66s7qum3qJGpVsoa+aDZ I2OPst6rNnU1vhkBn9v90vchy5WOH0Tcs93j6amUz3H+aHO0z29FPzr9fRrtGPv5Fwx/acRnVnhv DZj/3GUHUpagQe0V95Z7DjpRoAnzAVVfWfeNkh9Q+1FYhV3YNRKgGSFGYSE/DGaGInzKsViai1Gs x85nM66g4jox7vaLLgVQ0okNnRAxg5GxmPRjkEDOQYyRM+iA4xNhQAkDk0Te8CQlJOJB5UkzDOmk kZRwJ6VNS1RpDi2SdPLkheG1aQKUWLZ5ZAlmQqFHnFYSEaabK7KjZ5pF9tnkn2nhuQKfizKZ5Zgl dGajmnISY8WTjX6S6JmGUlponYMGFeiPX1ZqqJ2IqmEMDc4II8QWAcAKq0e6WGXOrCS0isQnsYpi DIiJhiEKQ6Jo4UYesVpDBEx0DUuGsbwm20CZUuqZ/wcM1tZCA7KGnLWDIdry8s62d2rKQrXfWjuJ uLJyC2e6yhqrxbEIkVsuCiu++Ykk8wpLF3t2PASwvnZAq8yE1NKKbrzr0rujqEu8K64d8o6L6l+2 GtLvq8rU4keS8EJqzca06mIvCsHeCnCxE5ujB5d3oOzMNrqqS4Qe0+JY7SLSYvtHGYoo0+3MCvVs Mz/KmNwGrTsLs/DP0QrNdLrOHm2xpisq08XANdOMSoTMKPtHIjuXcXDOS4fRNMtPB+2u1E5zi7SP Ni/iratupFJ3rXRbYTfNefeddLADuCzMylx3/PIXgxdONeIP4TxjtRN9Qni4P4MiNOWoWJ5txnIn vf/pDptvAjekbT/sB+mWq4s56PbyM4Axsou9bxgdR6pN7LMLs/XOuGs6ucGsO751qNoInw/xhxvf XAyUFyPHyOv0vTcS0BN+t/E1/4pnsFkoBP4WZLu8rL6LLOQ4+bjaW20xEOPg+ekOI0/r+37E7/Pn VpfrPjqymC4fqKsf/P43Puah4nXlOpoeZFA7lhntE18r2ynGRqUGBs9+Bgyg8YR2PzhwMIH8m4Kq ZACMhUgPb5xIQAJY57HBtOx+KNQe51jYQj0JToCU04f6gNSJTdgKQDqUBA8PJwsWPo99/aNVtlB4 OX0gcWdCa2L+bGZD8I0gdD5hos+c2DoodkKK7qL/ItyuuLPQ8SMdQ+Kh73yYRAn+axIJUeMDgYZE IGYqUdUi49rAiMXjIWOPXTwgEswYBuexUY40zF1CIPaxQv6hBimEoz9ul0N9vS8dXwRYD5yhOC98 L5NJUJ8PWNU+kiVkIVV8RzsYIjRU2ECVSciWD1KhRdGJIJVxWFstXekuWEprl63rZb1gR72JFKMW YytlyOJYA2Ryoo4/cIbZJIfKWAqTDMSkXyCvGUxCesWWc9MVFJMwSRFW5ZE4KKcIp3eISyaQDu9T n0A+CYTvydMF9DzREiEWzEms8mdvSh0dJlKDgKrjltX650FDOFAC8sKgP+yjEtBIPRwsRJm2C8XX /yaaUWkKpJouWqhEwamOV5bUocW8mNFU6YJzpgJJMGzpDF66SNV0z0zfg6Uc9vkSIQ5MHz01okAi N1KSxUCTCAUPQUWQ1CQsVSpaXOhTaVY8AzW1kFBV6QjNlEZFgFWjEHxB7pDxVRGIQKxcM4FIUURV oVoVgQ/tpj+ratKKjhMHMZADTHFqPb3CSgh9fQM85UA7iq71WkAV4WE3mVglZtCfipCdruRnnl9O 1gVRrcRUSZbZuHYNqxCthUc0y9UsJu2rpQuXBTnqTBusVq07Y2tkw1Va0AoUUKONJGXvKtU1lFBg 7cSbX9VprAe6ExKFddXUiHoF87WzuaDNgVHd6v9Zjc1Sf0zdrQS1Z1nOhm6hXqPhVed6C/FiF7Hg NSbLhOEC2Ya0ozx7L0hDUVtliuy0gDzvdfOr3hcgclcDS65MU9MyAQ93e1Ey2U6BhtjZKpYdDU6W T8PRz8tp97uipSuGjaZhEyjUs6fwrXwwO2L9WpRlOxhSfRvyWj+w2Hchva/PtOvYEmf1HREs70rR AJjVWM8+8ESLPX9gIuqeckGpQ1BnlQxRJpusRrprT23fgiGijNM+Qd7QkMtSZDDYpboh0hEnn9yg 8MJoyWdmr4QihJa2jjnNZm4RcO3CoUZ4SCc5ldKRX/DlHvR5Jhe2Mo+Y0+S5XPkmKW5zHN9cZbT/ JFomIbEhpStNaQdYutJ/hkemLY3pTms6aT4EdaU/DepqDIbUNjS1qsVMITCqmoWs7jRHYp2AWZNa obZedaxrHWtcgzp0u2ahAhSg6rLKJtbF3jWcXz3sW/daKLYGdqcJIgAGOCTbQLj2LVtxbW2Dmwfc 7vYlHhDucD+A3NBggADOrW12q/sSBECAu7ONAALEWxDsrrdD4D2Wb/ObHePOtyAAHnBkDJzgazD3 wbWRboVbYt8Nv4W/Ib6GeU/8Fve2eBoknnE8VJwpBv/4FxLOcSqMnOTbZsDJ08BwlX/h4S1fg8dh /oOQzzwKGLc5EDaecyjUnOc8wHlPUi50k//c/wlG5znSk76Clwu9BzJ3uhSCLnSiU10FO486D3ye dRVYnedYr8nSbd70r0Og7DA/e9ahzvWpo70JYbf52L++da57Pe5zh3ndV6J2lbM9638neeCd7vao wz3uK9i7yvtO9btHPe9oZzzJHW+RwX+88E7HfMY1//PDCz3xik8B5T9u+aRDXuiS/3rpM376gnB+ 4p7/eewbPvuZg57noh89BFo/8dfnPPU8X33Wfd9w4Nej9ge//cyVH3Dmnzz3Nt/96I1/cOS3XPg2 Jz7VrR9w7I/D+fyG/snFX2/yW1z6MKe+4r3Pb/BzXPsw577T3V9v+EfD/O5Gv8X1f27+K5z6qf8c ++ldu3Hd0AkA76WA/Kkc/SWd/bkb/kGD/4UbACocBYKbBeabAJIcAU6eAR6gBCocA5KcA/4cBJ6b CHobth0gAGhgvmGgtr2gunHgx3kg64Eg16lgvpHgx5lgzqFguO0gJsRgts2guhWhQxxht9Vgxt1g 8eVg1A2huvVgxv3gzAUhuE2hJSRhPyxht3WhwLGcAjbhxD1h90Xh1SWgAkJAFU7cFbZcFr7bGmpF GGrDF96SHSLcGPJeGTbcGdZfGoodHfKeGzYcHJ6cHGbbFhKCADwAA0BiJEriJFJiJVriJbJh2j3i JXJiJ3oiJLLhJn7iKJIiID4gKaLiJz4AIY7/HgGk4ityIr5VHyzS4iSuolq4oADo4i7yYi/2IgIg gC8K4zDqYibmIjEiIzAi4zIWowIy4zNCozBmogpEYzVGIwBkojX2IgMQgDb2Iu954y6uYjjqIjY6 CAHI4jTSBDqqYzu64zsCHSvCYzSYopmw4zwWxD3i4z7yY/vJYz+W2wimI0BCgz4S5EEipMIx4kHW o5QYZELK20BC5ERSZLksJEE2JI48ZEUGwkZy5EeC5IBcJEBm5Ix4ZEhSwUmi5EqyZGWMZD+WpIuo ZEs6wUzS5E3i5Eq8JD/GJIrYZE6iwE8C5VASJSvs5D72ZIgIZU4uZVE65VN23D8SZVJSSFPe/6RV QmVWauXiSeVQUuU5SmRWYuVWkiVUHiU+fmWCjCVLrmVZuiVQnuU8puWAtCVK1uVb4iVLxiU8ziV/ 3CVI/mVeCiZH7uU79uV7BCZHJuZgMiZCFqY7HmZ6LCZFTmZjWuY+PmY7RuZ4VCZEduZlgmY7ZqY6 bmZ3fCZCnmZoqibvjeY0liZ1pCZBxuZq0iYUbuVrIsds9qNu1mZvYmFXAiVuCgdv7iNx+uZxKiRw 5qRw8oZxzqNzImd0dltrZiJz2gZ0viN2Sud22gt1hqJAuqV2cud4mol3kiF4lqV4kud6ooh59iF6 kqV6sud8iqRy4qR1toZ8ZqJ+0md/Uod7jv8efoIGfyoggfrngYIGgCqegGqGgbZiWCJohBKcgsYd g1aGgyoehkrohhYFhaKdhT6GhqKdiHJoiaqEh34diBoGiWYdi5roi9IDirYdfG6li8LojbqCjFKd iuKFjaIehOJokLanfd4kj8aFj/4ckrKkACAAAwRjiBJpTUYpfeqo4dGoViqpXT7ivD0AkEppPdxi IHAjjlZp0hmpWmRp9nlpfwJAly6guaFBmI6DnNLcmiJomX7elYqlnc6nKz4dvrUbCjSjAKAjNjoi AZgjOq6hCwIAOzbqQCpqCuziQIYpocpiM6ZdAlqqOY7pjeJpzp3pWKTpyY0qRwKjE4SpnxL/gCi2 6QPcIgI8ops6IiQ+AKwygJtCgK3iKq3yIQTc4qreKss1aQqM4ybCaafC6Kfinp5CZalWJLI+3Rr6 aaeO6S06Ijauqgu66arim586oqYeK536aru5KQBwoyMKaro5KQqcKrSaqLK2XKhqhbNCHL1OpLsS q7SyXJeaIwq8KgIQazfCKbpqYhsCLArA27pG68BtnJueKpy2IcvhK4fCa/Qx61PaK0RKXjGmKsut aq3K4i0i67k+HMGiqy3iG76uIrBKYq4CLMlKorryqX9WLMfJK1NkLA/O7Hr6KdjhW8eiQKPC6s8m 4MgKbLoirZN+o8oSKrvxYsS2qSYu7c5S/+mUsuTNFkXOxpvWHuS3SuothmmTMuy+JmDPjqvJlmy6 zVsKbBzTDpyjdunBVurLUu181mz6XaxTcu1BQqKmKuy6zqqv4pu5Aqys/irLoS3Seu2qFm1YrmKb AiquNqksOunQ0S2ZWu1KYi0U/FhfeG7JoF2g8dN2mqur1uqbuuqwfuwjYuOtlq3pgivSFmwbmi7l Ou7rpu6bmuO1uSq29V7dhubn5lHSkZnwgsQldK7x2lnciS6SkWc5rgD0pkAuTm+gZmq/SoH0TgH1 QgGm0qfxNpvCFa/y/hYhJC/5ClnoCq+rCWn7bobwhi/BjS/6ghjy6gKlCS8LQULfWNoS4P/vgn3d NOivDvCv/9qQ87pvAlvEIQhwAc/B/9KW0+kJBPfFABOwAeNv//ZYc5RV84YMJRALK4FZWXEM87LV bIXw+BiZoClwC9eDgeQLOt1TBBNvEAWB59IAQ+TwC92wYjgDJhgDKBgOccgMj6GTji0BIRwsg51w ETuXQoAD+7rwFLOBgXAMD8gYroBD/CYIoQ6Cy5RPnukEuDBLuMjJHnVVqggQpPjKa1gwpMBKyxgx 4CRxIFzbEtvLNMSKHD+xGSsEFQOyK5gFHkmLKGSxZOVDd9KbgoTWz7xxLzwyEgRMHtBCwBzYGqOW JQSxDrtBNsBWJa/RZAEaW51CMM2xKwX/zho0qqsCb4LocSmnTx93zB8Hci1bgllQUIv58V2Uy8e2 8qY48h8IxiIR115lRMskwl5VshjsTyabLyb704oV8j/t8DwlBCHryw5Jc1L9LyiU8p45wSqbrha9 sjZXGGWVgBTb8jqzgFlI8yToMjoncrk4Yu8CLxhfyCe/AwtFUiSFEXOdsQz1wYr9bxm8s18IwibH Qtc0lLRQlkERwyPIQCahlbzUEiWBTVagHKya7pai40eDdEiL9EiTdEmb9EmjtEkrAClTtGPNcAko QErL9EzTdE3b9E3jdE7r9E7zdE/79E8DdVAL9VATtUm7MzTJ1gqXwAEUdVPbdEdvaZTi/3Ma4Y5g sRCsXDVDbwlc8VQl/0DYdNIGj1Mq0AEoyEBZa1JCLIJAnbVT6ZNcVc4BA3D2crTpcqNT4zVNr/Tp 5JNLj1oOxHReC/ZgE3ZhG/ZhI3ZiKzZiu/P7fFQbybUJMPVi5/WtdvSTTsFUXxQ+u5RLaTUMjBI/ i9AstwwFIzQHc/IRD1Vo+3MErbE+SFRoQbNypQGT2jU5kzIsxTYhCQg7+/aDUHVFw9dSaEqrsjL2 SoFm80IZ6JUqFQMy6cFsYVRNjbYluzaA2e/2GJYxWIPsvBQ6r7VEC0Es39j8PMMa2La4asorm7IN VBgC/3Z8Q4E7J1B2HbJ99XLqIndmX/8yFCOxQ2tEOSVEGUg3VMmOYC2znyVUdh9x74QLLTHXRsm2 9EhXbh0xbbPBHQtbbpPxe1uYfIN4E9C3e7GWhOO3pvQtIzP3IrC4FWBxULh2gXuMPpP2ddevJvtL JeFKHiTLNre4jY8NMGhTMlz4XKsyHpcLe0/Wg8WEOod4INP3Dg83RNAzknuHDWe0tqQM6+ARgW81 gsnBfWwVXuE4BnMDmOiALqi5/+4vm8+BmR9wJNdxALf5Ay+Bm3OFkz85FR/Cmr+5nf85lUvw/Ub2 qFwwoFtwA+M5/1YaoK/XIJwv/RaG+n6unu+5C4Mv1c2vpDszpHP654Jzy3kwC196iGf/+qB/uucC capXsAlXeqnv+anXMKsHB4PTOpdRuudaOqy7r6z/3KZzemjwyrATe7Eb+7Eje7Ine9wpe7MfO6+H uLNLO7RQHb9M+7Vj+7RD+7Zze7d7+7eDe7iL+7iTe7mb+7mje7qr+7qze7u7+7vDe7zL+7zTe73b +73je77r+77ze7/7+78DfMAL/MATfMEb/MEjfMIr/MIzfMM7/MNDfMRL/MRTfMVb/MVjPIiHdOYu ICt6MRp8fEdyfMaTPIiL4q3+srsSLMrFpHqX/MtDu5yabSMC4sqzgcvDfM7vuZyi66QGZTcKKh0+ bdopqsxFqqA2qtDLnKUivaQaqj7i/7zOS318y7zHWnauxiq+Dau/XlvkRuLD6WrIovzXBmWsSuyl qq3Zc/3Us/2Td6kuuiLAcqsmYqu5Je6YnmrvpZvXXquv+i7ZQy4EmCs6jiHGlWu1jnzbKz6OQvUi 92zeC27kt2vKyuKqGizpJSCukj3DCmzrdiMfNmziL/7ol6h696zRuuzvqn6lqmvMEm30pv0k/m6b rrLsRz3p476Qmv4Yor4rRu3qr+HJBuPTiiu6uuI3AqOqOu0ujmvuU3y2Q7+zu2P0K/t+B8LuByUf 3iLkHuyYdqrlry27vj417j0fsmPcA6r5jz85UD+yW786tn/8E7vzV8aoY8Wut5yvD/8C9kstCEAE A5UIQ5SoyAAC80DCI4g0dJflDAFPOkvhGDUf8Ier6ZbM5rIBjUqn1Oo04Mxqt9yu9wsOcxPWsvmM bgzE7Lb7DY/L5/S6/Y7Pa8npvt+6pic4+PZniDWXszSiQ/DwqGQDoCIE84AQY/MopLiT6fiIoHPS +HhZ0tlm+IdI6Poaxrc6ixYIe4ubq7vL20soSxtcZetbPCd81voqIDDpxczE7OzlEulUbYdspmzc PQesjUzsTV5ufo7uTZYQcAU+HABcEN8wH3B/TzaAHzAQNZ4uoA4q/absgzKgQAN2+BISFAhRC0F/ Ug6qUcjwnsMrETsy4UPvn8Iz80b/QilZj18+NfwoqvEIM6bMmd3WAZgC4B1BACYbBMiZsoBQoWTu Db2HkOY5KgCAQknQFEoAjDyFDnAahZtSc0yxQr3pk+rQq+C0biXHB2tYNAUAuFTDM+jQAkWnCkX6 8qzevXz7ZrGJU+cVt1G+kplXZWphoAC1vPB7p6vJtmAVQ6341idkb5KjUJZKFTPHzXYEIJj2JS0w xSSjZo2LmKBJqPpI276NG+1CsFGA0t3XU+pVz2RTJu7J+IsjUbkL4RzgEnrl0J7bSTHb3BVT6P+G r71cfXT2N5iEpIaiVjFdlFPs8WGoMPYV5LXH27+PHw5gKUCbSi87Dx8J+WbdfIsl/8XFC5DkBwZT bfX24He8qZEZdgxmg1OEDfA03W6iXXdhGKAQcd6Gqyn004DBzbNRAcAZJ9uBeYVIY4347dcbGYRR ON9GN/kGQEtS2WUPglko+AgJNkoUGD3sgGdZVS6qpdmSkTW5TjwdQjUWlRZa2YMpl1jzF3on+mSd hidNZV1C6gXZ0JBHtQlmnXbuhaOZJp40YViIsbNnSXMNGaeRTIwg5gMMLMpoo44+Cmmkkk5KaaWW XsoAUwlw5yKUVDUUXAMLYEpqqaaeimqqmnI6gKe7gUrFqKnOSmutpSaqKJkf6ZkViiaphRhYN6lH pFCEavTPncouC1OeezoFXq8b8v9I4HHDZAEAoqYQwUy33n4Lbrjijktuueaei66miE3larSAoAtv vPLOS2+94arbDrtb9knFAPb+C3DA81qSpHll7iktawiv6We+8RV4XagzMktxxbq5++x7EK/Fpo6H bQzatVsg+QBqdmpq4k3t8iuexWGgnJPK+yZj8QxJ6uqEahGvxSvDLjpErLX9ukx00bqkNZmwI3G3 85R6yrfz0F2AYvDJgfl00Mo0G/0Fyv20o/U2FmNCYokFPQXU2Woax1BRDwttENdyz42HgDwl0NZI TQnlJVUUETgXXTzHTQ0CzCmLct4eSrg13Uzyd1hcYZfxpZUrxMLnenj9dNeK1rn/RmzgbovseOmm Y85nkL9eFZdBI7FGjz38KLQR4coxS1CWWSKEEcgtnz6QOws52WbvjS8LjRiyzONfVvvsKIWLCFHk kOz40C5xY8Bvv71gOYaThvZyg58Y90+Q/3v3yUiMfrLmv6++GVS2X9H29GcFPwT3S5W/9yHvb7v8 CVBu/lsYAA1VOgBWjm4K7N/6Dli/AUrQaAWEYAATuL8Fzq2B8KugBd03wRBWzIMfnBgG76fB8WXQ gSWshQhfCMMYynCGNKyhDW+IwxzqcIc87KEPfwjEIApxiEQsohGPiMQkKnGJTGyiE58IxShKcYpU rKIVr4jFLGpxi1zsohe/CMYw/4pxjGQsoxnPiMY0qnGNbGyjG98IxzjKcY50rKMd74jHPOpxj3zs ox//CMhACnKQhCykIQ+JyEQqcpGMtA8BToAAnOWCAJJ8RtUaiclM+hATCEDUJeEggE9u4XJt4IEm T4lKHDoiEqusAyPCQEo2mDKVtKylCGMJAQaIoluUXEQvd5CtGoSSAJMwTdmG6QxeLuFy2epl8mRQ BAL8cpa2rKY1uZcKRjQKCRAgGzcV9QNHLIoGI5KBohY1CW0tMwUAYBQ5M9FNYrpTmPC8pj3vyTVq eiKXLWCBOek5CUVNomwreOXlCspNHRRUSYzIATkZSgJ94nOiFL2TRHmgS0+E8v9wJOJmJBYaJiUw 4pXrzKUQfNBNUWjzpDGQaEVfCtMLzcBkK9UBDRyFhBwYcxP+nCUPSKrQFJxznKEkgeGGME+XxnSp TM1NQk0gClLeNJLeSgIqqApSn8YAqJTAASW71ZSSdfSr0lBqU8+K1r2QQgdGyCVzfnq4Tlp1liC1 qj+5atK89oBEKMgEM7lVz7QKdrA0mUEkZbAoFdAAAEedQQ1aeQPH2iAFrzScC+pa0hHUYK0jYI5m uxnRwBJ2tKQVCMn6yc8kOQMU31QCJhS1yhmQoJ2hKAFeD2oKJQRBobk1Z2l/C9x0dGudz9xBM46k W+PqoLhdYG4TnBvc6ErXHLj/nK51r+uy6mJ3u9wFE3S7C97wine85C2vec+L3vSqVy8qaa973wvf +L43DvKtr3zfYN/8ttdkbNCvf/+rkvwAeMD+pS+B7YvfA8uXv2JQsIPnu96IkPCD4vtCZsiXAOeg MA4TtmCFbdNhCH64CxcGX4bdwME3hPiAI46wMVYMwBZvocThOLEqVqifFrrwRjo+g4y1QGNt2JgN KXYDjPf3Yxfz4sj3S7ITgoyMIYuhyG1gMv2cjKcemwHLTICyMKT8MhyrWMtl4LKSb7GOFVXQWNET HN5EV4/AgdANmWGzZ9w8ksCFCswNas+K8swHOKdPeSeRRwXxBgxEL0TPh5Ez/wKzk+b2rPnPaYaz nufchjpTetEncbQU+Nw1P4u6HoGeyztSuIdCR+/QgisMni3taTOf+RXOmt9OevKTyKmkLvjYkaxL UKHWSaVaaOp1ZkDtha7gpEMb4oew+ZdjAyqsDG15y1XiAyd88Poevs5PrSvIuesAadfF5jb14hBs XBNbJdB7ioZ70yfQ6c3ZwUH1wdLDvui1+9r1yPZK2H3uWaPj22hIEX+IbSC0PXoJpuFCsN/SlI/9 b3GFeTd6hP0ZnmEFalXSwmFTLe18eyZI4n5bjBRuQkhTvGeUa3fEYZTwxVW44TMeDMTXPZs+IbsL nUnd/za+scp9/N5nag3Ewv/N8YmD59cCFwTBG31qi9SjOEkf3J7E5whR6qBCUp+SxK2ulp1zYTvR 8Q5rvNKnymUd5PheSAIU3Z5coy1oJ9cT02fy9DhHvUBeh3nU7K6Ftdf8Ol2nunWmHXaLb4hpFGI2 2ge9iKfuKuRuh3v05P4qk8f86k0/B8Gz3TenDOjrm0/Ocy1RSWDPR/Rt+TriE614nhRoKo5fXtAT dLOcsVwx9I57i15U9denvDmf7zWAWI/wv3P+9AsafK+Q73r6fDr28qH9z20P+eXmvgk6S1ivPfd7 upe+Pp2/WLx1RL0Kueh1tJHLUITz9k3RieEEOxyQe8T+dbfq7VJ3N4qxNDz/rrIhdIE3Z4M/XPBa uTJ5bYcXHFcS1IMSgvJ+WBN/FnF3MvF56Yd/UtF+Eshm/VCB87dc9UdiG+gTHXh4+yd/UyB2W6Ap xCOAd1OAFdIFCVg2OtB9IdOAG/OAvBM6g0KB/CeC5VcTK/cseRZ0VjE8geJvFPETTREkAlIC2UIw BSNNV4iF0qQA8yE9gLJuUBiFU6AAWUiGZXiFqxIfreJ4YHhhB2CGWFiFsOUMOcgxFNF+1QEeOfEm QuITYBgSFxgTn4eEXOgPXqhrhfKETfGHU6gt2/KGV7iFEdOF7fCFUBgSUTCGj/iIaDh1MciGVOCG mhiHKDCHu4cidggsWmIm/3uIiH4ohUSoDkbYH++RdnRxE9KTfNIiNSKQgFb4iJHYK5eBi9FnBpmo iWaILxcRg/4Tio8Yh3JVAnTIe78iD/nydg7jd7p4QSqHMbOIcsF4i/6QixMXQbyYKCigicAIGsIo jsRYBsZ4jGSYjAmxjGbQjG/4jOYhjb7yPeERD4AifsqHabDYC59HiwYSD4oxjlaHaaaxLSW4Mwmp EDhnBi34ON/zI4tzdv6zQPVHJvs4OKl4EdITkNpYjvZhkN+og+wwkaQnkAjkkEkCkQnDkoFyeCJn kVkAM9NSj5TTBR65gGeiMCKZECSpeS85fAR5ND2Th4O4M9LxNL4zbQMpA/+vlXoQoH6NF5XkSAU5 6QRekzW1JzYjEwo4AxLSdzYYgxj2wI/Blz3expRKwzBP6R0LOZULF5NXmZVQaZNcyYKxVxRheX1j 6RhlqXtgF5gqaRxsuRZuSTpKWZBDkiV/AzZTuYdRGX/xx5ALtwPatQRZ2Raf445W4JVNgDJXUYhi 6ZNb8FkH03oIcXiMUWef0yEBkpmjs4soKZnDQ5nDU2/YJpopcZu4uY0jqHWq1zQk15ebOX3/Bzlw kZqDuZqBd4PcxycCEpv6MJsXFzK2mZnMCYiQOWbDpoi98YQXdnZ6EzlgGBd3mZSM6HAJ1zoUWQal yQQo0349aQVqx2A4+A//lggSTwgysbE52Mae/Jib4yELiVggQdI88qme/Xag4LkF2RKfUTOfo1kF 9nk+z5mfqrmfXEBMWyALrBOGaFKecTck3cme7fmW4hmZhfF2kDOjIoZu+8OhwbNh0fYUNbqOVtYH 4ekRieajJlKkSHaj95OjJUBlbECkJ3KkTQajMVoGtialcOBlwbCk+iNmRvZAFAaX8gOkfsB0WUoL W9qkhLYNIoc+QjqlqFOlYxqkSUo/aNqlVfalHhamcVpCZYqjikc+9naYlMOm5OOmb1oi9dlCfqqk gAo+gmqdFSmn4bOnpLmodNo+drqj41mfk7pjiIoLnqoNjFqnjhoOkDp5/2SWoCqnqqsqBmY6C5pK P6i6BKIqDqCKq7mqq7vKq73qq78KrMEqrMNKrMVqrMeKrMmqrMvKrM3qrM8KrdEqrdNKrdVqrdeK rdmqrdvKrd3qrd8KruEqruNKruVqrueKrumqruvKru3qru8Kr/Eqr/NKr/Vqr/eKr/mqr/vKr50n MP8KsAErsANLsAULLv26q1RlsAvLsA3rsA8rL/aHsIhKTC1qsReLsRmrsRvLsR3rsR8LsiErsiNL sh57nBNLkBVbsivLsi3rsi8LszHrsieLskSosjKLszmrszvLsztLszXbeTfbs0NLtEVrtET7s0Ar cEJ7tE3rtE8LtRubtP9Ke2ZMG7VXi7VZ27NTS7UuZrVaC7ZhK7Yiy7Vdu15W+0in0RSmEUnZYjhv q7Zw27YXaxrNAIV1e7GUNLbsybZwa7cZG0p8C7dfG0x7K7VmK55Wi3pNsbhxWDI+kChfy0lgOLkW q0t0q7ZXSzaN8rcYewLsubkw0AKWm7mCa7gWirhKqbibwLiQQFtyG1a6ZDgCZbFkA4YwULodO1NY +7kg27tQ+LtGALK7u7dlm7rntbqX6wMw0AwwYLG0S1trC7rMu7aKoramobJlxQyd1BSrBIWPZLfd wr3fO74u4LadC753K021O7p8e753G0nBy1jt206ngb132wziW7HeW7z/x5uylnsJLWBYi+W8LQq9 BbxYwKtL+wtJjHVOBHwa44S7NvO48zS/4DS67jS6Q5XA3kRMslXAlEu/1etO3TtUIxy8KADCGRzB ojsmpmC4xuu/5LW6juDAmNC8iaK2uRJKtDu3TXECjwTEndVOdkuKl4tO8+sCj9u7I+DA+UsDxLtY l8C49vu4Nqy8liXCg7vEFfsD7eTFKMwtDvkCaovELQzEAvy4/TvD5be6jgVJBKzDYRW5F3sCuztV 5lvF9cvHS+zHYAyFJfO7i/W3U1yxn6vFjOUD34vCJ2zFUKhLxCu/vUiKCezEZ1y9f8zGbdx0q2sE sivHz3tO5duin8st/y1wuTtFxZjsx3i8TcYUyM0wAovbwahcuiscwmncosQbyWs8ySNMvDPFyjNF vGMrw5wMXp6sSz+Aw9FrwCNsxy0At3w8JmXMx8pLzI/7A96ixGHFDGPiA81Qy31cvd8yvbu8xr2s wOcMhsEsVhF8vSVTzGJ7zMjMXcoMCc2cy4EMzexLhUccSekMz32czYyrskQwyLDszeGsy1o8Uwls GuzczgLN0N28zuw5zsMsz2tszPa8tADswIIsx4kizv1MBCJMx1XsWNmyygPdykx80ojcvg8FxFNs t5+70qZsxrl7x+BC0ZYlWxINvPYL0AS90adbzx59XZ4sTk9MWyS9vP/P27m9m8SX+1rLbM3YrM0V nFsWPdKG0wLjHNKEbAnQ3ItlSdFI8ssATMXXHM8pvclKHWGEC7XSoMeA+7d2jdfSi7F6vbadS7KA zbF+vddxLdfqRdenq9iLjbVJfdjRldiMLdmTjbSPPdeUjdmZbbSObdm/FdmaDdqhTbadjdiibdqn XbKcTdqj9dmo7dqvrdqrPVhWC1Z/Hb63Xdt0C9iE3c6CLba8fbThy7Lm3NcrG9uynVar28Gui8BQ DcCdS72kW9xYq7wW69sya9O6zbFx+LUJvMvXDYbHjdxnpdwV27hb7U65C8ltTcfXDdyaHLXVbcDg /bKEjLHyfd+Ziwn/dOu5/cye4j3eTJW8O0y9CNy++wzJSUyF3v3e1ZDJ+Pvdvb3bE863vi3feu3d dw3hfK3hDt7bFY2/f3vhFl66EO3efyu/FgvgAZ5KvTTLI9oEq4vTlxDKUd26Cw3J+w3EzcxaLFy/ pkBJMPzUo3sClhC3prDDCXjTqrXEodCiVj1OVNzVrOXFnFTkm7C4IX3SId3Mi5WAEezkFKze8h3F QL7QNJ7PTI6xK87immRZQuxPMQ7A+70cNU67QV3Et2s45r3SpPgC8gTmzfC53ovTpFgeLL3QK50r fKxZbr3EgG3VX2zDQdDFiA65lHToh365hG7Fgp7dhBzFkczHK63n/8D7ziwtziXdvPG75Wve5qTF V5EgWiLw3DQQxzlMx2Ki3lUsxA8t6Dnu6C+N406c0IF75oeMyhVbt+2byHuc0AydyCf9xd3cu6as 7IIcz6lu7Aydysyeu9zNy6dhyA3t3+H96qyNjtyyVodS652lz1uN5Pk9U0JsySfQ0kb90nAryDOd v2Cd3Uqc4e7ewKX+7F4uu0Fc0dVO5GGt79Z85v1u76tOhW+L35Fs17/7uf8u04d77oS1UYsCjXL+ 5CVD449k5+Ve6ghNTAS8wJis1fk+zcVuvd47zhkOSW8rtFAey9x+8G0r1grvA3Lr8Axd5gsMwfPL xaWO0rqs8dKM8v/d2/GkBVaBB9Ko9+6xu92n0Uk2He7BXtCLvLZaz+9O/PC6TIou0Entu+3Ozu/Q nrl6+/MLD8hAzLY7T9MLvelqn/O5a8M7TvQ37fQcH/VoNb9XeMdO4Mmv5dQGXrvQfRpNHc67a1he f9Rzb1kJTfY0D/jd3MtGvPdenepUWM4JL/dKrMWTzsQ2nflHT+pnD+wYbbefvvm9u/bmPvhoFfL7 JPLs6bxNffU2DvtK39Ysj7tEoNFLrMZEBfq4LO6bD8JePlRPLvY7vyg5jLs4DvTd/MDmbcFFzyha /8WhK/0tKk7DH/pKvBwW/d+3j/tV41K0fdsebtfATeHy/7376+D/em23Qoz2IEAIACCM5CkgRMme 5UuIZLnStwnTKXISNmqXGtJ+L4CsFKy5WIAeCnjTTZm7JTWpqpIIkC84LB6Ty+YzOq1es9vuNzwu n9Pr9js+r9/z+/4/YCAAA4PMD4MAmRMXY6PjI2Sk5CRlpeUlZqbjFpdX4CdoqOgoaanpKWqq6ior ncmI2aLmLG2t7S1u7uTRlGfrL3Cw8DBxsfEx8qqMCQIDAoCirvQ0dbX1NVKy9jZ3t/c3eLg4hBFh IgFDNPY6e7v7te+4/Dx9vf09vjEihED614O6dwIHEizoKF6+hAoXMmzoMGG5fegCGqxo8aI1hA83 cuzo8SPIPstU/zhLNEbWJl6SVGKExDLTS5eNXr2aGdOdxpA6d/Ls6dOhiViSnFkS8KAlJaO3lBY9 ygjBg6hRn3Ehyuimrpw/t3Lt6vWrqX4inKHLibKR1aROkUZiWsut2kbNdjxgmYMLXHhg9/Lt6/cv m0IQVnwBAPCkTRpp7wqpkrcx5JUvGaOYTBnF2imXL1NRupnX3cc05iqmyhmyaGpaAbNu7fr1RsKE +R0WcxaJVAYkiBqdijkqSqbN+kEF3kXqCARUHywnLjU4g6iIdkuvUpy55syKfZMorvsJIeNGi1Ml kHt0deHTR3/fzSI69kHPnD3vrb3aatj69/Pvnww8VM4IhlgVhf+UYCBRvD3w3jPmHaGUg4PUBV4J E86FToXP9CNhcu11R5VyT1CVFgkTGvXgfSEaxQI6IxAFFYtHjVehiy4Y2KJ8EE54A2k0qrigfBxS GOE6+fl3JJJJKhkKTUJZV1qQQMLgFokn7miVUj3WBeGF85mm3QwUYvngIjtiVsWOc2F5lJYipPkM VUEaWIOVKl3nW5q6Jfhlhe0YuSSggQo66B23IdEMdi8+UEiH7OEgFZR9pkVUXSvoZsOaVRyyKG4l OaZcdChmR5dhL1TaXklrkbbpM2ZWGBUXw9XkllJ7npnaNH8SuiuvvfJnCLAyUKQYWbYeClyPPWZo VaaTwtmipS7/8skjc4dEEV2cFZLlal60HmXmqaW5pWaxraLYTLbdedjnmcZ6dh9+vso7L72vgUdT UAQ+CmVJcSpn3mjZ6ijtmSGWyCJUIjqV6Q1SzgUFbjdgWKKoU+yI4ZxZomqCqj2slaATKgw8hbIU d6Gnl7fCq1q9Lbv88lYqqHEWUzNSekKIO3K7cMp91uyUUbrNGCS7NEhJCNETn3xcxTcwC+d3D5so o5RbAo0daanulm7JRNuaKa7S6Aoz2WWb/dBthGCLiKLhjWAetqPiRtyZTywqpWHLOcEwetjWBXd0 sgSttsBSpbco0ru5Dd7dLiAen9rMITK41UzzuK62ibtLNeYs/5/9OeihgyMAsNAMW4QTLviwwgsq 3NZ6TVgYgUMKkak0+wwqQIyDDaRrhm8UKM1+7+7JyZIEEqjXXhnteEmRA2OrszO26NVbfz0oYr1S 1ulsef9I19+/Qz325Zt/vhwDgmFY9+K7f/n7BJGPPv312x+Gcrb5Y1v8/WtmqP/idb8BErCAYUCH 2ojSvgAysIG5MiAEIyjBAzqwghYU2wQzqMHPITCBswEDAC8owhFGYn4bPCEKj2SEL5TDJCwkIQxj WMIU0rCGg9oHGAAiLBDKsIc+lJgNgyhE/5SFdMrphwsHg68lMrGJTnwiFKMoxSlSsYpWvCIWs6hF KCJgiF78YhxrSLcMfiSRjFs8IxrTqMY1srGNbAQjHOOonxAAADs= --_004_7347100B5761DC41A166AC17F22DF1121B773138eusaamb103erics_-- From nobody Thu Feb 27 03:49: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 CB1391A0221 for ; Thu, 27 Feb 2014 03:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypze2SMn9FJf for ; Thu, 27 Feb 2014 03:49:17 -0800 (PST) Received: from smtp28.msg.oleane.net (smtp28.msg.oleane.net [62.161.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE731A0057 for ; Thu, 27 Feb 2014 03:49:16 -0800 (PST) Received: from MGosseDellM6800 (LMontsouris-656-01-05-162.w80-12.abo.wanadoo.fr [80.12.94.162]) (authenticated) by smtp28.msg.oleane.net (MSA) with ESMTP id s1RBnDWE032375 for ; Thu, 27 Feb 2014 12:49:13 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Thu, 27 Feb 2014 12:49:10 +0100 Message-ID: <007b01cf33b1$eddf5c20$c99e1460$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01CF33BA.4FA4FCA0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8zsZoingBBpZODRXOzXKkEjuNObw== Content-Language: fr X-Backend: vm-smtp-sophos02 X-PMX-Spam: Probability=11% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.27.113314 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/btQFnoas6KtVqImXLZ3dd5XORO0 Subject: [mpls] MPLS SDN World 2014: Segment Routing Update and Future X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 27 Feb 2014 11:49:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007C_01CF33BA.4FA4FCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MPLS SDN World will start in 3 weeks. A large session will be dedicated to the Segment Routing initiative, launched during the 2013 Edition of the Congress. Update and future evolution will be highlighted through fast reroute approaches testimonies from carriers. Alternative solutions like label advertisement or source label signaling will also be detailed. Another main focus of the program will be on Data Center Virtualization, especially overlays and WAN interconnection issues. Other sessions will cover OpenFlow aspects, performance and traffic engineering issues and mobile SDN. More info.: http://www.uppersideconferences.com/mpls2014/mpls2014program_day_1.html ------=_NextPart_000_007C_01CF33BA.4FA4FCA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MPLS SDN World will = start in 3 weeks.

 

A large session will = be dedicated to the Segment Routing initiative, launched during the 2013 = Edition of the Congress. Update and future evolution will be highlighted = through fast reroute approaches testimonies from carriers. Alternative = solutions like label advertisement or source label signaling will also = be detailed.

 

Another main focus = of the program will be on Data Center Virtualization, especially = overlays and WAN interconnection issues.

 

Other sessions will = cover OpenFlow aspects, performance and = traffic engineering issues and mobile SDN.

 

More info.: http://www.uppersideconferences.com/mpls2014/mpls= 2014program_day_1.html

 

------=_NextPart_000_007C_01CF33BA.4FA4FCA0-- From nobody Thu Feb 27 14:47: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 5DA7C1A0131 for ; Thu, 27 Feb 2014 14:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlXIEstphs7i for ; Thu, 27 Feb 2014 14:47:43 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 03CBE1A00ED for ; Thu, 27 Feb 2014 14:47:42 -0800 (PST) Received: from mail14-tx2-R.bigfish.com (10.9.14.231) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Thu, 27 Feb 2014 22:47:40 +0000 Received: from mail14-tx2 (localhost [127.0.0.1]) by mail14-tx2-R.bigfish.com (Postfix) with ESMTP id BB820340221; Thu, 27 Feb 2014 22:47:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz9371Ic85fh4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch9a9j1155h) Received-SPF: pass (mail14-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=mjork@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(164054003)(377454003)(50986001)(81342001)(93136001)(49866001)(74502001)(47976001)(81816001)(76786001)(76576001)(16236675002)(53806001)(76796001)(51856001)(77096001)(81686001)(47446002)(74706001)(47736001)(74662001)(94316002)(1941001)(94946001)(93516002)(95416001)(86362001)(19300405004)(81542001)(80976001)(54356001)(76482001)(15202345003)(59766001)(63696002)(85306002)(83072002)(87936001)(15975445006)(87266001)(80022001)(90146001)(95666003)(56816005)(56776001)(83322001)(85852003)(92566001)(19580405001)(54316002)(33646001)(31966008)(66066001)(65816001)(77982001)(74366001)(46102001)(69226001)(74876001)(4396001)(79102001)(2656002)(74316001)(19580395003)(19609705001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB625; H:BLUPR05MB230.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:3834759D.1CD09FF5.11F9BDCF.14EEDF2C.20163; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail14-tx2 (localhost.localdomain [127.0.0.1]) by mail14-tx2 (MessageSwitch) id 1393541258582880_25291; Thu, 27 Feb 2014 22:47:38 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.234]) by mail14-tx2.bigfish.com (Postfix) with ESMTP id 877F4A0109; Thu, 27 Feb 2014 22:47:38 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 27 Feb 2014 22:47:38 +0000 Received: from BLUPR05MB625.namprd05.prod.outlook.com (10.141.204.139) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 27 Feb 2014 22:47:31 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) by BLUPR05MB625.namprd05.prod.outlook.com (10.141.204.139) with Microsoft SMTP Server (TLS) id 15.0.888.9; Thu, 27 Feb 2014 22:47:30 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.99]) by BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.99]) with mapi id 15.00.0883.010; Thu, 27 Feb 2014 22:47:30 +0000 From: Markus Jork To: Ross Callon , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 Thread-Index: AQHPLCR2OTpjEBuO2kCqWeSg/5JC+ZrJwt9Q Date: Thu, 27 Feb 2014 22:47:28 +0000 Message-ID: <0767bf9555f04e82b49ee1b9f2c74cbe@BLUPR05MB230.namprd05.prod.outlook.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 013568035E Content-Type: multipart/alternative; boundary="_000_0767bf9555f04e82b49ee1b9f2c74cbeBLUPR05MB230namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_HFTD4X83-eHRhEcb1shGD-jNAQ Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 27 Feb 2014 22:47:45 -0000 --_000_0767bf9555f04e82b49ee1b9f2c74cbeBLUPR05MB230namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support (as contributor). -Markus From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Monday, February 17, 2014 4:09 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-1= 1 This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection= -11 as an MPLS working group document. Since this call will continue through th= e IETF meeting in London, I will extent the poll by one week (so that it will= be a three week poll). Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Tuesday March 11, 2014. This is of course the Tuesday af= ter the IETF. Thanks, Ross --_000_0767bf9555f04e82b49ee1b9f2c74cbeBLUPR05MB230namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support (as contributor).=

 <= /p>

-Markus=

 <= /p>

 <= /p>

From: mpls [= mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-prote= ction-11

 

This is to start a poll on adopting dra= ft-chen-mpls-p2mp-ingress-protection-11

as an MPLS working group document. Sinc= e this call will continue through the

IETF meeting in London, I will extent t= he poll by one week (so that it will be a

three week poll).

 

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

mailing list (mpls@ietf.org).

 

This poll will end Tuesday March 11, 20= 14. This is of course the Tuesday after

the IETF.

 

Thanks, Ross

 

 <= /p>

--_000_0767bf9555f04e82b49ee1b9f2c74cbeBLUPR05MB230namprd05pro_-- From nobody Thu Feb 27 18:17:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D521A0654 for ; Thu, 27 Feb 2014 18:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxLio9V6pNBB for ; Thu, 27 Feb 2014 18:17:49 -0800 (PST) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 103E91A064A for ; Thu, 27 Feb 2014 18:17:48 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,559,1389772800"; d="scan'208,217"; a="16973203" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 27 Feb 2014 18:34:09 -0800 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 27 Feb 2014 18:17:40 -0800 Received: from SJEXCHMB14.corp.ad.broadcom.com ([fe80::41d1:304:b35c:4eaa]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 18:17:40 -0800 From: Jafar Akhbarizadeh To: "bashandy@cisco.com" , "sprevidi@cisco.com" Thread-Topic: Segment routing to an external adjacency in MPLS (draft-filsfils-spring-segment-routing-mpls-00 ) Thread-Index: Ac80Kkhqn9nhI8BXSHykps2E9v7IqQ== Date: Fri, 28 Feb 2014 02:17:39 +0000 Message-ID: <989D91233FC2054788E9B31E8CC20DAEED3062@SJEXCHMB14.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: multipart/alternative; boundary="_000_989D91233FC2054788E9B31E8CC20DAEED3062SJEXCHMB14corpadb_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Qe9Sok2Bthx2KYOy9rXfJWMAZis Cc: "mpls@ietf.org" Subject: [mpls] Segment routing to an external adjacency in MPLS (draft-filsfils-spring-segment-routing-mpls-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, 28 Feb 2014 02:17:51 -0000 --_000_989D91233FC2054788E9B31E8CC20DAEED3062SJEXCHMB14corpadb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Ahmad and Stefano, Section x in SR architecture draft (draft-filsfils-rtgwg-segment-routing-01= ) talks about allocating ADJ-SID to an external link across two AS's. A use case is described for this case in section 4.1.3 of draft-filsfils-rt= gwg-segment-routing-use-cases. However, it is not clear how this 'external peering' should be implemented = in MPLS. Should the SR label representing the remote adjacency be swapped?= What about the labels underneath it? What assumptions must be made regarding MPLS support across the two AS's? I believe a section needs to be added to segment-routing-mpls draft to addr= ess external peering. Thanks, Jafar Akhbari Infrastructure and Networking / XGS Broadcom Corporation --_000_989D91233FC2054788E9B31E8CC20DAEED3062SJEXCHMB14corpadb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Ahmad and Stefano,

 

Section x in SR architecture draft (draft-filsfils-r= tgwg-segment-routing-01) talks about allocating ADJ-SID to an external link= across two AS’s.

A use case is described for this case in section 4.1= .3 of draft-filsfils-rtgwg-segment-routing-use-cases.

However, it is not clear how this ‘external pe= ering’ should be implemented in MPLS. Should the SR label representin= g  the remote adjacency be swapped? What about the labels underneath i= t?

What assumptions must be made regarding MPLS support= across the two AS’s?

I believe a section needs to be added to segment-rou= ting-mpls draft to address external peering.

 

Thanks,

Jafar Akhbari

 

Infrastructure an= d Networking / XGS

Broadcom Corporat= ion

 

--_000_989D91233FC2054788E9B31E8CC20DAEED3062SJEXCHMB14corpadb_-- From nobody Fri Feb 28 14:43: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 9D18E1A013E for ; Fri, 28 Feb 2014 14:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkDntm94D1Hm for ; Fri, 28 Feb 2014 14:43:16 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id D2AC81A0226 for ; Fri, 28 Feb 2014 14:43:15 -0800 (PST) Received: from mail71-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE035.bigfish.com (10.236.130.98) with Microsoft SMTP Server id 14.1.225.22; Fri, 28 Feb 2014 22:43:13 +0000 Received: from mail71-co9 (localhost [127.0.0.1]) by mail71-co9-R.bigfish.com (Postfix) with ESMTP id AF1184205AA; Fri, 28 Feb 2014 22:43:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz1390I62a3I9371I542Iec9I1432I4015I15c7mzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch9a9j1155h) Received-SPF: pass (mail71-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=mjork@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(37854004)(252514010)(164054003)(51704005)(377454003)(50084003)(189002)(199002)(83072002)(74706001)(74662001)(77096001)(95666003)(85852003)(74876001)(81686001)(76576001)(74316001)(74366001)(76786001)(76796001)(66066001)(90146001)(56816005)(65816001)(80022001)(85306002)(94946001)(77982001)(63696002)(69226001)(87266001)(2656002)(83322001)(19580405001)(19580395003)(76482001)(54316002)(56776001)(87936001)(46102001)(50986001)(81542001)(47736001)(47976001)(92566001)(95416001)(79102001)(33646001)(81342001)(94316002)(86362001)(51856001)(47446002)(49866001)(31966008)(74502001)(54356001)(4396001)(81816001)(53806001)(93516002)(59766001)(80976001)(93136001)(55754002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB770; H:BLUPR05MB230.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:A6BCC064.A7E890EE.A6FF6D0F.80F4B311.2043A; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail71-co9 (localhost.localdomain [127.0.0.1]) by mail71-co9 (MessageSwitch) id 13936273924996_18967; Fri, 28 Feb 2014 22:43:12 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.242]) by mail71-co9.bigfish.com (Postfix) with ESMTP id DFC346005D; Fri, 28 Feb 2014 22:43:11 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Feb 2014 22:43:11 +0000 Received: from BLUPR05MB770.namprd05.prod.outlook.com (10.141.209.25) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 28 Feb 2014 22:43:10 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) by BLUPR05MB770.namprd05.prod.outlook.com (10.141.209.25) with Microsoft SMTP Server (TLS) id 15.0.883.10; Fri, 28 Feb 2014 22:43:09 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.66]) by BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.66]) with mapi id 15.00.0883.010; Fri, 28 Feb 2014 22:43:09 +0000 From: Markus Jork To: "draft-george-mpls-ipv6-only-gap@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: draft-george-mpls-ipv6-only-gap-04.txt Thread-Index: AQHPKiTptRA/mEWmpESpRa8OC/NeGZrLVpAA Date: Fri, 28 Feb 2014 22:43:08 +0000 Message-ID: <4e6cd8a858d4400cbbb5a7e1fd543b8f@BLUPR05MB230.namprd05.prod.outlook.com> References: <52FF2006.7060900@pi.nu> In-Reply-To: <52FF2006.7060900@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0136C1DDA4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/GV9kb9HhOc0UzCd165VSIajWlWI Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 22:43:18 -0000 This is a very useful effort and should be adopted as a WG document. It is difficult to say whether the current draft has captured all the poten= tial problems but it appears quite exhaustive already. It is also clearly w= ritten and technically sound. The use case discussion in section 2 seems overly defensive and doesn't con= tribute much to the document, it might as well be removed for the sake of b= revity. Some minor technical feedback: The verdict at the end of section 3.3.2.1 is: "Gap: Major. RFC4659 needs to be updated to explicitly cover use case #2". I believe this is meant to say "RFC 4798". But I'm not sure that's fair. RF= C 4798 is very explicitly covering only the 6PE use case. That's all it is = trying to achieve, so adding "4PE" to this RFC would be overloading it. If = there are gaps with a "4PE" use case not sufficiently covered by existing s= pecs, and people are actually interested in doing this, then this should pr= obably be addressed by a new RFC dedicated that use case? In section 3, the reference for RSVP-TE should be RFC 3209 and not RFC 5420= . I also noticed two very minor typos: 3.3.2: "RFC4364 defines as VPN-IPv4 address type" 3.3.2.3: "tunnelling over an single-Address" -Markus > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Saturday, February 15, 2014 3:07 AM > To: David Allan I; Mach Chen; Markus Jork; draft-george-mpls-ipv6-only- > gap@tools.ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN > (MARTIN); Aissaoui, Mustapha (Mustapha) > Subject: draft-george-mpls-ipv6-only-gap-04.txt >=20 > Dave, Mach, Markus and Mustapha, >=20 > You have been selected as MPLS Review team reviewers for > draft-george-mpls-ipv6-only-gap-04. >=20 > Note to authors: You have been CC'd on this email so that you can know > that this review is going on. However, please do not review your own > document. >=20 > Note 2: All the IPv& expertise we have in the MPLS review team are > listed as contributors on this draft. I've therefore asked Mustapha > to review. >=20 > Reviews should comment on whether the document is coherent, is it > useful (ie, is it likely to be actually useful in operational > networks), and is the document technically sound? We are interested > in knowing whether the document is ready to be considered for WG > adoption (ie, it doesn't have to be perfect at this point, but should be > a good start). >=20 > 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. >=20 > Are you able to review this draft by March 1, 2014? >=20 >=20 > Thanks, Loa > (as MPLS WG chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20