From loa@pi.nu Sat Jun 1 01:46:25 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3877C21F881C for ; Sat, 1 Jun 2013 01:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ1PwwMpoMNm for ; Sat, 1 Jun 2013 01:46:13 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id C8D9A21F88A9 for ; Sat, 1 Jun 2013 01:46:12 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E0A501800272; Sat, 1 Jun 2013 10:46:10 +0200 (CEST) Message-ID: <51A9B4D5.1060509@pi.nu> Date: Sat, 01 Jun 2013 10:46:13 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" References: <51951C17.8010906@pi.nu> In-Reply-To: <51951C17.8010906@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Concluded: poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 08:46:25 -0000 Working Group, this poll has been closed and we have a new working group document. Can the authors please re-post the draft as: draft-ietf-mpls-rsvp-te-hsmp-lsp-01 Without any other changes than date and version number. /Loa for the mpls wg co-chairs On 2013-05-16 19:49, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-jjb-mpls-rsvp-te-hsmp-lsp-04 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. > > This poll ends May 31, 2013. > > There are one IPR claim against this document, see IPR claim #1840. > > 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. > > /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 marc@sniff.de Sat Jun 1 13:35:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A88C21F9D69; Sat, 1 Jun 2013 13:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJSUnIb61GXI; Sat, 1 Jun 2013 13:35:09 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8121F9D8A; Sat, 1 Jun 2013 13:35:08 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 48BE22AA0F; Sat, 1 Jun 2013 20:35:05 +0000 (GMT) Date: Sat, 1 Jun 2013 22:34:55 +0200 From: Marc Binderberger To: Jeffrey Haas , Sam Aldrin , Santiago Alvarez (saalvare) , Binny Jeshan Message-ID: <20130601223455119054.8703c711@sniff.de> In-Reply-To: <20130510172441.GB12732@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 20:35:09 -0000 Hello everyone, my apologies for the late reply. Too many things at once :-) It looks like we agree towards an "informal" document. This may be partially due to a misunderstanding, a "standard" document would define a minimum set of to-be-supported intervals, it would not forbid to support additional timer interval values, in my view. Anyway, the goal to improve interoperability can be reached with "informal" too, so I'm fine. For the split-off of appendix B: I can write a new draft, no problem. The question is to the BFD list though: do you think we should dive deeper into the timer negotiation area? If everyone thinks the appendix B is "obvious" or "trivial" then there is no point for a new document. If implementors think we better do write down these details and discuss them - then we have a basis for a new draft :-) To quickly explain the problem again: RFC5880 and the Poll sequence described therein implicitly assume that the peer can accept any timer value. Thus the Poll sequence is a simple P-bit, F-bit sequence. With hardware-based implementations we may see a more granular timer support and the peer can _not_ accept the new interval proposed. More negotiations would be required to find a commonly supported timer value (which exists when following the draft's minimum set of values). Appendix B describes the procedure we propose. Regards, Marc On Fri, 10 May 2013 13:24:41 -0400, Jeffrey Haas wrote: > On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: >> I echo what Santiago had said in his email. Good to have an >> informational document and do not support the idea of standardizing >> the intervals. > > Speaking as chair, while I'm not in favor of have a standardized set of > intervals (the fights such a document would create would be epic), I am > highly supportive of such a document having informational status. > > As a suggestion, there may be two actual documents in such a case: > - An informational document covering the intervals. > - A short document, potentially on the standards track, covering the > procedure by which timers can negotiate to such an interval. This may be > worth standardizing. (This is covered by Appendix B.) > > -- Jeff From nobo@cisco.com Sat Jun 1 19:27:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A457111E80A2; Sat, 1 Jun 2013 19:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3pgLw3WhRkd; Sat, 1 Jun 2013 19:27:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A468411E80EF; Sat, 1 Jun 2013 19:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3581; q=dns/txt; s=iport; t=1370140034; x=1371349634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cN6KhN/xqsWvX1FY3eNkN8pixJJLwqmKMF3XBxLtDok=; b=UNUi1+nS1FxU4DaOI9KqEYChSQDsarYCopOAP2wO306C4HlGCezddvCS ngL5QLtvJbjO77mjnbPm/r9lb0F9Z010kAVIsPJB+Q6VX9K4Q+3B5eeIx ItV3roR3P8zA4HtTKsNI293IemeLR/62NVUlDYRj9f8UtT1SF+M/82gXF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADisqlGtJV2d/2dsb2JhbABZgmghML8DfxZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCIgFAQu5JwSNWguBETEHBoJxYQOofoMPgXE2 X-IronPort-AV: E=Sophos;i="4.87,786,1363132800"; d="scan'208";a="217474187" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jun 2013 02:27:14 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r522RD3P029063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Jun 2013 02:27:13 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 1 Jun 2013 21:27:13 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Jeffrey Haas , "Sam Aldrin" , "Santiago Alvarez (saalvare)" , Binny Jeshan Thread-Topic: [mpls] Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAy8rAAAAN+FAAAAiuEAAAAzaYAfAr3RgARZDheAAAEjodA= Date: Sun, 2 Jun 2013 02:27:13 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> <20130601223455119054.8703c711@sniff.de> In-Reply-To: <20130601223455119054.8703c711@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 02:27:19 -0000 Hello Marc, et al, Before going into "timer negotiation deep dive", it'll be beneficial to def= ine the contents of the informational draft. In addition to set of interval= s specified, the document can also describe usefulness in implementation su= pporting multiples of specified intervals. Such implementations will be abl= e to support large set of intervals, and even larger set when jitter consid= ered. I think the result will be very useful to anybody implementing/operat= ing HW BFD. Once we converge on that, then perhaps we can take up the discu= ssion of whether we need additional standard track draft or not, and with w= hat contents. Regards, Nobo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Marc Binderberger > Sent: Saturday, June 01, 2013 4:35 PM > To: Jeffrey Haas; Sam Aldrin; Santiago Alvarez (saalvare); Binny Jeshan > Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org > Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 >=20 > Hello everyone, >=20 > my apologies for the late reply. Too many things at once :-) >=20 >=20 > It looks like we agree towards an "informal" document. This may be partia= lly > due to a misunderstanding, a "standard" document would define a > minimum set of to-be-supported intervals, it would not forbid to support > additional timer interval values, in my view. Anyway, the goal to improve > interoperability can be reached with "informal" too, so I'm fine. >=20 >=20 > For the split-off of appendix B: I can write a new draft, no problem. > The question is to the BFD list though: do you think we should dive deepe= r > into the timer negotiation area? If everyone thinks the appendix B is > "obvious" or "trivial" then there is no point for a new document. If > implementors think we better do write down these details and discuss > them - then we have a basis for a new draft :-) >=20 > To quickly explain the problem again: RFC5880 and the Poll sequence > described therein implicitly assume that the peer can accept any timer > value. Thus the Poll sequence is a simple P-bit, F-bit sequence. With > hardware-based implementations we may see a more granular timer > support and the peer can _not_ accept the new interval proposed. More > negotiations would be required to find a commonly supported timer value > (which exists when following the draft's minimum set of values). > Appendix B describes the procedure we propose. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Fri, 10 May 2013 13:24:41 -0400, Jeffrey Haas wrote: > > On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: > >> I echo what Santiago had said in his email. Good to have an > >> informational document and do not support the idea of standardizing > >> the intervals. > > > > Speaking as chair, while I'm not in favor of have a standardized set > > of intervals (the fights such a document would create would be epic), > > I am highly supportive of such a document having informational status. > > > > As a suggestion, there may be two actual documents in such a case: > > - An informational document covering the intervals. > > - A short document, potentially on the standards track, covering the > > procedure by which timers can negotiate to such an interval. This ma= y be > > worth standardizing. (This is covered by Appendix B.) > > > > -- Jeff > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jhaas@slice.pfrc.org Sun Jun 2 05:48:17 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1BF21F90FD; Sun, 2 Jun 2013 05:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6tqN3IObXCT; Sun, 2 Jun 2013 05:48:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0B84D21F8E8F; Sun, 2 Jun 2013 05:48:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7C8C4C21A; Sun, 2 Jun 2013 08:48:08 -0400 (EDT) Date: Sun, 2 Jun 2013 08:48:08 -0400 From: Jeffrey Haas To: Marc Binderberger Message-ID: <20130602124808.GK10807@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> <20130601223455119054.8703c711@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130601223455119054.8703c711@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mpls@ietf.org" , Santiago Alvarez , "pwe3@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:48:18 -0000 On Sat, Jun 01, 2013 at 10:34:55PM +0200, Marc Binderberger wrote: > It looks like we agree towards an "informal" document. This may be > partially due to a misunderstanding, a "standard" document would define > a minimum set of to-be-supported intervals, it would not forbid to > support additional timer interval values, in my view. Anyway, the goal > to improve interoperability can be reached with "informal" too, so I'm > fine. An informational draft on the specific timer values may be of benefit. One thing to ponder that has standards impact would be whether we'd want to request an IANA registry to record such "well known values". > For the split-off of appendix B: I can write a new draft, no problem. > The question is to the BFD list though: do you think we should dive > deeper into the timer negotiation area? If everyone thinks the > appendix B is "obvious" or "trivial" then there is no point for a new > document. If implementors think we better do write down these details > and discuss them - then we have a basis for a new draft :-) I think, given such a document specifying the well known values, that having a known mechanism supporting converging on those values may be helpful. My biggest concern for such a proposal is that it would encourage implementations to *only* support those values rather than providing targets for scaling certain specific timers. Consider, for example, a scenario where a device going into a temporary maintenance mode may want to significantly reduce its detection interval (say > 3s) for a short period of time. If the remote device didn't have that 3s+ value as one of its "magic numbers", then it may simply drop the session depending on procedure. These, of course, are just details to consider for the draft. -- Jeff From daniel@olddog.co.uk Mon Jun 3 03:13:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412FD21F949D for ; Mon, 3 Jun 2013 03:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdczx0rTPNPx for ; Mon, 3 Jun 2013 03:12:58 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A114121F8930 for ; Mon, 3 Jun 2013 03:12:56 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53ACiS0005266; Mon, 3 Jun 2013 11:12:46 +0100 Received: from Mal (h219-110-44-069.catv02.itscom.jp [219.110.44.69]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53ACccN005147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Jun 2013 11:12:41 +0100 From: "Daniel King" To: "'Loa Andersson'" , "'Mach Chen'" , , "'Curtis Villamizar'" References: <51975D16.9010709@pi.nu> In-Reply-To: <51975D16.9010709@pi.nu> Date: Mon, 3 Jun 2013 19:12:41 +0900 Message-ID: <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-language: en-gb Thread-index: AQJ0tZYK5UINXa0UjkIm4qRPc/mLsZfXGTyA Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-osborne-mpls-extended-admin-groups@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 10:13:03 -0000 Hi All, As a member of the MPLS-RT, I was asked to the review the following document: Extended Administrative Groups in MPLS-TE http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-01 The I-D looks to add a sub-TLV (IGP-TE) to provide for additional administrative groups (AGs). The requirement is derived from the current limit of 32 AGs. To extend beyond the 32 AG limit (Extended AGs - EAGs), the I-D proposes an OSPF/ISIS (TE) sub-TLV and an RSVP C-Type (Class 207). Overall the draft is well-written and the solution proposal has been documented. I think the document should be considered for WG adoption. A few areas that will require further discussion include: backwards compatibility, advertising default values, and a few NITS. 1. Backwards Compatibility Within the network of nodes that support EAG and those that do not. Given that AGs may already be widely used within the network. The author proposes that if a node is advertising both the AG and EAG, then the first 32 bits of the EAG must be identical to the advertised AG. Thus allowing the continued use of AGs, even if nodes in the network are incapable of supporting EAGs. This seems logical, but should be discussed and approved by users (operators). 2. Advertising Default Values The I-D proposes that specified but not unadvertised EAG have a default value of 0. This may differ from other vendor implementations of how they treat unadvertised AGs. Further discussion would be required with vendors who implemented AGs, and might be interested in implementing EAGs. Various NITs/suggestions: 3. There are a number of TBD ("To Be Discussed") and Editor Notes that need to be either discussed, but in some cases just updated or removed. 4. Use of Requirements Language should be checked, specifically uses of "must", "shouldn't". 5. Documenting Procedures and Error Handling. Although the I-D documents what seems to be the necessary procedures in various scenarios, it may be helpful (readability) to specifically highlight them in a procedures section or sub-section. 6. Maybe a paragraph or short sub-section providing motivation and context would be helpful to the reader (i.e., why are 32 colors not sufficient for today's networks?). Br, Dan. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: 18 May 2013 19:51 To: Daniel King; Mach Chen; n.leymann@telekom.de; Curtis Villamizar Cc: mpls-chairs@tools.ietf.org; draft-osborne-mpls-extended-admin-groups@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 Dan, Mach, Nic and Curtis, You have been selected as MPLS Review team reviewers for draft-osborne-mpls-extended-admin-groups-01. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. Are you able to review this draft by June 3, 2013? Thanks, Loa (as MPLS WG chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From daniel@olddog.co.uk Mon Jun 3 04:28:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C62C21F957B for ; Mon, 3 Jun 2013 04:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5W7zsFvwbkh for ; Mon, 3 Jun 2013 04:28:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA0A21F9424 for ; Mon, 3 Jun 2013 04:28:03 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53BRwB8025498; Mon, 3 Jun 2013 12:27:58 +0100 Received: from Mal (h219-110-44-069.catv02.itscom.jp [219.110.44.69]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53BRqC1025374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Jun 2013 12:27:55 +0100 From: "Daniel King" To: "'Loa Andersson'" , "'Mach Chen'" , , "'Curtis Villamizar'" References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> In-Reply-To: <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> Date: Mon, 3 Jun 2013 20:27:56 +0900 Message-ID: <00cc01ce604d$6870bc10$39523430$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-language: en-gb Thread-index: AQJ0tZYK5UINXa0UjkIm4qRPc/mLsQMvgbAUl72xrcA= Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-osborne-mpls-extended-admin-groups@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 11:28:09 -0000 Update! After having a Skype chat, we think the answer to the RBNF question is: ::= [ ] [ ] [ [ ] Br, Dan. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel King Sent: 03 June 2013 19:13 To: 'Loa Andersson'; 'Mach Chen'; n.leymann@telekom.de; 'Curtis Villamizar' Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-osborne-mpls-extended-admin-groups@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 Hi All, As a member of the MPLS-RT, I was asked to the review the following document: Extended Administrative Groups in MPLS-TE http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-01 The I-D looks to add a sub-TLV (IGP-TE) to provide for additional administrative groups (AGs). The requirement is derived from the current limit of 32 AGs. To extend beyond the 32 AG limit (Extended AGs - EAGs), the I-D proposes an OSPF/ISIS (TE) sub-TLV and an RSVP C-Type (Class 207). Overall the draft is well-written and the solution proposal has been documented. I think the document should be considered for WG adoption. A few areas that will require further discussion include: backwards compatibility, advertising default values, and a few NITS. 1. Backwards Compatibility Within the network of nodes that support EAG and those that do not. Given that AGs may already be widely used within the network. The author proposes that if a node is advertising both the AG and EAG, then the first 32 bits of the EAG must be identical to the advertised AG. Thus allowing the continued use of AGs, even if nodes in the network are incapable of supporting EAGs. This seems logical, but should be discussed and approved by users (operators). 2. Advertising Default Values The I-D proposes that specified but not unadvertised EAG have a default value of 0. This may differ from other vendor implementations of how they treat unadvertised AGs. Further discussion would be required with vendors who implemented AGs, and might be interested in implementing EAGs. Various NITs/suggestions: 3. There are a number of TBD ("To Be Discussed") and Editor Notes that need to be either discussed, but in some cases just updated or removed. 4. Use of Requirements Language should be checked, specifically uses of "must", "shouldn't". 5. Documenting Procedures and Error Handling. Although the I-D documents what seems to be the necessary procedures in various scenarios, it may be helpful (readability) to specifically highlight them in a procedures section or sub-section. 6. Maybe a paragraph or short sub-section providing motivation and context would be helpful to the reader (i.e., why are 32 colors not sufficient for today's networks?). Br, Dan. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: 18 May 2013 19:51 To: Daniel King; Mach Chen; n.leymann@telekom.de; Curtis Villamizar Cc: mpls-chairs@tools.ietf.org; draft-osborne-mpls-extended-admin-groups@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 Dan, Mach, Nic and Curtis, You have been selected as MPLS Review team reviewers for draft-osborne-mpls-extended-admin-groups-01. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. Are you able to review this draft by June 3, 2013? Thanks, Loa (as MPLS WG 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 From eosborne@cisco.com Mon Jun 3 06:05:11 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D2621F8DBC for ; Mon, 3 Jun 2013 06:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+BYfrfrnfmC for ; Mon, 3 Jun 2013 06:05:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9059721F9711 for ; Mon, 3 Jun 2013 06:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7531; q=dns/txt; s=iport; t=1370264703; x=1371474303; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zfN0cBNb9LhyOfA1u2PARtWKdQe+owJnkGE3jEvJfmg=; b=hH56bPtP8OFmAxT7rjMCHWZydElP4vjkvYyqMyADwA7mNA9Dxc6P7ZuN KOE3YksqjxwzVBW82PShgm8kOjraks5qRA99l8BLoUlVpQFEMldbRmUmn WXpqEOmNaNgupRFhiS2y0X1qVM/geepPltg2byBCND3BOq1S6X2C8PJdt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAJSTrFGtJV2Z/2dsb2JhbABZgwkwvwOBABZ0giMBAQEDAQEBATcxAwsFBwICAgEIEQQBAQsUCQcbDAsUCQgCBAENBQgTh2wGDLssBI1hC4EGBisHAgSCcWEDmGeQF4MPgWkIFx8 X-IronPort-AV: E=Sophos;i="4.87,792,1363132800"; d="scan'208";a="217853675" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jun 2013 13:05:03 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r53D52pJ010380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 13:05:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 08:05:01 -0500 From: "Eric Osborne (eosborne)" To: Daniel King , "'Loa Andersson'" , "'Mach Chen'" , "n.leymann@telekom.de" , "'Curtis Villamizar'" Thread-Topic: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 Thread-Index: AQHOYELzDIdet2w4V0mhdUM/sQIe7Jkj8A7A Date: Mon, 3 Jun 2013 13:05:01 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210255313@xmb-rcd-x09.cisco.com> References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> In-Reply-To: <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-osborne-mpls-extended-admin-groups@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 13:05:11 -0000 Hi Daniel- Thanks for your comments. My replies are inline. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Daniel King > Sent: Monday, June 03, 2013 6:13 AM > To: 'Loa Andersson'; 'Mach Chen'; n.leymann@telekom.de; 'Curtis > Villamizar' > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-osborne-mpls- > extended-admin-groups@tools.ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin- > groups-01 >=20 > Hi All, >=20 > As a member of the MPLS-RT, I was asked to the review the following > document: >=20 > Extended Administrative Groups in MPLS-TE > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-01 >=20 > The I-D looks to add a sub-TLV (IGP-TE) to provide for additional > administrative groups (AGs). The requirement is derived from the current > limit of 32 AGs. To extend beyond the 32 AG limit (Extended AGs - EAGs), > the > I-D proposes an OSPF/ISIS (TE) sub-TLV and an RSVP C-Type (Class 207). >=20 > Overall the draft is well-written and the solution proposal has been > documented. I think the document should be considered for WG adoption. >=20 > A few areas that will require further discussion include: backwards > compatibility, advertising default values, and a few NITS. >=20 > 1. Backwards Compatibility > Within the network of nodes that support EAG and those that do not. > Given > that AGs may already be widely used within the network. The author > proposes > that if a node is advertising both the AG and EAG, then the first 32 > bits of > the EAG must be identical to the advertised AG. Thus allowing the > continued > use of AGs, even if nodes in the network are incapable of supporting > EAGs. > This seems logical, but should be discussed and approved by users > (operators). >=20 EO# I agree that discussion is necesary and I welcome it.=20 For what it's worth, my first aproach to this (the -00 draft) did it the ot= her way around, starting the EAG numbering at bit 32. This is the only oth= er approach I can see, and it's much uglier. > 2. Advertising Default Values > The I-D proposes that specified but not unadvertised EAG have a default > value of 0. This may differ from other vendor implementations of how > they > treat unadvertised AGs. Further discussion would be required with > vendors > who implemented AGs, and might be interested in implementing EAGs. EO# Agreed. This isn't a new problem, though; the base TE specs have the = same issue. The current admin group sub-TLV is optional and there's no tex= t that describes what to do if it's not there. Is it possible to address t= his question only for EAG and not AG? I am nervous about providing new rul= es for AG since that may introduce big backward compatability questions. >=20 > Various NITs/suggestions: >=20 > 3. There are a number of TBD ("To Be Discussed") and Editor Notes that > need > to be either discussed, but in some cases just updated or removed. >=20 EO# Agreed. If I need to resolve them before making this a WG document pl= ease let me know. I am under the impression that working notes like this a= re OK in a WG document as long as they're all resolved prior to publication= as an RFC. > 4. Use of Requirements Language should be checked, specifically uses of > "must", "shouldn't". >=20 EO# ACK. I was probably sloppy here and will give it a good scrubbing at = next edit. > 5. Documenting Procedures and Error Handling. Although the I-D documents > what seems to be the necessary procedures in various scenarios, it may > be > helpful (readability) to specifically highlight them in a procedures > section > or sub-section. >=20 EO# ACK. > 6. Maybe a paragraph or short sub-section providing motivation and > context > would be helpful to the reader (i.e., why are 32 colors not sufficient > for > today's networks?). EO# ACK. The short answer is that some operators use link colors with glo= bal significance (e.g. "This is a link in the northeastern US part of my ne= twork") and use this information in their path calculation. Providing this= sort of geotagging information with the existing AGs limits you to 32 regi= ons worldwide. I'll add something to this effect at the next update. On the RBNF question from your other email: --- After having a Skype chat, we think the answer to the RBNF question is: ::=3D [ ] [ ] [ =20 [ ] --- I don't understand this. rfc3209 uses but really means "either or , as you want". It does not define SESSION_ATT= RIBUTE_RA. What I'm trying to do in section 3 of my draft is say "you can mix either o= r both of the _RA types but cannot mix the non-RA SESSION_ATTRIBUTE with th= e new EXTENDED_SESSION_ATTRIBUTE_RA". In other words: <---- OK <-------- OK <---- OK <---- NOT OK and I'd like to do this without having to go through rfc3209 and change all= the SESSION_ATTRIBUTE references to say "SESSION_ATTRIBUTE and/or SESSION_= ATTRIBUTE_RA" or add "Path_RA Message" rules and all the right wrapper text= around it. Is your comment saying that I can add an additional definition for Path to = rfc3209 and say "pick one of these two"? eric >=20 > Br, Dan. >=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 18 May 2013 19:51 > To: Daniel King; Mach Chen; n.leymann@telekom.de; Curtis Villamizar > Cc: mpls-chairs@tools.ietf.org; > draft-osborne-mpls-extended-admin-groups@tools.ietf.org; VIGOUREUX, > MARTIN > (MARTIN) > Subject: MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 >=20 > Dan, Mach, Nic and Curtis, >=20 > You have been selected as MPLS Review team reviewers for > draft-osborne-mpls-extended-admin-groups-01. >=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? 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 June 3, 2013? >=20 > Thanks, Loa > (as MPLS WG 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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Mon Jun 3 06:41:18 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D221F9943 for ; Mon, 3 Jun 2013 06:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyHhKUN7ZP-9 for ; Mon, 3 Jun 2013 06:41:14 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2321F9811 for ; Mon, 3 Jun 2013 06:41:13 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 631CD180101A; Mon, 3 Jun 2013 15:41:12 +0200 (CEST) Message-ID: <51AC9CFA.4050801@pi.nu> Date: Mon, 03 Jun 2013 15:41:14 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> <20ECF67871905846A80F77F8F4A2757210255313@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210255313@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "draft-osborne-mpls-extended-admin-groups@tools.ietf.org" , 'Curtis Villamizar' , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 13:41:18 -0000 Eric and Dan, what needs to be resolved - in terms of working notes - is a bit balancing act. True that some notes are OK, but not to much. I also depends a bit on the impact the resolution of the notes will have on the document. Assuming that we allow some of these notes through when it becomes a working group document it has t be resolved before we start the working last call. Since one of the effects of making a document a working group document is that the working group takes over the revision control it might be that an important "TBD" is a reason to make it a working group document. /Loa On 2013-06-03 15:05, Eric Osborne (eosborne) wrote: > Hi Daniel- > > Thanks for your comments. My replies are inline. > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Daniel King >> Sent: Monday, June 03, 2013 6:13 AM >> To: 'Loa Andersson'; 'Mach Chen'; n.leymann@telekom.de; 'Curtis >> Villamizar' >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-osborne-mpls- >> extended-admin-groups@tools.ietf.org >> Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin- >> groups-01 >> >> Hi All, >> >> As a member of the MPLS-RT, I was asked to the review the following >> document: >> >> Extended Administrative Groups in MPLS-TE >> http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-01 >> >> The I-D looks to add a sub-TLV (IGP-TE) to provide for additional >> administrative groups (AGs). The requirement is derived from the current >> limit of 32 AGs. To extend beyond the 32 AG limit (Extended AGs - EAGs), >> the >> I-D proposes an OSPF/ISIS (TE) sub-TLV and an RSVP C-Type (Class 207). >> >> Overall the draft is well-written and the solution proposal has been >> documented. I think the document should be considered for WG adoption. >> >> A few areas that will require further discussion include: backwards >> compatibility, advertising default values, and a few NITS. >> >> 1. Backwards Compatibility >> Within the network of nodes that support EAG and those that do not. >> Given >> that AGs may already be widely used within the network. The author >> proposes >> that if a node is advertising both the AG and EAG, then the first 32 >> bits of >> the EAG must be identical to the advertised AG. Thus allowing the >> continued >> use of AGs, even if nodes in the network are incapable of supporting >> EAGs. >> This seems logical, but should be discussed and approved by users >> (operators). >> > > > EO# I agree that discussion is necesary and I welcome it. > For what it's worth, my first aproach to this (the -00 draft) did it the other way around, starting the EAG numbering at bit 32. This is the only other approach I can see, and it's much uglier. > >> 2. Advertising Default Values >> The I-D proposes that specified but not unadvertised EAG have a default >> value of 0. This may differ from other vendor implementations of how >> they >> treat unadvertised AGs. Further discussion would be required with >> vendors >> who implemented AGs, and might be interested in implementing EAGs. > > EO# Agreed. This isn't a new problem, though; the base TE specs have the same issue. The current admin group sub-TLV is optional and there's no text that describes what to do if it's not there. Is it possible to address this question only for EAG and not AG? I am nervous about providing new rules for AG since that may introduce big backward compatability questions. > > >> >> Various NITs/suggestions: >> >> 3. There are a number of TBD ("To Be Discussed") and Editor Notes that >> need >> to be either discussed, but in some cases just updated or removed. >> > > EO# Agreed. If I need to resolve them before making this a WG document please let me know. I am under the impression that working notes like this are OK in a WG document as long as they're all resolved prior to publication as an RFC. > >> 4. Use of Requirements Language should be checked, specifically uses of >> "must", "shouldn't". >> > > EO# ACK. I was probably sloppy here and will give it a good scrubbing at next edit. > >> 5. Documenting Procedures and Error Handling. Although the I-D documents >> what seems to be the necessary procedures in various scenarios, it may >> be >> helpful (readability) to specifically highlight them in a procedures >> section >> or sub-section. >> > > EO# ACK. > >> 6. Maybe a paragraph or short sub-section providing motivation and >> context >> would be helpful to the reader (i.e., why are 32 colors not sufficient >> for >> today's networks?). > > EO# ACK. The short answer is that some operators use link colors with global significance (e.g. "This is a link in the northeastern US part of my network") and use this information in their path calculation. Providing this sort of geotagging information with the existing AGs limits you to 32 regions worldwide. I'll add something to this effect at the next update. > > On the RBNF question from your other email: > > --- > After having a Skype chat, we think the answer to the RBNF question is: > > ::= [ ] > > > [ ] > > [ > [ ] > --- > > I don't understand this. > rfc3209 uses but really means "either or , as you want". It does not define SESSION_ATTRIBUTE_RA. > > > What I'm trying to do in section 3 of my draft is say "you can mix either or both of the _RA types but cannot mix the non-RA SESSION_ATTRIBUTE with the new EXTENDED_SESSION_ATTRIBUTE_RA". In other words: > > <---- OK > > <-------- OK > > > <---- OK > > > > <---- NOT OK > > > > and I'd like to do this without having to go through rfc3209 and change all the SESSION_ATTRIBUTE references to say "SESSION_ATTRIBUTE and/or SESSION_ATTRIBUTE_RA" or add "Path_RA Message" rules and all the right wrapper text around it. > > > Is your comment saying that I can add an additional definition for Path to rfc3209 and say "pick one of these two"? > > > > > > eric > > >> >> Br, Dan. >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: 18 May 2013 19:51 >> To: Daniel King; Mach Chen; n.leymann@telekom.de; Curtis Villamizar >> Cc: mpls-chairs@tools.ietf.org; >> draft-osborne-mpls-extended-admin-groups@tools.ietf.org; VIGOUREUX, >> MARTIN >> (MARTIN) >> Subject: MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 >> >> Dan, Mach, Nic and Curtis, >> >> You have been selected as MPLS Review team reviewers for >> draft-osborne-mpls-extended-admin-groups-01. >> >> Note to authors: You have been CC'd on this email so that you can know >> that >> this review is going on. However, please do not review your own >> document. >> >> Reviews should comment on whether the document is coherent, is it useful >> (ie, is it likely to be actually useful in operational networks), and is >> the >> document technically sound? We are interested in knowing whether the >> document is ready to be considered for WG adoption (ie, it doesn't have >> to >> be perfect at this point, but should be a good start). >> >> Reviews should be sent to the document authors, WG co-chairs and WG >> secretary, and CC'd to the MPLS WG email list. If necessary, comments >> may be >> sent privately to only the WG chairs. >> >> Are you able to review this draft by June 3, 2013? >> >> Thanks, Loa >> (as MPLS WG 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 -- 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 Mon Jun 3 07:26:15 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F00721F99BE for ; Mon, 3 Jun 2013 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfMbzCTP+zAj for ; Mon, 3 Jun 2013 07:26:11 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id CCE0211E80E4 for ; Mon, 3 Jun 2013 07:26:05 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53EPvDb021783; Mon, 3 Jun 2013 15:25:57 +0100 Received: from 950129200 ([220.109.211.58]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53EPnuP021691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Jun 2013 15:25:52 +0100 From: "Adrian Farrel" To: "'Daniel King'" , "'Loa Andersson'" , "'Mach Chen'" , , "'Curtis Villamizar'" References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> <00cc01ce604d$6870bc10$39523430$@olddog.co.uk> In-Reply-To: <00cc01ce604d$6870bc10$39523430$@olddog.co.uk> Date: Mon, 3 Jun 2013 15:25:44 +0100 Message-ID: <044f01ce6066$406c67a0$c14536e0$@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: AQJ0tZYK5UINXa0UjkIm4qRPc/mLsQMvgbAUAZNvt0GXsUdrEA== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-osborne-mpls-extended-admin-groups@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 03 Jun 2013 14:26:15 -0000 I think Dan is missing a final closing square brace. That is... [ [ ] ] ...so that the whole is optional and the EX_RA is only present if _RA is present. That could be represented as: [ ] where ::= [ ] That is certainly one way of interpreting Eric's text. OTOH, maybe Eric intends that any of: - neither - just _RA - just EX_RA - both ...is allowed. If this is the case, then you simply need [ ] [ ] By the way, this thread caused me to open the I-D and I can't find motivation for the protocol extensions in the I-D. At this stage in a document's life I don't generally mind if the technical details are not all present or even if they are wrong, but I don't like creating protocol extensions without a clear motivation. And, yes, I *do* understand that the intention is to create more attribute colors, but why? Ciao, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Daniel King > Sent: 03 June 2013 12:28 > To: 'Loa Andersson'; 'Mach Chen'; n.leymann@telekom.de; 'Curtis Villamizar' > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-osborne-mpls-extended- > admin-groups@tools.ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin- > groups-01 > > Update! > > After having a Skype chat, we think the answer to the RBNF question is: > > ::= [ ] > > > [ ] > > [ > [ ] > > Br, Dan. > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Daniel King > Sent: 03 June 2013 19:13 > To: 'Loa Andersson'; 'Mach Chen'; n.leymann@telekom.de; 'Curtis Villamizar' > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-osborne-mpls-extended-admin-groups@tools.ietf.org > Subject: Re: [mpls] MPLS-RT review of > draft-osborne-mpls-extended-admin-groups-01 > > Hi All, > > As a member of the MPLS-RT, I was asked to the review the following > document: > > Extended Administrative Groups in MPLS-TE > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-01 > > The I-D looks to add a sub-TLV (IGP-TE) to provide for additional > administrative groups (AGs). The requirement is derived from the current > limit of 32 AGs. To extend beyond the 32 AG limit (Extended AGs - EAGs), the > I-D proposes an OSPF/ISIS (TE) sub-TLV and an RSVP C-Type (Class 207). > > Overall the draft is well-written and the solution proposal has been > documented. I think the document should be considered for WG adoption. > > A few areas that will require further discussion include: backwards > compatibility, advertising default values, and a few NITS. > > 1. Backwards Compatibility > Within the network of nodes that support EAG and those that do not. Given > that AGs may already be widely used within the network. The author proposes > that if a node is advertising both the AG and EAG, then the first 32 bits of > the EAG must be identical to the advertised AG. Thus allowing the continued > use of AGs, even if nodes in the network are incapable of supporting EAGs. > This seems logical, but should be discussed and approved by users > (operators). > > 2. Advertising Default Values > The I-D proposes that specified but not unadvertised EAG have a default > value of 0. This may differ from other vendor implementations of how they > treat unadvertised AGs. Further discussion would be required with vendors > who implemented AGs, and might be interested in implementing EAGs. > > Various NITs/suggestions: > > 3. There are a number of TBD ("To Be Discussed") and Editor Notes that need > to be either discussed, but in some cases just updated or removed. > > 4. Use of Requirements Language should be checked, specifically uses of > "must", "shouldn't". > > 5. Documenting Procedures and Error Handling. Although the I-D documents > what seems to be the necessary procedures in various scenarios, it may be > helpful (readability) to specifically highlight them in a procedures section > or sub-section. > > 6. Maybe a paragraph or short sub-section providing motivation and context > would be helpful to the reader (i.e., why are 32 colors not sufficient for > today's networks?). > > Br, Dan. > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 18 May 2013 19:51 > To: Daniel King; Mach Chen; n.leymann@telekom.de; Curtis Villamizar > Cc: mpls-chairs@tools.ietf.org; > draft-osborne-mpls-extended-admin-groups@tools.ietf.org; VIGOUREUX, > MARTIN > (MARTIN) > Subject: MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 > > Dan, Mach, Nic and Curtis, > > You have been selected as MPLS Review team reviewers for > draft-osborne-mpls-extended-admin-groups-01. > > Note to authors: You have been CC'd on this email so that you can know that > this review is going on. However, please do not review your own document. > > Reviews should comment on whether the document is coherent, is it useful > (ie, is it likely to be actually useful in operational networks), and is the > document technically sound? We are interested in knowing whether the > document is ready to be considered for WG adoption (ie, it doesn't have to > be perfect at this point, but should be a good start). > > Reviews should be sent to the document authors, WG co-chairs and WG > secretary, and CC'd to the MPLS WG email list. If necessary, comments may be > sent privately to only the WG chairs. > > Are you able to review this draft by June 3, 2013? > > Thanks, Loa > (as MPLS WG 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From zali@cisco.com Mon Jun 3 07:40:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B7021E8093 for ; Mon, 3 Jun 2013 07:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01Lw4coR7gTN for ; Mon, 3 Jun 2013 07:40:35 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6A75421F9691 for ; Mon, 3 Jun 2013 07:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1719; q=dns/txt; s=iport; t=1370270423; x=1371480023; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RYQ1nBbNG32Cqrwl4KQ4a80o3fS4pubAKSfGfng70E0=; b=CyhHYiVRPWdc5ZHogMQq2lIZl2dmDHmZOFe4xWgxYtCDGVY92x8pysz3 OVOjbh623/mF40w9TECYq4OXwmq5PfCngIjrc9jgwlc1pBXmJD7wO6vYk u5Vf74SlTUqZGN4yFmvwGTAhH+T+qOobfaHcqPq3vIQ1iehkXba9FaYQb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFACiqrFGtJXG9/2dsb2JhbABZgwkwvXiBCIEAFnSCIwEBAQQBAQFoAwsMAgQBCBEDAQILGSYMCx0IAgQBDQUIiAUMu1kEBI1hgRExBwaCcWEDqH6BWIE3gXE2 X-IronPort-AV: E=Sophos;i="4.87,793,1363132800"; d="scan'208";a="218100777" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 03 Jun 2013 14:40:22 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r53EeMa7017219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 14:40:22 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 09:40:22 -0500 From: "Zafar Ali (zali)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOv4486k135dEumc4v92mdr2JkkJqcA Date: Mon, 3 Jun 2013 14:40:21 +0000 Message-ID: In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [161.44.213.42] Content-Type: text/plain; charset="Windows-1252" Content-ID: <57F5DB92502B0B4F9D3ADD6EE1D37D9E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:40:40 -0000 Hi Loa and all-=20 Support, Thanks Regards =8A Zafar=20 -----Original Message----- From: Loa Andersson Date: Thursday, May 30, 2013 12:35 PM To: "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document >Working Group, > >This is to start a two week poll on adopting >draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls at 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. > >This poll ends June 14, 2013. > >There are two IPR claims against this document: > >https://datatracker.ietf.org/ipr/778/ >https://datatracker.ietf.org/ipr/2087/ > > >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. > >/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 eosborne@cisco.com Mon Jun 3 07:42:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CCC21F99A3 for ; Mon, 3 Jun 2013 07:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcCHrg8tWryX for ; Mon, 3 Jun 2013 07:41:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 932DA21F9691 for ; Mon, 3 Jun 2013 07:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8733; q=dns/txt; s=iport; t=1370270506; x=1371480106; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jGCSmAyFrBbqG2x5puCz0NjjWdC1Rw1tAq24pW/lQDc=; b=DMU5Y8/FqNBJ5HYPupwC2DHE1KCOK9bgTaJ4FLfg33tfVbXvTpbH5u1c +FYgUYVq3XvZWbXk5SlciOnnml8ZRLbsoHSEWWmM2kBex/v1AWF0aoAiP 2U0RasRqHll2PxQNMcMt3qhMxhJvfIMupJsxjf39D06HN2AqvVblfkZRd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFACiqrFGtJXHA/2dsb2JhbABZgwkwvwCBABZ0giMBAQEDAQEBATcxAwYFBQcCAgIBCBEEAQELFAkHGwwLFAkIAgQBDQUIEQKHbAYMu10EjWELgQYGIAsHAgSCcWEDmGeQF4MPgWkIFx8 X-IronPort-AV: E=Sophos;i="4.87,793,1363132800"; d="scan'208";a="218087054" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jun 2013 14:41:46 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r53EfjWC008308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 14:41:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 09:41:45 -0500 From: "Eric Osborne (eosborne)" To: "adrian@olddog.co.uk" , "'Daniel King'" , "'Loa Andersson'" , "'Mach Chen'" , "n.leymann@telekom.de" , "'Curtis Villamizar'" Thread-Topic: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 Thread-Index: AQHOYGZTocksCTfwQE6iv5zUkiRcRpkkDDOA Date: Mon, 3 Jun 2013 14:41:43 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721025554A@xmb-rcd-x09.cisco.com> References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> <00cc01ce604d$6870bc10$39523430$@olddog.co.uk> <044f01ce6066$406c67a0$c14536e0$@olddog.co.uk> In-Reply-To: <044f01ce6066$406c67a0$c14536e0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-osborne-mpls-extended-admin-groups@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:42:01 -0000 Inline > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Monday, June 03, 2013 10:26 AM > To: 'Daniel King'; 'Loa Andersson'; 'Mach Chen'; n.leymann@telekom.de; > 'Curtis Villamizar' > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-osborne-mpls- > extended-admin-groups@tools.ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin- > groups-01 >=20 > I think Dan is missing a final closing square brace. >=20 > That is... >=20 > [ > [ ] ] >=20 > ...so that the whole is optional and the EX_RA is only present if _RA is > present. > That could be represented as: >=20 > [ ] >=20 > where >=20 > ::=3D [ > ] >=20 Ah, OK. So if I did this: ::=3D [ ] [ ] [ ]=20 | [[SESSION_ATTRIBUTE of C-Type 7] []] That does what I want. Can I get away with saying "of C-Type $FOO" in BNF,= as I've done here? My only other choice is to define two different SESSIO= N_ATTRIBUTE strings (say, SESSION_ATTRIBUTE and SESSION_ATTRIBUTE_RA) and u= se those instead, but that brings me back to having to touch rfc3209 in a b= unch of places where I'd have to replace "SESSION_ATTRIBUTE" with "SESSION_= ATTRIBUTE or SESSION_ATTRIBUTE_RA". > By the way, this thread caused me to open the I-D and I can't find > motivation > for the protocol extensions in the I-D. At this stage in a document's > life I > don't generally mind if the technical details are not all present or > even if > they are wrong, but I don't like creating protocol extensions without a > clear > motivation. And, yes, I *do* understand that the intention is to create > more > attribute colors, but why? It's in my other reply to Dan, and I'll make sure I add something to the ne= xt rev. --- The short answer is that some operators use link colors with global signifi= cance (e.g. "This is a link in the northeastern US part of my network") and= use this information in their path calculation. Providing this sort of ge= otagging information with the existing AGs limits you to 32 regions worldwi= de. I'll add something to this effect at the next update. --- eric >=20 > Ciao, > Adrian >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Daniel King > > Sent: 03 June 2013 12:28 > > To: 'Loa Andersson'; 'Mach Chen'; n.leymann@telekom.de; 'Curtis > Villamizar' > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-osborne-mpls- > extended- > > admin-groups@tools.ietf.org > > Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended- > admin- > > groups-01 > > > > Update! > > > > After having a Skype chat, we think the answer to the RBNF question > is: > > > > ::=3D [ ] > > > > > > [ ] > > > > [ > > [ ] > > > > Br, Dan. > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Daniel King > > Sent: 03 June 2013 19:13 > > To: 'Loa Andersson'; 'Mach Chen'; n.leymann@telekom.de; 'Curtis > Villamizar' > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; > > draft-osborne-mpls-extended-admin-groups@tools.ietf.org > > Subject: Re: [mpls] MPLS-RT review of > > draft-osborne-mpls-extended-admin-groups-01 > > > > Hi All, > > > > As a member of the MPLS-RT, I was asked to the review the following > > document: > > > > Extended Administrative Groups in MPLS-TE > > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-01 > > > > The I-D looks to add a sub-TLV (IGP-TE) to provide for additional > > administrative groups (AGs). The requirement is derived from the > current > > limit of 32 AGs. To extend beyond the 32 AG limit (Extended AGs - > EAGs), the > > I-D proposes an OSPF/ISIS (TE) sub-TLV and an RSVP C-Type (Class > 207). > > > > Overall the draft is well-written and the solution proposal has been > > documented. I think the document should be considered for WG adoption. > > > > A few areas that will require further discussion include: backwards > > compatibility, advertising default values, and a few NITS. > > > > 1. Backwards Compatibility > > Within the network of nodes that support EAG and those that do not. > Given > > that AGs may already be widely used within the network. The author > proposes > > that if a node is advertising both the AG and EAG, then the first 32 > bits of > > the EAG must be identical to the advertised AG. Thus allowing the > continued > > use of AGs, even if nodes in the network are incapable of supporting > EAGs. > > This seems logical, but should be discussed and approved by users > > (operators). > > > > 2. Advertising Default Values > > The I-D proposes that specified but not unadvertised EAG have a > default > > value of 0. This may differ from other vendor implementations of how > they > > treat unadvertised AGs. Further discussion would be required with > vendors > > who implemented AGs, and might be interested in implementing EAGs. > > > > Various NITs/suggestions: > > > > 3. There are a number of TBD ("To Be Discussed") and Editor Notes that > need > > to be either discussed, but in some cases just updated or removed. > > > > 4. Use of Requirements Language should be checked, specifically uses > of > > "must", "shouldn't". > > > > 5. Documenting Procedures and Error Handling. Although the I-D > documents > > what seems to be the necessary procedures in various scenarios, it may > be > > helpful (readability) to specifically highlight them in a procedures > section > > or sub-section. > > > > 6. Maybe a paragraph or short sub-section providing motivation and > context > > would be helpful to the reader (i.e., why are 32 colors not sufficient > for > > today's networks?). > > > > Br, Dan. > > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: 18 May 2013 19:51 > > To: Daniel King; Mach Chen; n.leymann@telekom.de; Curtis Villamizar > > Cc: mpls-chairs@tools.ietf.org; > > draft-osborne-mpls-extended-admin-groups@tools.ietf.org; VIGOUREUX, > > MARTIN > > (MARTIN) > > Subject: MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 > > > > Dan, Mach, Nic and Curtis, > > > > You have been selected as MPLS Review team reviewers for > > draft-osborne-mpls-extended-admin-groups-01. > > > > Note to authors: You have been CC'd on this email so that you can know > that > > this review is going on. However, please do not review your own > document. > > > > Reviews should comment on whether the document is coherent, is it > useful > > (ie, is it likely to be actually useful in operational networks), and > is the > > document technically sound? We are interested in knowing whether the > > document is ready to be considered for WG adoption (ie, it doesn't > have to > > be perfect at this point, but should be a good start). > > > > Reviews should be sent to the document authors, WG co-chairs and WG > > secretary, and CC'd to the MPLS WG email list. If necessary, comments > may be > > sent privately to only the WG chairs. > > > > Are you able to review this draft by June 3, 2013? > > > > Thanks, Loa > > (as MPLS WG 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 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Mon Jun 3 07:47:41 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8A621E8093 for ; Mon, 3 Jun 2013 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCLFhBX6iQdK for ; Mon, 3 Jun 2013 07:47:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 59C6321E809F for ; Mon, 3 Jun 2013 07:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1668; q=dns/txt; s=iport; t=1370270856; x=1371480456; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SjmyL287S3AUCD11M8Jcu+iAwitL790xGz5dnS7HZII=; b=eKfifK6vH8ivlElUP1/wJ7xpBaxvCzY4bvlyYHeXSWQFVbpmwZ1FZ7iS P3UswzyteRIItX7Wzl4m85opZ4DNwzrF9UA8te1U4vTS7hz3qkxIcje8Z 0SqdlEVkcWHMNL9tDtfj3mHg/6cK5cfQYBdhGIaqnWm+ROk+kYQwzRHy0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngFAE+rrFGtJV2Y/2dsb2JhbABZgwkwvXeBCIEAFnSCIwEBAQQBAQE3MQMLDAIEAQgRAwECCxQFJgwLHQgCBAENBQiIBQy7WgQEjWGBETEHBoJxYQOofoFYgTeBcTY X-IronPort-AV: E=Sophos;i="4.87,793,1363132800"; d="scan'208";a="218103654" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 03 Jun 2013 14:47:28 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r53ElSV3021981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 14:47:28 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.189]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 09:47:28 -0500 From: "Luyuan Fang (lufang)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOtaOo0HnoK/EKFiDqrzzf+c5kj9lgA Date: Mon, 3 Jun 2013 14:47:27 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD93103AA066@xmb-rcd-x03.cisco.com> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.76.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <652CEB5D26A2104898192CBB055EC7F6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:47:41 -0000 Support. Luyuan -----Original Message----- From: Loa Andersson Date: Thursday, May 30, 2013 9:35 AM To: "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document >Working Group, > >This is to start a two week poll on adopting >draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls at 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. > >This poll ends June 14, 2013. > >There are two IPR claims against this document: > >https://datatracker.ietf.org/ipr/778/ >https://datatracker.ietf.org/ipr/2087/ > > >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. > >/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 msiva@cisco.com Mon Jun 3 07:52:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8C21F8C08 for ; Mon, 3 Jun 2013 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz+Uq9yGa9U0 for ; Mon, 3 Jun 2013 07:52:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DF23321F896D for ; Mon, 3 Jun 2013 07:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1618; q=dns/txt; s=iport; t=1370271145; x=1371480745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=in0cvy82MB+Ej1bHryapWpTM/P3iJId0wNnC5bccCmk=; b=llVsyJqT88fcpVoPvHtXN6htBWn44wFV20yF8pymmJhbWg8UluIKg5/g 6TSqwhy2L0UUnogRAWwWr7M31sJiUYdYawlup+eJGCOwQe0fC6xOmj8uf 4Bm2cr8U/dN5DsB+PYgDFh04jfklg9yHKv4iZoO/cB3vhjpSmpT6p9m5u c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngFACOtrFGtJV2Y/2dsb2JhbABZgwkwvXeBCIEBFnSCIwEBAQQBAQE3MQMLDAICAgEIEQQBAQsUBQQHGwwLFAkIAgQBDQUIiAUMu18EBI1hgRExBwaCcWEDqH6BWIE3gXE2 X-IronPort-AV: E=Sophos;i="4.87,793,1363132800"; d="scan'208";a="218087746" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jun 2013 14:52:24 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r53EqOxm027518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 14:52:24 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.169]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 09:52:24 -0500 From: "Siva Sivabalan (msiva)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOvP0LmTFkSnkeVeZhRcV8ov5kkGMgg Date: Mon, 3 Jun 2013 14:52:23 +0000 Message-ID: References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:52:29 -0000 Yes, support. Thanks, Siva -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 30, 2013 12:35 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.or= g Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-pro= xy-lsp-ping an MPLS working group document Working Group, This is to start a two week poll on adopting draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at 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. This poll ends June 14, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/778/ https://datatracker.ietf.org/ipr/2087/ 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. /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 adrian@olddog.co.uk Mon Jun 3 07:54:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED06E21F9925 for ; Mon, 3 Jun 2013 07:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJN-a2YZK8QX for ; Mon, 3 Jun 2013 07:53:54 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E304321F9922 for ; Mon, 3 Jun 2013 07:53:53 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53ErfZh017507; Mon, 3 Jun 2013 15:53:41 +0100 Received: from 950129200 ([220.109.211.58]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53ErYjT017482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Jun 2013 15:53:36 +0100 From: "Adrian Farrel" To: "'Eric Osborne \(eosborne\)'" , "'Daniel King'" , "'Loa Andersson'" , "'Mach Chen'" , , "'Curtis Villamizar'" References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> <20ECF67871905846A80F77F8F4A2757210255313@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210255313@xmb-rcd-x09.cisco.com> Date: Mon, 3 Jun 2013 15:53:27 +0100 Message-ID: <047401ce606a$205b7e70$61127b50$@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: AQJ0tZYK5UINXa0UjkIm4qRPc/mLsQMvgbAUAqvJHCaXqIs1IA== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-osborne-mpls-extended-admin-groups@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 03 Jun 2013 14:54:00 -0000 OK, now I have read Eric's email and am not really comfortable. The reason why 3209 does not draw a distinction between and is that they are the same object, and any single occurrence is allowed. So I think your proposal is a bit complicated because you are saying > <---- OK > > <-------- OK > > > <---- OK > > > <---- NOT OK This is hard to express in RNBF because we only deal in objects not in C-Types. A way to deal with this would be to simply use [ ... ] and then use text to say which C-Types are allowed and which not. However, by re-using the class number you run into a piece of RFC 2205. Viz. 2. Unknown C-Type for Known Class : Generally, the appearance of an object with unknown C-Type should result in rejection of the entire message and generation of an error message (ResvErr or PathErr as appropriate). This hits backward compatibility. You need to decide whether (for example) "exclude" should cause a set-up failure by a node that ignores it. Perhaps it should. Then again, the CNum seems to mean ignore the object if unknown. My recommendation, along with enhancing the document to include motivation, is to add text describing clearly what you want to allow and disallow, what information is carried, and how messages and objects should be handled. The bits and bytes can wait. Adrian From nobo@cisco.com Mon Jun 3 08:01:20 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A96921F962D for ; Mon, 3 Jun 2013 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjhNR69kLjfY for ; Mon, 3 Jun 2013 08:01:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6151021F8519 for ; Mon, 3 Jun 2013 08:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1721; q=dns/txt; s=iport; t=1370271675; x=1371481275; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ja5sth2SI/jJ2SUzZmjvotjr+gZB20GlSTd9BM0tJck=; b=UEtJybdYQaPKw1RnK7+Cx6EAEK4bwQ3jf4e9XGXmZd4mv4dUcShK1UPN dFKTpNQJaVJlgtOXbeCrB4GqRjcOhpuH3CmFMCusnyOwSMDEXVRzNV93W eCi8BoG5Nlkg34k3eAIKqCbZGVzV/XJugxZ0bvmQsbSkqXIdAPGPmazpE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkFAJWurFGtJXG9/2dsb2JhbABZgmghML13gQiBARZ0giMBAQEEAQEBNzEDCwwCAgIBCBEEAQELFAUEBxsMCxQJCAIEAQ0FCIgFAQu7XwQEjWGBETEHBoJxYQOofoFYgTeBcTY X-IronPort-AV: E=Sophos;i="4.87,793,1363132800"; d="scan'208";a="215126505" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 03 Jun 2013 15:01:15 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r53F1Ef9012652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 15:01:14 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.02.0318.004; Mon, 3 Jun 2013 10:01:14 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOtcnZsMB7xjUWEED4eZDYStpkkG59g Date: Mon, 3 Jun 2013 15:01:14 +0000 Message-ID: References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 15:01:20 -0000 Support. Regards, Nobo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Thursday, May 30, 2013 12:35 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp- > ping@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls- > proxy-lsp-ping an MPLS working group document >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give a technical motivation= for > your support/not support, especially if you think that the document shoul= d > not be adopted as a working group document. >=20 > This poll ends June 14, 2013. >=20 > There are two IPR claims against this document: >=20 > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ >=20 >=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. > 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 > /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 adrian@olddog.co.uk Mon Jun 3 08:03:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2022F21F99FC for ; Mon, 3 Jun 2013 08:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEdriKlc4Yer for ; Mon, 3 Jun 2013 08:03:37 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 7281921F99E8 for ; Mon, 3 Jun 2013 08:03:37 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53F3U3q019038; Mon, 3 Jun 2013 16:03:30 +0100 Received: from 950129200 ([220.109.211.58]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r53F3OYd018922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Jun 2013 16:03:26 +0100 From: "Adrian Farrel" To: "'Eric Osborne \(eosborne\)'" , "'Daniel King'" , "'Loa Andersson'" , "'Mach Chen'" , , "'Curtis Villamizar'" References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> <00cc01ce604d$6870bc10$39523430$@olddog.co.uk> <044f01ce6066$406c67a0$c14536e0$@olddog.co.uk> <20ECF67871905846A80F77F8F4A275721025554A@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721025554A@xmb-rcd-x09.cisco.com> Date: Mon, 3 Jun 2013 16:03:19 +0100 Message-ID: <048701ce606b$7f062780$7d127680$@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: AQJ0tZYK5UINXa0UjkIm4qRPc/mLsQMvgbAUAZNvt0EB2tcBQQIafDOFl5GojxA= Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-osborne-mpls-extended-admin-groups@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 03 Jun 2013 15:03:51 -0000 Hi Eric, > The short answer is that some operators use link colors with global significance > (e.g. "This is a link in the northeastern US part of my network") and use this > information in their path calculation. Providing this sort of geotagging information > with the existing AGs limits you to 32 regions worldwide. I'll add something to > this effect at the next update. Thanks for the background. It makes me wonder whether this use is really resource affinities or a different pseudo-SRLG-geo-proximity indicator. Maybe the answer is that you need an entirely new object for an entirely different application? Adrian From mwildt@cisco.com Mon Jun 3 08:16:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C849821F99BF for ; Mon, 3 Jun 2013 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3N3ZeOFhjAy for ; Mon, 3 Jun 2013 08:16:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7E43421F994A for ; Mon, 3 Jun 2013 08:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1615; q=dns/txt; s=iport; t=1370272591; x=1371482191; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lNkvBI/CEgRp4/1vhsSjPBnMuh3dlAcL30BOJquWaY4=; b=YzsDClBfclnmWfqihcShxUU+84yRid74Uwb8Ne1z0bzR+mRc3hRyfUsL N8FIuMH+lyENyFZxdPNlwxCumkZzooLe1UixhTMCcSvtIMs/9gZ3dPsP4 lNs3D0x+zTqWlULy/HsjWGQKkf9dKNcELCtMk2PNNQ7ASnnKuVReCrmhd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcUANOxrFGtJV2b/2dsb2JhbABZgXEEAYETML13gQiBAhZ0giMBAQEEAQEBNzEDCwwCAgIBCBEEAQELFAUEBxsMCxQJCAIEAQ0FCIgFDLttBASNYYERMQcGgnFhA6h+gViBN4FxNg X-IronPort-AV: E=Sophos;i="4.87,793,1363132800"; d="scan'208";a="218111929" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jun 2013 15:16:31 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r53FGU6r006711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 15:16:30 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.110]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 10:16:30 -0500 From: "Michael Wildt (mwildt)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOtHvVtSpxFfU2DxsxFzKRHw5kkH+fA Date: Mon, 3 Jun 2013 15:16:29 +0000 Message-ID: <785D51FE90E3F14F9F4EC45BC406BAD1230EA232@xmb-rcd-x02.cisco.com> References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.71.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 15:16:36 -0000 Support. Thanks Michael -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 30, 2013 12:35 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.or= g Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-pro= xy-lsp-ping an MPLS working group document Working Group, This is to start a two week poll on adopting draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at 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. This poll ends June 14, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/778/ https://datatracker.ietf.org/ipr/2087/ 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. /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 sboutros@cisco.com Mon Jun 3 09:02:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6434121F9951 for ; Mon, 3 Jun 2013 09:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJjKT70vMqDK for ; Mon, 3 Jun 2013 09:01:58 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB0D21F96C2 for ; Mon, 3 Jun 2013 09:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1368; q=dns/txt; s=iport; t=1370275318; x=1371484918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iyUNtNPv43JwgIhcFEqhqlNj0FsVYsrBh4VNkeI+Kf4=; b=MwYvP7/Aq1ZDo+R7tRXS5J9UoxMBNzlEENlIEmJBQnkONDUuyp0Y82BJ lq+SZdjpJvcx1LzeLikxVA0aP3xQtcP6/Qm2e+H3e0CFDAvxaf6Ba+X6r zblH2gd95E7R7w63ldFFcL9HQH9z8jnR4emLT+1g9O871BpXoetDtNzZK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAB+9rFGtJV2c/2dsb2JhbABZgwkwvXqBCIECFnSCIwEBAQMBAQEBNzEDCwUJAgIBCCIUBQsbDAslAgQOBQiHfwYMu24EBI1hgRExB4J3YQOofoFYgTeBcTY X-IronPort-AV: E=Sophos;i="4.87,794,1363132800"; d="scan'208";a="218209958" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jun 2013 16:01:49 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r53G1neb025061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 16:01:49 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.14]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 11:01:49 -0500 From: "Sami Boutros (sboutros)" To: Loa Andersson Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOvJMYjaFc5Y02cK+vrAFf/lJkkgHgA Date: Mon, 3 Jun 2013 16:01:48 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F1134A2B10@xmb-rcd-x08.cisco.com> References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.215.152] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B6750F0835D304F93C712E924A191C4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 16:02:03 -0000 Support. Thanks, Sami On May 30, 2013, at 9:35 AM, Loa Andersson wrote: > Working Group, >=20 > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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 > This poll ends June 14, 2013. >=20 > There are two IPR claims against this document: >=20 > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ >=20 >=20 > 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. >=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 lizho.jin@gmail.com Mon Jun 3 09:06:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9541921F8DDD for ; Mon, 3 Jun 2013 09:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0Z1KaGXlmtk for ; Mon, 3 Jun 2013 09:06:24 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 51D4721F8DBC for ; Mon, 3 Jun 2013 09:06:24 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id x7so2500522qeu.9 for ; Mon, 03 Jun 2013 09:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WVxAS9Fd400+9dKLMewxM/16DVwCuLn09/bs9ogUdmE=; b=jx0DdU2DRAqgzn71v8w61EI1FppJS0Z+HfxSOKMNbDrSaSU5wu4M9ObMZQl2pVFRZt A3XNZU2VZzuBkJD0hhHOf+DDjKRM92pCoK7JeFAFRKaDcSAi6tX/HoE1ckuRMTOS8qRo bj0vuNslqi8u/AWG8w28NdJuwB26vdSKi6J71RLdiQngnC8fZtuZynnXrmXZBF3QVpbZ l4rsWe4J7EX2WtcGP5ij5+VsqtN+thG45PqabLkr0Xz+VDJkB8WTqgZtuHNZGNlfPfKr X1D62xffcF+Lftnielag8hrQDFIGLyipMClGzk1632WAqsbSzu7L5XEqrzTolottfSVa mDKQ== MIME-Version: 1.0 X-Received: by 10.224.137.73 with SMTP id v9mr19605402qat.59.1370275583608; Mon, 03 Jun 2013 09:06:23 -0700 (PDT) Received: by 10.49.87.137 with HTTP; Mon, 3 Jun 2013 09:06:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 00:06:23 +0800 Message-ID: From: Lizhong Jin To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2dcc667e9b204de422530 Subject: Re: [mpls] mpls Digest, Vol 109, Issue 55 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 16:06:29 -0000 --001a11c2dcc667e9b204de422530 Content-Type: text/plain; charset=ISO-8859-1 Hi, Support. One comment, in the draft, it is said: Label 7 (when received) retains its meaning as ELI whether a regular or an extended special purpose label; however, an implementation SHOULD NOT insert a label of 7 as an extended special purpose label, preferring instead to send 7 as a regular special purpose label. Could we change "SHOULD NOT" to "MUST NOT", and let lable 7 to be reserved? Only one choice for the parser would ease the implementation. Regards Lizhong > ------------------- > > Message: 3 > Date: Thu, 30 May 2013 10:11:30 +0200 > From: Loa Andersson > To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" > , "" > , "VIGOUREUX, MARTIN (MARTIN)" > , > draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org > Subject: [mpls] OOOOPPS - Sorry Correction - Re: IPR poll on > draft-ietf-mpls-ldp-applicability-label-adv > Message-ID: <51A709B2.6000505@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working Group, > > a typo :(. We are not preparing this document for wglc, but we are > preparing the request for publication. > > The IPR are poll is still on. > > /Loa > > On 2013-05-30 10:02, Loa Andersson wrote: > > Working Group and authors; > > > > The authors of draft-ietf-mpls-ldp-applicability-label-adv and > > the working group chairs are working to prepare the draft for working > > group last call. > > > > We IPR poll on this draft before accepting it as a working group > > document. Since this is sometime ago we will do a new before > > starting the working group last call to check whether there is IPR > > on the document that needs to be disclosed. > > > > This mail starts that IPR poll. > > > > Are you aware of any IPR that applies to draft-ietf-mpls-ldp- > > applicability-label-adv? > > > > 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 contributor. > > > > If you are on the MPLS WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of any > > IPR that has not yet been disclosed in conformance with IETF rules. > > > > > > Thanks, Loa > > (as MPLS WG co-chair) > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > --001a11c2dcc667e9b204de422530 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
Support. One comment, in the draft, it is said:
La=
bel 7 (when received) retains its meaning as ELI whether a regular or an ex=
tended special purpose label; however, an implementation SHOULD NOT insert =
a label of 7 as an extended special purpose label, preferring instead to se=
nd 7 as a regular special purpose label.
Could we change "SHOULD NOT" to "MUS= T NOT", and let lable 7 to be reserved? Only one choice for the parser= would ease the implementation.=A0

Regards
Lizhong
=A0
-------------------

Message: 3
Date: Thu, 30 May 2013 10:11:30 +0200
From: Loa Andersson <loa@pi.nu>
To: "mpls@ietf.org" <mpls@ietf.org>, =A0 =A0"mpls-chairs@tools.ietf.org" =A0 =A0 =A0 =A0 <mpls-chai= rs@tools.ietf.org>, =A0 "<mpls-ads@tools.ietf.org>"
=A0 =A0 =A0 =A0 <mpls-ads@too= ls.ietf.org>, =A0 =A0 =A0"VIGOUREUX, MARTIN (MARTIN)"
=A0 =A0 =A0 =A0 <= martin.vigoureux@alcatel-lucent.com>,
=A0 =A0 =A0 =A0 draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.o= rg
Subject: [mpls] OOOOPPS - Sorry Correction - Re: IPR poll on
=A0 =A0 =A0 =A0 draft-ietf-mpls-ldp-applicability-label-adv
Message-ID: <51A709B2.6000505@= pi.nu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

Working Group,

a typo :(. We are not preparing this document for wglc, but we are
preparing the request for publication.

The IPR are poll is still on.

/Loa

On 2013-05-30 10:02, Loa Andersson wrote:
> Working Group and authors;
>
> The authors of draft-ietf-mpls-ldp-applicability-label-adv and
> the working group chairs are working to prepare the draft for working<= br> > group last call.
>
> We IPR poll on this draft before accepting it as a working group
> document. Since this is sometime ago we will do a new before
> starting the working group last call to check whether there is IPR
> on the document that needs to be disclosed.
>
> This mail starts that IPR poll.
>
> Are you aware of any IPR that applies to draft-ietf-mpls-ldp-
> applicability-label-adv?
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as a document author or contributor please respond t= o
> this email regardless of whether or not you are aware of any relevant<= br> > IPR. *The response needs to be sent to the MPLS wg mailing list.* The<= br> > documents will not advance to the next stage until a response
> has been received from each author and contributor.
>
> If you are on the MPLS WG email list but are not listed as an author o= r
> contributor, then please explicitly respond only if you are aware of a= ny
> IPR that has not yet been disclosed in conformance with IETF rules. >
>
> Thanks, Loa
> (as 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


--001a11c2dcc667e9b204de422530-- From lizho.jin@gmail.com Mon Jun 3 09:12:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421C521F90EF for ; Mon, 3 Jun 2013 09:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E64r34W1R+kO for ; Mon, 3 Jun 2013 09:12:18 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id CE44D21F905F for ; Mon, 3 Jun 2013 09:12:17 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id ih17so1924690qab.14 for ; Mon, 03 Jun 2013 09:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=W7kRLmhdPhPvoDki66WwlftiWnivDAAWrtaUAGSSXqA=; b=GhDi+IPFlIQ4S+sTFeuuh5yVB3pfzVfZq/rN6IzLCSVLBkPav11RX1Ub+uddnpoXDd w6JfOf+9yY8u8WqDBYeDOJrF/LYYLlyZ764I+9nZ8wIh7OLcKPCzseZZzZqrgVC8hdxf RPgNqjF2f+mxBGomQSicKvwpotNEbXse9Fcbb9uqD3oKfHARVcZ35Z/MIAslYUrzH89u 9VzeQ3LhLk5bcyeCFTEg22iVoI4YzS8q8oTaCqyUmjKdiWsUriRBhNXjRhQm6NqQXws+ ZkOUcmM/yZk6q6p629u0vGrFsIC6B8XQNjgSvp02D+BKp8YdXj00MGuWZebDWB3oEAKg IbCA== MIME-Version: 1.0 X-Received: by 10.224.47.6 with SMTP id l6mr19867620qaf.9.1370275937236; Mon, 03 Jun 2013 09:12:17 -0700 (PDT) Received: by 10.49.87.137 with HTTP; Mon, 3 Jun 2013 09:12:17 -0700 (PDT) Date: Tue, 4 Jun 2013 00:12:17 +0800 Message-ID: From: Lizhong Jin To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2c7e47bda7304de423ab4 Subject: Re: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 16:12:19 -0000 --001a11c2c7e47bda7304de423ab4 Content-Type: text/plain; charset=ISO-8859-1 Sorry, I meant to reply to list "Re: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04)" for below email. Please ignor my previous mail with subject "Re: mpls Digest, Vol 109, Issue 55". ----------------------------- Hi, Support. One comment, in the draft, it is said: Label 7 (when received) retains its meaning as ELI whether a regular or an extended special purpose label; however, an implementation SHOULD NOT insert a label of 7 as an extended special purpose label, preferring instead to send 7 as a regular special purpose label. Could we change "SHOULD NOT" to "MUST NOT", and let lable 7 to be reserved? Only one choice for the parser would ease the implementation. Regards Lizhong > ------------------- > > > > > --001a11c2c7e47bda7304de423ab4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry, I meant to reply to lis= t "Re: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft= -kompella-mpls-special-purpose-labels-04)" for below email. Please ign= or my previous mail with subject "Re: mpls Digest, Vol = 109, Issue 55".

-----------------------------
Hi,
S= upport. One comment, in the draft, it is said:
Label 7 (when=
 received) retains its meaning as ELI whether a regular or an extended spec=
ial purpose label; however, an implementation SHOULD NOT insert a label of =
7 as an extended special purpose label, preferring instead to send 7 as a r=
egular special purpose label.
Could we change "SHOULD NOT" to "MUS= T NOT", and let lable 7 to be reserved? Only one choice for the parser= would ease the implementation.=A0

Regards
Lizhong
=A0
-------------------





--001a11c2c7e47bda7304de423ab4-- From cpignata@cisco.com Mon Jun 3 09:46:43 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10C921F93B9 for ; Mon, 3 Jun 2013 09:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.134 X-Spam-Level: X-Spam-Status: No, score=-110.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkWZEINueXo6 for ; Mon, 3 Jun 2013 09:46:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8DF21F918F for ; Mon, 3 Jun 2013 09:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1531; q=dns/txt; s=iport; t=1370277990; x=1371487590; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=m5Qj+JreQ01kaBFSnqXu7c56gzHxUStZJxaYsvp4N04=; b=VU06unJoOS61bQgO62gJpJmyhFh12PSMKYcYEprLMHRtk+JIcm1tuxAq /c3okacFGW0gClBxrLo6WmlfqLoVbxGSMjlYPrnXCy0K8k/VjciJUl6nf 4IYdFz9zanONGHpsv7oSLX9WA5wupZLVI9nBCzxZcN/c2tD/w1fpMy98z 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAADHrFGtJXG8/2dsb2JhbABZgwkwvXyBCIECFnSCIwEBAQMBAQEBNzEDCwUJAgIBCCIUBQsbDAslAgQOBQgTh2wGDLt5BASNYYEPAjEHgndhA6h+gViBN4FxNg X-IronPort-AV: E=Sophos;i="4.87,794,1363132800"; d="scan'208";a="217947182" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jun 2013 16:46:29 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r53GkTQY025565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 16:46:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 11:46:29 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOw3mIuIkaA0k+qWPvLGlFIq5kkjPGA Date: Mon, 3 Jun 2013 16:45:12 +0000 Message-ID: <95067C434CE250468B77282634C96ED322BDC755@xmb-aln-x02.cisco.com> References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B451D0EB4FE784ABA6AD9864269A9C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 16:46:43 -0000 Support. I support adoption of this document as it solves scalable OAM in multipoint= scenarios, real problem and sound technical solution. Thanks, -- Carlos. On May 30, 2013, at 12:35 PM, Loa Andersson wrote: > Working Group, >=20 > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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 > This poll ends June 14, 2013. >=20 > There are two IPR claims against this document: >=20 > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ >=20 >=20 > 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. >=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 >=20 From renwei.li@huawei.com Mon Jun 3 10:44:58 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B626B11E80B8 for ; Mon, 3 Jun 2013 10:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag98Um83e5qV for ; Mon, 3 Jun 2013 10:44:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A690F21F9648 for ; Mon, 3 Jun 2013 10:39:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN55573; Mon, 03 Jun 2013 17:39:45 +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.1.323.7; Mon, 3 Jun 2013 18:38:57 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 4 Jun 2013 01:39:43 +0800 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Mon, 3 Jun 2013 10:39:38 -0700 From: Richard Li To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOvpppJrZwxmEGFWYvrVeGQWpkkR7vA Date: Mon, 3 Jun 2013 17:39:37 +0000 Message-ID: References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.123] 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-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 17:44:58 -0000 Support. /Richard -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 30, 2013 9:35 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.or= g Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-pro= xy-lsp-ping an MPLS working group document Working Group, This is to start a two week poll on adopting draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at 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. This poll ends June 14, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/778/ https://datatracker.ietf.org/ipr/2087/ 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. /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 eosborne@cisco.com Mon Jun 3 11:39:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50921F8618 for ; Mon, 3 Jun 2013 11:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxIvfGzD+4Uo for ; Mon, 3 Jun 2013 11:38:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 880D911E80D1 for ; Mon, 3 Jun 2013 11:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1558; q=dns/txt; s=iport; t=1370284723; x=1371494323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4yivOb4bBTrBglIL30Vix74GMsVJZy59wdDCN+1oWyg=; b=N0SmX5/3zYhRjzZmzjCUHKVm24KgrdiQo7Ji6LkryPK2CfFlNbZcJM5f nYL34LXxolivFWF3bwhxs+8I/Fj5YNOkmunK0dxS3lHP4H108fpQTjSPW zluCuDmqRhpUmAbdRi1bGUA/6tP4s4cROrOvCBPv6dopFd620FQ39Zm4a s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABPhrFGtJXG8/2dsb2JhbABZgwm/NoEGFnSCIwEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIiAW8No52MQcGgnFhA6h+gw+CJw X-IronPort-AV: E=Sophos;i="4.87,794,1363132800"; d="scan'208";a="215223155" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 03 Jun 2013 18:38:43 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r53IcgD1011775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 18:38:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 13:38:42 -0500 From: "Eric Osborne (eosborne)" To: "adrian@olddog.co.uk" , "'Daniel King'" , "'Loa Andersson'" , "'Mach Chen'" , "n.leymann@telekom.de" , "'Curtis Villamizar'" Thread-Topic: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 Thread-Index: AQHOYGZTocksCTfwQE6iv5zUkiRcRpkkDDOAgABdyYD//+eSAA== Date: Mon, 3 Jun 2013 18:38:42 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210255BD4@xmb-rcd-x09.cisco.com> References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> <00cc01ce604d$6870bc10$39523430$@olddog.co.uk> <044f01ce6066$406c67a0$c14536e0$@olddog.co.uk> <20ECF67871905846A80F77F8F4A275721025554A@xmb-rcd-x09.cisco.com> <048701ce606b$7f062780$7d127680$@olddog.co.uk> In-Reply-To: <048701ce606b$7f062780$7d127680$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-osborne-mpls-extended-admin-groups@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 18:39:06 -0000 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Monday, June 03, 2013 11:03 AM > To: Eric Osborne (eosborne); 'Daniel King'; 'Loa Andersson'; 'Mach > Chen'; n.leymann@telekom.de; 'Curtis Villamizar' > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-osborne-mpls- > extended-admin-groups@tools.ietf.org > Subject: RE: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin- > groups-01 >=20 > Hi Eric, >=20 > > The short answer is that some operators use link colors with global > significance > > (e.g. "This is a link in the northeastern US part of my network") and > use this > > information in their path calculation. Providing this sort of > geotagging > information > > with the existing AGs limits you to 32 regions worldwide. I'll add > something > to > > this effect at the next update. >=20 > Thanks for the background. >=20 > It makes me wonder whether this use is really resource affinities or a > different > pseudo-SRLG-geo-proximity indicator. >=20 > Maybe the answer is that you need an entirely new object for an entirely > different application? A whole new object is overkill, IMO. What I've describe is how (some) peop= le are already using affinity groups, they just want more of them. Other uses of affinity groups that I've seen indicate not geolocation but f= unction (PE-P link, satellite link, encrypted link, etc). I see no reason = why this function can't coexist with the geolocation function I've describe= d. eric From rajiva@cisco.com Mon Jun 3 12:32:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B3721F8C38 for ; Mon, 3 Jun 2013 12:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG2SUjYRLKFY for ; Mon, 3 Jun 2013 12:32:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A729121F91B0 for ; Mon, 3 Jun 2013 12:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1988; q=dns/txt; s=iport; t=1370287548; x=1371497148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t9pLK2mrLD0PauggW0nRFbiZnDOsXFMD/diYaBQVH4s=; b=Dv9NOqc7/mqrn0cKQ7g/el9aGnpUnFHKU+kwFV30WllGqpvaTYy2vmF/ PKxDM1HzVsJZQWw7VcKwCHn/yrxSo155XdOwo7VdA6sf5PVntm8NVzm1O JpVAikcnT1WEGJiKVO1NH09rJUu+eviJZXcTHvZz+T/6e2//oET2SIvHS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngFAIPsrFGtJV2Z/2dsb2JhbABZgwkwvgCBCIEGFnSCIwEBAQMBAQEBNzEDCwUHAgICAQgOAwQBAR8FBAcbDAsUCQgCBA4FiAcGDLxCBASNYYEPMwcGgnFhA5c+kUCBWIE3gXE X-IronPort-AV: E=Sophos;i="4.87,794,1363132800"; d="scan'208";a="218225001" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jun 2013 19:25:48 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r53JPlRq004237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 19:25:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 14:25:47 -0500 From: "Rajiv Asati (rajiva)" To: Richard Li Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOvyr7TGz4y10G/N8KIFKkanpkkR7vAgAAd6uQ= Date: Mon, 3 Jun 2013 19:25:47 +0000 Message-ID: <5DCE4E51-E5B4-403D-AB5D-33953183D5A3@cisco.com> References: <51A77FBD.6010605@pi.nu>, In-Reply-To: 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 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 19:32:44 -0000 Support. Cheers, Rajiv Sent from my Phone On Jun 3, 2013, at 1:45 PM, "Richard Li" wrote: > Support. >=20 > /Richard >=20 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa Andersson > Sent: Thursday, May 30, 2013 9:35 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.= org > Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-p= roxy-lsp-ping an MPLS working group document >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working group= mailing list (mpls at ietf.org). Please give a technical motivation for yo= ur support/not support, especially if you think that the document should no= t be adopted as a working group document. >=20 > This poll ends June 14, 2013. >=20 > There are two IPR claims against this document: >=20 > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ >=20 >=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. > 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 > /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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Mon Jun 3 13:08:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0321E80ED for ; Mon, 3 Jun 2013 13:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw1jJLJZ-+EG for ; Mon, 3 Jun 2013 13:08:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3D021F9433 for ; Mon, 3 Jun 2013 12:59:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN61508; Mon, 03 Jun 2013 19:59:06 +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.1.323.7; Mon, 3 Jun 2013 20:58:19 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 4 Jun 2013 03:59:05 +0800 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Mon, 3 Jun 2013 12:58:58 -0700 From: Huaimo Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVO2qJWr2zMuXkWqwvDuyuzHG5kkbrMA Date: Mon, 3 Jun 2013 19:58:58 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451DD99D@dfweml509-mbx.china.huawei.com> References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.79] 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-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 20:08:31 -0000 Support. Best Regards, Huaimo -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 30, 2013 12:35 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.or= g Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-pro= xy-lsp-ping an MPLS working group document Working Group, This is to start a two week poll on adopting draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at 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. This poll ends June 14, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/778/ https://datatracker.ietf.org/ipr/2087/ 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. /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 naikumar@cisco.com Mon Jun 3 18:31:18 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6738421F9991 for ; Mon, 3 Jun 2013 18:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrzXEIRVcxaK for ; Mon, 3 Jun 2013 18:31:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DE95521E80D4 for ; Mon, 3 Jun 2013 17:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1370307005; x=1371516605; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Vy1qkdbzGYzEdzlBUikwTh5nTNyMrf5NSaIOwIjjKvI=; b=bzT5IJcl2hBSlwXoBEeBLQwJLl6PP4A4IhQyX5/4k3vBR0PIl1hluG1s 3s15ri8G9M4xskyP7mIWrsYlwSXUw8SuV2Jec7VaJaej7HIO+bqAMldDe 5QNvf96QCgBDztXKpN7K8yzPi4YP6fZBV81MjYaPeWgAhUjdg3ZCZzR4V c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngFAOw4rVGtJV2Y/2dsb2JhbABZgwkwvgCBCIEHFnSCIwEBAQQBAQE3MQMLDAICAgEIEQQBAQsUBQQHGwwLFAkIAgQBDQUIiAUMvHIEBI1hgRExBwaCcWEDqH6BWIE3gXE2 X-IronPort-AV: E=Sophos;i="4.87,796,1363132800"; d="scan'208";a="218353969" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 04 Jun 2013 00:49:12 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r540nCC9023159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Jun 2013 00:49:12 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.189]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 19:49:12 -0500 From: "Nagendra Kumar (naikumar)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOvE+dYQe3G7kuAj5RF8k8Hkpkkv+uQ Date: Tue, 4 Jun 2013 00:49:11 +0000 Message-ID: <47E76F08F1BCF5458111C1939C7B9C46101E7CBF@xmb-rcd-x03.cisco.com> References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.219.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 01:31:19 -0000 Support Regards, Nagendra -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 30, 2013 10:05 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.or= g Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-pro= xy-lsp-ping an MPLS working group document Working Group, This is to start a two week poll on adopting draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at 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. This poll ends June 14, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/778/ https://datatracker.ietf.org/ipr/2087/ 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. /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 mach.chen@huawei.com Mon Jun 3 18:41:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671BF11E815C for ; Mon, 3 Jun 2013 18:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM-CaXl5IKkz for ; Mon, 3 Jun 2013 18:41:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2C121E8116 for ; Mon, 3 Jun 2013 18:05:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASB73386; Tue, 04 Jun 2013 01:04:55 +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.1.323.7; Tue, 4 Jun 2013 02:04:07 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 4 Jun 2013 02:04:54 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Tue, 4 Jun 2013 09:04:50 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOunYTOudjPjkenFOeqNZxuPZkkxDRA Date: Tue, 4 Jun 2013 01:04:49 +0000 Message-ID: References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@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.96.176] 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-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 01:41:53 -0000 Yes/support Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa > Andersson > Sent: Friday, May 31, 2013 12:35 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.= org > Subject: [mpls] Poll to see if we have consensus to make > draft-lim-mpls-proxy-lsp-ping an MPLS working group document >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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 > This poll ends June 14, 2013. >=20 > There are two IPR claims against this document: >=20 > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ >=20 >=20 > 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. >=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 adrian@olddog.co.uk Mon Jun 3 21:20:27 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A178121E80B1 for ; Mon, 3 Jun 2013 21:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uck-shOgxSp for ; Mon, 3 Jun 2013 21:20:11 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED521F9703 for ; Mon, 3 Jun 2013 20:19:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r543JDpH000869; Tue, 4 Jun 2013 04:19:13 +0100 Received: from 950129200 (122x216x203x186.ap122.ftth.ucom.ne.jp [122.216.203.186]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r543J7dN000840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Jun 2013 04:19:09 +0100 From: "Adrian Farrel" To: "'Eric Osborne \(eosborne\)'" , "'Daniel King'" , "'Loa Andersson'" , "'Mach Chen'" , , "'Curtis Villamizar'" References: <51975D16.9010709@pi.nu> <00c301ce6042$e5885bf0$b09913d0$@olddog.co.uk> <00cc01ce604d$6870bc10$39523430$@olddog.co.uk> <044f01ce6066$406c67a0$c14536e0$@olddog.co.uk> <20ECF67871905846A80F77F8F4A275721025554A@xmb-rcd-x09.cisco.com> <048701ce606b$7f062780$7d127680$@olddog.co.uk> <20ECF67871905846A80F77F8F4A2757210255BD4@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210255BD4@xmb-rcd-x09.cisco.com> Date: Tue, 4 Jun 2013 04:19:01 +0100 Message-ID: <055f01ce60d2$46437df0$d2ca79d0$@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: AQJ0tZYK5UINXa0UjkIm4qRPc/mLsQMvgbAUAZNvt0EB2tcBQQIafDOFAgk2cskB9kFL3pdyetbQ Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-osborne-mpls-extended-admin-groups@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:20:27 -0000 > A whole new object is overkill, IMO. What I've describe is how (some) people are > already using affinity groups, they just want more of them. > > Other uses of affinity groups that I've seen indicate not geolocation but function > (PE-P link, satellite link, encrypted link, etc). I see no reason why this function > can't coexist with the geolocation function I've described. Yeah, people use resource affinities for all sorts of things. It is a rather convenient container for any number of things (some of them terrible hacks :-). Well, I'll wait to see your text describing the motivation in the next revision. A From internet-drafts@ietf.org Tue Jun 4 00:19:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3267521F9ABE; Tue, 4 Jun 2013 00:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6CUC-DMweiG; Tue, 4 Jun 2013 00:19:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE7F21F9B4D; Mon, 3 Jun 2013 23:19:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130604061949.7818.515.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 23:19:49 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-te-hsmp-lsp-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 07:19:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Hub and Spoke Multipoint Label Switched Path Tunnels Author(s) : Lizhong Jin Frederic Jounay Manav Bhatia Sriganesh Kini Filename : draft-ietf-mpls-rsvp-te-hsmp-lsp-00.txt Pages : 8 Date : 2013-06-03 Abstract: There are applications that require bi-directional, co-routed and guaranteed communication from a root node to several leaf nodes in a hub and spoke fashion. To meet such application requirements in a Multi-protocol Label Switching (MPLS) network this draft defines a Hub and Spoke Multipoint Traffic Engineered Label Switched Path (HSMP TE LSP) with resource reservations for guaranteed communication. This draft also defines a protocol to setup such LSPs by re-using and extending P2MP RSVP-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-te-hsmp-lsp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-hsmp-lsp-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ping@pingpan.org Tue Jun 4 07:10:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AC221F9CCD for ; Tue, 4 Jun 2013 07:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcrGTR39F3My for ; Tue, 4 Jun 2013 07:09:50 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with SMTP id 4DE4021F9A4B for ; Tue, 4 Jun 2013 05:34:21 -0700 (PDT) Received: from mail-qc0-f180.google.com ([209.85.216.180]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUa3ezHB7hEIfBgQamqiX0CObHMEUxC+N@postini.com; Tue, 04 Jun 2013 05:34:21 PDT Received: by mail-qc0-f180.google.com with SMTP id a10so80384qcx.25 for ; Tue, 04 Jun 2013 05:34:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=12QZJiXqf25MOklPDgzPKxMXcenYrvNud2nTv1Yj3rU=; b=op8qmZkc3PFus+Wd4QwX/O2QHBhGgsM3jBQr2mAAQWaK50ZShsVmfpyw/MWPiV8VsF 3zUrDHTd2m+rGRDvLoWkIpOzZHsnX+1OAbLAwcQDD1b25zCEm1sIdfJpQQzB8aBIkpFy iIVTXvQAMGjCLezhaeCsAmUJzpzUbKEEOh/tyFw5Rm8ndBTGYgDzXam+P8SEMsezIhl2 kzV4PziqZZ/XktnmNWD0bzI/O+Y3/908S9oU+wa5pGEBGQAdbm3HbD/l1zIyAyfIImic 9IrdFVa48b/F+Bp2AsXP44ktTVpzXp3eZnlw/61T5BFtbLsNLB9GkpXlRXEi84qwicjx ol4A== X-Received: by 10.229.150.20 with SMTP id w20mr8778783qcv.139.1370349259527; Tue, 04 Jun 2013 05:34:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.150.20 with SMTP id w20mr8778779qcv.139.1370349259396; Tue, 04 Jun 2013 05:34:19 -0700 (PDT) Received: by 10.49.130.34 with HTTP; Tue, 4 Jun 2013 05:34:19 -0700 (PDT) Received: by 10.49.130.34 with HTTP; Tue, 4 Jun 2013 05:34:19 -0700 (PDT) In-Reply-To: References: <51A77FBD.6010605@pi.nu> Date: Tue, 4 Jun 2013 05:34:19 -0700 Message-ID: From: Ping Pan To: =?UTF-8?B?Q2hlbk1hY2go6ZmI5Zu95LmJKQ==?= Content-Type: multipart/alternative; boundary=e89a8f647645d32d7d04de534c64 X-Gm-Message-State: ALoCoQmvce6g8nbHEbjDSF1ILxsQqsk/egKiNak3fFWI4tlj9nc9r1yTCgbSq4w0lvSDBHX0EnDwMIjmGDvfxXFfELY+6DY45dXPjoeETjFOBnM3FcFF0xqMqe0Lj/p0gNOzBPkX317U0aA5gqePNVc8Y3ogIH5nOA== Cc: mpls@ietf.org, draft-lim-mpls-proxy-lsp-ping@tools.ietf.org, mpls-chairs@tools.ietf.org, Loa Andersson Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:10:06 -0000 --e89a8f647645d32d7d04de534c64 Content-Type: text/plain; charset=UTF-8 +1 On Jun 3, 2013 6:42 PM, "Mach Chen" wrote: > Yes/support > > Best regards, > Mach > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa > > Andersson > > Sent: Friday, May 31, 2013 12:35 AM > > To: mpls@ietf.org > > Cc: mpls-chairs@tools.ietf.org; > draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > > Subject: [mpls] Poll to see if we have consensus to make > > draft-lim-mpls-proxy-lsp-ping an MPLS working group document > > > > Working Group, > > > > This is to start a two week poll on adopting > > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > > > > Please send your comments (support/not support) to the mpls working > > group mailing list (mpls at 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. > > > > This poll ends June 14, 2013. > > > > There are two IPR claims against this document: > > > > https://datatracker.ietf.org/ipr/778/ > > https://datatracker.ietf.org/ipr/2087/ > > > > > > 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. > > > > /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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --e89a8f647645d32d7d04de534c64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1

On Jun 3, 2013 6:42 PM, "Mach Chen" &l= t;mach.chen@huawei.com> wrot= e:
Yes/support

Best regards,
Mach

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa
> Andersson
> Sent: Friday, May 31, 2013 12:35 AM
> To: mpls@ietf.org
> Cc: mpls-chairs@tools.ie= tf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.org
> Subject: [mpls] Poll to see if we have consensus to make
> draft-lim-mpls-proxy-lsp-ping an MPLS working group document
>
> Working Group,
>
> This is to start a two week poll on adopting
> draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >
> Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give a technical
> motivation for your support/not support, especially if you think that<= br> > the document should not be adopted as a working group document.
>
> This poll ends June 14, 2013.
>
> There are two IPR claims against this document:
>
> ht= tps://datatracker.ietf.org/ipr/778/
> h= ttps://datatracker.ietf.org/ipr/2087/
>
>
> 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.
>
> /Loa
> (mpls wg co-chair)
> --
>
>
> Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0email: = loa@mail01.huawei.com
> Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@p= i.nu
> Huawei Technologies (consultant) =C2=A0 =C2=A0 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
ht= tps://www.ietf.org/mailman/listinfo/mpls
--e89a8f647645d32d7d04de534c64-- From lucy.yong@huawei.com Tue Jun 4 10:23:43 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3141821F9C75 for ; Tue, 4 Jun 2013 10:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCTOISL2nsGw for ; Tue, 4 Jun 2013 10:23:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2721F9DA1 for ; Tue, 4 Jun 2013 08:40:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO42346; Tue, 04 Jun 2013 15:40:16 +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.1.323.7; Tue, 4 Jun 2013 16:39:26 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 4 Jun 2013 16:40:15 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 4 Jun 2013 08:40:09 -0700 From: Lucy yong To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVOzEzho0qw+tkSJcLQHIuMt3JkluODg Date: Tue, 4 Jun 2013 15:40:08 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4526F1A3@dfweml509-mbx.china.huawei.com> References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.80] 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-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 17:23:43 -0000 Support! Cheers, Lucy > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Thursday, May 30, 2013 11:35 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp- > ping@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus to make draft-lim- > mpls-proxy-lsp-ping an MPLS working group document >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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 > This poll ends June 14, 2013. >=20 > There are two IPR claims against this document: >=20 > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ >=20 >=20 > 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. >=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 ietfc@btconnect.com Tue Jun 4 10:34:46 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8269D21F949F for ; Tue, 4 Jun 2013 10:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvIMjj8hK4z3 for ; Tue, 4 Jun 2013 10:34:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id F0D4921F9EE7 for ; Tue, 4 Jun 2013 09:03:40 -0700 (PDT) Received: from mail158-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Jun 2013 16:03:39 +0000 Received: from mail158-va3 (localhost [127.0.0.1]) by mail158-va3-R.bigfish.com (Postfix) with ESMTP id D16F430008C; Tue, 4 Jun 2013 16:03:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz9371I542I1432I1418I4015Idb28izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh304l1d11m1155h) Received: from mail158-va3 (localhost.localdomain [127.0.0.1]) by mail158-va3 (MessageSwitch) id 1370361817366929_11446; Tue, 4 Jun 2013 16:03:37 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.238]) by mail158-va3.bigfish.com (Postfix) with ESMTP id 515C4C0055; Tue, 4 Jun 2013 16:03:37 +0000 (UTC) Received: from DB3PRD0711HT001.eurprd07.prod.outlook.com (157.56.254.197) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Jun 2013 16:03:35 +0000 Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.183.34) with Microsoft SMTP Server (TLS) id 14.16.311.1; Tue, 4 Jun 2013 16:03:26 +0000 Message-ID: <00ec01ce613c$3d29ba80$4001a8c0@gateway.2wire.net> From: t.petch To: References: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> Date: Tue, 4 Jun 2013 16:47:11 +0100 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.250.117] X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org Subject: [mpls] IANA Considerations was Re: AD review of draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 17:34:46 -0000 ---- Original Message ----- From: "Adrian Farrel" To: Cc: Sent: Wednesday, May 29, 2013 7:18 AM Subject: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology > Hi authors, > > Thanks for this document. > > I have done my usual AD review which is intended to catch any issues > that I see, and to smooth out the wrinkles before the I-D goes to IETF > last call and IESG review. > > As you will see below, I have a number of editorial comments (nits and > larger changes) and also a few questions/issues. > > The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. > I suggest you read the comments against those sections all together. > Note that in my comment for section 9, I think I have worked out what > you need to do, and so the resolution to the comments for 3.4 and 3.8 > may simply be documenting this change to the IANA registry. > > As usual, all my comments are up for discussion, so please don't feel > you are required to make changes if you think there is a good reason why > things are the way they are. > > At the moment it looks like a new revision will be needed to address the > review, so I have set the flag in the datatracker. Please work with your > document shepherd to produce and post a new revision. > > Thanks, > Adrian > > === > > The document seems to end with a spurious page header. > > --- > > The index seems to be considerably adrift from reality. > In particular, there is no Appendix in this document. > > --- > > Why do you say that this updates RFC 4379? Is it your belief that an > implementation of RFC 4379 will not be complete/conformant without these > extensions? Or are you just defining extensions which an implementation > in an MPLS-MT environment will need to support? > > I note that you (in my view, correctly) do not say that this document > updates RFC 5036, yet it defines extensions to LDP in a similar way. I am not sure I follow this logic; RFC6426 adds TLVs and sub-TLVs and is recorded as updating RFC4379. That RFC also updates the "Pseudowire Associated Channel Types" registry but is not recorded as updating the RFC for that registry. So I think that this I-D is following a pre-established path. Tom Petch > --- > > Please expand all acronyms on first use unless they show with an > asterisk in the RFC Editor's list at > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > I see: > CSP > LSP > QoS > > --- > > Abstract and Introduction > > "IGP protocol" is bad because the "P" in "IGP" is "protocol". > > --- > > The RFC Editor prefers documents to have the Introduction as Section 1. > > You may prefer to make this change yourself, because it will possibly > cause some expansions of terms and acronyms that the RFC Editor might > so in a way you don't like. > > --- > > In section 1, the term "MT Topology" is odd because the "T" of "MT" > stands for "Topology". Surely you don't mean "Multi Topology Topology"? > > --- > > Section 3.1 > > s/infers/implies/ > > --- > > Section 3.2 > > I prefer that you don't repeat protocol encodings that are defined > elsewhere. This can cause nasty problems if you make a mistake or if > the original definition is updated. > > It is enough for you to write... > > The LDP base specification [RFC5036] (Section 4.1) defines the > "Prefix" FEC Element. The "Prefix" encoding is defined for a given > "Address Family" (AF), and has length (in bits) specified by the > "PreLen" field. > > To extend IP address families for MT, two new Address Families named > "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes > within a topology scope. > > --- > > Section 3.2 Figure 2 > > This figure gives the impression that both IPv4 and IPv6 addresses are > four bytes long! > > I think you need: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ IP Address ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | MT-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2: MT IP Address Family Format > > ...and... > > Where "IP Address" is a variable length field padded to a four octet > boundary and containing an IPv4 or IPv6 address/prefix for the "MT > IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to > the 16-bit Topology ID for given address. > > ...but you need to check I got that right! > > However, before doing this work, see my comment on Section 3.3 > > --- > > Section 3.2 > > The proposed FEC Elements with "MT IP" Address Family can be used in > > You are not proposing any more, you are defining! > > See also section 3.6, 3.8, 4.1, 4.3, and 8 > > --- > > Section 3.2 > > [RFC5036] does not specify the handling of "Unknown" Address > Families. Therefore, [RFC5036] will need to be updated to include > the handling procedure for unknown address families. > > Ouch! > > This had me really worried because it implied that you are breaking > existing LDP deployments. But I discussed it with Loa, and he pointed me > at Section 3.4.1.1 of RFC 5036 > > "If in decoding a FEC TLV an LSR encounters a FEC Element with an > Address Family it does not support, it SHOULD stop decoding the FEC > TLV, abort processing the message containing the TLV, and send an > "Unsupported Address Family" Notification message to its LDP peer > signaling an error. > > If it encounters a FEC Element type it cannot decode, it SHOULD stop > decoding the FEC TLV, abort processing the message containing the > TLV, and send an "Unknown FEC" Notification message to its LDP peer > signaling an error." > > So I think you can just delete this paragraph. > > Furthermore, Section 3.5 defines a capability advertisement that enables > you to know whether it is safe to use one of the new AFs. So surely you > should also say "MUST NOT send an MT AF unless the peer has said it can > handle it." > > See my re-write in the next comment. > > --- > > Section 3.3 appears to be repeating a lot of Section 3.2, but in a > better and more concise way. For example, Figure 3 nicely shows how the > Prefix FEC element works with the new AFs. > > This leads me to think that Section 3.2 could be reduced to just a few > lines that say... > > The LDP base specification [RFC5036] (Section 4.1) defines the > the use of an "Address Family" (AF) field in FEC Elements to indicate > the encoding of the "Prefix" or "Address" that follows, and to > indicate how the FEC should be interpreted. > > This document defines two new AF values named "MT IP" and "MT IPv6" > that are used to specify the use of IPv4 or IPv6 within a topology > scope. The data associated with these new AFs includes an "MT-ID" > field that carries the 16-bit Topology ID for a topology. > > The value of MT-ID=0 corresponds to default topology and MUST be > ignored on receipt so as to not cause any conflict/confusion with > existing non-MT procedures. > > FEC Elements with the new AFs can be used in any LDP message and > procedures that currently specify and allow the use of FEC Elements > with the IP or IPv6 AFs, but MUST NOT be used unless the peer has > indicated it can handle them as described in Section 3.5. Note that > behavior by an LDP speaker that receives a FEC element containing an > unknown AF is described in Section 3.4.1.1 of [RFC5036]. > > --- > > Section 3.4 is perfectly clear except it doesn't say what "reserved", > "special", and "translating" mean. > > This opens up a number of questions including why you need a registry > at all. Presumably the "translation" needed is to ensure that the > values used in LDP have the same meaning as they do in the IGP. If that > is the case, why not simply use exactly the same value? > > And looking at the registry further, it seems to say that only values > allocated by IANA and stored in the registry can be used. That means > that an operator that wants to use MT in their network cannot just > assign values to the MT-IDs for the topologies because the registry > has no space for this to happen. > > Now, it is possible that you have simply used the wrong words in the > registry in section 9, and failed to provide any explanation in the > text. Note that "unassigned" means "not yet assigned, but available > to be assigned by IANA". And "Reserved" means "Do not assign until > a new RFC defines how they should be used." > > But there are other questions: > > Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? > I guess 16 is convenient to hold either, but how are the top 4 bits to > be handled? > > How do you handle the case where there are multiple instances of an IGP > (or different IGPs) running? > > If you *do* expect there to be a mapping function between IGP MT-ID and > LDP MT-ID, how do you ensure the same function is used at both ends of > an LDP session? > > But Section 3.8 really does seem to say that only MT-IDs in the registry > are allowed, which seems to make this I-D almost useless because you > have only defined "default" (which we have already), "ISIS IPv6", and > "all". Isn't an operator allowed to partition their network into > topologies? > > So... > > I think what you need in Section 9 is... > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. The allocation policies for this registry > are: > > Range Registration Policy > ------ ------------------- > 0-3995 Expert Review > 3996-4095 Private Use > 4096-4127 Expert Review > 4128-4255 Private Use > 4256-4351 Reserved (IANA does not assign) > 4352-4511 Expert Review > 4512-65535 Private Use > > IANA is requested to populate this registry as follows: > > > Range/Value Purpose Reference > ----------- ------------------------------------- --------- > 0 Default/standard topology in IS-IS [This.I-D] > 1 IPv4 in-band management in IS-IS [This.I-D] > 2 IPv6 routing topology in IS-IS [This.I-D] > 3 IPv4 multicast topology in IS-IS [This.I-D] > 4 IPv6 multicast topology in IS-IS [This.I-D] > 5 IPv6 in-band management in IS-IS [This.I-D] > 6-3995 Unassigned (intended to mirror IS-IS) > 3996-4095 Reserved for private use (from IS-IS) [This.I-D] > 4096 Default/standard topology in OSPF [This.I-D] > 4097 Default multicast topology in OSPF [This.I-D] > 4098 IPv4 in-band management in OSPF [This.I-D] > 4099-4127 Unassigned (intended to mirror OSPF) > 4128-4255 Reserved for private use (from OSPF) [This.I-D] > 4256-4351 Reserved (IANA does not assign) [This.I-D] > 4352-4511 Unassigned > 4512-65535 Reserved for Private Use [This.I-D] > > This would address many of the issues in Sections 3.4 and 3.8, and needs > to be discussed in those sections. > > --- > > In Section 3.5 > > o Length: The length (in octets) of TLV. > > Are you sure it is not just the length in octets of the value? > Compare with RFC 5036 Section 3.3 > > --- > > Sections 3.5 and 3.6 need to be more closely grouped. > > Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 > > --- > > Section 3.6 > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker MAY send an "MT Capability" > including the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker MAY send "MT Capability" with one or more MT Typed FEC > elements in it. > > I don't think this is "MAY" in either case. This *is* how the LDP > speaker announces it. There is no other way to announce it. So... > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker sends an "MT Capability" including > the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker sends "MT Capability" with one or more MT Typed FEC elements > in it. > > --- > > Section 3.6 > > o If an LSR has not advertised MT capability, its peer must not send > messages that include MT identifier to this LSR. > > Isn't that "MUST NOT"? > > --- > > Section 3.8 > > Certain MT topologies are assigned to serve predetermined purposes: > > It is not the topology that is assigned, but the MT-ID. Should read: > > Certain MT-ID values are assigned to indicate specific meanings: > > --- > > Section 3.8 > > It is not helpful to "propose" numbers in this section and then to > also reference Section 9 for the definitive numbers. I suggest you > remove all numbers from this section and simply point at Section 9. > > --- > > Section 4.2 > > This MAY allow an LDP speaker to signal its IP convergence... > > What does 2119 MAY mean in this context? > > --- > > Section 4.3 > > [RFC4379] defines procedures to detect data-plane failures in MPLS > LSPs via LSP ping. The specification defines a "Target FEC Stack" > TLV that describes the FEC stack being tested. > > Ha, ha! You got me :-) > s/The specification/That specification/ > > --- > > Section 4.3.1 > > Sub-Type Length Value Field > -------- ------ ----------------- > TBA5 5 MT LDP IPv4 prefix > TBA6 17 MT LDP IPv6 prefix > > Are you sure you don't mean 8 and 20? > > --- > > Section 4.3.4 > > When detect data plane failures using LSP Ping for a specific topoly, > the router will intiate an LSP Ping request with the targer FEC stack > > I think > > s/When/To/ > > s/topoly/topology/ > > s/intiate/initiate/ > > s/targer/target/ > > --- > > Section 4.3.4 > > For the case that the LSP ping with return path not specified , the > reply packet may go through the default topology instead of the > topology where the Echo Request goes through. > > Is that really "the default" or "any"? > If you mean "the default" then I think you need some "MUST NOT" text to > talk about other topologies. > > --- > > Section 5 > > The extensions defined in this document utilise the existing LDP > error handling defined in [RFC5036]. If an LSR receives an error > notification from a peer for an MPLS-MT session, it terminates the > LDP session by closing the TCP transport connection for the session > and discarding all MT-ID label mappings learned via the session. > > There is nothing wrong with this text, but it does open a question that > is not addressed anywhere in the document: what is the relationship > between LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? > > This is somewhat assumable from the discussion of multiple MT-ID > wildcard FEC elements in the Multi-Topology Capability TLV, but it is > not explicit. > > --- > > Shouldn't Section 6 comment on how each of the new protocol elements > will not be seen by a legacy implementation because they are only used > after successful capability negotiation? > > But you do need to describe how a legacy node will react to attempted > MT capability negotiation. > > You could also restate the reference to RFC 5036 section 3.4.1.1 since > this issue seemed to be a question for you. > > --- > > I'm slightly doubtful about the value of Section 7, but I note that the > point you are trying to convey is not quite worded correctly. You have: > > and the specified > signaling mechanisms do not provide any way for the data plane to > associate a given packet with a context-specific label space. > > I don't think the signaling mechanism is relevant, and I think "context- > specific" hides what you are trying to say. Perhaps you should have: > > and there is no way > for the data plane to associate a received packet with any one > topology, meaning that topology-specific label spaces cannot be used. > > --- > > Section 9 > > o New Status Code: "Multi-Topology Capability not supported" > (requested code point: TBA2 from LDP registry "Status Code Name > Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is an implementation that does not know the new MT Capability > TLV supposed to generate this status code? Or are you referencing an > existing error code: in which case it should not appear in this section. > > o New Status Code: "Unknown Address Family" (requested code point: > TBA4 from LDP registry "Status Code Name Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is a legacy implementation that does not know either of your > new MT AFs supposed to generate this status code? But I suspect you are > just referencing an existing error code (see Section 3.2) as defined in > RFC 5036, and so you should not mention it in this section. > > Figure 10 does not show either of these status codes. > > --- > > Figure 10 shows a specific value for the new status code. Is this a > request or demand? I don't think it has already been allocated. > > --- > > Section 9 > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. > > This registry is discussed earlier in my notes. but please be aware that > you will need to define the allocation policy because it is a new > registry. > > --- > > Section 9 > > I want to ask Loa Andersson to look again at the LSP Ping TLV > allocations to check that they conform to the work he is currently > doing with that registry. > > --- > > It would help considerably to add a Manageability Considerations section > to this document because the function being added here is not simple to > manage or operate, and will have impact on the way that the network is > run. Good guidance on such sections can be found in RFC 5706. Appendix A > is particularly helpful at summarising things to consider. > > -------------------- > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From dhruv.dhody@huawei.com Tue Jun 4 21:04:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361E21F9AD9 for ; Tue, 4 Jun 2013 21:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKfHU7+AqZ-s for ; Tue, 4 Jun 2013 21:04:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B321F9ADC for ; Tue, 4 Jun 2013 21:04:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO76915; Wed, 05 Jun 2013 04:04:34 +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.1.323.7; Wed, 5 Jun 2013 05:03:44 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 05:04:34 +0100 Received: from blrprnc03ns (10.18.96.92) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server id 14.1.323.7; Wed, 5 Jun 2013 12:04:28 +0800 From: Dhruv Dhody To: References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Date: Wed, 5 Jun 2013 09:34:27 +0530 Organization: HTIPL Message-ID: <005e01ce61a1$c6406160$52c12420$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5dU65nqmHOfOz8SiGtQXYgGAMnMQETgdeQ Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 04:04:40 -0000 Support. **************************************************************************** *** Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: Thursday, May 30, 2013 10:05 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls- > proxy-lsp-ping an MPLS working group document > > Working Group, > > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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. > > This poll ends June 14, 2013. > > There are two IPR claims against this document: > > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ > > > 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. > > /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 From lberger@labn.net Wed Jun 5 10:55:23 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8DA21F8FBE for ; Wed, 5 Jun 2013 10:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.666 X-Spam-Level: X-Spam-Status: No, score=-100.666 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T4RrGsg53UX for ; Wed, 5 Jun 2013 10:55:17 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 3BA8921F8B21 for ; Wed, 5 Jun 2013 10:55:15 -0700 (PDT) Received: (qmail 22854 invoked by uid 0); 5 Jun 2013 17:54:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 5 Jun 2013 17:54:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=pbtx+XdtLlrzMK9/v3GxR5pU/F56r0EAbT5rUIHkN98=; b=0HE9goY6Q/t9+q32VLrfCAd/lDJlqhf8XnZWwU1/12kTiyAZrKXLHAnYk9f8DI6fEkDoA+aNOm5W4+SW/s7Q1RJ56HQdIx5GJIMRJUh2k3oxGPZTyCY4Fc3GTMUpNcVh; Received: from box313.bluehost.com ([69.89.31.113]:49781 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UkHv4-0005fL-8q; Wed, 05 Jun 2013 11:54:46 -0600 Message-ID: <51AF7B61.8080906@labn.net> Date: Wed, 05 Jun 2013 13:54:41 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org References: <04ae01ce57f1$a6b72b80$f4258280$@olddog.co.uk> In-Reply-To: <04ae01ce57f1$a6b72b80$f4258280$@olddog.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 17:55:23 -0000 Hi, I took a look at this document and have some additional comments: (BTW FWIW I'm a coauthor of RFC4875 and co-chair of CCAMP, but am commenting as an individual contributor.) - At a high level, I too had a really hard time trying to figure out what problems this draft is trying to address, and consequently evaluating if the proposed solutions are reasonable (or even applicable). I think Adrian covers this pretty well in his mail, so I won't revisit the details. - It's not clear if the draft fully considers defined mechanisms. For example the draft states When processing a Path message, the border node may not have knowledge of all the destinations of the P2MP LSP; for example, in the case when not all S2L sub-LSPs pass through this border node. In that case, existing protocol mechanisms do not provide sufficient information for it to be able to expand the loose hop(s) such that the overall P2MP LSP tree is guaranteed to be re-merge free. Actually the statement on no guarantee applies to any time loose hop(s) are expanded, which is of course why the RFC4875 addresses this problem in the first place. - Furthermore, it really seems the draft is just trying to replace the RFC4875 defined mechanisms: This document describes how crankback signaling extensions for MPLS and GMPLS RSVP-TE defined in [RFC4920] can be used for setting up P2MP TE LSPs to resolve re-merges. and ... procedures described in this document are equally applicable to the intra-domain (i.e. single domain) P2MP-TE LSPs. So in other words, this draft throws out the 4875 defined mechanism for removal of the re-merge branch(es) via signaling and replaces it with a RFC4920-based approach. Is this right? I really don't see the issues/RFC4875 functionality gap being addressed by this draft to justify such a major change to P2MP operation. Also, as currently formulated, it seems that this document should state that it updates RFC4875. - Assuming that a RFC4920-based approach is used as defined, I don't see how complex multi-domain induced re-merges are resolved by such an approach alone. For example, consider the following (SD=source domain, TD=transit domain, DD=Destination domain). DD1 / +-----TD1-+ DD2 | \ / SD TD2 | | +-----TD3-+-TD4--TD5--DD5 \ \ DD3 DD4 and assume that there are two different border routers to TD4, and one S2L sub-LSP routed sd->TD1->TD2->TD4a->DD5 and another S2L sub-LSP routed sd->TD3->TD4b->DD4 and there is a remerge somewhere in TD4 that is not at a border. In this case neither border router sees a remerge, nor can either fix the problem as the S2L list needs to be fixed somewhere in SD. Now if the intent of section 3.2 is to support both the 4875 defined approach and a RFC4920-based approach, one has to ask why? Is it just that you want an domain border node that identifies a re-merge in path computation to start the signaling to eliminate the re-merge? If so, why not just state that the 4875 defined mechanism for removal of the re-merge branch(es) via signaling at the border node? - Section 6. It's really unclear to me what is different in this section from what is specified in RFC4736. As far as I can tell it really comes down to a new P2MP specific flag and sub-code. If this is this case, what's the point? The existing flag and sub-code can be used on any LSP type, S2L sub-LSP or destination subset. Now I could see a discussion about how to use RFC4736 mechanisms for sub-LSP or specific destination reoptimization, but I think this is more an informational piece than a PS as nothing on the wire needs to change. Furthermore, from a procedural perspective I think it problematic for a Standards track document to update an informational document such as RFC4736. I think this at least does not belong in the same document. Perhaps it would be better to have a RFC4736 bis that moves the base RFC to Standards track and addresses P2MP considerations. Of course, again, this is just a personal opinion. =Now on to more detailed comments: - Section 1, A minor nit: [RFC4875] specifies two approaches to handle re-merge conditions. The first method is based on control plane handling the re-merge. Actually, RFC4875 Section 18.1.1 says There are two approaches to dealing with the re-merge case. In the first, the node detecting the re-merge case, i.e., the re-merge node, allows the re-merge case to persist, but data from all but one incoming interface is dropped at the re-merge node. In the second, the re-merge node initiates the removal of the re-merge branch(es) via signaling. So the first method is based on data plane handling. - Section 4.3, A major nit: When a node that does not support data plane based re-merge handling receives an S2L sub-LSP Path message with LSP Attributes sub-object that has "P2MP-TE Re-merge Recording Request" Flag set, and if the S2L is causing a re-merge condition, the node MUST reject the S2L sub-LSP Path message and send the PathErr with the error code "Routing Problem" and the error value "ERO resulted in re-merge" as specified in [RFC4875]. So this document is actually updating RFC4875 and (implicitly) changing the following requirement: There are two approaches to dealing with the re-merge case.... A node MUST support both approaches and MUST allow user configuration of which approach is to be used. Either this text should be removed or this update to RFC4875 should be made explicit. - Also in Section 4.3: If a node is capable of data plane based re- merge handling but operator may have disabled it via a configuration, the the node MUST also reject the re-merge and send this PathErr. This is already in RFC4875 so there's no need to respecify it here. - Section 4.3, almost the whole section. I think I understand the intent of these requirements, but this text is seriously broken and needs a major rewrite. I can provide a detailed list of all the issues or suggested text if desired. Some examples: When a Path message is received at a transit node for an S2L sub-LSP and "P2MP-TE Re-merge Recording Request" Flag is set in the LSP Attributes sub-object, the node MAY decide to accept the re-merge S2L sub-LSP based on the local policy and node capability. Is the acceptance of re-merge really based on the presence of the recording flag? I think not, as this is already covered in RFC4875. In this case, before the Resv message is sent to the upstream node for this S2L sub-LSP, the node MUST add the RRO Attributes sub-object in the Resv RRO if not already present and set the "P2MP-TE Re-merge Present" Flag if traffic from the incoming interface of this S2L sub-LSP will be dropped. To me this reads as if a Resv is generated by the transit node in response to a Path message. Clearly this isn't the case. This same incoming interface can still be used for a different S2L sub-LSP in the P2MP LSP to forward traffic and "P2MP-TE Re-merge Present" flag will not be set for that S2L sub-LSP. Is this referring to a cross over case, if so, it should say so, if not what case is this? The proposed signaling extensions allow an ingress node and an ingress border node to have a complete view of the re-merge conditions on the entire S2L path and on all S2Ls of the P2MP tree. but wait A border node due to local policy MAY remove the record route object from the Resv message of the S2L sub-LSP and propagate Resv message towards the ingress node. If the border node is not able to resolve the re-merge condition, the border node SHOULD send the PathErr with the error code "Routing Problem" and the error value "ERO resulted in re-merge" as specified in [RFC4875]. Why only a SHOULD? What happens when a node doesn't send the PathErr? - Section 4.3, An ingress node MAY immediately start sending traffic on all S2Ls in up state even when re-merge conditions are present on some S2Ls of the P2MP LSP. This paragraph is modifying RFC4875. This too should either be dropped or made an explicit update to RFC4875. I think that's it, Lou On 5/23/2013 4:11 PM, Adrian Farrel wrote: > Hi, > > I have done my usual AD review of this draft on receipt of the > publication request from the MPLS WG chairs. As well as the desire > to remove issues that might otherwise show up during IETF last call and > IESG review (thereby saving resources), my review is to make sure that > I understand the intention and details of the work so that I can support > the document as it goes through these later reviews and also the > publication process. > > As you will see from my comments below, I am not currently comfortable > with the document. At the moment I am not saying that the proposals are > bad and dangerous, although I am at least believing them to be > unnecessary and based on some misstatements of the problems that need to > be addressed. > > I understand that the chairs report there is WG consensus behind this > document in its current form, but I am unable to support it for > publication as an RFC. > > You have two options open to you to advance your work as a standards > track RFC. Firstly, you could seek to address my concerns through a > combination of changes to the text and discussions with me. Secondly, > you can attempt to find another AD to sponsor the work - possibly > Stewart is a good starting point. > > For the moment, I am returning the I-D to the working group. > > Thanks, > Adrian > > --- > > Was this document shown to the CCAMP working group? The P2MP work > (4875) was developed in partnership with CCAMP because it was intended > to be equally applicable to MPLS-TE and GMPLS. Presumably this is also > true of this work. You might find that by consulting CCAMP you are > able to get some more P2MP implementers to have a look at the problems > this draft is proposing to solve. > > --- > > I am surprised that the working group has taken this approach to the > described problem of re-merge avoidance. This problem is addressed by > the combination of PCE and Path Keys. However, if the working group has > considered that approach and has consensus to take this other approach, > I will not object. > > Could the chairs confirm that the existing mechanisms have been > considered and that the WG determined to add new extensions to the > signaling protocols instead. > > --- > > I'm afraid I find myself wondering whether this document is addressing > the wrong problem :-( Re-merge is a bad thing to have as a persistent > situation, and certainly must not be allowed to cause data duplication > downstream of the re-remerge point. > > However, avoiding re-merge by selecting disjoint paths is not the > solution. If re-merge happens, it is because the path to one set of > destinations has intersected the path to another set of destinations. > When this happens, one of the two paths to the re-merge point must be > optimal (for *any* definition of optimal) or the paths are equally > optimal. In either case, the correct solution is to move all of the > destinations (the union of the two sets) onto the same path and prune > out the sub-optimal one. In this case, the bottom line will be that > the upstream branch was wrong to use two distinct domain border nodes > for the two sets of destinations. That is the problem that needs to be > fixed. > > What I seem to be reading here is an attempt to avoid re-merge that > favors the use of suboptimal paths. In many network configurations that > will be impossible. But in any case, it will prove as costly in terms of > network resources as the re-merge itself. > > The discussion about re-optimization using 4736, is a different problem > that you can raise. The description of the problem doesn't really > surface until the description of the solution in Section 1.1, which is a > pity. This is largely a descriptive issue, although I would argue that > the partial reomptimization is easily handled using partial resignaling, > and therefore without any protocol extensions. > > --- > > Please fix the minor spacing not reported by idnits. > > --- > > idnits shows several problems with references. > > You are missing RFC 2119 from the normative references. > You are missing RFC 4874 from the informative references. > You are missing RFC 2205 from the normative references. > RFC 4726 is an informative reference, but not cited. Possibly work it > into the 4th para of the Introduction? > RFC 5920 is a downref. Does it need to be a normative reference? > RFC 4736 is a downref. It appears that you are using it in a normative > way - please confirm this so that we can handle the downref correctly. > > Document Shepherd - please update the write-up to correctly note the > downrefs that remain after this work. > > --- > > Please remove citations from the Abstract. The Abstract is stand-alone > text and cannot have external references. > > --- > > The Abstract is not clear and needs work. > - The issues *may* arise, but do not always arise > - The "computation of loosely routed inter-domain P2MP-TE LSP paths that > are re-merge free" is not an issue and is not addressed in this > document. Please describe the actual issue you are addressing. > - s/vs./versus/ > - I don't think "the loosely routing domain ingress border node is not > aware of the reoptimization scope" describes a problem well because > the issue is the "there is no way to indicate which branches of the > P2MP tree are to be reoptimised". > - In the light of my observation that techniques already exist to > address the problems described in this document, it may be too strong > to say "This document defines the required protocol extensions needed > for ..." Maybe change this to "This document defines signaling > protocol extensions for..." > > --- > > It would really help the reader and reviewers if someone could take an > editorial pass on the document. This is not so much a problem of English > usage as missing words and such like. A native speaker would clean it up > very quickly and avoid the risk of the RFC Editor accidentally breaking > the technical content. > > --- > > In the Introduction... > > Consequently one > of the requirements for signaling P2MP LSPs is to choose a P2MP path > that is re-merge free. > > Is this a signaling requirement? > 1. Surely it is a path computation requirement, if it is a requirement > at all. > 2. Isn't the point that signaling is supposed to detect and resolve > re-merge issues rather than avoid them? > > --- > > In the Introduction... > > For the purposes of this document, a domain is considered to be any > collection of network elements within a common sphere of address > management or path computational responsibility. Examples of such > domains include Interior Gateway Protocol (IGP) areas and Autonomous > Systems (ASes). A border node is a node between different routing > domains. > > "domain" or "routing domain"? > > --- > > In the Introduction... > > In that case, the border node for a new domain will be > given loose next hops for one or more destinations in a P2MP LSP. > > s/will be/may be/ ? > > --- > > In the Introduction... > > A > border node can ensure that it computes the re-merge free paths while > performing loose hop ERO expansions by individually grafting > destinations. Note that the computed P2MP tree by a border node in > this case may not be optimal. > > Why are you suggesting a mechanism for computing paths? That is an > implementation detail. Furthermore, suggesting a mechanism that is > almost certain to generate a suboptimal solution seems perverse! > > --- > > In the Introduction... > > In that case, existing protocol mechanisms > do not provide sufficient information for it to be able to expand the > loose hop(s) such that the overall P2MP LSP tree is guaranteed to be > re-merge free. > > Weeeeell... > > Even if you don't want to use PCE and Path Key, you could use RRO and > XRO with suitable staggered processing at the branch node. That would > provide sufficient information using existing protocol elements, > although a small (but obvious) piece of processing needs to added at > the branch node > > --- > > In the Introduction... > > [RFC4875] specifies two approaches to handle re-merge conditions. The > first method is based on control plane handling the re-merge. In this > case the node detecting the re-merge condition, i.e. the re-merge > node initiates the removal of the re-merge sub-LSP(s) by sending a > PathErr message(s) towards the ingress node. However, this can lead > to a deadlock in setting up the P2MP LSP in certain cases; for > example, when the first S2L setup causes the re-merge with all > subsequent S2Ls in the tree. > > I am glad you are now discussing the mechanisms in 4875, but I disagree > that there is a deadlock condition as you claim. You are saying that if > the first S2L sub-LSP takes a route that causes all other S2L sub-LSPs > to re-merge then there will be deadlock. Far from it! What will happen > is that a PathErr will be sent for each subsequent S2L sub-LSP stating > "re-merge", and the destinations for each subsequent S2L sub-LSP will > be added to the set of destinations in the first S2L sub-LSP. > > So, what is the issue with the first mechanism in 4875? > > --- > > In the Introduction... > > [RFC4736] defines procedures and signaling extensions for > reoptimizing an inter-domain P2P LSP. Specifically, an ingress node > sends a "path re-evaluation request" to a border node by setting a > flag (0x20) in SESSION_ATTRIBUTES object in a Path message. A border > node sends a PathErr code 25 (notify error defined in [RFC3209]) with > sub-code 6 to indicate "preferable path exists" to the ingress node. > The ingress node upon receiving this PathErr may initiate > reoptimization of the LSP. [RFC4736] however does not define a > procedure to reoptimize the entire P2MP LSP as a whole tree. > > I'm afraid that the mechanism you have accurately described could be > used precisely as specified for reoptimising the whole tree since such > reoptimization takes place from the ingress node. > > But I think (from 1.1) that you are trying to describe the subtleties > involved in reoptimizing only some parts of the tree downstream of the > reporting border node. > > Firstly, you need to clarify the problem being addressed with clearer > text in the Introduction. > > Then you need to decide why you need to address the problem. In 4736 > there is no distinction made about which of the loose hops should be > reomptimised and which not. So it is unclear why you should want to > apply such a filter in the case of a P2MP LSP. If there is a reason > it would be good to set it out in more detail. > > It is also possible that the ingress will want to dampen its activity to > ensure is receives all 25/6 reports before starting reoptimization. It > is also possible that if you ignore the way 4875 handles remerge, this > could get complicated. > > --- > > In the Introduction... > > The > Sub-Group-Based reoptimization is not always applicable because it > can lead to data duplication inside the backbone. > > I am suspicious of this statement! Are you saying that the remerge > issues may give rise to data duplication? Or is it the make-before- > break nature that may cause the problem? Is it a transitory problem > during the one or two seconds of signaling change, or is it a long-term > problem? > > If you want to persist with this assertion then you need to substantiate > it in the draft. > > --- > > The comparison in Section 1.1 of re-merge "avoidance" with crankback is > interesting, but the two issues are different. Crankback is designed to > facilitate re-route to avoid blocking resources, while re-merge > avoidance is about moving destinations from one sub-tree to another. > > But, you could consider the PathErr mechanism of 4875 as crankback > because it reports the error relating to the re-merge node, it unpicks > the LSP setup, and it allows an upstream node to "correct" the issue. > > The only thing that you might want to add to 4875 is the replacement of > the ID of the reporting node with the ID of the reporting domain so that > the upstream node can apply meaning to the PathErr. Maybe if the problem > was clearly described, this solution would stand out. > > --- > > Section 1.3 says that this work is limited to "multiple routing domains > that belong to a single administrative area. Use case for the Multiple > administrative domains (e.g. autonomous systems) is outside the scope > of this document." > > A couple of points: > - An "administrative area" is a new term and the next sentence uses > "administrative domains" so that is probably what you mean. > - It is unclear whether multiple ASes is in scope since the second > sentence appears to rule them out, but multiple ASes may be under > the care of one administrator. > - You haven't given any reason for excluding multiple administrative > domains, and that would help people understand what your objectives > are and what the problems are. > > --- > > Section 3 > > It is RECOMMENDED that boundary re-routing is requested for P2MP LSPs > > The use of upper case "RECOMMENDED" is equivalent to "SHOULD". This is > usually protocol requirements language. Anyway, if you use "SHOULD" you > also need to discuss the associated "MAY". > > --- > > In Section 3.1 you recommend that the ingress node of a P2MP LSP selects > the same ingress border node in the loose hop ERO for all sibling S2L > sub-LSPs that transit through a given domain. > > This, of course, produces sub-optimal LSPs and can be resolved using > PCE. > > But I am interested in the overlap between this statement and the scope > statement in 1.3. You are recommending using only single attachments > between domains: that means that remerge can only happen when the sub- > LSPs transit different domains and come back together in a further > domain. But since you are (apparently) limiting to IGP areas and ruling > out ASes, the largest domain diameter you have is 3 with the result that > remerge is entirely impossible! > > --- > > In Section 3.1 you have "RECOMMENDED". What is the associated "MAY"? > > --- > > Here's another example from Section 3.2 > > If an ingress border node on the path of the P2MP LSP is unable to > find a route that can supply the required resources or that is re- > merge free, it MUST generate a PathErr message for the subset of the > S2L sub-LSPs which it is not able to route. > > This implies that the border node is trying to find a disjoint path. > Such a path represents a waste of network resources that is *worse* > than the data plane remerge case that you reject as a bad idea. > > The point of re-merge avoidance is simply moving destinations from one > sub-tree to another and it can only be done at the branch point for the > two trees - or even at the ingress depending on your signaling approach > and explicit paths. > > --- > > Section 3.2 > > For this purpose the > ingress border node SHOULD try to find a minimum subset of S2L sub- > LSPs for which the PathErr needs to be generated towards the ingress > node. These are the S2L sub-LSPs on an incoming interface that has > less number of S2L sub-LSPs compared to the second incoming interface > that is causing the re-merge condition. > > OK. It took me four or five readings and a lot of pain to parse what you > are trying to say. > > You are saying that, if the border node is a branch node for two sets of > sub-LSPs that are remerging, then the border node should fix this by > moving the smaller set to share the path with the larger set. > > There are two reasons why this is a bad idea: > > 1. The first set may have been set up with a Path/Resv exchange, while > the second set has not been set up and a PathErr was returned. > Maybe the remerge node could have made the decision you are > suggesting, but even that sounds like a bad idea. > > 2. The choice of the correct path to the remerge node should be made > according to which is the shortest path, not which path has the > most destinations. > > --- > > Section 3.2 > > The RSVP-TE Notify messages do not include S2L_SUB_LSP objects and > cannot be used to send errors for a subset of the S2L sub-LSPs in a > Path message. > > This is not true! > > A Downstream Notify message (headed upstream) is described in RFC 3473 > as: > > ::= [] > [ [ | ] ... ] > [ ] > > > ::= [ ] > | > > > ::= [...] > > > And according to RFC 4875, nets down to one or > more of... > > ::= > [ ] > > --- > > Section 3.2 > > A border node receiving a PathErr message for a set of S2L sub-LSPs > MAY hold the message and attempt to signal an alternate path that can > avoid re-merge through its domain for those S2L sub-LSPs that pass > through it. However, in the case of a re-merge error for which some > of the re-merging S2L sub-LSPs do not pass through the border node, > it SHOULD propagate the PathErr upstream towards the ingress node. If > the subsequent attempt by the border node is successful, the border > node discards the held PathErr and follows the crankback roles of > [RFC4920] and [RFC5151]. If repeated subsequent attempts by the > border node are unsuccessful, the border node MUST send the held > PathErr upstream towards the ingress node. > > How can an attempt to avoid re-merge be unsuccessful? There is already a > suitable path. We know this because the re-merge has happened. > > --- > > Section 3.2 > > If the ingress node receives a PathErr message with error code > "Routing Problem" and error value "ERO resulted in re-merge", then it > SHOULD attempt to signal an alternate path through a different domain > or through a different border node for the affected S2L sub-LSPs. The > ingress node MAY use the error node information from the PathErr for > this purpose. > > This is plain wrong. It should attempt to move the destinations to the > same sub-tree, not try to signal the remerging destinations on a > diverse sub-tree. > > --- > > Section 4 purports to be about the dataplane re-merge handling scenario, > and it starts well. But then... > > The following sections define the RSVP-TE signaling extensions for > "P2MP- TE Re-merge Recording Request" and "P2MP-TE Re-merge Present" > messages. > > That look like it is control plane work and so does not belong in this > section. > > Furthermore, this section appears to be offering a third solution to add > to the two noted in 4875. That is, you are proposing that dataplane > handling should be used, but that the control plane should be used to > resolve the issue. > > This is an OK idea, but was discussed at the time of 4875 when two > approaches handling this situation were discussed. > > 1. Use a Notify message sent after the Resv > 2. Use a non-destructive PathErr sent after the Resv > > Admittedly, neither of those approaches is quite tidy, but it was > thought that if you cared about the remerge you would fix it at setup > time, and if you didn't care, then you didn't care. Thus the case you > are fixing is a corner case (care a bit, but not too much) and the > existing untidy solutions are enough. > > Nevertheless, the mechanism you describe does provide some additional > useful diagnostics, and so should not be ruled out. Of course, those > diagnostics are already visible simply by inspecting the full set of > RRO information from the various S2L sub-LSPs as a re-merge point will > show up as the same node appearing in two different sub-trees. Thus, the > question only applies when RRO information is being stripped at domain > boundaries. > > However, this last issue is the one you note in the final paragraph of > section 4.3. There you appear to say that since the re-merge report info > would be stripped from the Resv, the Resv should be discarded and a > PathErr sent upstream. That would be fine, but it does seem to leave > half an LSP provisioned and doing nothing (downstream between the border > node and the re-merge point) > > --- > > 4.3 > > This can be achieved by computing and > selecting alternate path(s) for the S2L(s) bypassing the re-merge > node(s). > > Again, avoiding the remerge node is not the best result. > > --- > > Section 5 > > Re-merges between S2Ls in a single domain can occur due to > provisioning errors or path computation errors in the environment > where IGP-TE or PCE is used. > > What is a "provisioning error"? Are you referring to cases where the > EROs of P2MP trees are entered by hand? > > What has IGP-TE to do with this? > > If PCE (whether a separate component or embedded in an LSR) is making > such fundamental computation errors, then we should certainly not crash, > but I also don't think we should optimise the protocol to handle it. > This represents a critical implementation bug! > > --- > > Section 6.3 > > Using signaling procedure defined in [RFC4736], an ingress node MUST > initiate "path re-evaluation request" query to reoptimize a > destination in a P2MP LSP. Note that this message MUST be used to > reoptimize a single or a sub-set of the destinations in a P2MP LSP. > Ingress node MUST send this query in a Path message for each > destination it is reoptimizing. > > When a Path message for a destination in a P2MP LSP with "path > re-evaluation request" flag [RFC4736] is received at the border node, > it MUST re-compute the loose-hop ERO to see if a preferable path > exists for that destination. > > I am hugely worried about your use of 2119 language in this text. Is it > your intention to redefine the procedures of RFC 4736? Because that is > what you are doing! > > Perhaps you consider that you are only defining the procedures for P2MP > LSPs with the claim that they were not covered by 4736. I don't see on > what evidence such a claim would be made, and I am particularly > concerned that you have turned the request in 4736 into a demand in your > draft. > > --- > > Section 6.3 is almost impossible to understand. I think there are > probably some assumptions that a request to reoptimise the path to a > single destination would: > a. be made > b. be responded with "not telling you, but I could reoptimise the > whole sub-tree." > > On the other hand, there also seems to be a desire to send a > reoptimise request that identifies just on destination, but is actually > a request to reoptimise the whole tree. > > Colour me confused! > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > From prvs=0868b280ec=eric.gray@ericsson.com Wed Jun 5 12:01:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF6C21F9C49 for ; Wed, 5 Jun 2013 12:01:57 -0700 (PDT) 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=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwNYT8lC1Nz7 for ; Wed, 5 Jun 2013 12:01:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDF921F9C3E for ; Wed, 5 Jun 2013 12:01:42 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-a4-51af8b0eecd3 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D8.AA.05617.E0B8FA15; Wed, 5 Jun 2013 21:01:34 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 15:01:34 -0400 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVO2jVdv3lmzr0iBYQoJl/eoppkngPbg Date: Wed, 5 Jun 2013 19:01:33 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60B4AE0@eusaamb107.ericsson.se> References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXRPiC5f9/pAg9Z/xhadU+Ut/s2dw2zx /dISFotbS1eyOrB4LFnyk8lj1vQ2No8vlz+zBTBHcdskJZaUBWem5+nbJXBn3Fswj7FgunBF 08fdTA2M6/m7GDk5JARMJN5dnc0OYYtJXLi3nq2LkYtDSOAoo8SUdXsYIZxljBKXDk1iA6li E9CQOHZnLSOILSJgJ7Hx1T+wImaBBYwSDbd+sHQxcnAIC1RLTO4JgqipkXg85xwTSFhEwEji QqsnSJhFQEXiVcMjsMW8At4Sl1cvBRsvBBQ/+XcZM4jNKaAqMfvJV7AaRqDjvp9awwRiMwuI S9x6Mp8J4mgBiSV7zjND2KISLx//Y4WwlSWWPNnPAlGvI7Fg9yc2CFtbYtnC18wQewUlTs58 wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYwcpcWpZbnpRoabGIExdEyCzXEH44JPlocYpTlYlMR5 dXgXBwoJpCeWpGanphakFsUXleakFh9iZOLgBBFcUg2M0rEHJjiz/X9hIH7+C1NtUeKNaOOb P3pvTL5abuMXu79ih2Da+1knpW+JezbedE9z3VyyNumcaPJ0jc7ASROLY8N2TA+fk/7l8gvt yS67FYKlk1hWqa38XHSr1+3srd93Nsz7y2V0ZdZ9vpvS+dzcWfNWTFrFlFR+4/CT2BeLZ5xX 9NNh1cz+pcRSnJFoqMVcVJwIAJLdkK10AgAA Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 19:01:57 -0000 Don't support at the current time. The draft does not appear to deal reasonably with the case where a desired = remote=20 "Proxy LSP Ping" LSR does not support this capability. I searched and the = phrase "backward compatibility" is not in the full-text version of the draft. I also have some questions about the utility of this capability, given that= this might -=20 for instance - be used by an edge router to task other routers with "pingin= g" toward=20 another edge router. Presumably, this could include routers which are typi= cally not optimized to handle processing of traffic such as Ping responses. This could be made very much worse if - within the context of the service p= rovider=20 network - a large number of edge LSRs were compromised and became agents in= a=20 DDoS attack on the service provider core network. -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 30, 2013 12:35 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.or= g Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-pro= xy-lsp-ping an MPLS working group document Working Group, This is to start a two week poll on adopting draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at 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. This poll ends June 14, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/778/ https://datatracker.ietf.org/ipr/2087/ 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. /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 prvs=8868d8f1d8=eric.gray@ericsson.com Wed Jun 5 14:26:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9941F21F8EFE for ; Wed, 5 Jun 2013 14:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dcv-iesXMeiP for ; Wed, 5 Jun 2013 14:26:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C0D2621F96F5 for ; Wed, 5 Jun 2013 14:26:34 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-c3-51afad043daa Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.F6.17537.40DAFA15; Wed, 5 Jun 2013 23:26:29 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 17:26:28 -0400 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVO2jVdv3lmzr0iBYQoJl/eoppkngPbggAAlfXA= Date: Wed, 5 Jun 2013 21:26:27 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60B4CE4@eusaamb107.ericsson.se> References: <51A77FBD.6010605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXRPiC7r2vWBBu1/hCw6p8pb/Js7h9ni +6UlLBa3lq5kdWDxWLLkJ5PHrOltbB5fLn9mC2CO4rZJSiwpC85Mz9O3S+DO+Pmvl63glGxF 17NO5gbG5+JdjJwcEgImEjcWTmKCsMUkLtxbz9bFyMUhJHCUUeLyxc2sEM4yRokF97vZQKrY BDQkjt1ZywhiiwjYSWx89Y8RpIhZYAGjRMOtHyxdjBwcwgLVEpN7giBqaiQezznHBGFbSRx+ vosVpIRFQEWi6XJkFyM7B6+At8QWS5ACIQFViX1bZ7OC2IxA53w/tQaskVlAXOLWk/lQZwpI LNlznhnCFpV4+fgfK4StLLHkyX4WiHodiQW7P7FB2NoSyxa+BqvnFRCUODnzCcsERtFZSMbO QtIyC0nLLCQtCxhZVjFylBanluWmGxlsYgTGyTEJNt0djHteWh5ilOZgURLnVeNdHCgkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDE0RwSTUwNm7wuWrpw3MiUXpp/qWJC8+zP8y/P2ddZI39U0YZ abcHx7oCX89/tGHFcnOtkxsEl8yVF+xQOFB4eO+MlAWsOeYXb/7pU0iI7Mj3MWhUnLF19urf +WXNYtG/lwRXcC/PeHde14kn/HTNfSGzLzPnvLp3bnvlleR9rkr1EqJnHqo+bU3aUyedqsRS nJFoqMVcVJwIAM5rjGhmAgAA Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 21:26:54 -0000 In addition to the previously noted issues, from discussion, it looks like = the values "assigned" in the IANA considerations section are at least questionable at this point. At present, there is only one obvious clash in these assignments (the draft= "assigns" the value "5" in the "Downstream [Mapping Address Type] Registry" and this value has = already been=20 assigned via RFC 6426). However, the MPLS WG now has in place an early ass= ignment process=20 and it may be the case that other assignments have been made via this proce= ss and a clash will=20 occur when these are permanently assigned later. As a NIT - compounding the issues in this case - two of the affected Regist= ries are incorrectly named in the IANA section. These values should be replaced with "variables" (e.g. - TBA-1, TBA-2, TBA-= 3, etc.) before the draft is adopted as a WG draft. Once adopted, the authors of this draft ma= y then apply for=20 early assignments via the existing process. -- Eric -----Original Message----- From: Eric Gray=20 Sent: Wednesday, June 05, 2013 3:02 PM To: 'Loa Andersson'; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.or= g Subject: RE: [mpls] Poll to see if we have consensus to make draft-lim-mpls= -proxy-lsp-ping an MPLS working group document Don't support at the current time. The draft does not appear to deal reasonably with the case where a desired = remote "Proxy LSP Ping" LSR does not support this capability. I searched a= nd the phrase "backward compatibility" is not in the full-text version of t= he draft. I also have some questions about the utility of this capability, given that= this might - for instance - be used by an edge router to task other router= s with "pinging" toward another edge router. Presumably, this could includ= e routers which are typically not optimized to handle processing of traffic= such as Ping responses. This could be made very much worse if - within the context of the service p= rovider network - a large number of edge LSRs were compromised and became a= gents in a DDoS attack on the service provider core network. -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 30, 2013 12:35 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.or= g Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-pro= xy-lsp-ping an MPLS working group document Working Group, This is to start a two week poll on adopting draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at 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. This poll ends June 14, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/778/ https://datatracker.ietf.org/ipr/2087/ 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. /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 loa@pi.nu Thu Jun 6 02:22:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B286721F9815 for ; Thu, 6 Jun 2013 02:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIUPdQQUFvQQ for ; Thu, 6 Jun 2013 02:22:51 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 18BEB21F96E1 for ; Thu, 6 Jun 2013 02:22:41 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C8CA0180101A; Thu, 6 Jun 2013 11:22:27 +0200 (CEST) Message-ID: <51B054D3.1070209@pi.nu> Date: Thu, 06 Jun 2013 11:22:27 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Gray References: <51A77FBD.6010605@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF60B4CE4@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF60B4CE4@eusaamb107.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 09:22:55 -0000 Eric, You point at an issue that we need to resolve. From a working group point of view there is no "early allocation" made for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there can't be any early allocation made, since these can be made only to working group documents. RFC 4020 says "The processes described below assume that the document in question is the product of an IETF Working Group." There is a practice among many authors to "propose" values in the IANA section. For new registries this is at least semi-encouraged. For existing registries this practice is most of the time not harmful, but could create problems if the proposed values are actually used in implementations. It is RECOMMENDED that our documents use the tbd-1 style variables. The problem here is the definition of "our documents", strictly draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be one of "our documents" until it actually is accepted as a working group document - when the working group take over the revision control. The working group can't tell the authors what to do with the document, until it becomes a working group document! My conclusion is that the issues on the IANA allocation you point to is a reason to making it a working group document. There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and draft-ietf-mpls-return-path-specified-lsp-ping are looking to assign new TLV Type values, it might be that the value proposed by draft-lim-mpls-proxy-lsp-ping (Type 22) is already assigned when we request publication of theis draft. Note: draft-lim-mpls-proxy-lsp-ping is currently in wg poll and should for the time being not be updated. /Loa On 2013-06-05 23:26, Eric Gray wrote: > In addition to the previously noted issues, from discussion, it looks like the values "assigned" > in the IANA considerations section are at least questionable at this point. > > At present, there is only one obvious clash in these assignments (the draft "assigns" the value > "5" in the "Downstream [Mapping Address Type] Registry" and this value has already been > assigned via RFC 6426). However, the MPLS WG now has in place an early assignment process > and it may be the case that other assignments have been made via this process and a clash will > occur when these are permanently assigned later. > > As a NIT - compounding the issues in this case - two of the affected Registries are incorrectly > named in the IANA section. > > These values should be replaced with "variables" (e.g. - TBA-1, TBA-2, TBA-3, etc.) before the > draft is adopted as a WG draft. Once adopted, the authors of this draft may then apply for > early assignments via the existing process. > > -- > Eric > > -----Original Message----- > From: Eric Gray > Sent: Wednesday, June 05, 2013 3:02 PM > To: 'Loa Andersson'; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > Subject: RE: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document > > Don't support at the current time. > > The draft does not appear to deal reasonably with the case where a desired remote "Proxy LSP Ping" LSR does not support this capability. I searched and the phrase "backward compatibility" is not in the full-text version of the draft. > > I also have some questions about the utility of this capability, given that this might - for instance - be used by an edge router to task other routers with "pinging" toward another edge router. Presumably, this could include routers which are typically not optimized to handle processing of traffic such as Ping responses. > > This could be made very much worse if - within the context of the service provider network - a large number of edge LSRs were compromised and became agents in a DDoS attack on the service provider core network. > -- > Eric > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, May 30, 2013 12:35 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document > > Working Group, > > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working group mailing list (mpls at 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. > > This poll ends June 14, 2013. > > There are two IPR claims against this document: > > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ > > > 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. > > /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 jdrake@juniper.net Thu Jun 6 05:56:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACD421F998D for ; Thu, 6 Jun 2013 05:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCFWvts0I3iy for ; Thu, 6 Jun 2013 05:55:59 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6270721F93E0 for ; Thu, 6 Jun 2013 05:55:59 -0700 (PDT) Received: from mail61-va3-R.bigfish.com (10.7.14.234) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 6 Jun 2013 12:55:58 +0000 Received: from mail61-va3 (localhost [127.0.0.1]) by mail61-va3-R.bigfish.com (Postfix) with ESMTP id 3D80D36039E for ; Thu, 6 Jun 2013 12:55:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I146fI542Iec9I1432Ic1dM4015Idb82ha097ozz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz31h2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: softfail (mail61-va3: transitioning domain of juniper.net does not designate 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=jdrake@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail61-va3 (localhost.localdomain [127.0.0.1]) by mail61-va3 (MessageSwitch) id 13705232921469_16807; Thu, 6 Jun 2013 12:54:52 +0000 (UTC) Received: from VA3EHSMHS040.bigfish.com (unknown [10.7.14.225]) by mail61-va3.bigfish.com (Postfix) with ESMTP id 917C01602F9 for ; Thu, 6 Jun 2013 12:54:44 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.52) by VA3EHSMHS040.bigfish.com (10.7.99.50) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 6 Jun 2013 12:54:42 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 6 Jun 2013 05:53:54 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 6 Jun 2013 05:53:53 -0700 Received: from DB8EHSOBE012.bigfish.com (213.199.154.189) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 6 Jun 2013 05:56:57 -0700 Received: from mail146-db8-R.bigfish.com (10.174.8.234) by DB8EHSOBE012.bigfish.com (10.174.4.75) with Microsoft SMTP Server id 14.1.225.23; Thu, 6 Jun 2013 12:53:51 +0000 Received: from mail146-db8 (localhost [127.0.0.1]) by mail146-db8-R.bigfish.com (Postfix) with ESMTP id 86CA03A0062 for ; Thu, 6 Jun 2013 12:53:51 +0000 (UTC) Received: from mail146-db8 (localhost.localdomain [127.0.0.1]) by mail146-db8 (MessageSwitch) id 1370523228852367_7426; Thu, 6 Jun 2013 12:53:48 +0000 (UTC) Received: from DB8EHSMHS019.bigfish.com (unknown [10.174.8.229]) by mail146-db8.bigfish.com (Postfix) with ESMTP id C3F98160061; Thu, 6 Jun 2013 12:53:48 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS019.bigfish.com (10.174.4.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 6 Jun 2013 12:53:48 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0311.000; Thu, 6 Jun 2013 12:53:45 +0000 From: John E Drake To: "adrian@olddog.co.uk" Thread-Topic: [mpls] AD review of draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp Thread-Index: Ac5X8Z5cL5m9BeCeSFm7SPc+FcNigQKwe9/A Date: Thu, 6 Jun 2013 12:53:44 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D51A752@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <04ae01ce57f1$a6b72b80$f4258280$@olddog.co.uk> In-Reply-To: <04ae01ce57f1$a6b72b80$f4258280$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:56:05 -0000 Adrian, The draft is not only ill-considered, because it tries to solve problems th= at are already solved, but also so poorly written that it is impossible to = tell whether it solves these already solved problems, although I suspect no= t.=20 Yours Irrespectively, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Thursday, May 23, 2013 1:11 PM > To: draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: [mpls] AD review of draft-ietf-mpls-inter-domain-p2mp-rsvp-te- > lsp >=20 > Hi, >=20 > I have done my usual AD review of this draft on receipt of the > publication request from the MPLS WG chairs. As well as the desire to > remove issues that might otherwise show up during IETF last call and > IESG review (thereby saving resources), my review is to make sure that > I understand the intention and details of the work so that I can > support the document as it goes through these later reviews and also > the publication process. >=20 > As you will see from my comments below, I am not currently comfortable > with the document. At the moment I am not saying that the proposals are > bad and dangerous, although I am at least believing them to be > unnecessary and based on some misstatements of the problems that need > to be addressed. >=20 > I understand that the chairs report there is WG consensus behind this > document in its current form, but I am unable to support it for > publication as an RFC. >=20 > You have two options open to you to advance your work as a standards > track RFC. Firstly, you could seek to address my concerns through a > combination of changes to the text and discussions with me. Secondly, > you can attempt to find another AD to sponsor the work - possibly > Stewart is a good starting point. >=20 > For the moment, I am returning the I-D to the working group. >=20 > Thanks, > Adrian >=20 > --- >=20 > Was this document shown to the CCAMP working group? The P2MP work > (4875) was developed in partnership with CCAMP because it was intended > to be equally applicable to MPLS-TE and GMPLS. Presumably this is also > true of this work. You might find that by consulting CCAMP you are > able to get some more P2MP implementers to have a look at the problems > this draft is proposing to solve. >=20 > --- >=20 > I am surprised that the working group has taken this approach to the > described problem of re-merge avoidance. This problem is addressed by > the combination of PCE and Path Keys. However, if the working group has > considered that approach and has consensus to take this other approach, > I will not object. >=20 > Could the chairs confirm that the existing mechanisms have been > considered and that the WG determined to add new extensions to the > signaling protocols instead. >=20 > --- >=20 > I'm afraid I find myself wondering whether this document is addressing > the wrong problem :-( Re-merge is a bad thing to have as a persistent > situation, and certainly must not be allowed to cause data duplication > downstream of the re-remerge point. >=20 > However, avoiding re-merge by selecting disjoint paths is not the > solution. If re-merge happens, it is because the path to one set of > destinations has intersected the path to another set of destinations. > When this happens, one of the two paths to the re-merge point must be > optimal (for *any* definition of optimal) or the paths are equally > optimal. In either case, the correct solution is to move all of the > destinations (the union of the two sets) onto the same path and prune > out the sub-optimal one. In this case, the bottom line will be that the > upstream branch was wrong to use two distinct domain border nodes for > the two sets of destinations. That is the problem that needs to be > fixed. >=20 > What I seem to be reading here is an attempt to avoid re-merge that > favors the use of suboptimal paths. In many network configurations that > will be impossible. But in any case, it will prove as costly in terms > of network resources as the re-merge itself. >=20 > The discussion about re-optimization using 4736, is a different problem > that you can raise. The description of the problem doesn't really > surface until the description of the solution in Section 1.1, which is > a pity. This is largely a descriptive issue, although I would argue > that the partial reomptimization is easily handled using partial > resignaling, and therefore without any protocol extensions. >=20 > --- >=20 > Please fix the minor spacing not reported by idnits. >=20 > --- >=20 > idnits shows several problems with references. >=20 > You are missing RFC 2119 from the normative references. > You are missing RFC 4874 from the informative references. > You are missing RFC 2205 from the normative references. > RFC 4726 is an informative reference, but not cited. Possibly work it > into the 4th para of the Introduction? > RFC 5920 is a downref. Does it need to be a normative reference? > RFC 4736 is a downref. It appears that you are using it in a normative > way - please confirm this so that we can handle the downref correctly. >=20 > Document Shepherd - please update the write-up to correctly note the > downrefs that remain after this work. >=20 > --- >=20 > Please remove citations from the Abstract. The Abstract is stand-alone > text and cannot have external references. >=20 > --- >=20 > The Abstract is not clear and needs work. > - The issues *may* arise, but do not always arise > - The "computation of loosely routed inter-domain P2MP-TE LSP paths > that > are re-merge free" is not an issue and is not addressed in this > document. Please describe the actual issue you are addressing. > - s/vs./versus/ > - I don't think "the loosely routing domain ingress border node is not > aware of the reoptimization scope" describes a problem well because > the issue is the "there is no way to indicate which branches of the > P2MP tree are to be reoptimised". > - In the light of my observation that techniques already exist to > address the problems described in this document, it may be too strong > to say "This document defines the required protocol extensions needed > for ..." Maybe change this to "This document defines signaling > protocol extensions for..." >=20 > --- >=20 > It would really help the reader and reviewers if someone could take an > editorial pass on the document. This is not so much a problem of > English usage as missing words and such like. A native speaker would > clean it up very quickly and avoid the risk of the RFC Editor > accidentally breaking the technical content. >=20 > --- >=20 > In the Introduction... >=20 > Consequently one > of the requirements for signaling P2MP LSPs is to choose a P2MP path > that is re-merge free. >=20 > Is this a signaling requirement? > 1. Surely it is a path computation requirement, if it is a requirement > at all. > 2. Isn't the point that signaling is supposed to detect and resolve > re-merge issues rather than avoid them? >=20 > --- >=20 > In the Introduction... >=20 > For the purposes of this document, a domain is considered to be any > collection of network elements within a common sphere of address > management or path computational responsibility. Examples of such > domains include Interior Gateway Protocol (IGP) areas and Autonomous > Systems (ASes). A border node is a node between different routing > domains. >=20 > "domain" or "routing domain"? >=20 > --- >=20 > In the Introduction... >=20 > In that case, the border node for a new domain will be > given loose next hops for one or more destinations in a P2MP LSP. >=20 > s/will be/may be/ ? >=20 > --- >=20 > In the Introduction... >=20 > A > border node can ensure that it computes the re-merge free paths > while > performing loose hop ERO expansions by individually grafting > destinations. Note that the computed P2MP tree by a border node in > this case may not be optimal. >=20 > Why are you suggesting a mechanism for computing paths? That is an > implementation detail. Furthermore, suggesting a mechanism that is > almost certain to generate a suboptimal solution seems perverse! >=20 > --- >=20 > In the Introduction... >=20 > In that case, existing protocol mechanisms > do not provide sufficient information for it to be able to expand > the > loose hop(s) such that the overall P2MP LSP tree is guaranteed to be > re-merge free. >=20 > Weeeeell... >=20 > Even if you don't want to use PCE and Path Key, you could use RRO and > XRO with suitable staggered processing at the branch node. That would > provide sufficient information using existing protocol elements, > although a small (but obvious) piece of processing needs to added at > the branch node >=20 > --- >=20 > In the Introduction... >=20 > [RFC4875] specifies two approaches to handle re-merge conditions. > The > first method is based on control plane handling the re-merge. In > this > case the node detecting the re-merge condition, i.e. the re-merge > node initiates the removal of the re-merge sub-LSP(s) by sending a > PathErr message(s) towards the ingress node. However, this can lead > to a deadlock in setting up the P2MP LSP in certain cases; for > example, when the first S2L setup causes the re-merge with all > subsequent S2Ls in the tree. >=20 > I am glad you are now discussing the mechanisms in 4875, but I disagree > that there is a deadlock condition as you claim. You are saying that if > the first S2L sub-LSP takes a route that causes all other S2L sub-LSPs > to re-merge then there will be deadlock. Far from it! What will happen > is that a PathErr will be sent for each subsequent S2L sub-LSP stating > "re-merge", and the destinations for each subsequent S2L sub-LSP will > be added to the set of destinations in the first S2L sub-LSP. >=20 > So, what is the issue with the first mechanism in 4875? >=20 > --- >=20 > In the Introduction... >=20 > [RFC4736] defines procedures and signaling extensions for > reoptimizing an inter-domain P2P LSP. Specifically, an ingress node > sends a "path re-evaluation request" to a border node by setting a > flag (0x20) in SESSION_ATTRIBUTES object in a Path message. A border > node sends a PathErr code 25 (notify error defined in [RFC3209]) > with > sub-code 6 to indicate "preferable path exists" to the ingress node. > The ingress node upon receiving this PathErr may initiate > reoptimization of the LSP. [RFC4736] however does not define a > procedure to reoptimize the entire P2MP LSP as a whole tree. >=20 > I'm afraid that the mechanism you have accurately described could be > used precisely as specified for reoptimising the whole tree since such > reoptimization takes place from the ingress node. >=20 > But I think (from 1.1) that you are trying to describe the subtleties > involved in reoptimizing only some parts of the tree downstream of the > reporting border node. >=20 > Firstly, you need to clarify the problem being addressed with clearer > text in the Introduction. >=20 > Then you need to decide why you need to address the problem. In 4736 > there is no distinction made about which of the loose hops should be > reomptimised and which not. So it is unclear why you should want to > apply such a filter in the case of a P2MP LSP. If there is a reason it > would be good to set it out in more detail. >=20 > It is also possible that the ingress will want to dampen its activity > to ensure is receives all 25/6 reports before starting reoptimization. > It is also possible that if you ignore the way 4875 handles remerge, > this could get complicated. >=20 > --- >=20 > In the Introduction... >=20 > The > Sub-Group-Based reoptimization is not always applicable because it > can lead to data duplication inside the backbone. >=20 > I am suspicious of this statement! Are you saying that the remerge > issues may give rise to data duplication? Or is it the make-before- > break nature that may cause the problem? Is it a transitory problem > during the one or two seconds of signaling change, or is it a long-term > problem? >=20 > If you want to persist with this assertion then you need to > substantiate it in the draft. >=20 > --- >=20 > The comparison in Section 1.1 of re-merge "avoidance" with crankback is > interesting, but the two issues are different. Crankback is designed to > facilitate re-route to avoid blocking resources, while re-merge > avoidance is about moving destinations from one sub-tree to another. >=20 > But, you could consider the PathErr mechanism of 4875 as crankback > because it reports the error relating to the re-merge node, it unpicks > the LSP setup, and it allows an upstream node to "correct" the issue. >=20 > The only thing that you might want to add to 4875 is the replacement of > the ID of the reporting node with the ID of the reporting domain so > that the upstream node can apply meaning to the PathErr. Maybe if the > problem was clearly described, this solution would stand out. >=20 > --- >=20 > Section 1.3 says that this work is limited to "multiple routing domains > that belong to a single administrative area. Use case for the Multiple > administrative domains (e.g. autonomous systems) is outside the scope > of this document." >=20 > A couple of points: > - An "administrative area" is a new term and the next sentence uses > "administrative domains" so that is probably what you mean. > - It is unclear whether multiple ASes is in scope since the second > sentence appears to rule them out, but multiple ASes may be under > the care of one administrator. > - You haven't given any reason for excluding multiple administrative > domains, and that would help people understand what your objectives > are and what the problems are. >=20 > --- >=20 > Section 3 >=20 > It is RECOMMENDED that boundary re-routing is requested for P2MP > LSPs >=20 > The use of upper case "RECOMMENDED" is equivalent to "SHOULD". This is > usually protocol requirements language. Anyway, if you use "SHOULD" > you also need to discuss the associated "MAY". >=20 > --- >=20 > In Section 3.1 you recommend that the ingress node of a P2MP LSP > selects the same ingress border node in the loose hop ERO for all > sibling S2L sub-LSPs that transit through a given domain. >=20 > This, of course, produces sub-optimal LSPs and can be resolved using > PCE. >=20 > But I am interested in the overlap between this statement and the scope > statement in 1.3. You are recommending using only single attachments > between domains: that means that remerge can only happen when the sub- > LSPs transit different domains and come back together in a further > domain. But since you are (apparently) limiting to IGP areas and > ruling out ASes, the largest domain diameter you have is 3 with the > result that remerge is entirely impossible! >=20 > --- >=20 > In Section 3.1 you have "RECOMMENDED". What is the associated "MAY"? >=20 > --- >=20 > Here's another example from Section 3.2 >=20 > If an ingress border node on the path of the P2MP LSP is unable to > find a route that can supply the required resources or that is re- > merge free, it MUST generate a PathErr message for the subset of the > S2L sub-LSPs which it is not able to route. >=20 > This implies that the border node is trying to find a disjoint path. > Such a path represents a waste of network resources that is *worse* > than the data plane remerge case that you reject as a bad idea. >=20 > The point of re-merge avoidance is simply moving destinations from one > sub-tree to another and it can only be done at the branch point for the > two trees - or even at the ingress depending on your signaling approach > and explicit paths. >=20 > --- >=20 > Section 3.2 >=20 > For this purpose the > ingress border node SHOULD try to find a minimum subset of S2L sub- > LSPs for which the PathErr needs to be generated towards the ingress > node. These are the S2L sub-LSPs on an incoming interface that has > less number of S2L sub-LSPs compared to the second incoming > interface > that is causing the re-merge condition. >=20 > OK. It took me four or five readings and a lot of pain to parse what > you are trying to say. >=20 > You are saying that, if the border node is a branch node for two sets > of sub-LSPs that are remerging, then the border node should fix this by > moving the smaller set to share the path with the larger set. >=20 > There are two reasons why this is a bad idea: >=20 > 1. The first set may have been set up with a Path/Resv exchange, while > the second set has not been set up and a PathErr was returned. > Maybe the remerge node could have made the decision you are > suggesting, but even that sounds like a bad idea. >=20 > 2. The choice of the correct path to the remerge node should be made > according to which is the shortest path, not which path has the > most destinations. >=20 > --- >=20 > Section 3.2 >=20 > The RSVP-TE Notify messages do not include S2L_SUB_LSP objects and > cannot be used to send errors for a subset of the S2L sub-LSPs in a > Path message. >=20 > This is not true! >=20 > A Downstream Notify message (headed upstream) is described in RFC 3473 > as: >=20 > ::=3D [] > [ [ | ] ... ] > [ ] > >=20 > ::=3D [ ] > | > >=20 > ::=3D [...] > >=20 > And according to RFC 4875, nets down to one or > more of... >=20 > ::=3D > [ ] >=20 > --- >=20 > Section 3.2 >=20 > A border node receiving a PathErr message for a set of S2L sub-LSPs > MAY hold the message and attempt to signal an alternate path that > can > avoid re-merge through its domain for those S2L sub-LSPs that pass > through it. However, in the case of a re-merge error for which some > of the re-merging S2L sub-LSPs do not pass through the border node, > it SHOULD propagate the PathErr upstream towards the ingress node. > If > the subsequent attempt by the border node is successful, the border > node discards the held PathErr and follows the crankback roles of > [RFC4920] and [RFC5151]. If repeated subsequent attempts by the > border node are unsuccessful, the border node MUST send the held > PathErr upstream towards the ingress node. >=20 > How can an attempt to avoid re-merge be unsuccessful? There is already > a suitable path. We know this because the re-merge has happened. >=20 > --- >=20 > Section 3.2 >=20 > If the ingress node receives a PathErr message with error code > "Routing Problem" and error value "ERO resulted in re-merge", then > it > SHOULD attempt to signal an alternate path through a different > domain > or through a different border node for the affected S2L sub-LSPs. > The > ingress node MAY use the error node information from the PathErr for > this purpose. >=20 > This is plain wrong. It should attempt to move the destinations to the > same sub-tree, not try to signal the remerging destinations on a > diverse sub-tree. >=20 > --- >=20 > Section 4 purports to be about the dataplane re-merge handling > scenario, and it starts well. But then... >=20 > The following sections define the RSVP-TE signaling extensions for > "P2MP- TE Re-merge Recording Request" and "P2MP-TE Re-merge Present" > messages. >=20 > That look like it is control plane work and so does not belong in this > section. >=20 > Furthermore, this section appears to be offering a third solution to > add to the two noted in 4875. That is, you are proposing that dataplane > handling should be used, but that the control plane should be used to > resolve the issue. >=20 > This is an OK idea, but was discussed at the time of 4875 when two > approaches handling this situation were discussed. >=20 > 1. Use a Notify message sent after the Resv 2. Use a non-destructive > PathErr sent after the Resv >=20 > Admittedly, neither of those approaches is quite tidy, but it was > thought that if you cared about the remerge you would fix it at setup > time, and if you didn't care, then you didn't care. Thus the case you > are fixing is a corner case (care a bit, but not too much) and the > existing untidy solutions are enough. >=20 > Nevertheless, the mechanism you describe does provide some additional > useful diagnostics, and so should not be ruled out. Of course, those > diagnostics are already visible simply by inspecting the full set of > RRO information from the various S2L sub-LSPs as a re-merge point will > show up as the same node appearing in two different sub-trees. Thus, > the question only applies when RRO information is being stripped at > domain boundaries. >=20 > However, this last issue is the one you note in the final paragraph of > section 4.3. There you appear to say that since the re-merge report > info would be stripped from the Resv, the Resv should be discarded and > a PathErr sent upstream. That would be fine, but it does seem to leave > half an LSP provisioned and doing nothing (downstream between the > border node and the re-merge point) >=20 > --- >=20 > 4.3 >=20 > This can be achieved by computing and > selecting alternate path(s) for the S2L(s) bypassing the re-merge > node(s). >=20 > Again, avoiding the remerge node is not the best result. >=20 > --- >=20 > Section 5 >=20 > Re-merges between S2Ls in a single domain can occur due to > provisioning errors or path computation errors in the environment > where IGP-TE or PCE is used. >=20 > What is a "provisioning error"? Are you referring to cases where the > EROs of P2MP trees are entered by hand? >=20 > What has IGP-TE to do with this? >=20 > If PCE (whether a separate component or embedded in an LSR) is making > such fundamental computation errors, then we should certainly not > crash, but I also don't think we should optimise the protocol to handle > it. > This represents a critical implementation bug! >=20 > --- >=20 > Section 6.3 >=20 > Using signaling procedure defined in [RFC4736], an ingress node MUST > initiate "path re-evaluation request" query to reoptimize a > destination in a P2MP LSP. Note that this message MUST be used to > reoptimize a single or a sub-set of the destinations in a P2MP LSP. > Ingress node MUST send this query in a Path message for each > destination it is reoptimizing. >=20 > When a Path message for a destination in a P2MP LSP with "path > re-evaluation request" flag [RFC4736] is received at the border > node, > it MUST re-compute the loose-hop ERO to see if a preferable path > exists for that destination. >=20 > I am hugely worried about your use of 2119 language in this text. Is it > your intention to redefine the procedures of RFC 4736? Because that is > what you are doing! >=20 > Perhaps you consider that you are only defining the procedures for P2MP > LSPs with the claim that they were not covered by 4736. I don't see on > what evidence such a claim would be made, and I am particularly > concerned that you have turned the request in 4736 into a demand in > your draft. >=20 > --- >=20 > Section 6.3 is almost impossible to understand. I think there are > probably some assumptions that a request to reoptimise the path to a > single destination would: > a. be made > b. be responded with "not telling you, but I could reoptimise the > whole sub-tree." >=20 > On the other hand, there also seems to be a desire to send a reoptimise > request that identifies just on destination, but is actually a request > to reoptimise the whole tree. >=20 > Colour me confused! >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From prvs=6869812cb3=eric.gray@ericsson.com Thu Jun 6 07:18:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653EB21F8EC6 for ; Thu, 6 Jun 2013 07:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orSRmHDpYwND for ; Thu, 6 Jun 2013 07:17:57 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A840921F8617 for ; Thu, 6 Jun 2013 07:17:56 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-ee-51b09a13f790 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 14.7D.17537.31A90B15; Thu, 6 Jun 2013 16:17:55 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 10:17:55 -0400 From: Eric Gray To: Loa Andersson Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVO2jVdv3lmzr0iBYQoJl/eoppkngPbggAAlfXCAARCsgIAACzSw Date: Thu, 6 Jun 2013 14:17:54 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60B5149@eusaamb107.ericsson.se> References: <51A77FBD.6010605@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF60B4CE4@eusaamb107.ericsson.se> <51B054D3.1070209@pi.nu> In-Reply-To: <51B054D3.1070209@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPiK7wrA2BBiu/Wlh0TpW3+Dd3DrPF 90tLWCxuLV3J6sDisWTJTyaPWdPb2Dy+XP7MFsAcxW2TlFhSFpyZnqdvl8CdcfbYeqaCCRYV 3afWszQwPtTpYuTkkBAwkZh+uZcZwhaTuHBvPRuILSRwlFHi/lfrLkYuIHsZo8TOlbfZQRJs AhoSx+6sZQSxRQRkJa5t+8kEUsQscJBRYssaEIeDQ1igWmJyTxBETY3E4znnmCBsN4kDT9az g5SwCKhIbPtRAxLmFfCWuHlxFxPErkZGiYm/nrOB1HAKqEqsa8sHqWEEuu37qTVgY5gFxCVu PZnPBHGzgMSSPeeh7heVePn4HyuErSyx5Ml+Foh6HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJ jGKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLYxAiMoGMSbLo7GPe8tDzEKM3BoiTOq8a7 OFBIID2xJDU7NbUgtSi+qDQntfgQIxMHJ4jgkmpgVG/7NP/M69xXFqneeYmWXy9ovHvy8fKR jiXHvf+sF1RKrHuxheXmh2jZtqvTjgQqXo+O4dScs2LSU5MfvGYzpNT2tqx8cshqnSYPz3S5 36IN6illr95JfeIq+/9DuWW9XeVkq2nXSs/5XFv/o/jtltjn6fHiz5do3L93POTxpCNr9t92 cVppfFaJpTgj0VCLuag4EQCgt3qXcwIAAA== Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:18:03 -0000 Loa, Mostly good points. However, it is frequently the case that the WG chairs= require=20 certain changes to be made - other than the obvious "name change" for the d= raft - based on comments made during the polling for adoption. This is by no means unusual. This is what I am suggesting needs to be done in this case - i.e. - if the= draft is adopted by the WG, it should not be published as a WG draft without fixing the IANA= section. As to the point you make about the faults in the IANA section being a good= reason to adopt the draft as a working group draft - well - sorry but that is ridicul= ous (as I am sure you will realize if you think about it). If that were true, the easiest way to= get any draft adopted by the WG would be to abuse the IANA Considerations section. We would clearly be risking setting a dangerous precedent by even suggesti= ng this. What should instead be the case is that any private draft that expects to = use an IANA registry that is "owned" by an IETF working group MUST use the "tbd-#" styl= e variables or it can be explicitly removed from the ID repository based on a request from th= e chair(s) of that working group. -- Eric -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Thursday, June 06, 2013 5:22 AM To: Eric Gray Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-pin= g@tools.ietf.org Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls= -proxy-lsp-ping an MPLS working group document Importance: High Eric, You point at an issue that we need to resolve. From a working group point of view there is no "early allocation" made for= draft-lim-mpls-proxy-lsp-ping; as a matter of fact there can't be any earl= y allocation made, since these can be made only to working group documents.= RFC 4020 says "The processes described below assume that the document in q= uestion is the product of an IETF Working Group." There is a practice among many authors to "propose" values in the IANA sect= ion. For new registries this is at least semi-encouraged. For existing registries this practice is most of the time not harmful, but = could create problems if the proposed values are actually used in implement= ations. It is RECOMMENDED that our documents use the tbd-1 style variables. The problem here is the definition of "our documents", strictly draft-lim-m= pls-proxy-lsp-ping does really meet the criteria to be one of "our document= s" until it actually is accepted as a working group document - when the wor= king group take over the revision control. The working group can't tell the authors what to do with the document, unti= l it becomes a working group document! My conclusion is that the issues on = the IANA allocation you point to is a reason to making it a working group d= ocument. There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and draft= -ietf-mpls-return-path-specified-lsp-ping are looking to assign new TLV Typ= e values, it might be that the value proposed by draft-lim-mpls-proxy-lsp-p= ing (Type 22) is already assigned when we request publication of theis draf= t. Note: draft-lim-mpls-proxy-lsp-ping is currently in wg poll and should for the time being not be updated. /Loa On 2013-06-05 23:26, Eric Gray wrote: > In addition to the previously noted issues, from discussion, it looks lik= e the values "assigned" > in the IANA considerations section are at least questionable at this poin= t. > > At present, there is only one obvious clash in these assignments (the=20 > draft "assigns" the value "5" in the "Downstream [Mapping Address=20 > Type] Registry" and this value has already been assigned via RFC=20 > 6426). However, the MPLS WG now has in place an early assignment=20 > process and it may be the case that other assignments have been made via = this process and a clash will occur when these are permanently assigned lat= er. > > As a NIT - compounding the issues in this case - two of the affected=20 > Registries are incorrectly named in the IANA section. > > These values should be replaced with "variables" (e.g. - TBA-1, TBA-2,=20 > TBA-3, etc.) before the draft is adopted as a WG draft. Once adopted,=20 > the authors of this draft may then apply for early assignments via the ex= isting process. > > -- > Eric > > -----Original Message----- > From: Eric Gray > Sent: Wednesday, June 05, 2013 3:02 PM > To: 'Loa Andersson'; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org;=20 > draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > Subject: RE: [mpls] Poll to see if we have consensus to make=20 > draft-lim-mpls-proxy-lsp-ping an MPLS working group document > > Don't support at the current time. > > The draft does not appear to deal reasonably with the case where a desire= d remote "Proxy LSP Ping" LSR does not support this capability. I searched= and the phrase "backward compatibility" is not in the full-text version of= the draft. > > I also have some questions about the utility of this capability, given th= at this might - for instance - be used by an edge router to task other rout= ers with "pinging" toward another edge router. Presumably, this could incl= ude routers which are typically not optimized to handle processing of traff= ic such as Ping responses. > > This could be made very much worse if - within the context of the service= provider network - a large number of edge LSRs were compromised and became= agents in a DDoS attack on the service provider core network. > -- > Eric > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Loa Andersson > Sent: Thursday, May 30, 2013 12:35 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org;=20 > draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > Subject: [mpls] Poll to see if we have consensus to make=20 > draft-lim-mpls-proxy-lsp-ping an MPLS working group document > > Working Group, > > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working group= mailing list (mpls at ietf.org). Please give a technical motivation for yo= ur support/not support, especially if you think that the document should no= t be adopted as a working group document. > > This poll ends June 14, 2013. > > There are two IPR claims against this document: > > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ > > > The authors has stated on the working group mailing list that they are no= t aware of any other IPR claims against this draft. > 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. > > /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 ietfc@btconnect.com Fri Jun 7 06:48:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5C21F94D3 for ; Fri, 7 Jun 2013 06:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ-AvodSmqtu for ; Fri, 7 Jun 2013 06:48:34 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4A00F21F9476 for ; Fri, 7 Jun 2013 06:48:33 -0700 (PDT) Received: from mail119-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE020.bigfish.com (10.174.4.83) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Jun 2013 13:48:31 +0000 Received: from mail119-db8 (localhost [127.0.0.1]) by mail119-db8-R.bigfish.com (Postfix) with ESMTP id A70A3200120; Fri, 7 Jun 2013 13:48:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zz98dI9371I936eI542I1432I62a3Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail119-db8 (localhost.localdomain [127.0.0.1]) by mail119-db8 (MessageSwitch) id 1370612909682952_3656; Fri, 7 Jun 2013 13:48:29 +0000 (UTC) Received: from DB8EHSMHS023.bigfish.com (unknown [10.174.8.231]) by mail119-db8.bigfish.com (Postfix) with ESMTP id 9A66A3C004D; Fri, 7 Jun 2013 13:48:29 +0000 (UTC) Received: from AMXPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.69) by DB8EHSMHS023.bigfish.com (10.174.4.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Jun 2013 13:48:28 +0000 Received: from DBXPRD0411HT005.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.242.9.163) with Microsoft SMTP Server (TLS) id 14.16.311.1; Fri, 7 Jun 2013 13:48:27 +0000 Message-ID: <02fd01ce6385$d18e7ee0$4001a8c0@gateway.2wire.net> From: t.petch To: Eric Gray , Loa Andersson References: <51A77FBD.6010605@pi.nu><48E1A67CB9CA044EADFEAB87D814BFF60B4CE4@eusaamb107.ericsson.se><51B054D3.1070209@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF60B5149@eusaamb107.ericsson.se> Date: Fri, 7 Jun 2013 14:49:17 +0100 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.165] X-OriginatorOrg: btconnect.com Cc: mpls , mpls-chairs@tools.ietf.org, draft-lim-mpls-proxy-lsp-ping@tools.ietf.org Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 13:48:40 -0000 ----- Original Message ----- From: "Eric Gray" To: "Loa Andersson" Cc: ; ; Sent: Thursday, June 06, 2013 3:17 PM > Loa, > > Mostly good points. However, it is frequently the case that the WG chairs require > certain changes to be made - other than the obvious "name change" for the draft - based on > comments made during the polling for adoption. > > This is by no means unusual. Eric I think otherwise. My experience in the IETF is that when an I-D is adopted by a WG, then the only change is to the title. Often the instruction from the WG Chair explicitly spells this out. Of course, changes can be made beforehand, to smooth the adoption, and after, under the control of the WG, but at adoption, I think best not; what might be uncontentious to one party might be a reason for changing their mind to another, so only changing the name obviates that. I agree that the IANA Considerations need work. It would be better IMO if the authors took out the 'hard' values beforehand. If I had to express an opinion, then it would be not to adopt until all those values had been removed (which is not exactly a technical reason). Tom Petch > This is what I am suggesting needs to be done in this case - i.e. - if the draft is adopted > by the WG, it should not be published as a WG draft without fixing the IANA section. > > As to the point you make about the faults in the IANA section being a good reason to > adopt the draft as a working group draft - well - sorry but that is ridiculous (as I am sure you > will realize if you think about it). If that were true, the easiest way to get any draft adopted > by the WG would be to abuse the IANA Considerations section. > > We would clearly be risking setting a dangerous precedent by even suggesting this. > > What should instead be the case is that any private draft that expects to use an IANA > registry that is "owned" by an IETF working group MUST use the "tbd-#" style variables or it > can be explicitly removed from the ID repository based on a request from the chair(s) of that > working group. > > -- > Eric > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, June 06, 2013 5:22 AM > To: Eric Gray > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document > Importance: High > > Eric, > > You point at an issue that we need to resolve. > > From a working group point of view there is no "early allocation" made for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there can't be any early allocation made, since these can be made only to working group documents. RFC 4020 says "The processes described below assume that the document in question is the product of an IETF Working Group." > > There is a practice among many authors to "propose" values in the IANA section. For new registries this is at least semi-encouraged. > > For existing registries this practice is most of the time not harmful, but could create problems if the proposed values are actually used in implementations. It is RECOMMENDED that our documents use the tbd-1 style variables. > > The problem here is the definition of "our documents", strictly draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be one of "our documents" until it actually is accepted as a working group document - when the working group take over the revision control. > > The working group can't tell the authors what to do with the document, until it becomes a working group document! My conclusion is that the issues on the IANA allocation you point to is a reason to making it a working group document. > > There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and draft-ietf-mpls-return-path-specified-lsp-ping are looking to assign new TLV Type values, it might be that the value proposed by draft-lim-mpls-proxy-lsp-ping (Type 22) is already assigned when we request publication of theis draft. > > Note: draft-lim-mpls-proxy-lsp-ping is currently in wg poll and should > for the time being not be updated. > > /Loa > > On 2013-06-05 23:26, Eric Gray wrote: > > In addition to the previously noted issues, from discussion, it looks like the values "assigned" > > in the IANA considerations section are at least questionable at this point. > > > > At present, there is only one obvious clash in these assignments (the > > draft "assigns" the value "5" in the "Downstream [Mapping Address > > Type] Registry" and this value has already been assigned via RFC > > 6426). However, the MPLS WG now has in place an early assignment > > process and it may be the case that other assignments have been made via this process and a clash will occur when these are permanently assigned later. > > > > As a NIT - compounding the issues in this case - two of the affected > > Registries are incorrectly named in the IANA section. > > > > These values should be replaced with "variables" (e.g. - TBA-1, TBA-2, > > TBA-3, etc.) before the draft is adopted as a WG draft. Once adopted, > > the authors of this draft may then apply for early assignments via the existing process. > > > > -- > > Eric > > > > -----Original Message----- > > From: Eric Gray > > Sent: Wednesday, June 05, 2013 3:02 PM > > To: 'Loa Andersson'; mpls@ietf.org > > Cc: mpls-chairs@tools.ietf.org; > > draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > > Subject: RE: [mpls] Poll to see if we have consensus to make > > draft-lim-mpls-proxy-lsp-ping an MPLS working group document > > > > Don't support at the current time. > > > > The draft does not appear to deal reasonably with the case where a desired remote "Proxy LSP Ping" LSR does not support this capability. I searched and the phrase "backward compatibility" is not in the full-text version of the draft. > > > > I also have some questions about the utility of this capability, given that this might - for instance - be used by an edge router to task other routers with "pinging" toward another edge router. Presumably, this could include routers which are typically not optimized to handle processing of traffic such as Ping responses. > > > > This could be made very much worse if - within the context of the service provider network - a large number of edge LSRs were compromised and became agents in a DDoS attack on the service provider core network. > > -- > > Eric > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Loa Andersson > > Sent: Thursday, May 30, 2013 12:35 PM > > To: mpls@ietf.org > > Cc: mpls-chairs@tools.ietf.org; > > draft-lim-mpls-proxy-lsp-ping@tools.ietf.org > > Subject: [mpls] Poll to see if we have consensus to make > > draft-lim-mpls-proxy-lsp-ping an MPLS working group document > > > > Working Group, > > > > This is to start a two week poll on adopting > > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > > > > Please send your comments (support/not support) to the mpls working group mailing list (mpls at 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. > > > > This poll ends June 14, 2013. > > > > There are two IPR claims against this document: > > > > https://datatracker.ietf.org/ipr/778/ > > https://datatracker.ietf.org/ipr/2087/ > > > > > > 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. > > > > /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 > From loa@pi.nu Fri Jun 7 07:00:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7571021F93C4 for ; Fri, 7 Jun 2013 07:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RolAP1bkcIU for ; Fri, 7 Jun 2013 07:00:16 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id D241621F93B9 for ; Fri, 7 Jun 2013 07:00:13 -0700 (PDT) Received: from [109.58.187.224] (109.58.187.224.bredband.tre.se [109.58.187.224]) (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 8B2EA1801110; Fri, 7 Jun 2013 16:00:09 +0200 (CEST) Message-ID: <51B1E768.6030002@pi.nu> Date: Fri, 07 Jun 2013 16:00:08 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "t.petch" References: <51A77FBD.6010605@pi.nu><48E1A67CB9CA044EADFEAB87D814BFF60B4CE4@eusaamb107.ericsson.se><51B054D3.1070209@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF60B5149@eusaamb107.ericsson.se> <02fd01ce6385$d18e7ee0$4001a8c0@gateway.2wire.net> In-Reply-To: <02fd01ce6385$d18e7ee0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls , mpls-chairs@tools.ietf.org, draft-lim-mpls-proxy-lsp-ping@tools.ietf.org Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:00:21 -0000 Fokks, I'd prefer that the hard values before going to poll to make it a working group document; but as a working group chair I would not require that any authors make any changes to any non-working group documents. There are things that needs to be fixed before starting the poll; a perfect IANA section is not one of them. Updating the IANA sections as part of what we do to working group documents; I guess there are numerous author groups that can verify that that happens prior to the request publication. I see no reason to treat drfat-lim- differently. /Loa On 2013-06-07 15:49, t.petch wrote: > ----- Original Message ----- > From: "Eric Gray" > To: "Loa Andersson" > Cc: ; ; > > Sent: Thursday, June 06, 2013 3:17 PM >> Loa, >> >> Mostly good points. However, it is frequently the case that the WG > chairs require >> certain changes to be made - other than the obvious "name change" for > the draft - based on >> comments made during the polling for adoption. >> >> This is by no means unusual. > > Eric > > I think otherwise. My experience in the IETF is that when an I-D is > adopted by a WG, then the only change is to the title. Often the > instruction from the WG Chair explicitly spells this out. > > Of course, changes can be made beforehand, to smooth the adoption, and > after, under the control of the WG, but at adoption, I think best not; > what might be uncontentious to one party might be a reason for changing > their mind to another, so only changing the name obviates that. > > I agree that the IANA Considerations need work. It would be better IMO > if the authors took out the 'hard' values beforehand. If I had to > express an opinion, then it would be not to adopt until all those values > had been removed (which is not exactly a technical reason). > > Tom Petch > >> This is what I am suggesting needs to be done in this case - i.e. - if > the draft is adopted >> by the WG, it should not be published as a WG draft without fixing the > IANA section. >> >> As to the point you make about the faults in the IANA section being a > good reason to >> adopt the draft as a working group draft - well - sorry but that is > ridiculous (as I am sure you >> will realize if you think about it). If that were true, the easiest > way to get any draft adopted >> by the WG would be to abuse the IANA Considerations section. >> >> We would clearly be risking setting a dangerous precedent by even > suggesting this. >> >> What should instead be the case is that any private draft that expects > to use an IANA >> registry that is "owned" by an IETF working group MUST use the "tbd-#" > style variables or it >> can be explicitly removed from the ID repository based on a request > from the chair(s) of that >> working group. >> >> -- >> Eric >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Thursday, June 06, 2013 5:22 AM >> To: Eric Gray >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-lim-mpls-proxy-lsp-ping@tools.ietf.org >> Subject: Re: [mpls] Poll to see if we have consensus to make > draft-lim-mpls-proxy-lsp-ping an MPLS working group document >> Importance: High >> >> Eric, >> >> You point at an issue that we need to resolve. >> >> From a working group point of view there is no "early allocation" > made for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there can't > be any early allocation made, since these can be made only to working > group documents. RFC 4020 says "The processes described below assume > that the document in question is the product of an IETF Working Group." >> >> There is a practice among many authors to "propose" values in the IANA > section. For new registries this is at least semi-encouraged. >> >> For existing registries this practice is most of the time not harmful, > but could create problems if the proposed values are actually used in > implementations. It is RECOMMENDED that our documents use the tbd-1 > style variables. >> >> The problem here is the definition of "our documents", strictly > draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be one of > "our documents" until it actually is accepted as a working group > document - when the working group take over the revision control. >> >> The working group can't tell the authors what to do with the document, > until it becomes a working group document! My conclusion is that the > issues on the IANA allocation you point to is a reason to making it a > working group document. >> >> There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and > draft-ietf-mpls-return-path-specified-lsp-ping are looking to assign new > TLV Type values, it might be that the value proposed by > draft-lim-mpls-proxy-lsp-ping (Type 22) is already assigned when we > request publication of theis draft. >> >> Note: draft-lim-mpls-proxy-lsp-ping is currently in wg poll and should >> for the time being not be updated. >> >> /Loa >> >> On 2013-06-05 23:26, Eric Gray wrote: >>> In addition to the previously noted issues, from discussion, it > looks like the values "assigned" >>> in the IANA considerations section are at least questionable at this > point. >>> >>> At present, there is only one obvious clash in these assignments > (the >>> draft "assigns" the value "5" in the "Downstream [Mapping Address >>> Type] Registry" and this value has already been assigned via RFC >>> 6426). However, the MPLS WG now has in place an early assignment >>> process and it may be the case that other assignments have been made > via this process and a clash will occur when these are permanently > assigned later. >>> >>> As a NIT - compounding the issues in this case - two of the affected >>> Registries are incorrectly named in the IANA section. >>> >>> These values should be replaced with "variables" (e.g. - TBA-1, > TBA-2, >>> TBA-3, etc.) before the draft is adopted as a WG draft. Once > adopted, >>> the authors of this draft may then apply for early assignments via > the existing process. >>> >>> -- >>> Eric >>> >>> -----Original Message----- >>> From: Eric Gray >>> Sent: Wednesday, June 05, 2013 3:02 PM >>> To: 'Loa Andersson'; mpls@ietf.org >>> Cc: mpls-chairs@tools.ietf.org; >>> draft-lim-mpls-proxy-lsp-ping@tools.ietf.org >>> Subject: RE: [mpls] Poll to see if we have consensus to make >>> draft-lim-mpls-proxy-lsp-ping an MPLS working group document >>> >>> Don't support at the current time. >>> >>> The draft does not appear to deal reasonably with the case where a > desired remote "Proxy LSP Ping" LSR does not support this capability. I > searched and the phrase "backward compatibility" is not in the full-text > version of the draft. >>> >>> I also have some questions about the utility of this capability, > given that this might - for instance - be used by an edge router to task > other routers with "pinging" toward another edge router. Presumably, > this could include routers which are typically not optimized to handle > processing of traffic such as Ping responses. >>> >>> This could be made very much worse if - within the context of the > service provider network - a large number of edge LSRs were compromised > and became agents in a DDoS attack on the service provider core network. >>> -- >>> Eric >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of Loa Andersson >>> Sent: Thursday, May 30, 2013 12:35 PM >>> To: mpls@ietf.org >>> Cc: mpls-chairs@tools.ietf.org; >>> draft-lim-mpls-proxy-lsp-ping@tools.ietf.org >>> Subject: [mpls] Poll to see if we have consensus to make >>> draft-lim-mpls-proxy-lsp-ping an MPLS working group document >>> >>> Working Group, >>> >>> This is to start a two week poll on adopting >>> draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >>> >>> Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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. >>> >>> This poll ends June 14, 2013. >>> >>> There are two IPR claims against this document: >>> >>> https://datatracker.ietf.org/ipr/778/ >>> https://datatracker.ietf.org/ipr/2087/ >>> >>> >>> 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. >>> >>> /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 >> > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From prvs=3870a4c59c=eric.gray@ericsson.com Fri Jun 7 07:18:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7585B21F8E93 for ; Fri, 7 Jun 2013 07:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4AvlBZfSW-g for ; Fri, 7 Jun 2013 07:18:14 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id AB90A21F8E89 for ; Fri, 7 Jun 2013 07:18:13 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-8e-51b1eba42db4 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 44.30.17537.4ABE1B15; Fri, 7 Jun 2013 16:18:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 10:18:12 -0400 From: Eric Gray To: Loa Andersson , t.petch , "Stewart Bryant (stbryant) (stbryant@cisco.com)" , "adrian@olddog.co.uk" Thread-Topic: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: AQHOXVO2jVdv3lmzr0iBYQoJl/eoppkngPbggAAlfXCAARCsgIAACzSwgAGOboqAAEZIAP//vX0g Date: Fri, 7 Jun 2013 14:18:11 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60B58BA@eusaamb107.ericsson.se> References: <51A77FBD.6010605@pi.nu><48E1A67CB9CA044EADFEAB87D814BFF60B4CE4@eusaamb107.ericsson.se><51B054D3.1070209@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF60B5149@eusaamb107.ericsson.se> <02fd01ce6385$d18e7ee0$4001a8c0@gateway.2wire.net> <51B1E768.6030002@pi.nu> In-Reply-To: <51B1E768.6030002@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF60B58BAeusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyuXRPoO6S1xsDDbY/sbT40XOD2aJzqrzF tUf3WSz+zZ3DbPH90hIWi1tLV7JanHs6h9GB3WPX0R/sHlN+b2T1WLLkJ5PHis0rGT1mTW9j 8/hy+TNbAFsUt01SYklZcGZ6nr5dAnfG99kvWApm3mKqmHUoroFx6kqmLkZODgkBE4mV7dtZ IWwxiQv31rN1MXJxCAkcZZTYfKiTEcJZxiixddoJsA42AQ2JY3fWgiVEBLYwSnw9OxXMYRbY xijRs/0e0CwODmGBaonJPUEgDSICNRKP55xjgrCjJE7c+8EMYrMIqEisu7UYLM4r4C3x4MJL doht3UwSv79sByviFFCV+DX7JRuIzQh03/dTa8AamAXEJW49mQ/1g4DEkj3nmSFsUYmXj/9B /aMsseTJfhaI+nyJKbNOsUEsE5Q4OfMJywRG0VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+Z YewzBx4zIYsvYGRfxchRWpxalptuZLCJERi3xyTYdHcw7nlpeYhRmoNFSZxXjXdxoJBAemJJ anZqakFqUXxRaU5q8SFGJg5OEMEl1cAY//TpvPVnL3xyuT4rYq1p2cMzNYdvVKV18lxZuJZH pedxwKwnjR8tHpX776gLeCcQX1F/9NbaiUq9GWESRwJm6nrXruwxyZ3/7Y+bWLVOTd0RQ1t9 r8sdzzeprlyRtodD87q9p5fFEwGpFwmiHgkMHE6hPudOnL3AeErpPefTf5smHBA2rTFWYinO SDTUYi4qTgQAwkiuhq4CAAA= Cc: mpls , "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:18:19 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF60B58BAeusaamb107ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Loa, This would be acceptable to me, provided that the authors a= nd the WG chairs make it a priority to fix the IANA considerations section immediately after adoption, AND prov= ided that the Chairs instruct the draft authors to remove the instance where the draft is known to use a = value already assigned in a published RFC prior to reposting it as a WG draft. There is a big difference between telling a draft author to= make changes in his or her draft while it remains a private draft and telling them conditions under which it may b= e published as a working group draft. As a working group, we certainly can say "we will adopt you= r private draft as a working group draft, provided you make these specified changes." As a working group, we= have a responsibility not to ignore blatant errors in draft that will be a working group draft - no m= atter when we discover them. And, as I have already said, there are clearly cases where = draft authors may inadvertently include inappropriate abuse of IETF resources where it MUST be the case tha= t working group chairs and/or the IESG can direct either correction or removal of the draft - what= ever its status at the time. By the way, just to avoid any confusion, I did not ask for = a "perfect IANA section" - I asked only that we not adopt an Internet Draft where the IANA section is clearly and s= pecifically wrong. -- Eric -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Friday, June 07, 2013 10:00 AM To: t.petch Cc: Eric Gray; mpls; mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-p= ing@tools.ietf.org Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls= -proxy-lsp-ping an MPLS working group document Fokks, I'd prefer that the hard values before going to poll to make it a working g= roup document; but as a working group chair I would not require that any authors make any = changes to any non-working group documents. There are things that needs to be fixed before starting the poll; a perfect= IANA section is not one of them. Updating the IANA sections as part of wha= t we do to working group documents; I guess there are numerous author group= s that can verify that that happens prior to the request publication. I see no reason to treat drfat-lim- differently. /Loa On 2013-06-07 15:49, t.petch wrote: > ----- Original Message ----- > From: "Eric Gray" > > To: "Loa Andersson" > > Cc: >; >; > > > Sent: Thursday, June 06, 2013 3:17 PM >> Loa, >> >> Mostly good points. However, it is frequently the case that the WG > chairs require >> certain changes to be made - other than the obvious "name change" for > the draft - based on >> comments made during the polling for adoption. >> >> This is by no means unusual. > > Eric > > I think otherwise. My experience in the IETF is that when an I-D is > adopted by a WG, then the only change is to the title. Often the > instruction from the WG Chair explicitly spells this out. > > Of course, changes can be made beforehand, to smooth the adoption, and > after, under the control of the WG, but at adoption, I think best not; > what might be uncontentious to one party might be a reason for > changing their mind to another, so only changing the name obviates that. > > I agree that the IANA Considerations need work. It would be better > IMO if the authors took out the 'hard' values beforehand. If I had to > express an opinion, then it would be not to adopt until all those > values had been removed (which is not exactly a technical reason). > > Tom Petch > >> This is what I am suggesting needs to be done in this case - i.e. - >> if > the draft is adopted >> by the WG, it should not be published as a WG draft without fixing >> the > IANA section. >> >> As to the point you make about the faults in the IANA section being a > good reason to >> adopt the draft as a working group draft - well - sorry but that is > ridiculous (as I am sure you >> will realize if you think about it). If that were true, the easiest > way to get any draft adopted >> by the WG would be to abuse the IANA Considerations section. >> >> We would clearly be risking setting a dangerous precedent by even > suggesting this. >> >> What should instead be the case is that any private draft that >> expects > to use an IANA >> registry that is "owned" by an IETF working group MUST use the "tbd-#" > style variables or it >> can be explicitly removed from the ID repository based on a request > from the chair(s) of that >> working group. >> >> -- >> Eric >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Thursday, June 06, 2013 5:22 AM >> To: Eric Gray >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-lim-mpls-proxy-lsp-ping@tools.ietf.org >> Subject: Re: [mpls] Poll to see if we have consensus to make > draft-lim-mpls-proxy-lsp-ping an MPLS working group document >> Importance: High >> >> Eric, >> >> You point at an issue that we need to resolve. >> >> From a working group point of view there is no "early allocation" > made for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there > can't be any early allocation made, since these can be made only to > working group documents. RFC 4020 says "The processes described below > assume that the document in question is the product of an IETF Working Gr= oup." >> >> There is a practice among many authors to "propose" values in the >> IANA > section. For new registries this is at least semi-encouraged. >> >> For existing registries this practice is most of the time not >> harmful, > but could create problems if the proposed values are actually used in > implementations. It is RECOMMENDED that our documents use the tbd-1 > style variables. >> >> The problem here is the definition of "our documents", strictly > draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be one > of "our documents" until it actually is accepted as a working group > document - when the working group take over the revision control. >> >> The working group can't tell the authors what to do with the >> document, > until it becomes a working group document! My conclusion is that the > issues on the IANA allocation you point to is a reason to making it a > working group document. >> >> There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and > draft-ietf-mpls-return-path-specified-lsp-ping are looking to assign > new TLV Type values, it might be that the value proposed by > draft-lim-mpls-proxy-lsp-ping (Type 22) is already assigned when we > request publication of theis draft. >> >> Note: draft-lim-mpls-proxy-lsp-ping is currently in wg poll and should >> for the time being not be updated. >> >> /Loa >> >> On 2013-06-05 23:26, Eric Gray wrote: >>> In addition to the previously noted issues, from discussion, it > looks like the values "assigned" >>> in the IANA considerations section are at least questionable at this > point. >>> >>> At present, there is only one obvious clash in these assignments > (the >>> draft "assigns" the value "5" in the "Downstream [Mapping Address >>> Type] Registry" and this value has already been assigned via RFC >>> 6426). However, the MPLS WG now has in place an early assignment >>> process and it may be the case that other assignments have been made > via this process and a clash will occur when these are permanently > assigned later. >>> >>> As a NIT - compounding the issues in this case - two of the affected >>> Registries are incorrectly named in the IANA section. >>> >>> These values should be replaced with "variables" (e.g. - TBA-1, > TBA-2, >>> TBA-3, etc.) before the draft is adopted as a WG draft. Once > adopted, >>> the authors of this draft may then apply for early assignments via > the existing process. >>> >>> -- >>> Eric >>> >>> -----Original Message----- >>> From: Eric Gray >>> Sent: Wednesday, June 05, 2013 3:02 PM >>> To: 'Loa Andersson'; mpls@ietf.org >>> Cc: mpls-chairs@tools.ietf.org; >>> draft-lim-mpls-proxy-lsp-ping@tools.ietf.org >>> Subject: RE: [mpls] Poll to see if we have consensus to make >>> draft-lim-mpls-proxy-lsp-ping an MPLS working group document >>> >>> Don't support at the current time. >>> >>> The draft does not appear to deal reasonably with the case where a > desired remote "Proxy LSP Ping" LSR does not support this capability. > I searched and the phrase "backward compatibility" is not in the > full-text version of the draft. >>> >>> I also have some questions about the utility of this capability, > given that this might - for instance - be used by an edge router to > task other routers with "pinging" toward another edge router. > Presumably, this could include routers which are typically not > optimized to handle processing of traffic such as Ping responses. >>> >>> This could be made very much worse if - within the context of the > service provider network - a large number of edge LSRs were > compromised and became agents in a DDoS attack on the service provider co= re network. >>> -- >>> Eric >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-= bounces@ietf.org] On Behalf >>> Of Loa Andersson >>> Sent: Thursday, May 30, 2013 12:35 PM >>> To: mpls@ietf.org >>> Cc: mpls-chairs@tools.ietf.org; >>> draft-lim-mpls-proxy-lsp-ping@tools.ietf.org >>> Subject: [mpls] Poll to see if we have consensus to make >>> draft-lim-mpls-proxy-lsp-ping an MPLS working group document >>> >>> Working Group, >>> >>> This is to start a two week poll on adopting >>> draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. >>> >>> Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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. >>> >>> This poll ends June 14, 2013. >>> >>> There are two IPR claims against this document: >>> >>> https://datatracker.ietf.org/ipr/778/ >>> https://datatracker.ietf.org/ipr/2087/ >>> >>> >>> 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. >>> >>> /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 >> > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --_000_48E1A67CB9CA044EADFEAB87D814BFF60B58BAeusaamb107ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Loa,

 

        &= nbsp;       This would be acceptable to me, p= rovided that the authors and the WG chairs make it a priority

to fix the IANA considerations section immediatel= y after adoption, AND provided that the Chairs instruct

the draft authors to remove the instance where th= e draft is known to use a value already assigned in a

published RFC prior to reposting it as a WG draft= .

 

        &= nbsp;       There is a big difference between= telling a draft author to make changes in his or her draft while

it remains a private draft and telling them condi= tions under which it may be published as a working group

draft.

 

        &= nbsp;       As a working group, we certainly = can say "we will adopt your private draft as a working group

draft, provided you make these specified  ch= anges."  As a working group, we have a responsibility not

to ignore blatant errors in draft that will be a = working group draft - no matter when we discover them.

 

        &= nbsp;       And, as I have already said, ther= e are clearly cases where draft authors may inadvertently

include inappropriate abuse of IETF resources whe= re it MUST be the case that working group chairs

and/or the IESG can direct either correction or r= emoval of the draft - whatever its status at the time.

 

        &= nbsp;       By the way, just to avoid any con= fusion, I did not ask for a "perfect IANA section" - I asked only=

that we not adopt an Interne= t Draft where the IANA section is clearly and specifically wrong.

 

--

Eric

 

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu]
Sent: Friday, June 07, 2013 10:00 AM
To: t.petch
Cc: Eric Gray; mpls; mpls-chairs@tools.ietf.org; draft-lim-mpls-proxy-lsp-p= ing@tools.ietf.org
Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls= -proxy-lsp-ping an MPLS working group document

 

Fokks,

 

<chair hat off>

 

I'd prefer that the hard values before going to p= oll to make it a working group document;

 

<chair hat on>

 

but as a working group chair I would not require = that any authors make any changes to any non-working group documents.<= /o:p>

 

There are things that needs to be fixed before st= arting the poll; a perfect IANA section is not one of them. Updating the IA= NA sections as part of what we do to working group documents; I guess there= are numerous author groups that can verify that that happens prior to the request publication.

 

I see no reason to treat drfat-lim- differently.<= o:p>

 

/Loa

 

On 2013-06-07 15:49, t.petch wrote:

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

> From: "Eric Gray" <eric.gray@ericsson.com>

> To: "Loa Andersson" <lo= a@pi.nu>

> Cc: <mpls@ietf.org= >; <mpls-chairs@tools.ietf.org>= ;;

> <draft-lim-mpls-proxy-lsp-ping@tools.ietf.org>

> Sent: Thursday, June 06, 2013 3:17 PM

>> Loa,

>> 

>> Mostly good points.  However, it is= frequently the case that the WG

> chairs require

>> certain changes to be made - other than = the obvious "name change" for

> the draft - based on

>> comments made during the polling for ado= ption.

>> 

>> This is by no means unusual.<= /p>

> 

> Eric

> 

> I think otherwise.  My experience in th= e IETF is that when an I-D is

> adopted by a WG, then the only change is to = the title.  Often the

> instruction from the WG Chair explicitly spe= lls this out.

> 

> Of course, changes can be made beforehand, t= o smooth the adoption, and

> after, under the control of the WG, but at a= doption, I think best not;

> what might be uncontentious to one party mig= ht be a reason for

> changing their mind to another, so only chan= ging the name obviates that.

> 

> I agree that the IANA Considerations need wo= rk.  It would be better

> IMO if the authors took out the 'hard' value= s beforehand.  If I had to

> express an opinion, then it would be not to = adopt until all those

> values had been removed (which is not exactl= y a technical reason).

> 

> Tom Petch

> 

>> This is what I am suggesting needs to be= done in this case - i.e. -

>> if

> the draft is adopted

>> by the WG, it should not be published as= a WG draft without fixing

>> the

> IANA section.

>> 

>> As to the point you make about the fault= s in the IANA section being a

> good reason to

>> adopt the draft as a working group draft= - well - sorry but that is

> ridiculous (as I am sure you

>> will realize if you think about it).&nbs= p; If that were true, the easiest

> way to get any draft adopted

>> by the WG would be to abuse the IANA Con= siderations section.

>> 

>> We would clearly be risking setting a da= ngerous precedent by even

> suggesting this.

>> 

>> What should instead be the case is that = any private draft that

>> expects

> to use an IANA

>> registry that is "owned" by an= IETF working group MUST use the "tbd-#"

> style variables or it

>> can be explicitly removed from the ID re= pository based on a request

> from the chair(s) of that

>> working group.

>> 

>> --

>> Eric

>> 

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

>> From: Loa Andersson [mailto:loa@= pi.nu]

>> Sent: Thursday, June 06, 2013 5:22 AM

>> To: Eric Gray

>> Cc: mpls@ietf.org= ; mpls-chairs@tools.ietf.org;<= /p>

> draft-lim-mpls-proxy-= lsp-ping@tools.ietf.org

>> Subject: Re: [mpls] Poll to see if we ha= ve consensus to make

> draft-lim-mpls-proxy-lsp-ping an MPLS workin= g group document

>> Importance: High

>> 

>> Eric,

>> 

>> You point at an issue that we need to re= solve.

>> 

>>   From a working group point o= f view there is no "early allocation"

> made for draft-lim-mpls-proxy-lsp-ping; as a= matter of fact there

> can't be any early allocation made, since th= ese can be made only to

> working group documents. RFC 4020 says "= ;The processes described below

> assume that the document in question is the = product of an IETF Working Group."

>> 

>> There is a practice among many authors t= o "propose" values in the

>> IANA

> section. For new registries this is at least= semi-encouraged.

>> 

>> For existing registries this practice is= most of the time not

>> harmful,

> but could create problems if the proposed va= lues are actually used in

> implementations. It is RECOMMENDED that our = documents use the tbd-1

> style variables.

>> 

>> The problem here is the definition of &q= uot;our documents", strictly

> draft-lim-mpls-proxy-lsp-ping does really me= et the criteria to be one

> of "our documents" until it actual= ly is accepted as a working group

> document - when the working group take over = the revision control.

>> 

>> The working group can't tell the authors= what to do with the

>> document,

> until it becomes a working group document! M= y conclusion is that the

> issues on the IANA allocation you point to i= s a reason to making it a

> working group document.

>> 

>> There are potential "clashes",= both draft-lim-mpls-proxy-lsp-ping and

> draft-ietf-mpls-return-path-specified-lsp-pi= ng are looking to assign

> new TLV Type values, it might be that the va= lue proposed by

> draft-lim-mpls-proxy-lsp-ping (Type 22) is a= lready assigned when we

> request publication of theis draft.

>> 

>> Note: draft-lim-mpls-proxy-lsp-ping is c= urrently in wg poll and should

>>       = ;  for the time being not be updated.

>> 

>> /Loa

>> 

>> On 2013-06-05 23:26, Eric Gray wrote:

>>> In addition to the previously noted = issues, from discussion, it

> looks like the values "assigned"

>>> in the IANA considerations section a= re at least questionable at this

> point.

>>> 

>>> At present, there is only one obviou= s clash in these assignments

> (the

>>> draft "assigns" the value = "5" in the "Downstream [Mapping Address

>>> Type] Registry" and this value = has already been assigned via RFC

>>> 6426).  However, the MPLS WG no= w has in place an early assignment

>>> process and it may be the case that = other assignments have been made

> via this process and a clash will occur when= these are permanently

> assigned later.

>>> 

>>> As a NIT - compounding the issues in= this case - two of the affected

>>> Registries are incorrectly named in = the IANA section.

>>> 

>>> These values should be replaced with= "variables" (e.g. - TBA-1,

> TBA-2,

>>> TBA-3, etc.) before the draft is ado= pted as a WG draft.  Once

> adopted,

>>> the authors of this draft may then a= pply for early assignments via

> the existing process.

>>> 

>>> --

>>> Eric

>>> 

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

>>> From: Eric Gray

>>> Sent: Wednesday, June 05, 2013 3:02 = PM

>>> To: 'Loa Andersson'; mpl= s@ietf.org

>>> Cc: mpls-ch= airs@tools.ietf.org;

>>> draft-lim-mpls-proxy-= lsp-ping@tools.ietf.org

>>> Subject: RE: [mpls] Poll to see if w= e have consensus to make

>>> draft-lim-mpls-proxy-lsp-ping an MPL= S working group document

>>> 

>>> Don't support at the current time.

>>> 

>>> The draft does not appear to deal re= asonably with the case where a

> desired remote "Proxy LSP Ping" LS= R does not support this capability. 

> I searched and the phrase "backward com= patibility" is not in the

> full-text version of the draft.

>>> 

>>> I also have some questions about the= utility of this capability,

> given that this might - for instance - be us= ed by an edge router to

> task other routers with "pinging" = toward another edge router. 

> Presumably, this could include routers which= are typically not

> optimized to handle processing of traffic su= ch as Ping responses.

>>> 

>>> This could be made very much worse i= f - within the context of the

> service provider network - a large number of= edge LSRs were

> compromised and became agents in a DDoS atta= ck on the service provider core network.

>>> --

>>> Eric

>>> 

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

>>> From: mpls-bounc= es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf

>>> Of Loa Andersson

>>> Sent: Thursday, May 30, 2013 12:35 P= M

>>> To: mpls@ietf.org=

>>> Cc: mpls-ch= airs@tools.ietf.org;

>>> draft-lim-mpls-proxy-= lsp-ping@tools.ietf.org

>>> Subject: [mpls] Poll to see if we ha= ve consensus to make

>>> draft-lim-mpls-proxy-lsp-ping an MPL= S working group document

>>> 

>>> Working Group,

>>> 

>>> This is to start a two week poll on = adopting

>>> draft-lim-mpls-proxy-lsp-ping-02 as = an MPLS working group document.

>>> 

>>> Please send your comments (support/n= ot support) to the mpls working

> group mailing list (mpls at ietf.org). Pleas= e give a technical

> motivation for your support/not support, esp= ecially if you think that

> the document should not be adopted as a work= ing group document.

>>> 

>>> This poll ends June 14, 2013.

>>> 

>>> There are two IPR claims against thi= s document:

>>> 

>>> https:/= /datatracker.ietf.org/ipr/778/

>>> https:= //datatracker.ietf.org/ipr/2087/

>>> 

>>> 

>>> The authors has stated on the workin= g group mailing list that they

> are not aware of any other IPR claims agains= t this draft.

>>> However if you are on the the mpls w= orking group mailing list and

> aware of IPR that relates to this draft, the= time to disclose this is

> now.

>>> 

>>> /Loa

>>> (mpls wg co-chair)

>>> 

>> 

>> --

>> 

>> 

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

>> Senior MPLS Expert   &nbs= p;            &= nbsp;         loa@pi.nu<= o:p>

>> Huawei Technologies (consultant) &n= bsp;   phone: +46 739 81 21 64

>> ________________________________________= _______

>> mpls mailing list

>> mpls@ietf.org

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

>> 

> 

> 

 

--

 

 

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

Senior MPLS Expert     &= nbsp;           &nbs= p;        <= span style=3D"color:windowtext;text-decoration:none">loa@pi.nu

Huawei Technologies (consultant)   = ;  phone: +46 739 81 21 64

--_000_48E1A67CB9CA044EADFEAB87D814BFF60B58BAeusaamb107ericsso_-- From adrian@olddog.co.uk Fri Jun 7 07:31:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B3121F9843; Fri, 7 Jun 2013 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZgvF+m97hSY; Fri, 7 Jun 2013 07:31:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2548021F9920; Fri, 7 Jun 2013 07:31:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57EV6D2007140; Fri, 7 Jun 2013 15:31:06 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57EV5Kk007127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 15:31:06 +0100 From: "Adrian Farrel" To: , , , , Date: Fri, 7 Jun 2013 15:30:59 +0100 Message-ID: <0afa01ce638b$a2067820$e6136860$@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: Ac5ji41bX64WTevZT8eVu8We0gvrYQ== Content-Language: en-gb Cc: draft-ietf-ipsecme-ad-vpn-problem.all@tools.ietf.org Subject: [mpls] Heads up : IETF Last Call on "Auto Discovery VPN Problem Statement and Requirements" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 14:31:28 -0000 Hi VPN-related working groups, Please be aware of this document that is in IETF last call. Comments should be sent following the instructions in the email below and *not* to the mailing lists I have spammed. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 07 June 2013 15:00 > To: IETF-Announce > Cc: ipsec@ietf.org > Subject: Last Call: (Auto Discovery > VPN Problem Statement and Requirements) to Informational RFC > > > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'Auto Discovery VPN Problem Statement and Requirements' > as Informational RFC > > 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 2013-06-21. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes the problem of enabling a large number of > systems to communicate directly using IPsec to protect the traffic > between them. It then expands on the requirements, for such a > solution. > > Manual configuration of all possible tunnels is too cumbersome in > many such cases. In other cases the IP address of endpoints change > or the endpoints may be behind NAT gateways, making static > configuration impossible. The Auto Discovery VPN solution will > address these requirements. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From adrian@olddog.co.uk Fri Jun 7 09:13:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60D521F9702 for ; Fri, 7 Jun 2013 09:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ipJw9Id6X6L for ; Fri, 7 Jun 2013 09:13:48 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7340421F96F4 for ; Fri, 7 Jun 2013 09:13:48 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57GDkj4021332; Fri, 7 Jun 2013 17:13:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57GDjjD021299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 17:13:46 +0100 From: "Adrian Farrel" To: "'t.petch'" References: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> <00ec01ce613c$3d29ba80$4001a8c0@gateway.2wire.net> In-Reply-To: <00ec01ce613c$3d29ba80$4001a8c0@gateway.2wire.net> Date: Fri, 7 Jun 2013 17:13:39 +0100 Message-ID: <0b2901ce6399$f95f1fb0$ec1d5f10$@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: AQJNw4GCFePBlpQH+5QQk6q31ZighAJQUTXJmBknahA= Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] IANA Considerations was Re: AD review of draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:13:54 -0000 Hi Tom, Repeating history is not always the right way to decide what the right thing to do is. > > Why do you say that this updates RFC 4379? Is it your belief that an > > implementation of RFC 4379 will not be complete/conformant without > > these extensions? Or are you just defining extensions which an > > implementation in an MPLS-MT environment will need to support? > > > > I note that you (in my view, correctly) do not say that this document > > updates RFC 5036, yet it defines extensions to LDP in a similar way. > > I am not sure I follow this logic; RFC6426 adds TLVs and sub-TLVs and is > recorded as updating RFC4379. > > That RFC also updates the "Pseudowire Associated Channel Types" registry > but is not recorded as updating the RFC for that registry. > > So I think that this I-D is following a pre-established path. My logic is that if this document updates 4379, then it also updates 5036 because in both cases, this I-D adds TLVs to the protocols defined in those RFCs. But the trend of usage of "updates" is not the weaker "adds some protocol extensions", but the stronger "adds to the core function set". Thus, a reasonable view is that if you were republishing the base protocol spec tomorrow, would you fold the new work into that specification? If so use "updates". If not, do not. I am still open to the argument that this document *does* update 4379, but I don't see it. I think you would only use MT LSP Ping in MT deployments (just as you would only use MT LDP in such deployments) and core implementations of MPLS might choose to support neither. Cheers, Adrian From internet-drafts@ietf.org Fri Jun 7 09:14:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4519621F98CC; Fri, 7 Jun 2013 09:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-Z4vLs5AP9y; Fri, 7 Jun 2013 09:14:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9B21F965B; Fri, 7 Jun 2013 09:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130607161453.19896.22639.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2013 09:14:53 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-gach-adv-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 16:14:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS Generic Associated Channel (G-ACh) Advertisement Pr= otocol Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-gach-adv-08.txt Pages : 22 Date : 2013-06-07 Abstract: The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-gach-adv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-gach-adv-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-gach-adv-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=987046ee83=gregory.mirsky@ericsson.com Fri Jun 7 15:19:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDD521F99AA; Fri, 7 Jun 2013 15:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYFkG6S9h3cq; Fri, 7 Jun 2013 15:19:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 388D121F99A6; Fri, 7 Jun 2013 15:18:59 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-0c-51b25c4d1d4c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.4F.17537.E4C52B15; Sat, 8 Jun 2013 00:18:54 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 18:18:53 -0400 From: Gregory Mirsky To: Mach Chen , "wayne.caowei@huawei.com" , Attila Takacs , "ppan@infinera.com" , "mpls@ietf.org" , "pwe3@ietf.org" Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2Mg== Date: Fri, 7 Jun 2013 22:18:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@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.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPrK5fzKZAg5nrpCwurBW2uLV0JavF isfvWC36Pm1hsWg+dordgdWj5chbVo8lS34yeVx6cYgtgDmK2yYpsaQsODM9T98ugTvjeMts poItIhV/F39ga2DsE+xi5OSQEDCR+HFvKROELSZx4d56ti5GLg4hgaOMEvNudLBDOMsYJc5t WcgCUsUmYCTxYmMPWEJE4BujRNuCf2DtwgKOEp9XT2QEsUUE3CSm9i5gg7D1JFa1PmQGsVkE VCQav/9kB7F5BXwl7t8/B1bPCLT6+6k1YHOYBcQlbj2ZD3WSgMSSPeeZIWxRiZeP/7FC2MoS S57sZ4Goz5f4MG0OM8RMQYmTM5+wTGAUmoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z 4DETsvgCRvZVjBylxalluelGBpsYgZFzTIJNdwfjnpeWhxilOViUxHnVeBcHCgmkJ5akZqem FqQWxReV5qQWH2Jk4uAEEVxSDYxFCrWz79Y+/357Dtf0ybeNJ9oKLrSZyyaxUnBqVjPzJW3T +jXtR2ac0zr3tmehdBqTwl/ZZfFqQesOTn42y3wfy5vN6+xU1/c4O+aaR4s9XFY5q7m1ufd8 yOU1bqtz589XYfY2O315ZcvX52tmmInw/ez0fmd2/u6iCv5zS4Nf50TUqFeqH3JQYinOSDTU Yi4qTgQA0Q8PKW8CAAA= Subject: [mpls] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 22:19:07 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., I've prepared some questions and comments that I hope you'll kindly conside= r: * I've got confused by definition of C bit in section 2.1. That might= be in part because congruency in geometry has very certain definition and = I'm projecting that to term congruent path introduced in the document. In a= ddition I think that "same route" in the second sentence is vague. Does tha= t imply that active PE requests far-end PE to use co-routed LSP? If that is= the case, should C bit explained as request to use Co-routed path? * Last sentence of section 2.1 defines that detection of C and S bits= being simultaneously set as error. How that error being signaled in LDP St= atus Codes? Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
I've prepared some questions and comments that I hope you'll kindly co= nsider:
  • I've got confused by definition of C bit in section 2.1. That might be = in part because congruency in geometry has very certain definition and I'm = projecting that to term congruent path introduced in the document. In addit= ion I think that "same route" in the second sentence is vague. Does that imply that active PE requests far-e= nd PE to use co-routed LSP? If that is the case, should C bit explained as = request to use Co-routed path?
  • Last sentence of section 2.1 defines= that detection of C and S bits being simultaneously set as error. How that= error being signaled in LDP Status Codes?
 
        Regards,
           &nbs= p;    Greg
 
 --_000_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_-- From internet-drafts@ietf.org Sat Jun 8 13:48:49 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682D821F935A; Sat, 8 Jun 2013 13:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKM--uspy+U1; Sat, 8 Jun 2013 13:48:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAEB21F92F5; Sat, 8 Jun 2013 13:48:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130608204818.6462.34004.idtracker@ietfa.amsl.com> Date: Sat, 08 Jun 2013 13:48:18 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-retire-ach-tlv-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 20:48:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Retiring TLVs from the Associated Channel Header of the = MPLS Generic Associated Channel Author(s) : Adrian Farrel Stewart Bryant Filename : draft-ietf-mpls-retire-ach-tlv-01.txt Pages : 5 Date : 2013-06-08 Abstract: The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-retire-ach-tlv-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-retire-ach-tlv-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Sat Jun 8 14:34:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDCA21F90F1 for ; Sat, 8 Jun 2013 14:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH81QGluC4KG for ; Sat, 8 Jun 2013 14:34:24 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB3521F8CDD for ; Sat, 8 Jun 2013 14:34:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r58LYMjQ011859 for ; Sat, 8 Jun 2013 22:34:22 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r58LYLUR011840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Jun 2013 22:34:22 +0100 From: "Adrian Farrel" To: References: <20130608204848.6462.27686.idtracker@ietfa.amsl.com> In-Reply-To: <20130608204848.6462.27686.idtracker@ietfa.amsl.com> Date: Sat, 8 Jun 2013 22:34:17 +0100 Message-ID: <0c8901ce648f$ee0eeea0$ca2ccbe0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHLO72PDyb6MLWQlEYNsNhAwl315pkyoLeA Content-Language: en-gb Subject: [mpls] FW: New Version Notification for draft-ietf-mpls-retire-ach-tlv-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 08 Jun 2013 21:34:29 -0000 Hi, Only change is a nit pointed out by Jia. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 08 June 2013 21:49 > To: Adrian Farrel; Stewart Bryant > Subject: New Version Notification for = draft-ietf-mpls-retire-ach-tlv-01.txt >=20 >=20 > A new version of I-D, draft-ietf-mpls-retire-ach-tlv-01.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-ietf-mpls-retire-ach-tlv > Revision: 01 > Title: Retiring TLVs from the Associated Channel Header of the MPLS > Generic Associated Channel > Creation date: 2013-06-08 > Group: mpls > Number of pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-mpls-retire-ach-tlv- > 01.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv > Htmlized: = http://tools.ietf.org/html/draft-ietf-mpls-retire-ach-tlv-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-retire-ach-tlv-01 >=20 > Abstract: > The MPLS Generic Associated Channel (G-ACh) is a generalization of > the applicability of the Pseudowire (PW) Associated Channel Header > (ACH). RFC 5586 defines the concept of TLV constructs that can be > carried in messages on the G-ACh by placing them in the ACH between > the fixed header fields and the G-ACh message. These TLVs are = called > ACH TLVs >=20 > No Associated Channel Type yet defined uses an ACH TLV. = Furthermore, > it is believed that handling TLVs in hardware introduces = significant > problems to the fast-path, and since G-ACh messages are intended to > be processed substantially in hardware, the use of ACH TLVs is > undesirable. >=20 > This document updates RFC 5586 by retiring ACH TLVs and removing = the > associated registry. >=20 >=20 >=20 >=20 > The IETF Secretariat From hejia@huawei.com Sat Jun 8 17:33:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D359C21F944F for ; Sat, 8 Jun 2013 17:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbMD+h2R8Rvs for ; Sat, 8 Jun 2013 17:33:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 19CF321F93D7 for ; Sat, 8 Jun 2013 17:33:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASF78183; Sun, 09 Jun 2013 00:33:18 +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.1.323.7; Sun, 9 Jun 2013 01:32:20 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 01:33:17 +0100 Received: from SZXEML505-MBX.china.huawei.com ([169.254.1.22]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Sun, 9 Jun 2013 08:33:11 +0800 From: "Hejia (Jia)" To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-ietf-mpls-retire-ach-tlv-01.txt Thread-Index: AQHLO72PDyb6MLWQlEYNsNhAwl315pkyoLeAgAA5XNA= Date: Sun, 9 Jun 2013 00:33:11 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952C6DCD77@SZXEML505-MBX.china.huawei.com> References: <20130608204848.6462.27686.idtracker@ietfa.amsl.com> <0c8901ce648f$ee0eeea0$ca2ccbe0$@olddog.co.uk> In-Reply-To: <0c8901ce648f$ee0eeea0$ca2ccbe0$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] FW: New Version Notification for draft-ietf-mpls-retire-ach-tlv-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 00:33:25 -0000 QWRyaWFuLA0KDQpUaGFua3MgZm9yIHRha2luZyBjYXJlIG9mIHRoaXMuDQoNCkIuUi4NCkppYQ0K DQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEFkcmlhbiBGYXJyZWwNCreiy83KsbzkOiAy MDEzxOo21MI5yNUgNTozNA0KytW8/sjLOiBtcGxzQGlldGYub3JnDQrW98ziOiBbbXBsc10gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1tcGxzLXJldGlyZS1hY2gt dGx2LTAxLnR4dA0KDQpIaSwNCg0KT25seSBjaGFuZ2UgaXMgYSBuaXQgcG9pbnRlZCBvdXQgYnkg SmlhLg0KDQpUaGFua3MsDQpBZHJpYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddDQo+IFNlbnQ6IDA4IEp1bmUgMjAxMyAyMTo0OQ0KPiBUbzogQWRyaWFuIEZhcnJl bDsgU3Rld2FydCBCcnlhbnQNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1pZXRmLW1wbHMtcmV0aXJlLWFjaC10bHYtMDEudHh0DQo+IA0KPiANCj4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbXBscy1yZXRpcmUtYWNoLXRsdi0wMS50eHQNCj4g aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBZHJpYW4gRmFycmVsIGFuZCBwb3N0 ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtaWV0 Zi1tcGxzLXJldGlyZS1hY2gtdGx2DQo+IFJldmlzaW9uOgkgMDENCj4gVGl0bGU6CQkgUmV0aXJp bmcgVExWcyBmcm9tIHRoZSBBc3NvY2lhdGVkIENoYW5uZWwgSGVhZGVyIG9mIHRoZSBNUExTDQo+ IEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTA2LTA4 DQo+IEdyb3VwOgkJIG1wbHMNCj4gTnVtYmVyIG9mIHBhZ2VzOiA1DQo+IFVSTDogICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXJl dGlyZS1hY2gtdGx2LQ0KPiAwMS50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1yZXRpcmUtYWNoLXRsdg0KPiBIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1y ZXRpcmUtYWNoLXRsdi0wMQ0KPiBEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1yZXRpcmUtYWNoLXRsdi0wMQ0KPiANCj4gQWJz dHJhY3Q6DQo+ICAgIFRoZSBNUExTIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsIChHLUFDaCkg aXMgYSBnZW5lcmFsaXphdGlvbiBvZg0KPiAgICB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgUHNl dWRvd2lyZSAoUFcpIEFzc29jaWF0ZWQgQ2hhbm5lbCBIZWFkZXINCj4gICAgKEFDSCkuICBSRkMg NTU4NiBkZWZpbmVzIHRoZSBjb25jZXB0IG9mIFRMViBjb25zdHJ1Y3RzIHRoYXQgY2FuIGJlDQo+ ICAgIGNhcnJpZWQgaW4gbWVzc2FnZXMgb24gdGhlIEctQUNoIGJ5IHBsYWNpbmcgdGhlbSBpbiB0 aGUgQUNIIGJldHdlZW4NCj4gICAgdGhlIGZpeGVkIGhlYWRlciBmaWVsZHMgYW5kIHRoZSBHLUFD aCBtZXNzYWdlLiAgVGhlc2UgVExWcyBhcmUgY2FsbGVkDQo+ICAgIEFDSCBUTFZzDQo+IA0KPiAg ICBObyBBc3NvY2lhdGVkIENoYW5uZWwgVHlwZSB5ZXQgZGVmaW5lZCB1c2VzIGFuIEFDSCBUTFYu ICBGdXJ0aGVybW9yZSwNCj4gICAgaXQgaXMgYmVsaWV2ZWQgdGhhdCBoYW5kbGluZyBUTFZzIGlu IGhhcmR3YXJlIGludHJvZHVjZXMgc2lnbmlmaWNhbnQNCj4gICAgcHJvYmxlbXMgdG8gdGhlIGZh c3QtcGF0aCwgYW5kIHNpbmNlIEctQUNoIG1lc3NhZ2VzIGFyZSBpbnRlbmRlZCB0bw0KPiAgICBi ZSBwcm9jZXNzZWQgc3Vic3RhbnRpYWxseSBpbiBoYXJkd2FyZSwgdGhlIHVzZSBvZiBBQ0ggVExW cyBpcw0KPiAgICB1bmRlc2lyYWJsZS4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBS RkMgNTU4NiBieSByZXRpcmluZyBBQ0ggVExWcyBhbmQgcmVtb3ZpbmcgdGhlDQo+ICAgIGFzc29j aWF0ZWQgcmVnaXN0cnkuDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0K From internet-drafts@ietf.org Sat Jun 8 19:10:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9928421F96FB; Sat, 8 Jun 2013 19:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM0vXyrrEQVJ; Sat, 8 Jun 2013 19:10:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E14721F96E9; Sat, 8 Jun 2013 19:10:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130609021036.27153.89002.idtracker@ietfa.amsl.com> Date: Sat, 08 Jun 2013 19:10:36 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 02:10:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Encapsulating MPLS in UDP Author(s) : Xiaohu Xu Nischal Sheth Lucy Yong Carlos Pignataro Yongbing Fan Filename : draft-ietf-mpls-in-udp-02.txt Pages : 9 Date : 2013-06-08 Abstract: Existing technologies to encapsulate Multi-Protocol Label Switching (MPLS) over IP are not adequate for efficient load balancing of MPLS application traffic, such as MPLS-based Layer2 Virtual Private Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic across IP networks. This document specifies additional IP-based encapsulation technology, referred to as MPLS-in-User Datagram Protocol (UDP), which can facilitate the load balancing of MPLS application traffic across IP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-in-udp-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From xuxiaohu@huawei.com Sat Jun 8 19:24:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDAB21F9711 for ; Sat, 8 Jun 2013 19:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=2.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47sm3q6s7Wxu for ; Sat, 8 Jun 2013 19:24:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B8BC521F96FF for ; Sat, 8 Jun 2013 19:24:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASF82102; Sun, 09 Jun 2013 02:24:06 +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.1.323.7; Sun, 9 Jun 2013 03:24:02 +0100 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.1.323.7; Sun, 9 Jun 2013 03:23:48 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Sun, 9 Jun 2013 10:23:42 +0800 From: Xuxiaohu To: MPLS WG Mailing List Thread-Topic: New Version Notification for draft-ietf-mpls-in-udp-02.txt Thread-Index: AQHOZLaN7BTGiPlmbUWQizoUV0FUHZkspANA Date: Sun, 9 Jun 2013 02:23:42 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C6600@NKGEML512-MBS.china.huawei.com> References: <20130609021037.27153.7579.idtracker@ietfa.amsl.com> In-Reply-To: <20130609021037.27153.7579.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] New Version Notification for draft-ietf-mpls-in-udp-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 02:24:12 -0000 SGkgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1tcGxzLWluLXVkcC0w Mi50eHQgaXMgYXZhaWxhYmxlIG5vdy4NCg0KT25lIHRlY2huaWNhbCBjaGFuZ2UgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpczogb25seSBhIHNpbmdsZSBVRFAgZGVzdGluYXRpb24gcG9ydCBu dW1iZXIgaXMgbm93IHJlcXVpcmVkIHRvIGluZGljYXRlIE1QTFMsIGluc3RlYWQgb2YgcmVxdWly aW5nIHR3byBwb3J0IG51bWJlcnMgdG8gaW5kaWNhdGUgdXBzdHJlYW0tYXNzaWduZWQgTVBMUyBh bmQgZG93bnN0cmVhbS1hc3NpZ25lZCBNUExTIHJlc3BlY3RpdmVseS4gQXMgZm9yIHdoZXRoZXIg dGhlIHRvcCBsYWJlbCBpbiB0aGUgTVBMUyBsYWJlbCBzdGFjayBpcyBkb3duc3RyZWFtLWFzc2ln bmVkIG9yIHVwc3RyZWFtLWFzc2lnbmVkLCBpdCBTSE9VTEQgYmUgZGV0ZXJtaW5lZCBiYXNlZCBv biB0aGUgdHVubmVsIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MuIFRoYXQgaXMgdG8gc2F5LCBpZiB0 aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzcyBpcyBhIG11bHRpY2FzdCBhZGRyZXNzLCB0aGUgdG9w IGxhYmVsIFNIT1VMRCBiZSB1cHN0cmVhbS1hc3NpZ25lZCwgb3RoZXJ3aXNlIGlmIHRoZSBkZXN0 aW5hdGlvbiBJUCBhZGRyZXNzIGlzIGEgdW5pY2FzdCBhZGRyZXNzLCBpdCBTSE9VTEQgYmUgZG93 bnN0cmVhbS1hc3NpZ25lZC4NCg0KQW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2Vs Y29tZS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1IChvbiBiZWhhbGYgb2YgYWxsIGNvLWF1dGhv cnMgb2YgdGhpcyBkb2MpDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10NCj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0NuaciDnml6UgMTA6MTENCj4g5pS25Lu25Lq6OiBO aXNjaGFsIFNoZXRoOyBMdWN5IHlvbmc7IFh1eGlhb2h1OyBGYW4gWW9uZ2Jpbmc7IFh1eGlhb2h1 OyBDYXJsb3MNCj4gUGlnbmF0YXJvOyBZb25nYmluZyBGYW4NCj4g5Li76aKYOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDIudHh0DQo+IA0KPiAN Cj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbXBscy1pbi11ZHAtMDIudHh0DQo+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQg dG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1t cGxzLWluLXVkcA0KPiBSZXZpc2lvbjoJIDAyDQo+IFRpdGxlOgkJIEVuY2Fwc3VsYXRpbmcgTVBM UyBpbiBVRFANCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDYtMDkNCj4gR3JvdXA6CQkgbXBscw0K PiBOdW1iZXIgb2YgcGFnZXM6IDkNCj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTAyLnR4dA0KPiBTdGF0dXM6ICAgICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLWluLXVk cA0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbXBscy1pbi11ZHAtMDINCj4gRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1wbHMtaW4tdWRwLTAyDQo+IA0KPiBBYnN0cmFjdDoN Cj4gICAgRXhpc3RpbmcgdGVjaG5vbG9naWVzIHRvIGVuY2Fwc3VsYXRlIE11bHRpLVByb3RvY29s IExhYmVsIFN3aXRjaGluZw0KPiAgICAoTVBMUykgb3ZlciBJUCBhcmUgbm90IGFkZXF1YXRlIGZv ciBlZmZpY2llbnQgbG9hZCBiYWxhbmNpbmcgb2YgTVBMUw0KPiAgICBhcHBsaWNhdGlvbiB0cmFm ZmljLCBzdWNoIGFzIE1QTFMtYmFzZWQgTGF5ZXIyIFZpcnR1YWwgUHJpdmF0ZQ0KPiAgICBOZXR3 b3JrIChMMlZQTikgb3IgTGF5ZXIzIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIChMM1ZQTikgdHJh ZmZpYw0KPiAgICBhY3Jvc3MgSVAgbmV0d29ya3MuIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFk ZGl0aW9uYWwgSVAtYmFzZWQNCj4gICAgZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5LCByZWZlcnJl ZCB0byBhcyBNUExTLWluLVVzZXIgRGF0YWdyYW0NCj4gICAgUHJvdG9jb2wgKFVEUCksIHdoaWNo IGNhbiBmYWNpbGl0YXRlIHRoZSBsb2FkIGJhbGFuY2luZyBvZiBNUExTDQo+ICAgIGFwcGxpY2F0 aW9uIHRyYWZmaWMgYWNyb3NzIElQIG5ldHdvcmtzLg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From mach.chen@huawei.com Sat Jun 8 20:03:27 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3F921F96D9; Sat, 8 Jun 2013 20:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vD106pJfXRY; Sat, 8 Jun 2013 20:03:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 578BC21F96A9; Sat, 8 Jun 2013 20:03:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR85650; Sun, 09 Jun 2013 03:03:17 +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.1.323.7; Sun, 9 Jun 2013 04:02:18 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 04:03:14 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Sun, 9 Jun 2013 11:03:02 +0800 From: Mach Chen To: Gregory Mirsky , "Caowei (Wayne)" , Attila Takacs , "ppan@infinera.com" , "mpls@ietf.org" , "pwe3@ietf.org" Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2MgA690VA Date: Sun, 9 Jun 2013 03:03:01 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 03:03:28 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments! Yes, it intends to mean co-routed here. Not use the "co-routed" because the= re is definition of co-routed bidirectional LSP, where the "co-routed" mea= ns not only co-routed but signaled by a single path/resv exchange. If the W= G think co-routed is better, I am fine to change to it. For example, change the C (Congruent Path) bit to C (Co-routed path) bit, a= nd then it's definition would like this: "C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the prope= rties of the underlying LSPs. When set, the remote T-PE/S-PEs need to selec= t co-routed LSP as the PSN tunnel. If there is no such tunnel available, th= e node may trigger the remote T-PE/S-PEs to establish a new LSP." How do you think? Best regards, Mach From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, June 08, 2013 6:19 AM To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.= org; pwe3@ietf.org Subject: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Dear Authors, et al., I've prepared some questions and comments that I hope you'll kindly conside= r: * I've got confused by definition of C bit in section 2.1. That mig= ht be in part because congruency in geometry has very certain definition an= d I'm projecting that to term congruent path introduced in the document. In= addition I think that "same route" in the second sentence is vague. Does t= hat imply that active PE requests far-end PE to use co-routed LSP? If that = is the case, should C bit explained as request to use Co-routed path? * Last sentence of section 2.1 defines that detection of C and S bi= ts being simultaneously set as error. How that error being signaled in LDP = Status Codes? Regards, Greg --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Greg,=

=  

= Thanks for your comments!

=  

= Yes, it intends to mean co-routed here. Not use the “co-routed” because there is definition of <= span style=3D"mso-spacerun:yes">  co-routed bidirectional LSP, where the “co-routed”= means not only co-routed but signaled by a single path/resv exchange. If the WG think co-routed is better, I am fine to= change to it.

=  

= For example, change the C (Congru= ent Path) bit to C (Co-routed path) bit, and then it’s definition would = like this:

=  

= “C (Co-routed path) bit: Th= is informs the remote T-PE/S-PEs about the properties of the underlying LSPs. When se= t, the remote T-PE/S-PEs need to select co-routed LSP as the PSN tunnel. If= there is no such tunnel available, the node may trigger the remote T-PE/S-= PEs to establish a new LSP.”

=  

= How do you think?

=  

= Best regards,

= Mach

=  

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, June 08, 201= 3 6:19 AM
To: Mach Chen; Caowei (Wayne= ); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: Comments to draft-i= etf-pwe3-mpls-tp-pw-over-bidir-lsp-01

 

Dear Authors, et = al.,

I've prepared som= e questions and comments that I hope you'll kindly consider:

·         I've got confused by definition of C bit in section 2.1. That might be in part because congruency in geometry has very certain definition and = I'm projecting that to term congruent path introduced in the document. In a= ddition I think that "same route" in the second sentence is vague= . Does that imply that active PE requests far-end PE to use co-routed LSP? If that is the case, should C bit explain= ed as request to use Co-routed path?

·         Last sentence of section 2.1 defines that detection of C and S bits being simultaneously set as error. How that error being signaled in LDP St= atus Codes?

 =

   = ;     Regards,

   = ;             G= reg

 =

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2szxeml558mbschi_-- From liushucheng@huawei.com Sun Jun 9 05:06:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E9621F9691 for ; Sun, 9 Jun 2013 05:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-t97R+5wEez for ; Sun, 9 Jun 2013 05:06:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D6B4B21F9642 for ; Sun, 9 Jun 2013 05:06:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASG07729; Sun, 09 Jun 2013 12:06:18 +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.1.323.7; Sun, 9 Jun 2013 13:06:13 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 13:06:15 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.81]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Sun, 9 Jun 2013 20:05:58 +0800 From: "Will Liu (Shucheng)" To: "mpls@ietf.org" Thread-Topic: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt Thread-Index: AQHOVlmidmIrNtZlCEydD0bqhMBO45kQf6+AgAOhJICABCuTMIAAvTOAgBRZESA= Date: Sun, 9 Jun 2013 12:05:57 +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.66.78.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:06:34 -0000 Folks, We addressed the comments from Francesco by updating the MplsLSPID descript= ion as pasted below. Please let us know your thoughts, thanks. MplsLSPID ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier within an MPLS network that is assigned to each LSP. This is assigned at the head end of the LSP and can be used by all LSRs to identify this LSP. This value is piggybacked by the signaling protocol when this LSP is signaled within the network. This identifier can then be used at each LSR to identify which labels are being swapped to other labels for this LSP. This object can also be used to disambiguate LSPs that share the same RSVP sessions between the same source and destination. For LSPs established using CR-LDP, the LSPID is composed of the ingress LSR Router ID (or any of its own IPv4 addresses) and a locally unique CR-LSP ID to that LSR. The first two bytes carry the CR-LSPID, and the remaining 4 bytes carry the Router ID. The LSPID is useful in network management, in CR-LSP repair, and in using an already established CR-LSP as a hop in an ER-TLV. For LSPs signaled using RSVP-TE, the LSP_ID is a local --= we mainly updated this paragraph number defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself. The LSP_ID is only unique within the context of the SESSION and it cannot be used as network identifier. RSVP-TE signaling use a 5-tuple to uniquely identify an LSP within an operator's network. This tuple is composed of a Tunnel End-point Address, Tunnel_ID, Extended Tunnel ID, Tunnel Sender Address, and LSP_ID. The length of this object should only be 2 or 6 bytes. If the length of this octet string is 2 bytes, then it must identify an RSVP-TE LSP_ID, or it is 6 bytes, it must contain a CR-LDP LSPID." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, [RFC3209]. Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX OCTET STRING (SIZE (2|6)) Regards, Will > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Will Liu (Shucheng) > Sent: Monday, May 27, 2013 9:09 PM > To: Francesco Fondelli > Cc: mpls@ietf.org > Subject: Re: [mpls] FW: New Version Notification for > draft-manral-mpls-rfc3811bis-02.txt >=20 > Hi Francesco, >=20 > Thanks for your comments. Please see below in-line. >=20 > > -----Original Message----- > > From: Francesco Fondelli [mailto:francesco.fondelli@gmail.com] > > Sent: Saturday, May 25, 2013 2:09 AM > > To: Will Liu (Shucheng) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] FW: New Version Notification for > > draft-manral-mpls-rfc3811bis-02.txt > > > > Hi Will, all, > > > > I have always thought MplsLSPID description in 3811 was misleading (or > > inconsistent): "A unique identifier within an MPLS network that is assi= gned > > to each LSP...". For LDP this is 6 bytes 'IP addr + local ID' and can > > be used as a network-unique handle. However, for LSPs signaled using > > RSVP-TE, RFC3811 suggests to use the LSP_ID (2 byte) used in the > > SENDER_TEMPLATE obj. This is just a local number (it is unique within > > the scope of the SESSION) so it cannot be used to uniquely identify an > > LSP on a network. >=20 > Agree. > > > > Can we also "fix" this in 3811bis ? >=20 > Yes. I think we can fix this in the next version. > > > > We can simply state (in the MplsLSPID description) that for LSPs signal= ed > > using RSVP-TE this is just a local number. Alternatively, we can make > > room (now is max 6 octets) for full network level LSP identification: > > 5-tuple { Destination Address, Tunnel_ID, Extended Tunnel ID, Sender > > Address, > > LSP_ID }. > > > > thank you > > ciao > > fra > > > > On Wed, May 22, 2013 at 5:02 AM, Will Liu (Shucheng) > > wrote: > > > Folks, > > > > > > We updated the draft by modifying the introduction, typos in section = 5, > and > > adding a section highlighting the changes on rfc3811. > > > > > > Your review and comments are highly appreciated. > > > > > > Regards, > > > Will > > > > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Wednesday, May 22, 2013 3:30 AM > > > To: Tina TSOU; Will Liu (Shucheng); Vishwas Manral; Will Liu (Shuchen= g) > > > Subject: New Version Notification for draft-manral-mpls-rfc3811bis-02= .txt > > > > > > > > > A new version of I-D, draft-manral-mpls-rfc3811bis-02.txt > > > has been successfully submitted by Vishwas Manral and posted to the > > > IETF repository. > > > > > > Filename: draft-manral-mpls-rfc3811bis > > > Revision: 02 > > > Title: Definitions of Textual Conventions (TCs) for > > Multiprotocol Label Switching (MPLS) Management > > > Creation date: 2013-05-20 > > > Group: Individual Submission > > > Number of pages: 22 > > > URL: > > http://www.ietf.org/internet-drafts/draft-manral-mpls-rfc3811bis-02.txt > > > Status: > > http://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis > > > Htmlized: > > http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-02 > > > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-manral-mpls-rfc3811bis-02 > > > > > > Abstract: > > > This memo defines a Management Information Base (MIB) module > > which > > > contains Textual Conventions to represent commonly used > > Multiprotocol > > > Label Switching (MPLS) management information. The intent is that > > > these TEXTUAL CONVENTIONS (TCs) will be imported and used in > > MPLS > > > related MIB modules that would otherwise define their own > > > representations. > > > > > > This document obsoletes RFC3811 as it addresses the need to suppor= t > > > IPv6 extended TunnelID's by defining a new TC- > > > MplsNewExtendedTunnelID which suggests using IPv4 address of the > > > ingress or egress LSR for the tunnel for an IPv6 network. Changes > > > from RFC3811 and the effect of the new TC to other related > > documents > > > are summarized in Section 4 and 5, respectively. > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > 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 Alexander.Vainshtein@ecitele.com Sun Jun 9 05:54:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F5221F8B64 for ; Sun, 9 Jun 2013 05:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.944 X-Spam-Level: * X-Spam-Status: No, score=1.944 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHJwqrjWRkCa for ; Sun, 9 Jun 2013 05:54:03 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFB221F8BB7 for ; Sun, 9 Jun 2013 05:54:02 -0700 (PDT) Received: from [85.158.136.67:63372] by server-4.bemta-5.messagelabs.com id BD/CB-12332-6EA74B15; Sun, 09 Jun 2013 12:53:58 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-207.messagelabs.com!1370782428!26606838!8 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17987 invoked from network); 9 Jun 2013 12:53:58 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-4.tower-207.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jun 2013 12:53:58 -0000 X-AuditID: 93eaf2e7-b7f736d000006937-b0-51b47ae23aed Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 86.AD.26935.2EA74B15; Sun, 9 Jun 2013 15:53:54 +0300 (IDT) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Sun, 9 Jun 2013 15:53:52 +0300 From: Alexander Vainshtein To: "Hejia (Jia)" Thread-Topic: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv Thread-Index: AQHOS8JMkQ5ZZhSZYU2ktTA0E8MN1pkSvnnwgBq6lqA= Date: Sun, 9 Jun 2013 12:53:51 +0000 Message-ID: References: <518A064C.7090006@pi.nu> <735916399E11684EAF4EB4FB376B71952C6CCBDA@SZXEML505-MBX.china.huawei.com> In-Reply-To: <735916399E11684EAF4EB4FB376B71952C6CCBDA@SZXEML505-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="gb2312" content-transfer-encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUy+dWnL7qPqrYEGqy8b2TRMuUds8W/uXOY LW4tXcnqwOzRcuQtq8eSJT+ZPGZNb2MLYI5qYLRJzMvLL0ksSVVISS1OtlUKKMosS0yuVFLI TLFVMlRSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+uhYWppa6 hkp2asqGxtZcIRmZxQqpurmJmTkKuanFxYnpqQpAkYQtzBnN/4QK1qhWbOw7z9rAuEGli5GT Q0LARGLjwnnMELaYxIV769m6GLk4hAQOMkocWbuQFcI5wigx6/EzNpAqNgFbiU2r74LZIgIq ErtO97OAFDELrGGS+PP3ExNIQljAVeLbt9nMEEVuEuv23waKcwDZVhIdTyxBwixAvdtOrwab wysQINF98RCYLSRQIDH13EVWEJtTIEzixurFLCA2I9B130+tARvPLCAucevJfCaIqwUkluw5 D/WBqMTLx/9YIWw5iSdPTrFA1GtJzGv4DdWrKDGl+yE7xF5BiZMzn7BA1EtKHFxxg2UCo/gs JCtmIWmfhaR9FpL2BYwsqxhFM3MKSpJy0w0M9VKTM0tSc1L1kvNzNzFCUsvzHYy/5qscYnQF +nsisxR3cj4wNeWVxBsbGODmKInzLm8I9xcSSAemm+zU1ILUovii0pzU4kOMTBycUg2Md2f2 BS/Ys5bNOeT3kqajKyyT/uvJ/k/yDtun63iwebuf66vruTn3fN/a/5l/U/ZRVE1k2VJb7YeN mWmnNQwDb+7TSL3++a3yZ7G1DX96Nm41SJy44OONLc1dLP9Xv3t1Xa3mt7LLE/PkrQd4DqzS bvk87/UMUSH3D36Gu6qv2PJEb32+t1djvhJLcUaioRZzUXEiAEf2dt0lAwAA Cc: "draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:54:08 -0000 SmlhIGFuZCBhbGwsDQoNCkkgZnVsbHkgYWdyZWUgdGhhdCB0aGUgdGV4dCBleHBsYWluaW5n IHdoeSBBQ0ggVExWcyBhcmUgbm90IG5lZWRlZCBkb2VzIG5vdCBoYXZlIHRvIGJlIHZlcnkg c3BlY2lmaWMuIA0KDQpBdCB0aGUgc2FtZSB0aW1lIEkgYW0gbm90IHN1cmUgdGhhdCBNRVAt SUQgVExWIGluIFJGQyA2NDI4IGlzIGEgc3Ryb25nIGV4YW1wbGUgZm9yIHRoZSBuZWVkIG9m IEhXIHByb2Nlc3Npbmcgb2YgVExWcyBpbiBHLUFDSCBtZXNzYWdlcy4NCg0KTXkgMmMsDQog ICAgIFNhc2hhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbXBs cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YNCj4gSGVqaWEgKEppYSkNCj4gU2VudDogVGh1cnNkYXksIE1heSAyMywgMjAx MyAyOjUyIFBNDQo+IFRvOiBMb2EgQW5kZXJzc29uOyBNYXJ0aW4gVmlnb3VyZXV4OyBkcmFm dC1mYXJicnlhbnRyZWwtbXBscy1yZXRpcmUtYWNoLQ0KPiB0bHZAdG9vbHMuaWV0Zi5vcmc7 IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+IENjOiBtcGxzQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbbXBsc10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtZmFyYnJ5YW50cmVs LW1wbHMtcmV0aXJlLWFjaC10bHYNCj4gDQo+IEhpLA0KPiANCj4gSSBub3RpY2VkIGEgMDEg dmVyc2lvbiBvZiBkcmFmdC1mYXJicnlhbnRyZWwtbXBscy1yZXRpcmUtYWNoLXRsdiBpcyBh dmFpbGFibGUuIFNvIEkNCj4gYmFzZWQgbXkgTVBMUyBSVCByZXZpZXcgb24gdGhhdCB2ZXJz aW9uLiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBjb2hlcmVudCwNCj4gdXNlZnVsLCB0ZWNo bmljYWxseSBzb3VuZCBhbmQgcmVhZHkgdG8gYmUgYWRvcHRlZCBhcyBhIFdHIGRyYWZ0LiBK dXN0IG9uZQ0KPiBjb21tZW50Og0KPiANCj4gMSkgSW4gdGhlIEFic3RyYWN0IHBhcnQsIGl0 IGlzIHdyaXR0ZW4gYXMNCj4gDQo+ICAgIE5vIEFzc29jaWF0ZWQgQ2hhbm5lbCBUeXBlIHll dCBkZWZpbmVkIHVzZXMgYSBUTFYuIEZ1cnRoZXJtb3JlLCBpdA0KPiAgICBpcyBiZWxpZXZl ZCB0aGF0IGhhbmRsaW5nIFRMVnMgaW4gaGFyZHdhcmUgaW50cm9kdWNlcyBzaWduaWZpY2Fu dA0KPiAgICBwcm9ibGVtcyB0byB0aGUgZmFzdC1wYXRoLCBhbmQgc2luY2UgRy1BQ2ggbWVz c2FnZXMgYXJlIGludGVuZGVkIHRvDQo+ICAgIGJlIHByb2Nlc3NlZCBzdWJzdGFudGlhbGx5 IGluIGhhcmR3YXJlLCB0aGUgdXNlIG9mIFRMVnMgaW4NCj4gICAgdW5kZXNpcmFibGUuDQo+ IA0KPiBUaGUgd2hvbGUgcGFyYWdyYXBoIHNlZW1zIHRhbGtpbmcgZ2VuZXJhbGx5IGFib3V0 IFRMVnMgZm9yIEctQUNoIG1lc3NhZ2VzLA0KPiBub3Qgc3BlY2lmaWNhbGx5IGFuIEFDSCBU TFYuIFRoaXMgbWlnaHQgbm90IGJlIHNvIGFjY3VyYXRlIHNpbmNlIHdlIGhhdmUgc29tZQ0K PiBHLUFDaCBjaGFubmVsIHR5cGUgdXNpbmcgVExWcyBpbiBpdHMgbWVzc2FnZSwgZS5nLiBS RkMgNjQyOCBkZWZpbmVzIGEgc291cmNlDQo+IE1FUC1JRCBUTFYgZm9yIHRoZSBNUExTLVRQ IENWIHR5cGUgd2hpY2ggYWxzbyByZXF1aXJlcyBoYXJkd2FyZSBwcm9jZXNzaW5nLiBJDQo+ IHRoaW5rIGl0IG1pZ2h0IGJlIGJldHRlciB0byBzaW1wbHkgc2F5IEFDSCBUTFYgaXMgbm90 IHVzZWQgYW5kIG1heSBjYXVzZQ0KPiBhZGRpdGlvbmFsIHByb2Nlc3Npbmcgd2hpY2ggaXMg bm90IGRlc2lyYWJsZS4gT3Igc29tZSBiZXR0ZXIgd29yZGluZy4uLg0KPiANCj4gVGhhbmtz IQ0KPiANCj4gDQo+IEIuUi4NCj4gSmlhDQo+IA0KPiANCj4gLS0tLS3Tyrz+1K28/i0tLS0t DQo+ILeivP7IyzogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0NCj4gt6LLzcqx vOQ6IDIwMTPE6jXUwjjI1SAxNjowMQ0KPiDK1bz+yMs6IExpemhvbmcgSmluOyBIZWppYSAo SmlhKTsgR3JlZ29yeSBNaXJza3k7IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOw0KPiBNYXJ0 aW4gVmlnb3VyZXV4DQo+ILOty806IGRyYWZ0LWZhcmJyeWFudHJlbC1tcGxzLXJldGlyZS1h Y2gtdGx2QHRvb2xzLmlldGYub3JnOyBtcGxzLQ0KPiBjaGFpcnNAdG9vbHMuaWV0Zi5vcmcN Cj4g1vfM4jogTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtZmFyYnJ5YW50cmVsLW1wbHMtcmV0 aXJlLWFjaC10bHYNCj4gDQo+IEppYSwgTGl6aG9uZywgR3JlZyBhbmQgRXJpYywNCj4gDQo+ IFlvdSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgYW4gTVBMUyBSZXZpZXcgdGVhbSByZXZpZXdl cnMgZm9yDQo+IGRyYWZ0LWZhcmJyeWFudHJlbC1tcGxzLXJldGlyZS1hY2gtdGx2LTAwLg0K PiANCj4gTm90ZSB0byBhdXRob3JzOiBZb3UgaGF2ZSBiZWVuIENDJ2Qgb24gdGhpcyBlbWFp bCBzbyB0aGF0IHlvdSBjYW4ga25vdw0KPiB0aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9u LiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmlldyB5b3VyIG93bg0KPiBkb2N1bWVudC4N Cj4gDQo+IFJldmlld3Mgc2hvdWxkIGNvbW1lbnQgb24gd2hldGhlciB0aGUgZG9jdW1lbnQg aXMgY29oZXJlbnQsIGlzIGl0DQo+IHVzZWZ1bCAoaWUsIGlzIGl0IGxpa2VseSB0byBiZSBh Y3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0aW9uYWwNCj4gbmV0d29ya3MpLCBhbmQgaXMgdGhl IGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5kPyAgV2UgYXJlIGludGVyZXN0ZWQNCj4gaW4g a25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBjb25zaWRlcmVk IGZvciBXRw0KPiBhZG9wdGlvbiAoaWUsIGl0IGRvZXNuJ3QgaGF2ZSB0byBiZSBwZXJmZWN0 IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUNCj4gYSBnb29kIHN0YXJ0KS4NCj4gDQo+ IFJldmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50IGF1dGhvcnMsIFdHIGNv LWNoYWlycyBhbmQNCj4gV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUgTVBMUyBXRyBl bWFpbCBsaXN0LiBJZiBuZWNlc3NhcnksIGNvbW1lbnRzDQo+IG1heSBiZSBzZW50IHByaXZh dGVseSB0byBvbmx5IHRoZSBXRyBjaGFpcnMuDQo+IA0KPiBBcmUgeW91IGFibGUgdG8gcmV2 aWV3IHRoaXMgZHJhZnQgYnkgTWF0IDI0LCAyMDEzPw0KPiANCj4gVGhhbmtzLCBMb2ENCj4g KGFzIE1QTFMgV0cgY2hhaXIpDQo+IC0tDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiAgICAg ICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gU2Vu aW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4g SHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgx IDIxIDY0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KVGhpcyBlLW1haWwgbWVz c2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBp bmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9w cmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFu c21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBv ciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhl cmVvZi4NCg0K From Alexander.Vainshtein@ecitele.com Sun Jun 9 07:28:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A96121F8F7B for ; Sun, 9 Jun 2013 07:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.944 X-Spam-Level: * X-Spam-Status: No, score=1.944 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfU7QSvfd+aU for ; Sun, 9 Jun 2013 07:28:14 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.144]) by ietfa.amsl.com (Postfix) with ESMTP id D136621F8F6D for ; Sun, 9 Jun 2013 07:28:13 -0700 (PDT) Received: from [85.158.139.211:55527] by server-8.bemta-5.messagelabs.com id 18/7A-29170-CF094B15; Sun, 09 Jun 2013 14:28:12 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1370788090!17564248!1 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22585 invoked from network); 9 Jun 2013 14:28:12 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jun 2013 14:28:12 -0000 X-AuditID: 93eaf2e7-b7f736d000006937-c6-51b490fabd90 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 79.3F.26935.AF094B15; Sun, 9 Jun 2013 17:28:10 +0300 (IDT) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Sun, 9 Jun 2013 17:28:09 +0300 From: Alexander Vainshtein To: John E Drake Thread-Topic: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv Thread-Index: AQHOS8JMkQ5ZZhSZYU2ktTA0E8MN1pkSvnnwgBq6lqD///RcAIAANbng Date: Sun, 9 Jun 2013 14:28:09 +0000 Message-ID: References: <518A064C.7090006@pi.nu> <735916399E11684EAF4EB4FB376B71952C6CCBDA@SZXEML505-MBX.china.huawei.com>, <98B2E045-3B7A-4C1E-8BCF-B67566F37CD5@juniper.net> In-Reply-To: <98B2E045-3B7A-4C1E-8BCF-B67566F37CD5@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.220.171] Content-Type: text/plain; charset="gb2312" content-transfer-encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUy+dWnL7q/JmwJNPg6xcSiZco7Zovvl5aw WNxaupLVgdmj5chbVo8lS34yeXy5/JktgDmqgdEmMS8vvySxJFUhJbU42VYpoCizLDG5Ukkh M8VWyVBJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrq GirZqSkbGltzhWRkFiuk6uYmZuYo5KYWFyempyoARRK2MGf8XTyfseCEWcX2awkNjFNMuxg5 OCQETCSmz3LpYuQEMsUkLtxbz9bFyMUhJHCQUeLU/0XMEM4RRonOZV+ZQKrYBGwlNq2+ywZi iwioSrz+9BKsg1lgCpPE5hcnwBLCAj4SbxrbmCGKfCXu7dnMCLJNRMBN4sD9XJAwi4CKxLzP 58Fm8goESMxb+4oFYtkrRok7n/aygCQ4Bewljvz4zw5iMwKd9/3UGrAGZgFxiVtP5jNBnC0g sWTPeWYIW1Ti5eN/rBC2gsTZ3cuZIeq1JOY1/IbqVZSY0v2QHWKxoMTJmU9YIOolJQ6uuMEy gVF8FpIVs5C0z0LSPgtJ+wJGllWMopk5BSVJuekGhnqpyZklqTmpesn5uZsYIanl+Q7GX/NV DjG6Aj0+kVmKOzkfmJrySuKNDQxwc5TEeZc3hPsLCaQD0012ampBalF8UWlOavEhRiYOTqkG xkM/y9ZZCDvoeXpdnxWt0MT0wtCkK6z+tPucjKMhf84ny3zZaiuTXzj18pXej1eU9N9n2z/O W9XebGxtOl1y7uTFjLPY3/89F/DE9vhagylXLwfb7lUSyDPT+zV/ffa0Dyw/Vf6/WuB+dsJi 1nstD4UW1PuFb9DYXnmyt+J5/OV/d9YaMmWa31RiKc5INNRiLipOBAAf+FOeJQMAAA== Cc: "draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson , "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:28:19 -0000 Sm9obiwNCkxvdHMgb2YgdGhhbmtzIGZvciBhIHByb21wdCByZXNwb25zZS4NCg0KSXQgZnVs bHkgbWF0Y2hlcyBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBzaXR1YXRpb24sIGFuZCB0aGlz IGlzIHdoeSBJJ3ZlIHNhaWQgdGhhdCB0aGUgZXhhbXBsZSBnaXZlbiBieSBKaWEgaXMgYSBz dHJvbmcgb25lLg0KDQpNeSAyYywNCiAgICAgU2FzaGENCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaG4gRSBEcmFrZSBbbWFpbHRvOmpkcmFrZUBqdW5p cGVyLm5ldF0NCj4gU2VudDogU3VuZGF5LCBKdW5lIDA5LCAyMDEzIDU6MTQgUE0NCj4gVG86 IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IENjOiBIZWppYSAoSmlhKTsgZHJhZnQtZmFyYnJ5 YW50cmVsLW1wbHMtcmV0aXJlLWFjaC10bHZAdG9vbHMuaWV0Zi5vcmc7DQo+IG1wbHNAaWV0 Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBMb2EgQW5kZXJzc29uDQo+IFN1 YmplY3Q6IFJlOiBbbXBsc10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtZmFyYnJ5YW50cmVs LW1wbHMtcmV0aXJlLWFjaC10bHYNCj4gDQo+IEFjdHVhbGx5LCB0aGUgZGVzaWduIGFsbG93 cyBDQyB0byBiZSBwcm9jZXNzZWQgaW4gaGFyZHdhcmUgYW5kIENWIGluIHNvZnR3YXJlDQo+ IHdoaWxlIGFsbG93aW5nIHRoZSBwcmVzZW5jZSBvZiB0aGUgKnRyYWlsaW5nKiBUTFYgdXNl ZCBpbiBDViB0byBiZSBkZXRlY3RlZCBpbg0KPiBoYXJkd2FyZS4NCj4gDQo+IFNlbnQgZnJv bSBteSBpUGhvbmUNCj4gDQo+IE9uIEp1biA5LCAyMDEzLCBhdCA4OjU0IEFNLCAiQWxleGFu ZGVyIFZhaW5zaHRlaW4iDQo+IDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4g d3JvdGU6DQo+IA0KPiA+IEppYSBhbmQgYWxsLA0KPiA+DQo+ID4gSSBmdWxseSBhZ3JlZSB0 aGF0IHRoZSB0ZXh0IGV4cGxhaW5pbmcgd2h5IEFDSCBUTFZzIGFyZSBub3QgbmVlZGVkIGRv ZXMgbm90DQo+IGhhdmUgdG8gYmUgdmVyeSBzcGVjaWZpYy4NCj4gPg0KPiA+IEF0IHRoZSBz YW1lIHRpbWUgSSBhbSBub3Qgc3VyZSB0aGF0IE1FUC1JRCBUTFYgaW4gUkZDIDY0MjggaXMg YSBzdHJvbmcNCj4gZXhhbXBsZSBmb3IgdGhlIG5lZWQgb2YgSFcgcHJvY2Vzc2luZyBvZiBU TFZzIGluIEctQUNIIG1lc3NhZ2VzLg0KPiA+DQo+ID4gTXkgMmMsDQo+ID4gICAgIFNhc2hh DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbXBs cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YNCj4gPj4gSGVqaWEgKEppYSkNCj4gPj4gU2VudDogVGh1cnNkYXksIE1heSAy MywgMjAxMyAyOjUyIFBNDQo+ID4+IFRvOiBMb2EgQW5kZXJzc29uOyBNYXJ0aW4gVmlnb3Vy ZXV4OyBkcmFmdC1mYXJicnlhbnRyZWwtbXBscy1yZXRpcmUtYWNoLQ0KPiA+PiB0bHZAdG9v bHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ID4+IENjOiBtcGxz QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gTVBMUy1SVCByZXZpZXcgb2Yg ZHJhZnQtZmFyYnJ5YW50cmVsLW1wbHMtcmV0aXJlLWFjaC10bHYNCj4gPj4NCj4gPj4gSGks DQo+ID4+DQo+ID4+IEkgbm90aWNlZCBhIDAxIHZlcnNpb24gb2YgZHJhZnQtZmFyYnJ5YW50 cmVsLW1wbHMtcmV0aXJlLWFjaC10bHYgaXMgYXZhaWxhYmxlLiBTbw0KPiBJDQo+ID4+IGJh c2VkIG15IE1QTFMgUlQgcmV2aWV3IG9uIHRoYXQgdmVyc2lvbi4gSSB0aGluayB0aGUgZG9j dW1lbnQgaXMgY29oZXJlbnQsDQo+ID4+IHVzZWZ1bCwgdGVjaG5pY2FsbHkgc291bmQgYW5k IHJlYWR5IHRvIGJlIGFkb3B0ZWQgYXMgYSBXRyBkcmFmdC4gSnVzdCBvbmUNCj4gPj4gY29t bWVudDoNCj4gPj4NCj4gPj4gMSkgSW4gdGhlIEFic3RyYWN0IHBhcnQsIGl0IGlzIHdyaXR0 ZW4gYXMNCj4gPj4NCj4gPj4gICBObyBBc3NvY2lhdGVkIENoYW5uZWwgVHlwZSB5ZXQgZGVm aW5lZCB1c2VzIGEgVExWLiBGdXJ0aGVybW9yZSwgaXQNCj4gPj4gICBpcyBiZWxpZXZlZCB0 aGF0IGhhbmRsaW5nIFRMVnMgaW4gaGFyZHdhcmUgaW50cm9kdWNlcyBzaWduaWZpY2FudA0K PiA+PiAgIHByb2JsZW1zIHRvIHRoZSBmYXN0LXBhdGgsIGFuZCBzaW5jZSBHLUFDaCBtZXNz YWdlcyBhcmUgaW50ZW5kZWQgdG8NCj4gPj4gICBiZSBwcm9jZXNzZWQgc3Vic3RhbnRpYWxs eSBpbiBoYXJkd2FyZSwgdGhlIHVzZSBvZiBUTFZzIGluDQo+ID4+ICAgdW5kZXNpcmFibGUu DQo+ID4+DQo+ID4+IFRoZSB3aG9sZSBwYXJhZ3JhcGggc2VlbXMgdGFsa2luZyBnZW5lcmFs bHkgYWJvdXQgVExWcyBmb3IgRy1BQ2gNCj4gbWVzc2FnZXMsDQo+ID4+IG5vdCBzcGVjaWZp Y2FsbHkgYW4gQUNIIFRMVi4gVGhpcyBtaWdodCBub3QgYmUgc28gYWNjdXJhdGUgc2luY2Ug d2UgaGF2ZQ0KPiBzb21lDQo+ID4+IEctQUNoIGNoYW5uZWwgdHlwZSB1c2luZyBUTFZzIGlu IGl0cyBtZXNzYWdlLCBlLmcuIFJGQyA2NDI4IGRlZmluZXMgYQ0KPiBzb3VyY2UNCj4gPj4g TUVQLUlEIFRMViBmb3IgdGhlIE1QTFMtVFAgQ1YgdHlwZSB3aGljaCBhbHNvIHJlcXVpcmVz IGhhcmR3YXJlDQo+IHByb2Nlc3NpbmcuIEkNCj4gPj4gdGhpbmsgaXQgbWlnaHQgYmUgYmV0 dGVyIHRvIHNpbXBseSBzYXkgQUNIIFRMViBpcyBub3QgdXNlZCBhbmQgbWF5IGNhdXNlDQo+ ID4+IGFkZGl0aW9uYWwgcHJvY2Vzc2luZyB3aGljaCBpcyBub3QgZGVzaXJhYmxlLiBPciBz b21lIGJldHRlciB3b3JkaW5nLi4uDQo+ID4+DQo+ID4+IFRoYW5rcyENCj4gPj4NCj4gPj4N Cj4gPj4gQi5SLg0KPiA+PiBKaWENCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS3Tyrz+1K28/i0t LS0tDQo+ID4+ILeivP7IyzogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0NCj4g Pj4gt6LLzcqxvOQ6IDIwMTPE6jXUwjjI1SAxNjowMQ0KPiA+PiDK1bz+yMs6IExpemhvbmcg SmluOyBIZWppYSAoSmlhKTsgR3JlZ29yeSBNaXJza3k7IEVyaWMgT3Nib3JuZSAoZW9zYm9y bmUpOw0KPiA+PiBNYXJ0aW4gVmlnb3VyZXV4DQo+ID4+ILOty806IGRyYWZ0LWZhcmJyeWFu dHJlbC1tcGxzLXJldGlyZS1hY2gtdGx2QHRvb2xzLmlldGYub3JnOyBtcGxzLQ0KPiA+PiBj aGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4g1vfM4jogTVBMUy1SVCByZXZpZXcgb2YgZHJh ZnQtZmFyYnJ5YW50cmVsLW1wbHMtcmV0aXJlLWFjaC10bHYNCj4gPj4NCj4gPj4gSmlhLCBM aXpob25nLCBHcmVnIGFuZCBFcmljLA0KPiA+Pg0KPiA+PiBZb3UgaGF2ZSBiZWVuIHNlbGVj dGVkIGFzIGFuIE1QTFMgUmV2aWV3IHRlYW0gcmV2aWV3ZXJzIGZvcg0KPiA+PiBkcmFmdC1m YXJicnlhbnRyZWwtbXBscy1yZXRpcmUtYWNoLXRsdi0wMC4NCj4gPj4NCj4gPj4gTm90ZSB0 byBhdXRob3JzOiBZb3UgaGF2ZSBiZWVuIENDJ2Qgb24gdGhpcyBlbWFpbCBzbyB0aGF0IHlv dSBjYW4ga25vdw0KPiA+PiB0aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVy LCBwbGVhc2UgZG8gbm90IHJldmlldyB5b3VyIG93bg0KPiA+PiBkb2N1bWVudC4NCj4gPj4N Cj4gPj4gUmV2aWV3cyBzaG91bGQgY29tbWVudCBvbiB3aGV0aGVyIHRoZSBkb2N1bWVudCBp cyBjb2hlcmVudCwgaXMgaXQNCj4gPj4gdXNlZnVsIChpZSwgaXMgaXQgbGlrZWx5IHRvIGJl IGFjdHVhbGx5IHVzZWZ1bCBpbiBvcGVyYXRpb25hbA0KPiA+PiBuZXR3b3JrcyksIGFuZCBp cyB0aGUgZG9jdW1lbnQgdGVjaG5pY2FsbHkgc291bmQ/ICBXZSBhcmUgaW50ZXJlc3RlZA0K PiA+PiBpbiBrbm93aW5nIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIGNv bnNpZGVyZWQgZm9yIFdHDQo+ID4+IGFkb3B0aW9uIChpZSwgaXQgZG9lc24ndCBoYXZlIHRv IGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZQ0KPiA+PiBhIGdvb2Qg c3RhcnQpLg0KPiA+Pg0KPiA+PiBSZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1 bWVudCBhdXRob3JzLCBXRyBjby1jaGFpcnMgYW5kDQo+ID4+IFdHIHNlY3JldGFyeSwgYW5k IENDJ2QgdG8gdGhlIE1QTFMgV0cgZW1haWwgbGlzdC4gSWYgbmVjZXNzYXJ5LCBjb21tZW50 cw0KPiA+PiBtYXkgYmUgc2VudCBwcml2YXRlbHkgdG8gb25seSB0aGUgV0cgY2hhaXJzLg0K PiA+Pg0KPiA+PiBBcmUgeW91IGFibGUgdG8gcmV2aWV3IHRoaXMgZHJhZnQgYnkgTWF0IDI0 LCAyMDEzPw0KPiA+Pg0KPiA+PiBUaGFua3MsIExvYQ0KPiA+PiAoYXMgTVBMUyBXRyBjaGFp cikNCj4gPj4gLS0NCj4gPj4NCj4gPj4NCj4gPj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAg ICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gPj4gU2VuaW9y IE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4gPj4g SHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgx IDIxIDY0DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+IG1wbHNAaWV0Zi5vcmcNCj4g Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4NCj4g Pg0KPiA+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGll bnQgb25seSBhbmQgY29udGFpbnMNCj4gaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5U SUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJDQo+IFRlbGVjb20uIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2Ug aW5mb3JtIHVzIGJ5IGUtDQo+IG1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtcGxzIG1h aWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGlu dGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9u IHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRv IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp biBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5k IHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KDQo= From IHussain@infinera.com Mon Jun 10 19:48:15 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07E921F9921 for ; Mon, 10 Jun 2013 19:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdnTx24ogdlZ for ; Mon, 10 Jun 2013 19:48:02 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9900921F98AD for ; Mon, 10 Jun 2013 19:48:02 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Mon, 10 Jun 2013 19:48:01 -0700 From: Iftekhar Hussain To: "mpls@ietf.org" Thread-Topic: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document Thread-Index: Ac5mTMOkX1QeZEVzTWWNL+RYHdGRfg== Date: Tue, 11 Jun 2013 02:48:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE53FA67323SVEXDBPROD2infi_" MIME-Version: 1.0 Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 02:48:16 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE53FA67323SVEXDBPROD2infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Thanks, Iftekhar > Working Group, > > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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. > > This poll ends June 14, 2013. > > There are two IPR claims against this document: > > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ > > > 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. > > /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 > --_000_D7D7AB44C06A2440B716F1F1F5E70AE53FA67323SVEXDBPROD2infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Thanks,

Iftekhar

> Working Group,

>

> This is to start a two week poll on adopting

> draft-lim-mpls-proxy-lsp-ping-02 as an MPLS wor= king group document.

>

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

> group mailing list (mpls at ietf.org). Please g= ive a technical

> motivation for your support/not support, especi= ally if you think that

> the document should not be adopted as a working= group document.

>

> This poll ends June 14, 2013.

>

> There are two IPR claims against this document:=

>

> https://datatracker.ietf.org/ipr/778/

> https://datatracker.ietf.org/ipr/2087/

>

>

> The authors has stated on the working group mai= ling list that they are

> not aware of any other IPR claims against this = draft.

> However if you are on the the mpls working grou= p mailing list and

> aware of IPR that relates to this draft, the ti= me to disclose this is

> now.

>

> /Loa

> (mpls wg co-chair)

> --

>

>

> Loa Andersson     &nbs= p;            &= nbsp;     email: loa@mail01.huawei.com

> Senior MPLS Expert     = ;            &n= bsp;        loa@pi.nu

> Huawei Technologies (consultant)  &nb= sp;  phone: +46 739 81 21 64

> _______________________________________________=

> mpls mailing list

> mpls@ietf.org

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

> 

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53FA67323SVEXDBPROD2infi_-- From ietf-secretariat-reply@ietf.org Tue Jun 11 09:03:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF8321F93B9 for ; Tue, 11 Jun 2013 09:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzZWX3TlYEmX for ; Tue, 11 Jun 2013 09:03:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B85FE21F938E for ; Tue, 11 Jun 2013 09:03:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130611160329.4126.6062.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2013 09:03:29 -0700 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 16:03:38 -0000 Changed milestone "Framework for IP multicast over label-switched paths ready for advancement.", set due date to March 2001 from March 2001. Changed milestone "Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards", set due date to August 2001 from August 2001. Changed milestone "Specification for MPLS-specific recovery ready for advancement.", set due date to August 2001 from August 2001. Changed milestone "Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards", set due date to August 2001 from August 2001. Changed milestone "Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards", set due date to August 2001 from August 2001. Changed milestone "Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards", set due date to August 2001 from August 2001. Changed milestone "Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards", set due date to August 2001 from August 2001. Changed milestone "Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards", set due date to August 2001 from August 2001. Changed milestone "Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard", set due date to October 2003 from October 2003. Changed milestone "Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard", set due date to October 2003 from October 2003. Changed milestone "Submit specification on LSP Ping to the IESG for publication as a Proposed Standard", set due date to July 2004 from July 2004. Changed milestone "Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS)", set due date to July 2004 from July 2004. Changed milestone "Submit an OAM Framework Document to the IESG for publication as an Informational RFC", set due date to August 2004 from August 2004. Changed milestone "Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs", set due date to December 2005 from December 2005. Changed milestone "Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard", set due date to December 2008 from December 2008. Changed milestone "Submit LDP extensions for P2MP LSPs", set due date to January 2009 from January 2009. Changed milestone "Submit MPLS security framework for publication as an informational RFC", set due date to March 2009 from March 2009. Changed milestone "Submit draft-ietf-mpls-tp-itu-t-identifiers for publication", set due date to November 2012 from November 2012. Changed milestone "Submit draft-ietf-mpls-entropy-label for publication", set due date to November 2012 from November 2012. Changed milestone "Submit draft-ietf-mpls-tp-security-framework for publication", set due date to December 2012 from December 2012. Changed milestone "Submit draft-ietf-mpls-ipv6-pw-lsp-ping for publication", set due date to December 2012 from December 2012. Changed milestone "Submit draft-ietf-mpls-mldp-in-band-signaling for publication", set due date to December 2012 from December 2012. Changed milestone "Submit draft-ietf-mpls-tp-ethernet-addressing for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-mip-mep-map for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-ring-protection for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-te-mib for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-use-cases-and-design for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-rosetta-stone for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-gach-adv for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-ipv6 for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-applicability-label-adv = for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-dod for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-hello-crypto-auth for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-return-path-specified-lsp-ping for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-targeted-mldp for publication", set due date to June 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-oam-id-mib for publication", set due date to July 2013 from July 2013. Changed milestone "Submit draft-ietf-mpls-seamless-mpls for publication", set due date to August 2013 from August 2013. Changed milestone "Submit draft-ietf-mpls-ldp-multi-topology for publication", set due date to September 2013 from May 2013. Changed milestone "Submit draft-ietf-mpls-seamless-mcast for publication", set due date to October 2013 from October 2013. Changed milestone "Submit draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf = for publication", set due date to November 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-tp-1ton-protection for publication", set due date to November 2013 from June 2013. Changed milestone "Submit draft-ietf-mpls-ldp-ip-pw-capability for publication", set due date to November 2013 from November 2013. Added milestone "Submit draft-ietf-mpls-retire-ach-tlv for publication", due November 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From prvs=7874684126=gregory.mirsky@ericsson.com Tue Jun 11 11:32:20 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354BD21F9799; Tue, 11 Jun 2013 11:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STqAcTEcFwtG; Tue, 11 Jun 2013 11:32:13 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6583C21F9811; Tue, 11 Jun 2013 11:32:12 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-bc-51b76d2b6b7d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.3B.17537.B2D67B15; Tue, 11 Jun 2013 20:32:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 14:32:10 -0400 From: Gregory Mirsky To: Mach Chen , "Caowei (Wayne)" , Attila Takacs , "ppan@infinera.com" , "mpls@ietf.org" , "pwe3@ietf.org" Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2MgA690VAAIXnbXA= Date: Tue, 11 Jun 2013 18:32:09 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@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.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPuK527vZAg6PrZCwurBW2uLV0JavF isfvWC36Pm1hsWg+dordgdWj5chbVo8lS34yeVx6cYgtgDmK2yYpsaQsODM9T98ugTvjyMLj 7AVHtzBVdF3dydLAeHgyUxcjB4eEgInEiS8sXYycQKaYxIV769m6GLk4hASOMkr8/vaSHcJZ zihx93MrE0gVm4CRxIuNPWAJEYG3jBK/pvaxgSSEBVwltrQ3gBWJCLhJTO1dwAZhW0msXL6Z FcRmEVCV2HtzGdg6XgFfifUPV0NtmMkosWbNPLBmToEwiRfLt4IVMQLd9P3UGrA4s4C4xK0n 85kgbhWQWLLnPDOELSrx8vE/VghbWWLJk/0sEPX5EjdO7GSDWCYocXLmE5YJjCKzkIyahaRs FpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chgEyMw2o5JsOnuYNzz 0vIQozQHi5I4rxrv4kAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBcerluGuXmdX3PxLs XB1SIsYd/sE/oPkmw64czzD2b/M7jU5fFJpfpCEdUfHoy8OcveaPVtxkNbt85/HLJ9bbu9a/ Wx8xjf2HUfGuWoGj1WtW5nqeEmaw2vZnxcqFDB03JFhex1xa3JTRfij17Hm3H2v/XZYvaEk6 udnb2OTDsdZN5jo1fjc+/VNiKc5INNRiLipOBAAyZepLiQIAAA== Subject: Re: [mpls] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 18:32:20 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mach, yes, I think I see what caused your hesitation "the remote T-PE/S-PEs to es= tablish a new (co-routed) LSP". Frankly, I need to go back to authoritive s= ources, but I think that signaling of a co-routed LSP is not mandated to be= in single Path/Resv pass. I think that if intention is to map PW onto co-r= outed LSP, then C in C-bit should stand for "co-routed". Regards, Greg ________________________________ From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Saturday, June 08, 2013 8:03 PM To: Gregory Mirsky; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@= ietf.org; pwe3@ietf.org Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Hi Greg, Thanks for your comments! Yes, it intends to mean co-routed here. Not use the "co-routed" because the= re is definition of co-routed bidirectional LSP, where the "co-routed" mea= ns not only co-routed but signaled by a single path/resv exchange. If the W= G think co-routed is better, I am fine to change to it. For example, change the C (Congruent Path) bit to C (Co-routed path) bit, a= nd then it's definition would like this: "C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the prope= rties of the underlying LSPs. When set, the remote T-PE/S-PEs need to selec= t co-routed LSP as the PSN tunnel. If there is no such tunnel available, th= e node may trigger the remote T-PE/S-PEs to establish a new LSP." How do you think? Best regards, Mach From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, June 08, 2013 6:19 AM To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.= org; pwe3@ietf.org Subject: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Dear Authors, et al., I've prepared some questions and comments that I hope you'll kindly conside= r: * I've got confused by definition of C bit in section 2.1. That mig= ht be in part because congruency in geometry has very certain definition an= d I'm projecting that to term congruent path introduced in the document. In= addition I think that "same route" in the second sentence is vague. Does t= hat imply that active PE requests far-end PE to use co-routed LSP? If that = is the case, should C bit explained as request to use Co-routed path? * Last sentence of section 2.1 defines that detection of C and S bi= ts being simultaneously set as error. How that error being signaled in LDP = Status Codes? Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mach,
yes, I think I see what caused yo= ur hesitation "the remote T-PE/S-PEs to establish a new (co-routed) LS= P". Frankly, I need to go back to authoritive sources, but I think that signaling of a co-routed LSP is not mandated to be in sin= gle Path/Resv pass. I think that if intention is to map PW onto co-routed L= SP, then C in C-bit should stand for "co-routed".
 
 &n= bsp;  Regards,
 &n= bsp;      Greg

From: Mach Chen [mailto:mach.chen@h= uawei.com]
Sent: Saturday, June 08, 2013 8:03 PM
To: Gregory Mirsky; Caowei (Wayne); Attila Takacs; ppan@infinera.com= ; mpls@ietf.org; pwe3@ietf.org
Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-0= 1

= Hi Greg,

=  

= Thanks for your comments!

=  

= Yes, it intends to mean co-routed here. Not use the “co-routed” because there is defin= ition of  co-routed bidirectional LSP, where the “co-routed”= means not only co-routed but signaled by a single path/resv exchange. If the WG think co-routed is better, I am fine to= change to it.

=  

= For example, change the C (Congruent Path) bit to C (Co-routed path) bit, and then it’s defi= nition would like this:

=  

= “C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the properties of the underlying = LSPs. When set, the remote T-PE/S-PEs need to select co-routed LSP as the P= SN tunnel. If there is no such tunnel available, the node may trigger the r= emote T-PE/S-PEs to establish a new LSP.”

=  

= How do you think?

=  

= Best regards,

= Mach

=  

From:<= /b> Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, June 08, 20= 13 6:19 AM
To: Mach Chen; Caowei (Wayn= e); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: Comments to draft-= ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01

 

Dear Authors, et al.,

I've prepared some questions and comments th= at I hope you'll kindly consider:

·= ;         I've got confused by d= efinition of C bit in section 2.1. That might be in part because congruency in geometry has very certain definitio= n and I'm projecting that to term congruent path introduced in the document= . In addition I think that "same route" in the second sentence is= vague. Does that imply that active PE requests far-end PE to use co-routed LSP? If that is the case, should C bit explain= ed as request to use Co-routed path?

·= ;         Last sentence of secti= on 2.1 defines that detection of C and S bits being simultaneously set as error. How that error being signaled in L= DP Status Codes?

 

        R= egards,

       &n= bsp;        Greg

 

--_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_-- From mach.chen@huawei.com Thu Jun 13 00:58:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BC21F9A38; Thu, 13 Jun 2013 00:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX5MPVlhrxeW; Thu, 13 Jun 2013 00:57:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E62621F99E9; Thu, 13 Jun 2013 00:57:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASK37160; Thu, 13 Jun 2013 07:57:51 +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.1.323.7; Thu, 13 Jun 2013 08:57:27 +0100 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 08:57:40 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.007; Thu, 13 Jun 2013 15:56:20 +0800 From: Mach Chen To: Gregory Mirsky , "Caowei (Wayne)" , Attila Takacs , "ppan@infinera.com" , "mpls@ietf.org" , "pwe3@ietf.org" Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2MgA690VAAIXnbXAATjsfsA== Date: Thu, 13 Jun 2013 07:56:20 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 07:58:00 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, OK, I am fine with "co-routed". In addition, regarding to "the C and S bits being simultaneously set", ther= e should be an error code should be signaled, a new status code("The C-bit = and S-bit cannot be both set") will be added in the next revision. Best regards, Mach From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, June 12, 2013 2:32 AM To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.= org; pwe3@ietf.org Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Hi Mach, yes, I think I see what caused your hesitation "the remote T-PE/S-PEs to es= tablish a new (co-routed) LSP". Frankly, I need to go back to authoritive s= ources, but I think that signaling of a co-routed LSP is not mandated to be= in single Path/Resv pass. I think that if intention is to map PW onto co-r= outed LSP, then C in C-bit should stand for "co-routed". Regards, Greg ________________________________ From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Saturday, June 08, 2013 8:03 PM To: Gregory Mirsky; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@= ietf.org; pwe3@ietf.org Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Hi Greg, Thanks for your comments! Yes, it intends to mean co-routed here. Not use the "co-routed" because the= re is definition of co-routed bidirectional LSP, where the "co-routed" mea= ns not only co-routed but signaled by a single path/resv exchange. If the W= G think co-routed is better, I am fine to change to it. For example, change the C (Congruent Path) bit to C (Co-routed path) bit, a= nd then it's definition would like this: "C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the prope= rties of the underlying LSPs. When set, the remote T-PE/S-PEs need to selec= t co-routed LSP as the PSN tunnel. If there is no such tunnel available, th= e node may trigger the remote T-PE/S-PEs to establish a new LSP." How do you think? Best regards, Mach From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, June 08, 2013 6:19 AM To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.= org; pwe3@ietf.org Subject: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Dear Authors, et al., I've prepared some questions and comments that I hope you'll kindly conside= r: * I've got confused by definition of C bit in section 2.1. That mig= ht be in part because congruency in geometry has very certain definition an= d I'm projecting that to term congruent path introduced in the document. In= addition I think that "same route" in the second sentence is vague. Does t= hat imply that active PE requests far-end PE to use co-routed LSP? If that = is the case, should C bit explained as request to use Co-routed path? * Last sentence of section 2.1 defines that detection of C and S bi= ts being simultaneously set as error. How that error being signaled in LDP = Status Codes? Regards, Greg --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Greg,

=  

= OK= , I am fine with “co-routed”.

=  

= In addition, regarding to “the C and S bits being simultaneously set= 221;, there should be an error code should be signaled, a new status code(&= #8220;The C-bit and S-bit cannot be both set”) will be added in the n= ext revision.

=  

= Be= st regards,

= Ma= ch

=  

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, June 12, 20= 13 2:32 AM
To: Mach Chen; Caowei (Wayne= ); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: RE: Comments to dra= ft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01

 

Hi Mach,

yes, I think I see what caused your hesitation "the remote T-= PE/S-PEs to establish a new (co-routed) LSP". Frankly, I need to go back to au= thoritive sources, but I think that signaling of a co-routed LSP is not man= dated to be in single Path/Resv pass. I think that if intention is to map P= W onto co-routed LSP, then C in C-bit should stand for "co-routed".

 

    = Regards,

        = Greg

 

From: Mach Chen [mailto:mach.chen@huawei.com]
Sent: Saturday, June 08, 201= 3 8:03 PM
To: Gregory Mirsky; Caowei (= Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: RE: Comments to dra= ft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01<= /span>

= Hi Greg,=

=  

= Thanks for your comments!

=  

= Yes, it intends to mean co-routed here. Not use the “co-routed” because there is definition of  co-routed bidirectional LSP, where the “co-routed” means= not only co-routed but signaled by a single path/resv exchange. If the WG = think co-routed is better, I am fine to change to it.

=  

= For example, change the C (Congru= ent Path) bit to C (Co-routed path) bit, and then it’s definition would = like this:

=  

= “C (Co-routed path) bit: Th= is informs the remote T-PE/S-PEs about the properties of the underlying LSPs. When se= t, the remote T-PE/S-PEs need to select co-routed LSP as the PSN tunnel. If= there is no such tunnel available, the node may trigger the remote T-PE/S-= PEs to establish a new LSP.”

=  

= How do you think?

=  

= Best regards,

= Mach

=  

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, June 08, 201= 3 6:19 AM
To: Mach Chen; Caowei (Wayne= ); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: Comments to draft-i= etf-pwe3-mpls-tp-pw-over-bidir-lsp-01

 

Dear Authors, et = al.,

I've prepared som= e questions and comments that I hope you'll kindly consider:

·    = ;     I've got confused by defin= ition of C bit in section 2.1. That might be in part because congruency in geometry has very certain definition and I'm projecting that to term co= ngruent path introduced in the document. In addition I think that "sam= e route" in the second sentence is vague. Does that imply that active = PE requests far-end PE to use co-routed LSP? If that is the case, should C bit explained as request to use Co-routed pa= th?

·    = ;     Last sentence of section 2= .1 defines that detection of C and S bits being simultaneously set as error. How that error being signaled in LDP Status Codes?

 =

   = ;     Regards,

   = ;             G= reg

 =

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_-- From loa@pi.nu Thu Jun 13 05:45:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECE821F9A58; Thu, 13 Jun 2013 05:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S9hshWzf43c; Thu, 13 Jun 2013 05:45:22 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id B875C21F9A31; Thu, 13 Jun 2013 05:44:10 -0700 (PDT) Received: from [10.140.13.213] (109.58.145.109.bredband.tre.se [109.58.145.109]) (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 8E4E81800272; Thu, 13 Jun 2013 14:44:08 +0200 (CEST) Message-ID: <51B9BE97.2090103@pi.nu> Date: Thu, 13 Jun 2013 14:44:07 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" , "pwe3@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: [mpls] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:45:28 -0000 Working Groups, PWE3 working group, This is to start a two week working group last call on an MPLS document, but since it will be of interest to the PWE3 group also the chairs agreed to copy it to the PWE3 mailing list as well. Please keep the discussion on the mpls working group mailing list. MPLS working group, this is to start a two week Working Group last call on draft-ietf-mpls-retire-ach-tlv-01. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and if you are happy with the document as is also indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPRs applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on June 27, 2013. /Loa for the 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 zengxinzong@huawei.com Thu Jun 13 05:53:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8A621F9A8C for ; Thu, 13 Jun 2013 05:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6jUWRpsRanS for ; Thu, 13 Jun 2013 05:53:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 886C321F96D9 for ; Thu, 13 Jun 2013 05:53:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATW64262; Thu, 13 Jun 2013 12:53:26 +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.1.323.7; Thu, 13 Jun 2013 13:53:16 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 13:53:23 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.49]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Thu, 13 Jun 2013 20:53:11 +0800 From: "Zengxinzong (Paul)" To: "mpls@ietf.org" , "zali@cisco.com" , "rgandhi@cisco.com" , "tsaad@cisco.com" , "y.kamite@ntt.com" , "robert.h.venator.civ@mail.mil" Thread-Topic: Comments to draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01 Thread-Index: Ac5oNPRPEcUj4e5gSdK7l002xkcB1Q== Date: Thu, 13 Jun 2013 12:53:10 +0000 Message-ID: <54B334E2F9AB214C80ABE154F4E754792AF225F5@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.165] Content-Type: multipart/alternative; boundary="_000_54B334E2F9AB214C80ABE154F4E754792AF225F5nkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Loa Andersson Subject: [mpls] Comments to draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:53:36 -0000 --_000_54B334E2F9AB214C80ABE154F4E754792AF225F5nkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, I've prepared some comments and I hope you'll kindly consider: 1. In RFC 4875, it is not clearly defined the remerge behavior, some im= plementation will accept remerge and some will not based on local policy. - From section 4.3: When a node that does not support data plane based re-merge handling receives an S2L sub-LSP Path message with LSP Attributes sub-object that has "P2MP-TE Re-merge Recording Request" Flag set, and if the S2L is causing a re-merge condition, the node MUST reject the S2L sub-LSP Path message and send the PathErr with the error code "Routing Problem" and the error value "ERO resulted in re-merge" as specified in [RFC4875]. In this draft section 4.3, it says must send PathErr when remerge happened,= if the implementation do not support this draft, the behavior is discard t= he "P2MP-TE Re-merge Recording Request" Flag and do not send PathErr back, = so it will cause backward compatibility issue. I think the default behavior of remerge process should not be changed. 2. From section 3.2: If the ingress node receives a PathErr message with error code "Routing Problem" and error value "ERO resulted in re-merge", then it SHOULD attempt to signal an alternate path through a different domain or through a different border node for the affected S2L sub-LSPs. When CSPF calculate for the affected S2L sub-LSPs, the un-affected S2L sub-= LSPs path maybe also be changed. Each calculation of CSPF must consider all= the S2L sub-LSPs, so in some scenario the un-affected S2L sub-LSPs change = cannot be avoided. If the affected and un-affected S2L sub-LSPs do the crank-back process, it = maybe cause new remerge and fall in a deadlock. How to solve this? 3. From section 3.1: Single Border Node For All S2Ls I think double border node is very common in the inter area, so if restrict= to single border node, it seems not meet most requirement. 4. From section 6, LSP reoptimization and Sub-LSP reoptimization is dif= ferent, I think we need to clarify when to do the lsp reoptimization and wh= en do the Sub-LSP reoptimization, it seems very confusing here. Regards, Paul zeng --_000_54B334E2F9AB214C80ABE154F4E754792AF225F5nkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

 

I've prepared some comments and I hope you'll kindly consid= er:

 

1.  &n= bsp;  In RFC 4875, it is= not clearly defined the remerge behavior, some implementation will accept = remerge and some will not based on local policy.

 

- From section 4.3:

When a node that does not support data plane based re-merge handli= ng

   receives an S2L sub-LSP Path message with LSP= Attributes sub-object

   that has "P2MP-TE Re-merge Recording Req= uest" Flag set, and if the

   S2L is causing a re-merge condition, the node= MUST reject the S2L

   sub-LSP Path message and send the PathErr wit= h the error code

   "Routing Problem" and the error val= ue "ERO resulted in re-merge" as

&= nbsp;  specified in [RFC4875].

 

In this draft section 4.3, it says must send Path= Err when remerge happened, if the implementation do not support this draft,= the behavior is discard the "P2MP-TE Re-merge Recording Request" Flag and do not send PathErr back, so it will cause backward= compatibility issue.

I think the default behavior of remerge process s= hould not be changed.

 

 

2.  &n= bsp;  From section 3.2:<= o:p>

If the ingress node receives a PathErr message with error code

"Routing Problem" and error value "ERO resulted in = re-merge", then it

SHOULD attempt to signal an alternate path through a different dom= ain

or through a different border node for the affected S2L sub-LSPs.<= o:p>

 

When CSPF calculate for the affected S2L = sub-LSPs, the un-affected S2L sub-LSPs path maybe also be changed. Each calculation of CSPF must consider all the S2L sub-LSPs, so in some sc= enario the un-affected S2L sub-LSPs change cannot be avoided.

If the affected and un-affected S2L sub-L= SPs do the crank-back process, it maybe cause new remerge and fall in a deadlock. How to solve this?

 

3.  &n= bsp;  From section 3.1: = Single Border Node For All S2Ls

 

I think double border node is very common= in the inter area, so if restrict to single border node, it seems not meet most requirement.

 

4.  &n= bsp;  From section 6, LS= P reoptimization and Sub-LSP reoptimization is different, I think we need t= o clarify when to do the lsp reoptimization and when do the Sub-LSP reoptimization, it seems very confusing here.

 

 

 

Regards,

      Paul zeng<= /p>

 

--_000_54B334E2F9AB214C80ABE154F4E754792AF225F5nkgeml507mbschi_-- From venkatflex@gmail.com Thu Jun 13 17:11:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4CC21F9B25 for ; Thu, 13 Jun 2013 17:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMrTw5HWqP9d for ; Thu, 13 Jun 2013 17:11:27 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 199B821F9B23 for ; Thu, 13 Jun 2013 17:11:26 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so1108747wgg.34 for ; Thu, 13 Jun 2013 17:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/BvAFB/LS9ZoW9ZRVpWJE2tmeE9yAjkaeBHFJ/OamQ0=; b=RPjFtsAYYRhC6I70WPUesIrR2NpmVu5CxXexqYD5JXghO9hcvo22aqQVivAymYP9jM 34ywyHTD8hH1U305jqcB6B90q2qVuAGtVAw8SBFU6j7oF0Qzq0ESzJUmoWXviI13hQYo FV7XVN60ic0WAE+dNHvmdwPpujW9Kd3qfCf04IHPbqcBGMx2TO+YwgToRDG6V+N7gjxS +gGYfnOlgHN1gMbHWoa5C45pV3eL0DiZqffX/KEKHBvOdZGofLrW2b75Z/OkxPHj4zB3 kN0+geHnYs8jmb0Mtr5flQWPR/hEgLUISE4expjLtvNNrbHdWEa/JwSvYe4AQcXpl6Hz Cjow== MIME-Version: 1.0 X-Received: by 10.180.103.103 with SMTP id fv7mr9005618wib.30.1371168686220; Thu, 13 Jun 2013 17:11:26 -0700 (PDT) Received: by 10.194.174.170 with HTTP; Thu, 13 Jun 2013 17:11:26 -0700 (PDT) In-Reply-To: References: <32CB7A1F0806AB4688CE3F22C29DAC870493882B@EXRAD5.ad.rad.co.il> Date: Thu, 13 Jun 2013 17:11:26 -0700 Message-ID: From: venkatesan mahalingam To: Venkatesan Mahalingam Content-Type: multipart/alternative; boundary=14dae9cc90a2782ea004df121653 Cc: "mpls@ietf.org" , Sam Aldrin Subject: Re: [mpls] Another comment to draft-ietf-mpls-tp-oam-id-mib-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 00:11:28 -0000 --14dae9cc90a2782ea004df121653 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Muly, As per the internal MPLS-TP OAM MIB authors discussion for outstanding MIB comments, we are planning to remove the object mplsOamIdMeProactiveOamSessI= ndex in the next version because we want to keep the MIB module simple and it is up to the MIB implementer to choose their own mechanism to provide the session reference between OAM and BFD modules. -Venkat. > > On Thu, Feb 14, 2013 at 8:03 AM, Muly Ilan wrote: > >> Hi,**** >> >> ** ** >> >> More than one proactive OAM session may be simultaneously activated over >> the same MEP. For example, CC-CV and PM (loss measurement and/or delay >> measurement).**** >> >> But in the mplsOamIdMeTable there=92s a pointer to only one session =96 >> mplsOamIdMeProactiveOamSessIndex.**** >> >> ** ** >> >> Instead of mplsOamIdMeProactiveOamSessIndex I suggest to define a new >> table that will list all the proactive OAM sessions per MEP.**** >> >> There are other alternatives but I think an additional table is the >> straightforward solution.**** >> >> ** ** >> >> Regards,**** >> >> ** ** >> >> Muly**** >> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --14dae9cc90a2782ea004df121653 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Muly,

As per the internal MPLS-TP= OAM MIB authors discussion for outstanding MIB comments, we are planning t= o remove the object=A0mplsOamIdMeProactiveOamSessIndex in the next version because we want to ke= ep the MIB module simple and it is up to the MIB implementer=A0to choose their own mechanism to provide the sessi= on reference between OAM and BFD modules.

=
-Venkat.

On T= hu, Feb 14, 2013 at 8:03 AM, Muly Ilan <muly_i@rad.com> wrote:<= br>

Hi,

=A0

More than one proactive OAM session may be simultane= ously activated over the same MEP. For example, CC-CV and PM (loss measurem= ent and/or delay measurement).

But in the mplsOamIdMeTable there=92s a pointer to o= nly one session =96 mplsOamIdMeProactiveOamSessIndex.

=A0

Instead of mplsOamIdMeProactiveOamSessIndex I sugges= t to define a new table that will list all the proactive OAM sessions per M= EP.

There are other alternatives but I think an addition= al table is the straightforward solution.

=A0

Regards,=

=A0

Muly



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


--14dae9cc90a2782ea004df121653-- From mustapha.aissaoui@alcatel-lucent.com Fri Jun 14 15:20:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC5B21E8087 for ; Fri, 14 Jun 2013 15:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKaZG4Qb8vo2 for ; Fri, 14 Jun 2013 15:20:07 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1D50B21E805D for ; Fri, 14 Jun 2013 15:20:07 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r5EMK4G9007420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jun 2013 17:20:05 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r5EMK0jq002890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Jun 2013 18:20:03 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.153]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 14 Jun 2013 18:20:00 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] status and paln for draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp Thread-Index: AQHOaU1PWQ5ymQqdLUWeLNf6ttLypQ== Date: Fri, 14 Jun 2013 22:20:00 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D60E50BFC@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <51A0F7FB.2040706@pi.nu> In-Reply-To: <51A0F7FB.2040706@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Loa Andersson Subject: Re: [mpls] status and paln for draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 22:20:13 -0000 Dear all, I read this draft and I have the following comments. 1. General comment: While I understand the need to work around a node which does not support re= -merge of S2L paths in the data plane (section 3), I am not able to compreh= end the need to avoid a node which supports it (section 4).=20 In a network where the ingress LER, or a border LSR, does not have visibili= ty of the entire network topology, a LSR node which supports the re-merge i= n data plane is actually preventing further unnecessary replication of traf= fic downstream of itself. However, it seems this draft is treating this as = a bad thing and is adding complicated procedures to record re-merge points = and in trying to avoid them may cause more duplication of packets over the = network. This is because if the ingress LER, or border LSR, decided to bran= ch out two sets of S2L paths by signaling them out off different border LSR= nodes and then these two sets intersected again in a downstream domain, re= routing them by excluding the re-merge node will only force one of the 2 S2= L sets to use disjoint paths and may cause duplication deeper into the netw= ork. Thus, I suggest that this draft focuses on describing resignaling procedure= s at ingress LER and border LSR nodes in the case of receiving a PathErr wi= th error code "Routing Problem" and error value "ERO resulted in re-merge".= This is because I can see that given the lack of topology knowledge at the= ingress LER and border LSR, there is a possibility of re-merge in downstre= am domain on a node which does not support data plane merging. Since this m= ay not be a correctable condition and can prevent some leaves from joining = the tree, re-routing a set of S2L paths by avoiding the node which does not= suppot re-merge in the data plane, and thus causing potentially more dupli= cation, might be an acceptable trade-off. This means keep section 3 but remove section 4. I am thus focusing my comme= nts on Section 3. 2. Section 3 - Control Plane Solution For Re-merge Handling " It is RECOMMENDED that boundary re-routing is requested for P2MP LSPs traversing multiple domains. This is because border nodes that are expanding loose hops are typically best placed to correct any re- merge errors that occur within their domain, not the ingress node. " I am having trouble understanding why a border node is best placed for corr= ecting a re-merge situation in its downstream domain. Unless the border nod= e itself created the re-merge situation when expanding the EROs for 2 sets = of S2Ls and in which case it can be corrected at the next re-optimization o= f those S2Ls, the most likely reason for re-merge is that the ingress LER, = due to limited topology view, signaled the two sets over two different bord= er LSRs and then they intersected in the second domain. But then, each bord= er node is only handling one set of S2Ls.=20 In the latter case, I can see that the border node which received the PathE= rr messages may want to avoid the re-merge node by rerouting around it and = thus achieving a higher S2L establishment rate at the expense of more traff= ic duplication in the network. 3. Section 3.1. - Single Border Node For All S2Ls " It is RECOMMENDED that the ingress node of a P2MP LSP selects the same ingress border node in the loose hop ERO for all sibling S2L sub-LSPs that transit through a given domain. The reason is that it will increase the possibility of re-merge downstream if two or more border nodes have roles simultaneously to expand loose EROs. An ingress border node that performs the loose ERO expansion for individual sub-LSP(s) has the necessary state information for the destinations transiting through its domain to ensure computed P2MP tree is re-merge free. " Without full topology knowledge, this is just another arbitrary decision li= ke the one which caused the re-merge to occur in the first place.=20 4. Section 3.2 - Crankback and PathErr Signaling Procedure Overall I think this section should explain what additional information is = needed on top of the PathErr message provided in RFC 4875 such that the cra= nckback information is meaningful. For example, you may want to report the = reporting node-id, which can be the border node which attempted to avoid th= e re-merge node but was unsuccessful.=20 ---------------------------------------------------------------------------= ----------------------------------------- -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Saturday, May 25, 2013 1:42 PM To: mpls@ietf.org; Adrian Farrel; draft-ietf-mpls-inter-domain-p2mp-rsvp-te= -lsp@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: [mpls] status and paln for draft-ietf-mpls-inter-domain-p2mp-rsvp-= te-lsp Working Group, On 2013-05-20 we requested publication of draft-ietf-mpls-inter-domain- p2m= p-rsvp-te-lsp as an RFC on the Standards Draft. After a timely and detailed AD review the document has been "returned to th= e working group for more work". The AD review comments has been has been sent to the working group mailing = list and to the authors. The comments are comprehensive, nevertheless the a= uthor should proceed as usual: - Create a list of the comments and for each comment explain how each comment has been addressed and verify that Adrian is comfortable about how the comments have been address. This process should to the extent possible take place on the mailing list. After further discussion with Adrian we have agreed that I as the document = shepherd should organize a review by "P2MP implementers". - The comments received via this review should be handle the same way as the comments from the AD review. I've a few names that I think fit the "P2MP implementer" profile, and will = soon send out mails directly to them. I'm also looking for more willing reviewers that are willing to undertake t= his review. If you are interested please send a uni-directional mail to me = or to the working group chairs. /Loa for the MPLS wg co-chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Sun Jun 16 02:52:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C018D21F8F0C for ; Sun, 16 Jun 2013 02:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuqzd-Xb+DhZ for ; Sun, 16 Jun 2013 02:51:55 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id CE70221F9C04 for ; Sun, 16 Jun 2013 02:51:54 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 521DA1800272; Sun, 16 Jun 2013 11:51:53 +0200 (CEST) Message-ID: <51BD8AB9.10407@pi.nu> Date: Sun, 16 Jun 2013 11:51:53 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] mLDP protection drafts reviewed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 09:52:00 -0000 Working Group, The working group chairs asked members of the MPLS-RT to review two drafts: draft-zhao-mpls-mldp-protections-03 and draft-wijnands-mpls-mldp-node-protection-02 We asked for a normal MPLS-RT review + suggestions how to move forward with the drafts. The feedback was a bit diversified, but an agreement that the drafts address the same problem but in two different ways. After the considering the reviews and drafts the working group chairs do not think it is possible to try to merge the drafts, and will therefore go ahead and start prepare polls to see if we have consensus to make one or the other or both wg drafts. Before we do this we'd like to to see the discussion of the merits of the other draft removed from each of the drafts. draft-zhao-mpls-mldp-protections were perceived as "hard to read" and need a substantial language and grammar review before we proceed. /Loa for 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 wwwrun@rfc-editor.org Mon Jun 17 07:32:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E474D21F8EF2 for ; Mon, 17 Jun 2013 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIVunmCuUD+Z for ; Mon, 17 Jun 2013 07:32:01 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 83BBF21F8D90 for ; Mon, 17 Jun 2013 07:32:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4388262113; Mon, 17 Jun 2013 07:29:55 -0700 (PDT) To: eric.gray@ericsson.com, nitinb@juniper.net, sboutros@cisco.com, raggarwa_1@yahoo.com, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20130617142955.4388262113@rfc-editor.org> Date: Mon, 17 Jun 2013 07:29:55 -0700 (PDT) Cc: joelrepiquet@gmail.com, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC6426 (3660) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:32:02 -0000 The following errata report has been submitted for RFC6426, "MPLS On-Demand Connectivity Verification and Route Tracing". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6426&eid=3660 -------------------------------------- Type: Editorial Reported by: Joël Repiquet Section: 7.2 Original Text ------------- Value Meaning Reference ----- ------------------- ----------------------------- 22 Static LSP this document (Section 2.4.1) 23 Static Pseudowire this document (Section 2.4.2) Corrected Text -------------- Value Meaning Reference ----- ------------------- ----------------------------- 22 Static LSP this document (Section 2.3.1) 23 Static Pseudowire this document (Section 2.3.2) Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6426 (draft-ietf-mpls-tp-on-demand-cv-07) -------------------------------------- Title : MPLS On-Demand Connectivity Verification and Route Tracing Publication Date : November 2011 Author(s) : E. Gray, N. Bahadur, S. Boutros, R. Aggarwal Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From loa@pi.nu Mon Jun 17 07:34:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3A921F9CB4 for ; Mon, 17 Jun 2013 07:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEXjs0ObZEmB for ; Mon, 17 Jun 2013 07:34:55 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0829921F9C8A for ; Mon, 17 Jun 2013 07:34:54 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 88781180121E; Mon, 17 Jun 2013 16:34:53 +0200 (CEST) Message-ID: <51BF1E8E.5080008@pi.nu> Date: Mon, 17 Jun 2013 16:34:54 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" References: <51A77FBD.6010605@pi.nu> In-Reply-To: <51A77FBD.6010605@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:35:00 -0000 Working Group, This poll has been closed. The working group chairs have noted that there is consensus to adopt the document as a working group document. However based on the discussion on the MPLS list we also think there are some minor changes that are needed before accepting the document. We will instruct the authors to update and the document. This will be done in a separate mail-thread between the authors and the wg-chairs and will be based on the discussion on the MPLS list during the call for adoption. Assuming that the document is updated appropriately, the wg-chairs may take the decision to accept the document without a further poll. /Loa for the mpls wg co-chairs On 2013-05-30 18:35, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at 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. > > This poll ends June 14, 2013. > > There are two IPR claims against this document: > > https://datatracker.ietf.org/ipr/778/ > https://datatracker.ietf.org/ipr/2087/ > > > 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. > > /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 rcallon@juniper.net Mon Jun 17 14:26:27 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9D921F9D79 for ; Mon, 17 Jun 2013 14:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.466 X-Spam-Level: X-Spam-Status: No, score=-98.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB18mqvynTkb for ; Mon, 17 Jun 2013 14:26:20 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id B328721F9476 for ; Mon, 17 Jun 2013 14:26:20 -0700 (PDT) Received: from mail152-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE034.bigfish.com (10.243.66.99) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Jun 2013 21:26:20 +0000 Received: from mail152-co1 (localhost [127.0.0.1]) by mail152-co1-R.bigfish.com (Postfix) with ESMTP id 0DCB9A0036D for ; Mon, 17 Jun 2013 21:26:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic85fh4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL18c673h8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail152-co1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=rcallon@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail152-co1 (localhost.localdomain [127.0.0.1]) by mail152-co1 (MessageSwitch) id 1371504377714361_30513; Mon, 17 Jun 2013 21:26:17 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.232]) by mail152-co1.bigfish.com (Postfix) with ESMTP id A1D6F740064 for ; Mon, 17 Jun 2013 21:26:17 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Jun 2013 21:26:17 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 17 Jun 2013 14:26:16 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 17 Jun 2013 14:26:15 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 17 Jun 2013 14:38:14 -0700 Received: from mail224-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Jun 2013 21:26:13 +0000 Received: from mail224-va3 (localhost [127.0.0.1]) by mail224-va3-R.bigfish.com (Postfix) with ESMTP id 2FA1AC400F2 for ; Mon, 17 Jun 2013 21:26:13 +0000 (UTC) Received: from mail224-va3 (localhost.localdomain [127.0.0.1]) by mail224-va3 (MessageSwitch) id 1371504371682389_21440; Mon, 17 Jun 2013 21:26:11 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.240]) by mail224-va3.bigfish.com (Postfix) with ESMTP id A27B552022D; Mon, 17 Jun 2013 21:26:11 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Jun 2013 21:26:11 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.181]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0324.000; Mon, 17 Jun 2013 21:26:11 +0000 From: Ross Callon To: Kireeti Kompella , "kireeti.kompella@gmail.com" , Loa Andersson , "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) Thread-Index: AQHOXUYiZ/qQsTTb6EC4pTEFAGKP35k6hJHg Date: Mon, 17 Jun 2013 21:26:10 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316CBFC12@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.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.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316CBFC12CH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%MAIL01.HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 21:26:27 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316CBFC12CH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, This poll has ended. We have a new working group document. Could the authors please republish the draft as draft-ietf-mpls- mpls-special-purpose-labels-00 without any other changes than version, file name and dates! After this is posted, the authors should work on addressing the various com= ments raised during the call for adoption (which may involve discussion on = the list and/or update to the WG draft). Thanks, Ross as wg co-chair _____________________________________________ From: Ross Callon Sent: Thursday, May 30, 2013 10:58 AM To: Ross Callon; mpls@ietf.org Cc: draft-kompella-mpls-special-purpose-labels@tools.ietf.org; mpls-chairs@= tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-= mpls-special-purpose-labels-04) Oops. I meant to say "poll for adoption". The message should be: This is to start a "two week" poll on adopting draft-kompella-mpls-special-purpose-labels-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end June 13, 2013. Thanks, Ross --_000_62CCD4C52ACDAD4481149BD5D8A72FD316CBFC12CH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
This poll has ended. We have a new working group document. Could the
authors please republish the draft as
 
draft-ietf-mpls- mpls-special-purpose-labels-00
 
without any other changes than version, file name and dates!
 
After this is posted, the authors should work on addressing the variou= s comments raised during the call for adoption (which may involve discussio= n on the list and/or update to the WG draft).
 
Thanks, Ross
as wg co-chair
 
_____= ________________________________________
From: Ross Callon
Sent: Thursday, May 30, 2013 10:58 AM
To: Ross Callon; mpls@ietf.org
Cc: draft-kompella-mpls-special-purpose-labels@tools.ietf.org; mpls-= chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN)
Subject: OOps, Poll for adoption (was: MPLS WG last call on draft-ko= mpella-mpls-special-purpose-labels-04)
 
 
Oops= . I meant to say “poll for adoption”. The message should be:
&nbs= p;
This= is to start a "two week" poll on adopting
draf= t-kompella-mpls-special-purpose-labels-04
as a= n MPLS working group document.
&nbs= p;
Plea= se send your comments (support/not support) to the mpls working
grou= p mailing list (mpls@ietf.org).=
&nbs= p;
This= poll will end June 13, 2013.
&nbs= p;
Than= ks, Ross
 
 
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316CBFC12CH1PRD0510MB355_-- From loa@pi.nu Tue Jun 18 01:30:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B7721F8B04 for ; Tue, 18 Jun 2013 01:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqhJcx5VusxB for ; Tue, 18 Jun 2013 01:30:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0D97621F9CBF for ; Tue, 18 Jun 2013 01:30:29 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5829C180121E; Tue, 18 Jun 2013 10:30:27 +0200 (CEST) Message-ID: <51C01AA4.90106@pi.nu> Date: Tue, 18 Jun 2013 10:30:28 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: RFC Errata System References: <20130617142955.4388262113@rfc-editor.org> In-Reply-To: <20130617142955.4388262113@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org, joelrepiquet@gmail.com, sboutros@cisco.com, rcallon@juniper.net, raggarwa_1@yahoo.com Subject: Re: [mpls] [Editorial Errata Reported] RFC6426 (3660) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 08:30:34 -0000 All, I think this is correct. Section 2 were restructured between version -02 and -03 of the ID. We missed updating the IANA section. We should move this to "verified" and keep it in mind if we need to update the RFC. /Loa On 2013-06-17 16:29, RFC Errata System wrote: > The following errata report has been submitted for RFC6426, > "MPLS On-Demand Connectivity Verification and Route Tracing". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6426&eid=3660 > > -------------------------------------- > Type: Editorial > Reported by: Joël Repiquet > > Section: 7.2 > > Original Text > ------------- > Value Meaning Reference > ----- ------------------- ----------------------------- > 22 Static LSP this document (Section 2.4.1) > 23 Static Pseudowire this document (Section 2.4.2) > > Corrected Text > -------------- > Value Meaning Reference > ----- ------------------- ----------------------------- > 22 Static LSP this document (Section 2.3.1) > 23 Static Pseudowire this document (Section 2.3.2) > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6426 (draft-ietf-mpls-tp-on-demand-cv-07) > -------------------------------------- > Title : MPLS On-Demand Connectivity Verification and Route Tracing > Publication Date : November 2011 > Author(s) : E. Gray, N. Bahadur, S. Boutros, R. Aggarwal > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Tue Jun 18 16:56:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469C821F93E5; Tue, 18 Jun 2013 16:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp-Vwkew5A2w; Tue, 18 Jun 2013 16:55:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D030521F93BA; Tue, 18 Jun 2013 16:55:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130618235559.31983.27844.idtracker@ietfa.amsl.com> Date: Tue, 18 Jun 2013 16:55:59 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 23:56:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Operations, Administration, and Management (OAM)= Identifiers Management Information Base (MIB) Author(s) : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-mpls-tp-oam-id-mib-03.txt Pages : 28 Date : 2013-06-18 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-oam-id-mib-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From N.Leymann@telekom.de Wed Jun 19 02:13:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF2821F9FA7 for ; Wed, 19 Jun 2013 02:13:07 -0700 (PDT) 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=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw6bmO9aPJo5 for ; Wed, 19 Jun 2013 02:12:58 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0899921F9F83 for ; Wed, 19 Jun 2013 02:12:56 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 19 Jun 2013 11:12:54 +0200 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%14]) with mapi; Wed, 19 Jun 2013 11:12:53 +0200 From: To: , , , , , Date: Wed, 19 Jun 2013 11:12:52 +0200 Thread-Topic: IPR poll on draft-ietf-mpls-ldp-applicability-label-adv Thread-Index: Ac5dDBLulqBoJlIgQSC649jfi3DvIgPvesCA Message-ID: <9762ACF04FA26B4388476841256BDE02011A938A6E15@HE111543.emea1.cds.t-internal.com> References: <51A707A0.7050704@pi.nu> In-Reply-To: <51A707A0.7050704@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] IPR poll on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 09:13:08 -0000 Hi Loa, I'm not aware of any IPR which applies to draft-ietf-mpls-ldp-applicability= -label-adv. Regards Nic -----Urspr=FCngliche Nachricht----- Von: Loa Andersson [mailto:loa@pi.nu] Gesendet: Donnerstag, 30. Mai 2013 10:03 An: mpls@ietf.org; mpls-chairs@tools.ietf.org; ; V= IGOUREUX, MARTIN (MARTIN); draft-ietf-mpls-ldp-applicability-label-adv@tool= s.ietf.org Betreff: IPR poll on draft-ietf-mpls-ldp-applicability-label-adv Working Group and authors; The authors of draft-ietf-mpls-ldp-applicability-label-adv and the working group chairs are working to prepare the draft for working group last call. We IPR poll on this draft before accepting it as a working group document. Since this is sometime ago we will do a new before starting the working group last call to check whether there is IPR on the document that needs to be disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-ldp- applicability-label-adv? 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 contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Thu Jun 20 09:29:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7E21F9E63; Thu, 20 Jun 2013 09:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqAVyQbfiK0e; Thu, 20 Jun 2013 09:29:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DDB21F9E46; Thu, 20 Jun 2013 09:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130620162913.8183.66672.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2013 09:29:13 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 16:29:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Disabling IPoMPLS and P2P PW LDP Application's State Adv= ertisement Author(s) : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-06.txt Pages : 13 Date : 2013-06-20 Abstract: Currently, no LDP capability is exchanged for LDP applications like IP Label Switching and L2VPN P2P PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like mLDP or ICCP. This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications. This, in turn, disables the advertisement of corresponding application state, which would have otherwise be advertised by default, over the established LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ip-pw-capability-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Thu Jun 20 14:48:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBDB21F9E35; Thu, 20 Jun 2013 14:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byJGapJnU7rg; Thu, 20 Jun 2013 14:48:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD7211E80EA; Thu, 20 Jun 2013 14:48:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130620214843.1819.13417.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2013 14:48:43 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'MPLS Generic Associated Channel (G-ACh) Advertisement Protocol' to Proposed Standard (draft-ietf-mpls-gach-adv-08.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 21:48:44 -0000 The IESG has approved the following document: - 'MPLS Generic Associated Channel (G-ACh) Advertisement Protocol' (draft-ietf-mpls-gach-adv-08.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-gach-adv/ Technical Summary The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. Working Group Summary There is good support in the working group for this draft. There were no significant controversies in progression of the document. Last call comments were constructive technical comments and the document has been updated accordingly. . Document Quality: For this document we seem to have an chicken and egg problem. We know of intended implementations, it seems that since the implementation delta is rather small the implementers in this case has decided to wait for the allocation of the ACh code point before implementing. The document received extensive (agressive?) review from the responsible AD and has been updated to address all comments raised. Personnel: Loa Andersson (loa@pi.nu) is the document shepherd. Adrian Farrel (adrian@olddog.co.uk) is the responsible AD. RFC Editor Note Please update the 2119 boilerplate to include "NOT RECOMMENDED" --- Section 6.1: OLD: "the following values MAY supported" NEW: "the following values MAY be supported" From sboutros@cisco.com Thu Jun 20 15:44:47 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8002C11E812A for ; Thu, 20 Jun 2013 15:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vlg3AH5Ozty for ; Thu, 20 Jun 2013 15:44:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 696CB11E80E3 for ; Thu, 20 Jun 2013 15:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2201; q=dns/txt; s=iport; t=1371768275; x=1372977875; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Jkfb19gp+K4CDC+OTEYkMk2iQ1XVEfC1Fza/pfAm8ls=; b=FfLdkLLKClN2nKN/CsNPRxFYwTpIIN70JCTRoakxqrqMMqUCFeSBuUIc +SlTBkwLQwfBLJ14xY5kv3f9qQtanNjF8BS4noMT6srYSHlM/2MHdWg38 aRfxRiLJlYLEKFpYBeECHPlej8Lo7r0lPSE6q+KO4n6n+k33FPBpVpMqQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEuFw1GtJV2d/2dsb2JhbABbgwl6vzaBABZ0giMBAQEDAWsDBgUFCQICAQgiHQcbFxQRAgQOBQiIAAa8PgSOAxB/AjEHgwBhA4hpoB6DD4FxNw X-IronPort-AV: E=Sophos;i="4.87,908,1363132800"; d="scan'208";a="222562396" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 20 Jun 2013 22:44:34 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5KMiYu9005304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 22:44:34 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.64]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 17:44:34 -0500 From: "Sami Boutros (sboutros)" To: " " Thread-Topic: IPR poll on draft-ietf-mpls-ldp-applicability-label-adv Thread-Index: AQHOXQwQKwVz7Nk1AkadZ/sAcwlZ55k9NBMAgAJ1HYA= Date: Thu, 20 Jun 2013 22:44:33 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F1134E025A@xmb-rcd-x08.cisco.com> References: <51A707A0.7050704@pi.nu> <9762ACF04FA26B4388476841256BDE02011A938A6E15@HE111543.emea1.cds.t-internal.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE02011A938A6E15@HE111543.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.232.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <40A03C5F0C66AC44B3883818E6A2B0CE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" , "" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 22:44:47 -0000 The same here. Thanks, Sami On Jun 19, 2013, at 2:12 AM, wrote: > Hi Loa, >=20 > I'm not aware of any IPR which applies to draft-ietf-mpls-ldp-applicabili= ty-label-adv. >=20 > Regards >=20 > Nic >=20 > -----Urspr=FCngliche Nachricht----- > Von: Loa Andersson [mailto:loa@pi.nu] > Gesendet: Donnerstag, 30. Mai 2013 10:03 > An: mpls@ietf.org; mpls-chairs@tools.ietf.org; ;= VIGOUREUX, MARTIN (MARTIN); draft-ietf-mpls-ldp-applicability-label-adv@to= ols.ietf.org > Betreff: IPR poll on draft-ietf-mpls-ldp-applicability-label-adv >=20 > Working Group and authors; >=20 > The authors of draft-ietf-mpls-ldp-applicability-label-adv and > the working group chairs are working to prepare the draft for working > group last call. >=20 > We IPR poll on this draft before accepting it as a working group > document. Since this is sometime ago we will do a new before > starting the working group last call to check whether there is IPR > on the document that needs to be disclosed. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-ldp- > applicability-label-adv? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > 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 contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From tsaad@cisco.com Thu Jun 20 15:53:02 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C104121E80C9 for ; Thu, 20 Jun 2013 15:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L-3spe7BJSo for ; Thu, 20 Jun 2013 15:52:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCB411E812D for ; Thu, 20 Jun 2013 15:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9558; q=dns/txt; s=iport; t=1371768756; x=1372978356; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=IAg7yzgVorx97uqS2X8V9lLyYATZnjrHOLtDeX4BXcY=; b=YmaTiAaI6pTSqAqJycyHNISfdDWdsVf2DbkKBU/tQbY8K1xoO3cr3/e3 0YcdzVDuTf18dMoS+C6HE8GxzLBMjYO2drUeyiUA2/kgWu5T20CDd81NR yWM4xbpeNXlV44noHApairJRSTXr8510xz+72DfX0N+PNYr9xTw/PSQjN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHOGw1GtJXG8/2dsb2JhbABRCoMJMUm/NoEAFnSCJQEEJxM/EgEIDhQUQicEAQ0FCAGIBQy8MI1+CQaBCzGDB2EDqQeDD4FxNw X-IronPort-AV: E=Sophos;i="4.87,908,1363132800"; d="scan'208";a="225535609" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 20 Jun 2013 22:52:21 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5KMqK8N013511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 22:52:20 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.152]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 17:52:20 -0500 From: "Tarek Saad (tsaad)" To: Ross Callon , Raveendra Torvi , Eric Gray , Lizhong Jin Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHObgjRXhu7Ou41qUaE6SAXznaJBA== Date: Thu, 20 Jun 2013 22:52:19 +0000 Message-ID: <2170E89B881FEA48B3A35413AB6FC4300FB39746@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [161.44.213.82] 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-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 22:53:02 -0000 Hi all, =20 I have been asked to the review the below document/draft: Extensions to RSVP-TE for P2MP LSP Egress Local Protection, http://www.ietf.org/id/draft-chen-mpls-p2mp-egress-protection-09.txt =20 Overall, the draft is well written, the motivation is clear, and the proposal is sound. I think the document should be considered for WG adoption, but more discussions and input will be needed from the group on the proposed mechanisms. =20 More comments below: 1. Suggest a change to the draft outline for easier flow of the draft, e.g.: - Applicability of Local Repair Techniques - One-to-one Backup - Facility Backup - RSVP extensions - Headend Behavior - PLR behavior - Signaling of Backup sub-LSP - .. - Behavior of All LSRs =20 2. Is the draft also intendeds to cover locally protecting egress nodes that act as transits/mids (aka P2MP bud LSR nodes)? Either way, could be helpful if it mentioned it. =20 3. Section 1: "An existing method for protecting the egress nodes of a P2MP LSP sets up a backup P2MP LSP from a backup ingress node to the backup egress nodes." * the backup P2MP LSP can also originate from same ingress node to the set of backup egress nodes. * a variant would be to graft another primary S2L sub-LSP to the "backup" egress node. Traffic flows on to both egress nodes, and receiver can select traffic from either based on route to source via RPF. =20 4. Section 4.1: Typo: follwing -> following =20 5. Consider PLR +--+--+ | | | A B C / | \ / + \ / / \ \ CE1---+ +--- CE2 =20 * If the same backup egress node (e.g. B) is used to protect two or more primary egress nodes (e.g. A and C), when PLR reroutes traffic onto the backup (detour or bypass tunnel via B) due to a failure of one of the primary egress nodes (eg. A), the receiver(s) connected to other primary egress node(s) (e.g. CE2) starts to receive duplicated traffic (via C and via B). =20 6. Section 4.2: "The previous hop node of the primary egress node sets up a backup sub LSP from itself" * Arguably, a PLR is one that usually provisions/assigns backup (detour or bypass). Personally, favour using the term upstream node PLR over previous hop node (used extensively in the draft). =20 7. Section 4.3: "After receiving the RSVP-TE RESV message for the backup sub LSP, the previous hop node creates a forwarding entry with an inactive state or flag called inactive forwarding entry." * which flag is being referred to? I presume non-signalled flag, or mere implementation detail? =20 8. Section 4.4: " The previous hop node of the primary egress node SHALL detect the failure of the link between the primary egress node and its destination node (e.g. the failure of the link between L1 and CE1 in Figure 1). =20 .. =20 Failure of the destination node and the link between the primary egress node and the destination node CAN be detected by a BFD session between the previous hop node and the destination node." * Not typical to trigger TE FRR on failures beyond the TE (sub)LSP path (beyond the PE egress node).. Is it meant to cover slow routing convergence (from PE to CE)? * AFAIK, the multihop BFD session will detect reachability from prev hop node to the destination node (not just L1-CE1 link liveliness). =20 " When we use the egress local protection to protect a primary egress node, we SHOULD NOT use any fast re-route to protect the link between the primary egress node and its previous hop node. The failure of the link is protected by the egress protection. " * While this may work for protecting subLSPs terminating on the primary egress node, there's still need to protect subLSPs transitting the primary egress node (in case of primary bud node). For example, consider case of facility bypass, one could potentially have 2 bypass tunnels (1 terminates on backup egress node) and another on PLR NHOP (regular NHOP pass) to protect the transit subLSPs. =20 9. Section 5: * Typo: FFR -> FRR =20 =20 10. Section 6: "6. Representation of a Backup Sub LSP" * rfc4090 defines two ways to identify backup subLSP (sender-template and path specific).. I assume both apply, if so could mention this * What about the backup subLSP sub-group fields (sub-group ID and sub-group originator)? Are these assigned/set by the PLR since it originates the Path message? =20 " An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to specify the explicit route of a backup sub LSP that is from a previous hop node to a backup egress node. The EB-SERO is defined in the following section. " * I'm not sure if the ingress really needs to compose and signal the backup subLSP SERO, given: 1. From rf4090, a PLR can independently (and optionally using constraints set in the FAST_REROUTE object) route and signal the detour or bypass tunnel. 2. In some cases (ingress resides in a different IGP area/domain), the ingress may not have the visibility to compute the path from PLR to the backup egress node; however, the PLR could (provided backup egress node is in its TED). =20 11. Section 6.1.1=20 * Suggest rename "Egress IPv4 address" to Egress Primary Sub LSP IPv4 destination address =20 12. Section 7.2.1. Backup LSP for One-to-One Protection: * It's not clear what goes on from the signalling perspective post the egress node failure. - will the primary S2L subLSP (to the failed egress node) persist after the egress node failure? If so, - will the fault (as detected by PLR) be notified back to the ingress node, how? - How will the change of path (after reroute) of the primary S2L subLSP be propagated back to the ingress? - What happens if the primary egress node (previously failed) recovers? - Would the backup egress node remain backup egress post the failure? =20 13. Section 7.2.1 " When a primary egress node of the LSP receives the Path message with an egress backup sub LSP descriptor list, it SHOULD ignore the egress backup sub LSP descriptor list and generate a PathErr message. " * I presume a transit/mid won't be allowed to act as a backup egress node too (i.e. become bud after FRR)? If so, can be clarified =20 " If an intermediate node receives the Path message with an egress backup sub LSP descriptor list, it MUST put the EGRESS_BACKUP_SUB_LSP containing a backup egress into a Path message to be sent towards the backup egress. This SHALL be done for each EGRESS_BACKUP_SUB_LSP containing a backup egress node in the list. " * Not clear? is what's intended to say that intermediate node forwards EGRESS_BACKUP_SUB_LSP in the Path unchanged? =20 =20 14. Section 7.2.2: * Typo: satisifies -> satisfies * The mechanisms proposed here are in violation of RFC4090 (section 3.1): " In the one-to-one backup method, a label-switched path is established that intersects the original LSP somewhere downstream of the point of link or node failure." (section 3.2): "The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR." =20 " When the previous hop node detects a failure in the primary egress, it has to imports the traffic for the protected P2MP LSP into the backup bypass tunnel using the backup label as the top label. " * statement not clear, suggest rewording. * Not clear what's really involved in making local egress node protection work with facility bypass tunnel Prior to the fault (egress node down): 1. Will there be an S2L subLSP signaled to the backup egress node or not? Post the fault (egress node down): 2. For link-protection, the top (outer) label will be the bypass tunnel label, and the inner label will be the label allocated by the next hop (backup egress node (?)). It's not clear how this inner label is learnt back at the PLR? 3. If multiple primary egress nodes are being protected by same backup egress node and same bypass tunnel, does the backup egress node allocate a unique label for each? 4. After the fault (egress node down), what happens to the primary subLSP? =20 Thanks, Tarek On 2013-06-11 10:16 PM, "Ross Callon" wrote: >Ravi, Eric, Tarek, Lizhong; > >You have been selected as MPLS Review team reviewers for >draft-chen-mpls-p2mp-egress-protection-09. > >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 June 26, 2013? > >Thanks, Ross >(as MPLS WG chair) > > > > > From venkat.mahalingams@gmail.com Thu Jun 20 20:15:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EA321E80F8; Thu, 20 Jun 2013 20:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHwxKOavjyTi; Thu, 20 Jun 2013 20:15:19 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 15C7221E80DF; Thu, 20 Jun 2013 20:15:18 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd20so7984169obb.19 for ; Thu, 20 Jun 2013 20:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=58bddBhBpoZT1qzEuJVcftvJZcU7C6snRPAkkti1Wiw=; b=y1OlXyrSw9zrcEDUGamb/t4RGdoJfXPv4babNPpkHboSR788Aj05Vp7jmS9g1X+KPT /HZaDcWc+OJO6xopwQegBlaqRkzVFCe8GMoKQMgW7mXee/fpgNIBWTFOVC7S/AEWZwF7 LHa0H+UTAgqvODk6Xz4ufKzLwquYoW2cbK4HUrkOpwLNEVMN5Yt8849MUZ4xY190VkOZ /mOuO3GrXhNJfQaoL/ZW6Gq1qGOqOAcgaae/Nwd8l5S6M8SxQYfI9g1vJRQRAIM8bZJU e7GMXgdTh8xRrJPfvWRYXoE+3s1uhR8votLH/HSElag73xu9+zgR5gs01YXqUi4sQQ7q WDJg== MIME-Version: 1.0 X-Received: by 10.182.106.130 with SMTP id gu2mr2769159obb.0.1371784518466; Thu, 20 Jun 2013 20:15:18 -0700 (PDT) Received: by 10.76.112.84 with HTTP; Thu, 20 Jun 2013 20:15:18 -0700 (PDT) In-Reply-To: References: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC> Date: Thu, 20 Jun 2013 20:15:18 -0700 Message-ID: From: Venkatesan Mahalingam To: venkatesan mahalingam Content-Type: multipart/alternative; boundary=089e015370f4ee82bd04dfa17864 Cc: mpls , "MIB Doctors \(E-mail\)" , "ppan@infinera.com" , Sami Boutros , Kannan Sampath , Loa Andersson Subject: Re: [mpls] MIB Doctor Review of draft-ietf-mpls-tp-oam-id-mib-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 03:15:21 -0000 --089e015370f4ee82bd04dfa17864 Content-Type: text/plain; charset=ISO-8859-1 Joan, We have addressed the below comments in the 03 version. We would be happy to address any of your further comments. Please let us know if any of the comments are not addressed properly. http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-03 -Venkat. On Sat, Apr 20, 2013 at 2:10 PM, venkatesan mahalingam wrote: > Joan, > > Please find below my comments with the tag VM>. We will publish the new > version of this draft soon. > > -Venkat. > > > On Mon, Mar 11, 2013 at 8:34 PM, Joan Cucchiara > wrote: > >> >> Authors, >> >> Most of the comments during the LC have been addressed. >> Thank you for that. Please see some follow-up comments below. >> >> Thanks, >> -Joan >> >> >> >> >> * MIB compiles cleanly with smicng and smilint >> >> >> Specific Comments: >> ==================== >> >> Section 3.3 Acronyms >> >> >> * MIP is specified slightly differently in the referenced docs. >> Please be consistant. >> > VM> OK. > >> >> >> Section 6. >> >> This example, specifies the mplsOamIdMeMpEntry as a MEP, but why >> isn't the SourceMepIndex or SinkMepIndex == mplsOamIdMeMpIndex? >> >> Also, there are at least 2 MEPs in an ME, and at least one ME >> in a MEG and these relationships are not completely evolved >> in this example. I think the example should be expanded >> to agree with what is stated in the first paragraph. >> >> VM> OK, the example will be expanded to represent MEG->ME->Source/Sink > MEPs clearly. > As per this MIB module, > MEG->ME->MPIndex([Source and Sink MEP] or MIP index) > For example, > > If we have multiple MEPs in a single ME within an MEG node. > MEG index - 1 > ME index - 1 > MP index - 1 (Source and Sink MEPs1) > MP index - 2 (Source and Sink MEPs2) > > *Entry-1:* > ME Table - 1,1,1 > mplsOamIdMeSourceMepIndex - 2 > mplsOamIdMeSinkMepIndex - 3 > > *Entry-2:* > ME Table - 1,1,2 > mplsOamIdMeSourceMepIndex - 4 > mplsOamIdMeSinkMepIndex - 5 > > *MIP entry:* > > MEG index - 1 > ME index - 1 > MP index - 3 (MIP index) > ME Table - 1,1,3 > mplsOamIdMeMpIfIndex - MPLS incoming/outgoing interface. > > > >> MIB Module comments >> ------------------- >> >> * TC: MplsOamPhbTCValue >> >> >> MplsOamPhbTCValue ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "This is the Per-hop Behavior (PHB) traffic class values >> for the MPLS OAM operations." >> SYNTAX INTEGER { >> be (1), >> af1 (2), >> af2 (3), >> af3 (4), >> af4 (5), >> ef (6), >> cs6 (7), >> cs7 (8) >> } >> >> VM> As MPLS header traffic class (TC) field has only 3 bits, we derived > the above TC values (8 possible values to represent it in 3 bits) from the > below TC values. > > >> Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of >> Differentiated Services", specifies that MPLS TP will use DSCP as per >> rfc2474 and other specs. Is that the intent wrt this TC? >> >> If not, please explain where these values are defined, otherwise, >> if these values are as per rfc3270, then please be consistant with the >> labels. >> >> TC labels should correspond more closely to DiffServ BHB traffic class >> values. >> In other words, >> >> http://www.iana.org/**assignments/dscp-registry/**dscp-registry.xml >> >> Name Space Reference >> CS0 000000 [RFC2474] >> CS1 001000 [RFC2474] >> CS2 010000 [RFC2474] >> CS3 011000 [RFC2474] >> CS4 100000 [RFC2474] >> CS5 101000 [RFC2474] >> CS6 110000 [RFC2474] >> CS7 111000 [RFC2474] >> AF11 001010 [RFC2597] >> AF12 001100 [RFC2597] >> AF13 001110 [RFC2597] >> AF21 010010 [RFC2597] >> AF22 010100 [RFC2597] >> AF23 010110 [RFC2597] >> AF31 011010 [RFC2597] >> AF32 011100 [RFC2597] >> AF33 011110 [RFC2597] >> AF41 100010 [RFC2597] >> AF42 100100 [RFC2597] >> AF43 100110 [RFC2597] >> EF PHB 101110 [RFC3246] >> VOICE-ADMIT 101100 [RFC5865] >> >> >> Continuing with that thought: I believe this TC could (and should) be >> formalized into an IANA-Maintained MIB if these values are the same >> as the above IANA-Maintained assignments for DFCPs. >> (NOTE: this was mentioned also in the LC comments.) Please discuss. >> >> Also, this TC should have a REFERENCE clause. >> >> >> >> * mplsOamIdMegIndex >> There is no information about how to employ mplsOamIdMegIndexNext to >> obtain a value for this index. Please update the DESCRIPTION >> accordingly. >> >> >> VM> Edited. > >> >> * mplsOamIdMegOperatorType >> Why does this say "should have valid values...", isn't this a MUST? >> Also, s/while making/when/ >> >> * mplsOamIdMegIdCc >> >> s/contains non-null ICC/MUST contain a/ >> >> s/otherwise null ICC value/otherwise a null ICC value/ >> >> s/should be assigned/MUST be assigned/ >> >> * mplsOamIdMegIdIcc >> >> Same comments as above. Please use MUST. >> >> * mplsOamIdMegIdUmc >> Same comments as above. Please use MUST. >> >> >> VM> Edited. > >> * mplsOamIdMegServiceType >> Could you please specify the service pointer by the object's name? >> >> Also, the references are within the DESCRIPTION which is fine, but >> they should also be in a REFERENCE clause. >> >> >> VM> Edited. > >> * mplsOamIdMeIndexNext and mplsOamIdMpIndexNext >> These objects are not referred to by mplsOamIdMeIndex or >> mplsOamIdMeMpIndex. >> There is not enough description to understand how the IndexNext objects >> are to be used. >> >> VM> Edited. > >> >> * MplsOamIdMeTable >> >> The mplsOamIdMeEntry states "An entry in this table >> represents MPLS-TP maintenance entity." Yet, looking at the >> INDEX { mplsOamIdMegIndex, >> mplsOamIdMeIndex, >> mplsOamIdMeMpIndex >> } >> >> This is not an ME because an ME by definition has 2 (source/sink)MEPs. >> An entry in this table represents either a MEP or MIP, not an ME. >> >> VM> Yes, this is not an ME but it contains ME information (MEPs/MIP). > Would it make more sense if we change it to mplsOamIdMeInfoEntry? > >> >> *) What is the benefit of combining MEP and MIP (i.e. the objects >> which contain "Mp" as part of their object name)? >> Many other objects in this table, need to figure out if the entry >> is describing a MEP or MIP before the value can be interpreted correctly. >> Additionally, there is duplicate info in the form of having a Source and >> Sink specified for each Mp. Could you elaborate on what the >> benefit is of having listing MEPs and MIPs in this way? >> >> It seems like the original intent may have been to specify an ME >> as being an entry in this table. However, that would mean the table >> should probably be indexed by MEG index, a ME index, a source MEP index >> and a sink MEP index. >> >> This would greatly simplify many of the object descriptions. >> >> Have you considered specifying MIPs in a 3rd table, such that each >> ME would have 2 MEPs and zero or more MIPs? >> >> Please discuss. >> >> VM> We thought through all the possible options, it looks like lot of > informations are duplicated unnecessarily if we have the seperate tables > for MEP/MIP configurations. For up/down MEPs configurations, all the > informations in the ME table will be used but for MIP, except the > Source/Sink MEPs objects, all other objects will be used. So, we wanted to > combine MEP/MIP in a single table for better management. > > So, we will certainly improvise the existing MEG&ME tables example to > provide all possible configuration options. > >> >> >> *) mplsOamIdMeMpIfIndex >> >> Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and states >> "Note that IF_Num had no relation with the ifNum object defined in >> RFC2863. Further, no mapping is mandated between IF_Num and ifIndex in >> RFC 2863." >> >> I don't see any mention of ifIndex in RFC 6371, so could you tell me what >> Section? Is this object supposed to represent IF_NUM in rfc6370? >> > VM> Reference should be replaced with rfc-6370 section4. > and RFC2863 should be removed. Good catch. Thanks. > >> >> *) mplsOamIdMeServicePointer >> >> The DESCRIPTION contains wording which is very loose. Could you >> please use wording which specifies a "SHOULD" or "MUST"? >> Under what circumstances should this be 0.0? >> >> VM> Edited. > >> >> Compliance Statement of the MIB >> >> *) Compliance (This has been asked before and I have not seen any >> discussion about it.) >> >> There is no read-only compliance. Has it been made clear >> to the WGs (MPLS and PWE3) that SNMP sets will need to >> be supported in order to be compliant with the MIB? >> >> VM> Not yet, sorry for the delay. We will make read-only compliance clear > to WG after this draft submission. > >> >> *) question above, about whether the intention is to support >> ifIndex as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may >> affect this. >> >> "MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. >> MANDATORY-GROUPS { >> ifGeneralInformationGroup, >> ifCounterDiscontinuityGroup" >> >> >> *) mplsOamIdNotificationObjectsGr**oup OBJECT-GROUP >> >> I don't see a need to make a specific group for >> these objects. They are already specified by mplsOamIdGroups. >> >> VM> Edited. > >> >> Section 8. Security Section >> >> Need to reference specific read-create objects and also read-only which >> could impact the network. >> >> Additionally, the incomplete sentence: >> "These are the tables and objects and their sensitivity/vulnerability: " >> needs to be completed. >> >> VM> Edited. > >> >> Section 9. IANA Considerations >> >> s/specified this document/specified in this document/ >> missing the word "in" >> >> >> VM> Edited. > >> Section 11. >> Thank you for the ack! >> >> ______________________________**_________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/**listinfo/mpls >> > > --089e015370f4ee82bd04dfa17864 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joan,

We have addressed the below= comments in the 03 version. We would be happy to address any of your furth= er comments.

Please let us know if any= of the comments are not addressed properly.


-Venkat.


On Sat,= Apr 20, 2013 at 2:10 PM, venkatesan mahalingam <venkatflex@gmail.com> wrote:
Joan,

Pl= ease find below my comments with the tag VM>. We will publish the new ve= rsion of this draft soon.

-Venkat.


On Mon, Mar 11, 2013 a= t 8:34 PM, Joan Cucchiara <jcucchiara@mindspring.com> wrote:

Authors,

Most of the comments during the LC have been addressed.
Thank you for that. =A0 Please see some follow-up comments below.

Thanks,
-Joan




* MIB compiles cleanly with smicng and smilint


Specific Comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Section 3.3 Acronyms


* MIP is specified slightly differently in the referenced docs.
Please be consistant.
VM> OK.=A0


Section 6.

This example, specifies the mplsOamIdMeMpEntry as a MEP, but why
isn't the SourceMepIndex or SinkMepIndex =3D=3D mplsOamIdMeMpIndex?

Also, there are at least 2 MEPs in an ME, and at least one ME
in a MEG and these relationships are not completely evolved
in this example. =A0I think the example should be expanded
to agree with what is stated in the first paragraph.

VM> OK, the example will be expanded to represent MEG->ME-&g= t;Source/Sink MEPs clearly.
As per this MIB module,
MEG->ME->MPIndex([Source and Sink MEP] or MIP index)
F= or example,

If we have multiple MEPs in a single M= E within an MEG node.
MEG index - 1
ME index - 1
MP index - 1 (Source and Sink MEPs1)
= MP index - 2 (Source and Sink MEPs2)

Entry-= 1:
ME Table - 1,1,1
mplsOamIdMeSourceMepIndex - 2
mplsOamIdMeSinkMepIn= dex - 3

Entry-2:
ME Table= - 1,1,2
mplsOamIdMeSourceMepIndex - 4
mplsOamIdMeSinkMepIndex - 5

MIP = entry:

MEG index - 1
ME i= ndex - 1
MP index - 3 (MIP index)
ME Table - 1,1,3
mplsOamIdMeMpIfIndex - MPLS incoming/ou= tgoing interface.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> MIB Module comments
-------------------

* TC: =A0MplsOamPhbTCValue


=A0 =A0 =A0 =A0 MplsOamPhbTCValue ::=3D TEXTUAL-CONVENTION
=A0 =A0 =A0 =A0 =A0 =A0STATUS =A0 =A0 =A0 =A0 =A0 =A0 =A0current
=A0 =A0 =A0 =A0 =A0 =A0DESCRIPTION
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"This is the Per-hop Behavior (PHB) tra= ffic class values
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for the MPLS OAM operations."
=A0 =A0 =A0 =A0 =A0 =A0SYNTAX =A0 =A0 =A0 =A0INTEGER {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be (1),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0af1 (2),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0af2 (3),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0af3 (4),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0af4 (5),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ef (6),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cs6 (7),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cs7 (8)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

VM> As MPLS header traffic class (TC) field has only 3 bits, we= derived the above TC values (8 possible values to represent it in 3 bits) = from the below TC values.
=A0
Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", specifies that MPLS TP will use DSCP as per<= br> rfc2474 and other specs. =A0 Is that the intent wrt this TC?

If not, please explain where these values are defined, otherwise,
if these values are as per rfc3270, then please be consistant with the labe= ls.

TC labels should correspond more closely to DiffServ BHB traffic class valu= es.
In other words,

http://www.iana.org/assignments/dscp-registry/= dscp-registry.xml

=A0 Name =A0 =A0 Space =A0Reference
=A0 CS0 =A0 =A0 =A0 =A0 000000 [RFC2474]
=A0 CS1 =A0 =A0 =A0 =A0 001000 [RFC2474]
=A0 CS2 =A0 =A0 =A0 =A0 010000 [RFC2474]
=A0 CS3 =A0 =A0 =A0 =A0 011000 [RFC2474]
=A0 CS4 =A0 =A0 =A0 =A0 100000 [RFC2474]
=A0 CS5 =A0 =A0 =A0 =A0 101000 [RFC2474]
=A0 CS6 =A0 =A0 =A0 =A0 110000 [RFC2474]
=A0 CS7 =A0 =A0 =A0 =A0 111000 [RFC2474]
=A0 AF11 =A0 =A0 =A0 =A0001010 [RFC2597]
=A0 AF12 =A0 =A0 =A0 =A0001100 [RFC2597]
=A0 AF13 =A0 =A0 =A0 =A0001110 [RFC2597]
=A0 AF21 =A0 =A0 =A0 =A0010010 [RFC2597]
=A0 AF22 =A0 =A0 =A0 =A0010100 [RFC2597]
=A0 AF23 =A0 =A0 =A0 =A0010110 [RFC2597]
=A0 AF31 =A0 =A0 =A0 =A0011010 [RFC2597]
=A0 AF32 =A0 =A0 =A0 =A0011100 [RFC2597]
=A0 AF33 =A0 =A0 =A0 =A0011110 [RFC2597]
=A0 AF41 =A0 =A0 =A0 =A0100010 [RFC2597]
=A0 AF42 =A0 =A0 =A0 =A0100100 [RFC2597]
=A0 AF43 =A0 =A0 =A0 =A0100110 [RFC2597]
=A0 EF PHB =A0 =A0 =A0101110 [RFC3246]
=A0 VOICE-ADMIT 101100 [RFC5865]


Continuing with that thought: I believe this TC could (and should) be
formalized into an IANA-Maintained MIB if these values are the same
as the above IANA-Maintained assignments for DFCPs.
(NOTE: this was mentioned also in the LC comments.) =A0Please discuss.

Also, this TC should have a REFERENCE clause.



* mplsOamIdMegIndex
There is no information about how to employ mplsOamIdMegIndexNext to
obtain a value for this index. =A0 Please update the DESCRIPTION accordingl= y.


VM> Edited.=A0
=

* mplsOamIdMegOperatorType
Why does this say "should have valid values...", isn't this a= MUST?
Also, s/while making/when/

* mplsOamIdMegIdCc

s/contains non-null ICC/MUST contain a/

s/otherwise null ICC value/otherwise a null ICC value/

s/should be assigned/MUST be assigned/

* mplsOamIdMegIdIcc

Same comments as above. =A0 Please use MUST.

* mplsOamIdMegIdUmc
Same comments as above. =A0Please use MUST.


VM> Edited.=A0
* mplsOamIdMegServiceType
Could you please specify the service pointer by the object's name?

Also, the references are within the DESCRIPTION which is fine, but
they should also be in a REFERENCE clause.


VM> Edited.=A0
* mplsOamIdMeIndexNext and mplsOamIdMpIndexNext
These objects are not referred to by mplsOamIdMeIndex or mplsOamIdMeMpIndex= .
There is not enough description to understand how the IndexNext objects
are to be used.

VM> Edited.=A0

* MplsOamIdMeTable

The mplsOamIdMeEntry states "An entry in this table
represents MPLS-TP maintenance entity." =A0 Yet, looking at the
=A0 =A0 =A0 =A0 =A0 =A0 =A0INDEX { mplsOamIdMegIndex,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mplsOamIdMeIndex,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mplsOamIdMeMpIndex
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

This is not an ME because an ME by definition has 2 (source/sink)MEPs.
An entry in this table represents either a MEP or MIP, not an ME.

VM> Yes, this is not an ME but it contains M= E information (MEPs/MIP).=A0
Would it make more sense if we chang= e it to mplsOamIdMeInfoEntry?=A0

*) What is the benefit of combining MEP and MIP (i.e. the objects
which contain "Mp" as part of their object name)?
Many other objects in this table, need to figure out if the entry
is describing a MEP or MIP before the value can be interpreted correctly. Additionally, there is duplicate info in the form of having a Source and Sink specified for each Mp. Could you elaborate on what the
benefit is of having listing MEPs and MIPs in this way?

It seems like the original intent may have been to specify an ME
as being an entry in this table. =A0However, that would mean the table
should probably be indexed by MEG index, a ME index, a source MEP index
and a sink MEP index.

This would =A0greatly simplify many of the object descriptions.

Have you considered specifying MIPs in a 3rd table, such that each
ME would have 2 MEPs and zero or more MIPs?

Please discuss.

VM> We thought through all the possible opti= ons, it looks like lot of informations are duplicated=A0unnecessarily if we= have the seperate tables for MEP/MIP configurations. For up/down MEPs conf= igurations, all the informations in the ME table will be used but for MIP, = except the Source/Sink MEPs objects, all other objects will be used. So, we= wanted to combine MEP/MIP in a single table for better management.

So, we will certainly improvise the existing MEG&ME= tables example to provide all possible configuration options.=A0


*) mplsOamIdMeMpIfIndex

Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and states
"Note that IF_Num had no relation with the ifNum object defined in
RFC2863. =A0Further, no mapping is mandated between IF_Num and ifIndex in RFC 2863."

I don't see any mention of ifIndex in RFC 6371, so could you tell me wh= at
Section? =A0 Is this object supposed to represent IF_NUM in rfc6370?
VM> Reference should be replaced with rfc-6370 sect= ion4.=A0
and RFC2863 should be removed. Good catch. Thanks.

*) mplsOamIdMeServicePointer

The DESCRIPTION contains wording which is very loose. =A0Could you
please use wording which specifies a "SHOULD" or "MUST"= ?
Under what circumstances should this be 0.0?

VM> Edited.=A0

Compliance Statement of the MIB

*) Compliance (This has been asked before and I have not seen any discussio= n about it.)

There is no read-only compliance. Has it been made clear
to the WGs (MPLS and PWE3) that SNMP sets will need to
be supported in order to be compliant with the MIB?

VM> Not yet, sorry for the delay. We will ma= ke read-only compliance clear to WG after this draft submission.=A0

*) question above, about whether the intention is to support
ifIndex as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may
affect this.

=A0 =A0 =A0"MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
=A0 =A0 =A0MANDATORY-GROUPS {
=A0 =A0 =A0 =A0 ifGeneralInformationGroup,
=A0 =A0 =A0 =A0 ifCounterDiscontinuityGroup"


*) =A0 =A0mplsOamIdNotificationObjectsGroup =A0OBJECT-GROUP

I don't see a need to make a specific group for
these objects. =A0They are already specified by mplsOamIdGroups.

VM> Edited.=A0

Section 8. Security Section

Need to reference specific read-create objects and also read-only which
could impact the network.

Additionally, the incomplete sentence:
"These are the tables and objects and their sensitivity/vulnerability:= "
needs to be completed.

VM> Edited.=A0

Section 9. =A0IANA Considerations

s/specified this document/specified in this document/
missing the word "in"


VM> Edited.=A0
Section 11.
Thank you for the ack!

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


--089e015370f4ee82bd04dfa17864-- From huaimo.chen@huawei.com Fri Jun 21 06:40:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F141821E811A for ; Fri, 21 Jun 2013 06:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MInUw3JSFsA9 for ; Fri, 21 Jun 2013 06:40:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BC58721E8116 for ; Fri, 21 Jun 2013 06:40:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASR34123; Fri, 21 Jun 2013 13:40:34 +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.1.323.7; Fri, 21 Jun 2013 14:39:52 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 21 Jun 2013 14:40:30 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Fri, 21 Jun 2013 06:40:24 -0700 From: Huaimo Chen To: "Tarek Saad (tsaad)" Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHObgjRXhu7Ou41qUaE6SAXznaJBJlAKYcA Date: Fri, 21 Jun 2013 13:40:24 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451E006F@dfweml509-mbx.china.huawei.com> References: <2170E89B881FEA48B3A35413AB6FC4300FB39746@xmb-aln-x08.cisco.com> In-Reply-To: <2170E89B881FEA48B3A35413AB6FC4300FB39746@xmb-aln-x08.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 13:40:45 -0000 Hi Tarek, Thanks much for very useful comments. We will wait until we see the com= ments from all the MPLS-RT reviewers before updating the draft. Could you please give us a hint which of your comments you think are ne= cessary to address before this document becomes a working group document? Best Regards, Huaimo -----Original Message----- From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com]=20 Sent: Thursday, June 20, 2013 6:52 PM To: Ross Callon; Raveendra Torvi; Eric Gray; Lizhong Jin Cc: mpls-chairs@tools.ietf.org; draft-chen-mpls-p2mp-egress-protection@tool= s.ietf.org; Martin Vigoureux; mpls@ietf.org Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi all, =20 I have been asked to the review the below document/draft: Extensions to RSVP-TE for P2MP LSP Egress Local Protection, http://www.ietf= .org/id/draft-chen-mpls-p2mp-egress-protection-09.txt =20 Overall, the draft is well written, the motivation is clear, and the propos= al is sound. I think the document should be considered for WG adoption, but= more discussions and input will be needed from the group on the proposed m= echanisms. =20 More comments below: 1. Suggest a change to the draft outline for easier flow of the draft, e.g.: - Applicability of Local Repair Techniques - One-to-one Backup - Facility Backup - RSVP extensions - Headend Behavior - PLR behavior - Signaling of Backup sub-LSP - .. - Behavior of All LSRs =20 2. Is the draft also intendeds to cover locally protecting egress nodes tha= t act as transits/mids (aka P2MP bud LSR nodes)? Either way, could be helpf= ul if it mentioned it. =20 3. Section 1: "An existing method for protecting the egress nodes of a P2MP LSP sets up a= backup P2MP LSP from a backup ingress node to the backup egress nodes." * the backup P2MP LSP can also originate from same ingress node to the set = of backup egress nodes. * a variant would be to graft another primary S2L sub-LSP to the "backup" egress node. Traffic flows on to both egress nodes, and receiver can select= traffic from either based on route to source via RPF. =20 4. Section 4.1: Typo: follwing -> following =20 5. Consider PLR +--+--+ | | | A B C / | \ / + \ / / \ \ CE1---+ +--- CE2 =20 * If the same backup egress node (e.g. B) is used to protect two or more pr= imary egress nodes (e.g. A and C), when PLR reroutes traffic onto the backu= p (detour or bypass tunnel via B) due to a failure of one of the primary eg= ress nodes (eg. A), the receiver(s) connected to other primary egress node(= s) (e.g. CE2) starts to receive duplicated traffic (via C and via B). =20 6. Section 4.2: "The previous hop node of the primary egress node sets up a backup sub LSP = from itself" * Arguably, a PLR is one that usually provisions/assigns backup (detour or = bypass). Personally, favour using the term upstream node PLR over previous = hop node (used extensively in the draft). =20 7. Section 4.3: "After receiving the RSVP-TE RESV message for the backup sub LSP, the previ= ous hop node creates a forwarding entry with an inactive state or flag call= ed inactive forwarding entry." * which flag is being referred to? I presume non-signalled flag, or mere im= plementation detail? =20 8. Section 4.4: " The previous hop node of the primary egress node SHALL detect the failure= of the link between the primary egress node and its destination node (e.g.= the failure of the link between L1 and CE1 in Figure 1). =20 .. =20 Failure of the destination node and the link between the primary egress nod= e and the destination node CAN be detected by a BFD session between the pre= vious hop node and the destination node." * Not typical to trigger TE FRR on failures beyond the TE (sub)LSP path (be= yond the PE egress node).. Is it meant to cover slow routing convergence (f= rom PE to CE)? * AFAIK, the multihop BFD session will detect reachability from prev hop no= de to the destination node (not just L1-CE1 link liveliness). =20 " When we use the egress local protection to protect a primary egress node, we SHOULD NOT use any fast re-route to protect the link between the primary egress node and its previous hop node. The failure of the link is protected by the egress protection. " * While this may work for protecting subLSPs terminating on the primary egr= ess node, there's still need to protect subLSPs transitting the primary egr= ess node (in case of primary bud node). For example, consider case of facil= ity bypass, one could potentially have 2 bypass tunnels (1 terminates on ba= ckup egress node) and another on PLR NHOP (regular NHOP pass) to protect th= e transit subLSPs. =20 9. Section 5: * Typo: FFR -> FRR =20 =20 10. Section 6: "6. Representation of a Backup Sub LSP" * rfc4090 defines two ways to identify backup subLSP (sender-template and p= ath specific).. I assume both apply, if so could mention this * What about the backup subLSP sub-group fields (sub-group ID and sub-group= originator)? Are these assigned/set by the PLR since it originates the Path message? =20 " An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to specify the explicit route of a backup sub LSP that is from a previous hop node to a backup egress node. The EB-SERO is defined in the following section. " * I'm not sure if the ingress really needs to compose and signal the backup= subLSP SERO, given: 1. From rf4090, a PLR can independently (and optionally using constraints= set in the FAST_REROUTE object) route and signal the detour or bypass tunn= el. 2. In some cases (ingress resides in a different IGP area/domain), the in= gress may not have the visibility to compute the path from PLR to the backu= p egress node; however, the PLR could (provided backup egress node is in it= s TED). =20 11. Section 6.1.1 * Suggest rename "Egress IPv4 address" to Egress Primary Sub LSP IPv4 desti= nation address =20 12. Section 7.2.1. Backup LSP for One-to-One Protection: * It's not clear what goes on from the signalling perspective post the egre= ss node failure. - will the primary S2L subLSP (to the failed egress node) persist after= the egress node failure? If so, - will the fault (as detected by PLR) be notified back to the ingress n= ode, how? - How will the change of path (after reroute) of the primary S2L subLSP= be propagated back to the ingress? - What happens if the primary egress node (previously failed) recovers? - Would the backup egress node remain backup egress post the failure? =20 13. Section 7.2.1 " When a primary egress node of the LSP receives the Path message with an egress backup sub LSP descriptor list, it SHOULD ignore the egress backup sub LSP descriptor list and generate a PathErr message. " * I presume a transit/mid won't be allowed to act as a backup egress node t= oo (i.e. become bud after FRR)? If so, can be clarified =20 " If an intermediate node receives the Path message with an egress backup sub LSP descriptor list, it MUST put the EGRESS_BACKUP_SUB_LSP containing a backup egress into a Path message to be sent towards the backup egress. This SHALL be done for each EGRESS_BACKUP_SUB_LSP containing a backup egress node in the list. " * Not clear? is what's intended to say that intermediate node forwards EGRE= SS_BACKUP_SUB_LSP in the Path unchanged? =20 =20 14. Section 7.2.2: * Typo: satisifies -> satisfies * The mechanisms proposed here are in violation of RFC4090 (section 3.1): " In the one-to-one backup method, a label-switched path= is established that intersects the original LSP somewhere downstream of th= e point of link or node failure." (section 3.2): "The bypass tunnel must intersect the path of the origin= al LSP(s) somewhere downstream of the PLR." =20 " When the previous hop node detects a failure in the primary egress, it has to imports the traffic for the protected P2MP LSP into the backup bypass tunnel using the backup label as the top label. " * statement not clear, suggest rewording. * Not clear what's really involved in making local egress node protection w= ork with facility bypass tunnel Prior to the fault (egress node down): 1. Will there be an S2L subLSP signaled to the backup egress node o= r not? Post the fault (egress node down): 2. For link-protection, the top (outer) label will be the bypass tu= nnel label, and the inner label will be the label allocated by the next hop (bac= kup egress node (?)). It's not clear how this inner label is learnt back at= the PLR? 3. If multiple primary egress nodes are being protected by same bac= kup egress node and same bypass tunnel, does the backup egress node allocate a u= nique label for each? 4. After the fault (egress node down), what happens to the primary = subLSP? =20 Thanks, Tarek On 2013-06-11 10:16 PM, "Ross Callon" wrote: >Ravi, Eric, Tarek, Lizhong; > >You have been selected as MPLS Review team reviewers for=20 >draft-chen-mpls-p2mp-egress-protection-09. > >Note to authors: You have been CC'd on this email so that you can know=20 >that this review is going on. However, please do not review your own=20 >document. > >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=20 >and grammar understandable (it doesn't need to be perfect at this=20 >point, but should be reasonably clear). We are interested in knowing=20 >whether the document is ready to be considered for WG adoption (ie, it=20 >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=20 >secretary, and CC'd to the MPLS WG email list. If necessary, Comments=20 >may be sent privately to only the WG chairs. > >Are you able to review this draft by June 26, 2013? > >Thanks, Ross >(as MPLS WG chair) > > > > > From stbryant@cisco.com Fri Jun 21 07:39:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D2521F9BDB; Fri, 21 Jun 2013 07:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.383 X-Spam-Level: X-Spam-Status: No, score=-110.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faByYFTegINx; Fri, 21 Jun 2013 07:39:09 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8C11E8193; Fri, 21 Jun 2013 07:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8857; q=dns/txt; s=iport; t=1371825548; x=1373035148; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=SZPcSEOoxK3ukKiU5hTJ1TDWrdeF6yPnSvZladOuWK4=; b=ZaPNa+t/BTz+JKpqtEOMviC0zBmDJ6M81l9xuTn5/uQrsZIVLlAClnsW Ovls2DwBkrjSKFtWu7gS4H9F1dTReCNgUJUYhtzp2syr9mG/9fla9XWR+ tYm+y1pSqJ7jwGmhP+vNqtXrAxVzeoO7w/Db6GXAVbNMTR/LZKLEidRh/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAK1kxFGQ/khN/2dsb2JhbABbgwkxiSm2VYECFnSCIwEBAQQBAQFrCgEMBBwDAQIKFg8JAwIBAgEVHwcCCAYBDAEFAgEBF4dzDLxCjX6BOhEHBoNbA5dDgSmQG4MQ X-IronPort-AV: E=Sophos;i="4.87,913,1363132800"; d="scan'208,217";a="14893308" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 21 Jun 2013 14:39:06 +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 r5LEd4u6025782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 14:39:04 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r5LEd3hm025510; Fri, 21 Jun 2013 15:39:03 +0100 (BST) Message-ID: <51C46587.3020907@cisco.com> Date: Fri, 21 Jun 2013 15:39:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: isis-wg , "ospf@ietf.org" , "mpls@ietf.org" , "rtgwg@ietf.org" , 6man@ietf.org References: <51C352CA.6000307@cisco.com> In-Reply-To: <51C352CA.6000307@cisco.com> X-Forwarded-Message-Id: <51C352CA.6000307@cisco.com> Content-Type: multipart/alternative; boundary="------------080101000407060509050103" Cc: ops-area@ietf.org Subject: [mpls] Fwd: Status BOF in Berlin X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 14:39:14 -0000 This is a multi-part message in MIME format. --------------080101000407060509050103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This BOF touches on technology of interest to each of the working groups on the "To" list. I apologies to those that have already seen this through circulation to routing-discussion, but I know that not everyone is subscribed there. The list for discussion of this topic is status@ietf.org - Stewart -------- Original Message -------- Subject: Status BOF in Berlin Date: Thu, 20 Jun 2013 20:06:50 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com To: routing-discussion@ietf.org CC: status@ietf.org STATUS * Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS] * Status: Approved * Description The IETF has two packet-based forwarding technologies: IP and MPLS. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940 ) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6. This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic. * Responsible Area Directors: Adrian Farrel and Stewart Bryant * BoF Chairs: Alvaro Retana, John Scudder * * Mailing list: https://www.ietf.org/mailman/listinfo/status Further details can be found at http://trac.tools.ietf.org/bof/trac/wiki - Stewart --------------080101000407060509050103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This BOF touches on technology of interest to each of the
working groups on the "To" list.

I apologies to those that have already seen this through
circulation to routing-discussion, but I know that not
everyone is subscribed there.

The list for discussion of this topic is status@ietf.org

- Stewart

-------- Original Message --------
Subject: Status BOF in Berlin
Date: Thu, 20 Jun 2013 20:06:50 +0100
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
To: routing-discussion@ietf.org
CC: status@ietf.org


STATUS

  • Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS]
  • Status: Approved
  • Description

The IETF has two packet-based forwarding technologies: IP and MPLS.

IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes.

Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE.

Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6.

This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic.

Further details can be found  at http://trac.tools.ietf.org/bof/trac/wiki

- Stewart



--------------080101000407060509050103-- From ietf-secretariat-reply@ietf.org Fri Jun 21 08:58:26 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D992B11E81A0 for ; Fri, 21 Jun 2013 08:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtCmhzb8bJm7 for ; Fri, 21 Jun 2013 08:58:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F321E8127 for ; Fri, 21 Jun 2013 08:58:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130621155825.12951.6969.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 08:58:25 -0700 From: IETF Secretariat Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 15:58:27 -0000 Changed milestone "Submit draft-ietf-mpls-gach-adv for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From rcallon@juniper.net Fri Jun 21 10:29:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE93421E812A for ; Fri, 21 Jun 2013 10:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.967 X-Spam-Level: X-Spam-Status: No, score=-98.967 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7rhb7oH9Mem for ; Fri, 21 Jun 2013 10:29:50 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0953121E812D for ; Fri, 21 Jun 2013 10:29:49 -0700 (PDT) Received: from mail20-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 17:29:49 +0000 Received: from mail20-ch1 (localhost [127.0.0.1]) by mail20-ch1-R.bigfish.com (Postfix) with ESMTP id 520BC2001E0 for ; Fri, 21 Jun 2013 17:29:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail20-ch1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rcallon@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail20-ch1 (localhost.localdomain [127.0.0.1]) by mail20-ch1 (MessageSwitch) id 1371835738502229_13464; Fri, 21 Jun 2013 17:28:58 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail20-ch1.bigfish.com (Postfix) with ESMTP id 5F5F04400BC for ; Fri, 21 Jun 2013 17:28:58 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 17:28:57 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 10:28:55 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 10:28:55 -0700 Received: from CO9EHSOBE034.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 10:40:52 -0700 Received: from mail93-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE034.bigfish.com (10.236.130.97) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 17:28:54 +0000 Received: from mail93-co9 (localhost [127.0.0.1]) by mail93-co9-R.bigfish.com (Postfix) with ESMTP id BFC43660618 for ; Fri, 21 Jun 2013 17:28:54 +0000 (UTC) Received: from mail93-co9 (localhost.localdomain [127.0.0.1]) by mail93-co9 (MessageSwitch) id 1371835731990710_30699; Fri, 21 Jun 2013 17:28:51 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.227]) by mail93-co9.bigfish.com (Postfix) with ESMTP id E5C83640067; Fri, 21 Jun 2013 17:28:51 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 17:28:50 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.127]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 17:28:45 +0000 From: Ross Callon To: "iana@iana.org" , "adrian@olddog.co.uk" Thread-Topic: Request an early allocation of a UDP port for MPLS-in-UDP encapsulation Thread-Index: AQHObqTHqWkenM7640mZiRMf8ofjyg== Date: Fri, 21 Jun 2013 17:28:44 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316CEA3B4@CH1PRD0510MB355.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.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IANA.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Request an early allocation of a UDP port for MPLS-in-UDP encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 17:29:57 -0000 IANA; We would like to request an early allocation of a UDP port for MPLS-in-UDP = encapsulation, as described in the email below and in the referenced Intern= et Draft. My understanding of the process is that Adrian needs to approve t= his as AD for the MPLS WG.=20 Thanks, Ross (as MPLS WG co-chair) -----Original Message----- From: Xuxiaohu [mailto:xuxiaohu@huawei.com]=20 Sent: Friday, June 21, 2013 6:13 AM To: mpls-chairs@tools.ietf.org Subject: Request an early allocation of an UDP port for MPLS-in-UDP encapsu= lation Hi MPLS WG Chairs: We co-authors of draft-ietf-mpls-in-udp want to ask for an early allocation= of an UDP port from the User Ports Range according to RFC4020 and RFC6335 = and therefore request the MPLS wg chairs to initiate the procedures for thi= s. The following is the information for an early allocation: Service Name : MPLS-in-UDP Transport Protocol(s) : UDP Assignee: Xiaohu Xu Contact : Xiaohu Xu Description : Encapsulate MPLS packets in UDP tunnels for load balancing = purpose. Reference : draft-ietf-mpls-in-udp (MPLS wg document) Motivation: The motivation and usage of MPLS-in-UDP is described in [draf= t-ietf-mpls-in-udp]. The reason why using a port number in the Dynamic Port= s range is unsuitable is: some applications of MPLS-in-UDP (e.g., PWE3) don= 't have any mechanism for announcing the dynamic port number. In addition, = IP-layer broadcast, multicast, or anycast communication would not be used i= n the application of MPLS-in-UDP. Port Number : a number from the User Ports range Best regards, Xiaohu From ice@cisco.com Fri Jun 21 16:40:20 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F89E21F9EA9 for ; Fri, 21 Jun 2013 16:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SzD3P6RIlSl for ; Fri, 21 Jun 2013 16:40:15 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 404F821F9E99 for ; Fri, 21 Jun 2013 16:40:15 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5LNeCTi002671; Fri, 21 Jun 2013 19:40:13 -0400 (EDT) Received: from [10.155.32.100] ([10.155.32.100]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r5LNeCRw004648; Fri, 21 Jun 2013 16:40:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: IJsbrand Wijnands In-Reply-To: <5175576A.5030700@alcatel-lucent.com> Date: Fri, 21 Jun 2013 16:40:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5175576A.5030700@alcatel-lucent.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.1499) Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-wijnands-mpls-mldp-node-protection-02 and of draft-zhao-mpls-mldp-protections-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 23:40:20 -0000 Hi Martin, Thanks, these are great comments, see my response inline. >=20 > In order to protect node N, all the members of the MP2MP must > participate in protecting node N by acting both as PLR and MPT LSR. >=20 > Is it really all the members of the MP2MP LSP or only the LDP peers of = the root? > Confusion can come from the fact that figure 2 shows a very simple = MP2MP LSP where all members of the LSP are also directly-connected-to-N = members Ice: Yes, good point, its all directly connected LDP peers, I'll update = the draft. > Section 2.3 > s/If the PLR address on N changes for a give MP LSP/If the PLR address = on N changes for a given MP LSP/ Ice: Ack. > Section 3 > s/the PLR would have assign a Label Mapping/the PLR would have = assigned a Label Mapping/ Ice: Ack. > Section 4 and Section 5 > These sections need a bit more work to clarify the procedures and = sequence of events, so as to lift potential misunderstandings. >=20 > With regards to the reachability of N. Beginning of Section 4 the text = says: > When LSR1 discovered that node N is unreachable, it > can't determine whether it is the 'LSR1 - N' link or node N that > failed. > but first paragraph of Section 5 says: > The procedures following are > depending on whether the link 'LSR1 - N' has failed or node N = itself. > The two pieces of text seem contradictory. Information should be given = on how (and when?) the distinction could be made. >=20 > Also, with regards to the reachability of N, it should be clarified if = it is only considered through the 'LSR1 - N' link or not. >=20 > Also, the two following sentences seem to contradict each other: > If only the link > failed, LSR2 and LSR3 will receive duplicate packets due to the two > protection mechanisms. To prevent duplicate packets to be forwarded > to LSR2 and LSR3, either the primary upstream LSRs or the secondary > upstream LSRs should be forwarding MPLS packets, but never both at > the same time. > The first one says that duplicate packets will be received while the = second says that duplicate packets should not be received. > Strictly speaking it seems that duplicate packets will be received by = LSR2 and LSR3 but be dropped and that it will be the case until label is = withdrawn, and from that point on no duplicate traffic will be received. >=20 > Also, in Section 4 the use of forwarding is somehow misleading. = Indeed, rather than which primary or secondary LSR forwards the packets, = the point seems to be more about which primary or secondary LSR do the = MPTs decide to receive traffic from. Ice: Great points, I'll update the text to make it more clear. >=20 >=20 > Section 5.1 and 5.2 > Similarly to a previous remark, it appears that LSR2 and LSR3 need to = be able to make a distinction between 'LSR1 - N' link failure and node N = failure. While I understand that both the capability to detect that N is = unreachable and the capability to make a distinction between the two = types of failures is outside of the scope of the document, I believe = that the described procedures strongly depends on this capability. > If so, I would suggest to add somewhere something like "It MUST be = possible to distinguish 'LSR1 - N' link failure from node N failure". Ice: Its not really the case that either the upstream or downstream = nodes need to determine if the link or node failed. The differentiator = is really only the reachability between the protected node and the = downstream nodes. The procedures on LSR1 (upstream) are the same for = link or node failure. Its only the downstream nodes that also need to = react of the protected node because unreachable. I'll see if I can make = it more clear in the text. >=20 > One could wonder why Section 5.1 and 5.2 are not in Section 4. Ice: Fixed. >=20 >=20 > Section 5.2 > If N is still reachable why does LSR1 invoke the node protection = mechanism? Ice: I think you mis-intepreted, N is reachable from the POV of LSR2 and = LSR3. > More generally, the procedures described in the document are based on = the fact that both protection mechanisms are invoked while Section 4 = states that is is only a MAY. Ice: Strictly speaking node protection can be enabled without link = protection. So its not a MUST. It makes sense to apply both, otherwise = we're not protected if the link between LSR1 and N fails. So the = procedures described just try to accommodate both scenarios. >=20 >=20 > Section 5.3 > LSR1 will find that M is its > new primary upstream LSR to reach the Root and LSR3 will find Q. >=20 > I guess what was meant is: > LSR2 will find that P is its > new primary upstream LSR to reach the Root and LSR3 will find Q. Ice: Ack. >=20 > Also I tend to think that M should be switched to P in: > As soon as the new primary > upstream LSRs M and Q are activated, >=20 Ice: Ack. >=20 > Section 10.1 > Update reference for draft-napierala-mpls-targeted-mldp Ice: Ack. Many thanks, Ice.= From internet-drafts@ietf.org Fri Jun 21 17:11:58 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A113D21E8093; Fri, 21 Jun 2013 17:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NDpnHotjo+E; Fri, 21 Jun 2013 17:11:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D261321E8051; Fri, 21 Jun 2013 17:11:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130622001157.16772.22499.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 17:11:57 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-wijnands-mpls-mldp-node-protection-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 00:11:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : mLDP Node Protection Author(s) : IJsbrand Wijnands Eric Rosen Kamran Raza Jeff Tantsura Alia Atlas Huawei Technology Filename : draft-wijnands-mpls-mldp-node-protection-03.txt Pages : 16 Date : 2013-06-21 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-wijnands-mpls-mldp-node-protection There's also a htmlized version available at: http://tools.ietf.org/html/draft-wijnands-mpls-mldp-node-protection-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-wijnands-mpls-mldp-node-protection= -03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jun 23 05:25:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E9521F9DB1; Sun, 23 Jun 2013 05:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OxnlZPKlIDo; Sun, 23 Jun 2013 05:25:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB2221F9DA3; Sun, 23 Jun 2013 05:24:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130623122456.12302.89900.idtracker@ietfa.amsl.com> Date: Sun, 23 Jun 2013 05:24:56 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-wijnands-mpls-mldp-node-protection-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:25:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : mLDP Node Protection Author(s) : IJsbrand Wijnands Eric Rosen Kamran Raza Jeff Tantsura Alia Atlas Huawei Technology Filename : draft-wijnands-mpls-mldp-node-protection-04.txt Pages : 16 Date : 2013-06-23 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-wijnands-mpls-mldp-node-protection There's also a htmlized version available at: http://tools.ietf.org/html/draft-wijnands-mpls-mldp-node-protection-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-wijnands-mpls-mldp-node-protection= -04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Sun Jun 23 05:45:11 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF9A21F9DA4 for ; Sun, 23 Jun 2013 05:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcbuKRh22bi8 for ; Sun, 23 Jun 2013 05:45:02 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id CE34D21F9C26 for ; Sun, 23 Jun 2013 05:45:01 -0700 (PDT) Received: from [95.209.163.101] (95.209.163.101.mobile.tre.se [95.209.163.101]) (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 B5E431801110; Sun, 23 Jun 2013 14:45:00 +0200 (CEST) Message-ID: <51C6EDCD.6000403@pi.nu> Date: Sun, 23 Jun 2013 14:45:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-wijnands-mpls-mldp-node-protection@tools.ietf.org, "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:45:11 -0000 Working Group, The authors of draft-wijnands-mpls-mldp-node-protection has 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 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-wijnands-mpls-mldp-node-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 contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ice@cisco.com Sun Jun 23 05:52:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B136821F9DB0 for ; Sun, 23 Jun 2013 05:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcLuaUq3pk1j for ; Sun, 23 Jun 2013 05:52:41 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id F0FB021F99D3 for ; Sun, 23 Jun 2013 05:52:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5NCqc4G025559; Sun, 23 Jun 2013 08:52:39 -0400 (EDT) Received: from sjc-vpn3-649.cisco.com (sjc-vpn3-649.cisco.com [10.21.66.137]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r5NCqZap002035; Sun, 23 Jun 2013 05:52:36 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: IJsbrand Wijnands In-Reply-To: <51C6EDCD.6000403@pi.nu> Date: Sun, 23 Jun 2013 08:52:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94816208-E748-46D9-B7EE-8BD1AD8B59B6@cisco.com> References: <51C6EDCD.6000403@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1499) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-wijnands-mpls-mldp-node-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:52:45 -0000 Hi Loa, > Are you aware of any IPR that applies to = draft-wijnands-mpls-mldp-node-protection? Yes. > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). Yes, please see https://datatracker.ietf.org/ipr/1727/ Thx, Ice. From ice@cisco.com Sun Jun 23 06:18:50 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD71221F9C25 for ; Sun, 23 Jun 2013 06:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.024 X-Spam-Level: X-Spam-Status: No, score=-10.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6rSLI3A03jU for ; Sun, 23 Jun 2013 06:18:46 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 8A36C21F9C20 for ; Sun, 23 Jun 2013 06:18:46 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5NDIgUV027953; Sun, 23 Jun 2013 09:18:43 -0400 (EDT) Received: from sjc-vpn3-649.cisco.com (sjc-vpn3-649.cisco.com [10.21.66.137]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r5NDId24019576; Sun, 23 Jun 2013 06:18:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: IJsbrand Wijnands In-Reply-To: <51422270.3080804@pi.nu> Date: Sun, 23 Jun 2013 09:18:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51422270.3080804@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1499) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-targeted-mldp@tools.ietf.org Subject: Re: [mpls] IPR poll for draft-ietf-mpls-targeted-mldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 13:18:50 -0000 Hi Loa, Sorry for the delay. > Are you aware of any IPR that applies to = draft-ietf-mpls-targeted-mldp? No IPR that I know of. Thx, Ice. >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > 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 contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author = or > contributor, then please explicitly respond only if you are aware of = any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 >=20 > Thanks, Loa > (as MPLS WG co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From lizho.jin@gmail.com Sun Jun 23 07:26:50 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0233C21F8B51 for ; Sun, 23 Jun 2013 07:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soJnFBAgr9WJ for ; Sun, 23 Jun 2013 07:26:49 -0700 (PDT) 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 A19B021F8B35 for ; Sun, 23 Jun 2013 07:26:46 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id l18so1670643qak.9 for ; Sun, 23 Jun 2013 07:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NpvRr2OmoW/JsjCoqXVK8Gon6W6b12en/CWDA87Ht74=; b=qIvmRb3J9qORU7XTng2Ch3V4/nQqnktVBN+6TlK1BR8QLtMVg95gpKNdkBoFjLsLbS 8NeeT9eEQokKsTo4wZwi26ugVKKDPEOEZMRVxhoSr0TvYMu15VhKivNzE3SbaUYfFb4d rMhlJ/T37eJUMooDTomEpz4S8qBie2g56SgP/nJgJoNa+xY/2PXoIs8ahkFGHmimWOD1 SGMlpQ+pwgSUJSQ4W+SiwYHQ07KzM52/Gxg8cRL/iv7kwXHpI2NuvYWQ6xIWlZFykfEW O4/i4bhgXOxV/t+FqvMBiZ6/tHUHKT2J77wiWx/tO9ETyR6876gD1fc3E9wtjWv/HsjL L1pg== MIME-Version: 1.0 X-Received: by 10.224.151.137 with SMTP id c9mr14634161qaw.107.1371997606071; Sun, 23 Jun 2013 07:26:46 -0700 (PDT) Received: by 10.49.65.35 with HTTP; Sun, 23 Jun 2013 07:26:45 -0700 (PDT) Date: Sun, 23 Jun 2013 22:26:45 +0800 Message-ID: From: Lizhong Jin To: Ross Callon Content-Type: multipart/alternative; boundary=089e01494bb0f152c704dfd315c3 Cc: "mpls@ietf.org" , Raveendra Torvi , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:26:50 -0000 --089e01494bb0f152c704dfd315c3 Content-Type: text/plain; charset=ISO-8859-1 Hi authors, I have been asked to review draft-chen-mpls-p2mp-egress-protection-09. Overally, there are some points that need to be discussed before WG adoption. And I would appreciate if the authors could help to clarify. 1. If I understand the draft correctly, the primary and backup egress node address should be two different address. But actually, the egress node is closely related with many customer service configurations (e.g, mvpn and p2mp pw). Anycast address based protection has been proved to be an efficient way for MVPN and other service over RSVP-TE P2MP. Then if anycast address is applied for egress node protection, FRR defined in RFC4090 could be reused, right? 2. section 7.2.2. I doubt if the facility proction could work in the egress protection. The backup egress node does not know the P2MP lable allocated by the primary egress node. And it is very likely that the P2MP lable received by backup egress node has already been allocated for other purpose. Or is there any sychronization mechanism between primary and backup node. Regards Lizhong On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon wrote: > Ravi, Eric, Tarek, Lizhong; > > You have been selected as MPLS Review team reviewers for > draft-chen-mpls-p2mp-egress-protection-09. > > 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 June 26, 2013? > > Thanks, Ross > (as MPLS WG chair) > > > > > --089e01494bb0f152c704dfd315c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi authors,
I have been asked to review draft-chen-mpls-p2mp-egress-protec= tion-09. Overally, there are some points that need to be discussed before W= G adoption. And I would appreciate if the authors could help to clarify.
=A0
1. If I unde= rstand the draft correctly, the primary and backup egress node address shou= ld=A0be two different=A0address. But actually, the egress node is closely r= elated with many customer service=A0configurations (e.g, mvpn and p2mp pw).= =A0Anycast address based protection has been proved to be an efficient way = for MVPN and other service over RSVP-TE P2MP. Then if anycast address is ap= plied for egress node protection, FRR defined in RFC4090 could be reused, r= ight?
2. section 7.2.2. I doubt if the facility procti= on could work in the egress protection. The backup egress node does not kno= w the P2MP lable allocated by the primary egress node. And it is very likel= y that the P2MP lable received by backup egress node has already been alloc= ated for other purpose. Or is there any sychronization mechanism between pr= imary and backup node.
=A0
Regards
Lizhong

On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <rcallon@juniper.net&= gt; wrote:
Ravi, Eric, Tarek, Lizhong;

You have been selected as MPLS Review team reviewers for
draft-chen-mpls-p2mp-egress-protection-09.

Note to authors: You have been CC'd on this email so that you can know<= br> 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? =A0Also, 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 June 26, 2013?

Thanks, Ross
(as MPLS WG chair)





--089e01494bb0f152c704dfd315c3-- From tsaad@cisco.com Sun Jun 23 21:20:26 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEB211E8118 for ; Sun, 23 Jun 2013 21:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaMR+1cGeZlV for ; Sun, 23 Jun 2013 21:20:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 60EFC11E80A2 for ; Sun, 23 Jun 2013 21:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10742; q=dns/txt; s=iport; t=1372047621; x=1373257221; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KPy0f3VEObKYTf7FYvMEY44HsCHimyc6jbNqaKNfKP8=; b=e2cFDHT2kpfwQkkODMlliINXV1l9WfA+KiBOmVaEZACs7/2cUxhZFy7V ZPIxSkxALAQ/FPwJQqIqshFWX3dPQUGUHfp0y54kg/tcks1OrsxKrGz/+ 4BbM9PK9/KBqlNkFWLk6v6pOo6+g3rBhgpUZaMfghIrlcNhdQ2n3BA/0Z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJrIx1GtJV2Y/2dsb2JhbABRCoMJMUm/N38WdIIjAQEBBCcTPwwGAQgRBAEBAQoUCTkUCQgCBA4FCAGIBQy4bY4ECQaBCzEHBoJ8YQOpB4MQgXE3 X-IronPort-AV: E=Sophos;i="4.87,926,1363132800"; d="scan'208";a="223484081" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jun 2013 04:20:20 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5O4KKMk023677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 04:20:20 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.152]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sun, 23 Jun 2013 23:20:20 -0500 From: "Tarek Saad (tsaad)" To: Huaimo Chen Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHObgjRXhu7Ou41qUaE6SAXznaJBJlAKYcAgAQvbwA= Date: Mon, 24 Jun 2013 04:20:19 +0000 Message-ID: <2170E89B881FEA48B3A35413AB6FC4300FB3AAA6@xmb-aln-x08.cisco.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D4451E006F@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.82.255.50] Content-Type: text/plain; charset="us-ascii" Content-ID: <38789EED2C0A454BB4A33FA563C73646@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 04:20:26 -0000 Hi Huaimo, On 2013-06-21 9:40 AM, "Huaimo Chen" wrote: >Hi Tarek, > > Thanks much for very useful comments. We will wait until we see the >comments from all the MPLS-RT reviewers before updating the draft. > > Could you please give us a hint which of your comments you think are >necessary to address before this document becomes a working group >document? Ideally all; otherwise, an agreed roadmap on how the remaining items will be addressed. Regards, Tarek > >Best Regards, >Huaimo > >-----Original Message----- >From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] >Sent: Thursday, June 20, 2013 6:52 PM >To: Ross Callon; Raveendra Torvi; Eric Gray; Lizhong Jin >Cc: mpls-chairs@tools.ietf.org; >draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; Martin Vigoureux; >mpls@ietf.org >Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection > >Hi all, > >=20 >I have been asked to the review the below document/draft: > >Extensions to RSVP-TE for P2MP LSP Egress Local Protection, >http://www.ietf.org/id/draft-chen-mpls-p2mp-egress-protection-09.txt >=20 > >Overall, the draft is well written, the motivation is clear, and the >proposal is sound. I think the document should be considered for WG >adoption, but more discussions and input will be needed from the group on >the proposed mechanisms. >=20 > >More comments below: >1. Suggest a change to the draft outline for easier flow of the draft, >e.g.: >- Applicability of Local Repair Techniques > - One-to-one Backup > - Facility Backup >- RSVP extensions >- Headend Behavior >- PLR behavior > - Signaling of Backup sub-LSP > - .. >- Behavior of All LSRs >=20 > >2. Is the draft also intendeds to cover locally protecting egress nodes >that act as transits/mids (aka P2MP bud LSR nodes)? Either way, could be >helpful if it mentioned it. >=20 > >3. Section 1: >"An existing method for protecting the egress nodes of a P2MP LSP sets up >a backup P2MP LSP from a backup ingress node to the backup egress nodes." >* the backup P2MP LSP can also originate from same ingress node to the >set of backup egress nodes. >* a variant would be to graft another primary S2L sub-LSP to the "backup" >egress node. Traffic flows on to both egress nodes, and receiver can >select traffic from either based on route to source via RPF. >=20 > >4. Section 4.1: >Typo: follwing -> following >=20 > >5. Consider > PLR > +--+--+ > | | | > A B C > / | \ > / + \ > / / \ \ >CE1---+ +--- CE2 >=20 >* If the same backup egress node (e.g. B) is used to protect two or more >primary egress nodes (e.g. A and C), when PLR reroutes traffic onto the >backup (detour or bypass tunnel via B) due to a failure of one of the >primary egress nodes (eg. A), the receiver(s) connected to other primary >egress node(s) (e.g. CE2) starts to receive duplicated traffic (via C and >via B). >=20 > >6. Section 4.2: >"The previous hop node of the primary egress node sets up a backup sub >LSP from itself" >* Arguably, a PLR is one that usually provisions/assigns backup (detour >or bypass). Personally, favour using the term upstream node PLR over >previous hop node (used extensively in the draft). >=20 > >7. Section 4.3: >"After receiving the RSVP-TE RESV message for the backup sub LSP, the >previous hop node creates a forwarding entry with an inactive state or >flag called inactive forwarding entry." >* which flag is being referred to? I presume non-signalled flag, or mere >implementation detail? >=20 > >8. Section 4.4: >" The previous hop node of the primary egress node SHALL detect the >failure of the link between the primary egress node and its destination >node (e.g. the failure of the link between L1 and CE1 in Figure 1). >=20 >.. =20 >Failure of the destination node and the link between the primary egress >node and the destination node CAN be detected by a BFD session between >the previous hop node and the destination node." >* Not typical to trigger TE FRR on failures beyond the TE (sub)LSP path >(beyond the PE egress node).. Is it meant to cover slow routing >convergence (from PE to CE)? >* AFAIK, the multihop BFD session will detect reachability from prev hop >node to the destination node (not just L1-CE1 link liveliness). >=20 >" > When we use the egress local protection to protect a primary egress > node, we SHOULD NOT use any fast re-route to protect the link between > the primary egress node and its previous hop node. The failure of > the link is protected by the egress protection. >" >* While this may work for protecting subLSPs terminating on the primary >egress node, there's still need to protect subLSPs transitting the >primary egress node (in case of primary bud node). For example, consider >case of facility bypass, one could potentially have 2 bypass tunnels (1 >terminates on backup egress node) and another on PLR NHOP (regular NHOP >pass) to protect the transit subLSPs. >=20 > >9. Section 5: >* Typo: FFR -> FRR >=20 >=20 > >10. Section 6: >"6. Representation of a Backup Sub LSP" >* rfc4090 defines two ways to identify backup subLSP (sender-template and >path specific).. I assume both apply, if so could mention this >* What about the backup subLSP sub-group fields (sub-group ID and >sub-group originator)? > Are these assigned/set by the PLR since it originates the Path message? >=20 >" > An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to > specify the explicit route of a backup sub LSP that is from a > previous hop node to a backup egress node. The EB-SERO is defined in > the following section. >" >* I'm not sure if the ingress really needs to compose and signal the >backup subLSP SERO, given: > 1. From rf4090, a PLR can independently (and optionally using >constraints set in the FAST_REROUTE object) route and signal the detour >or bypass tunnel. > 2. In some cases (ingress resides in a different IGP area/domain), the >ingress may not have the visibility to compute the path from PLR to the >backup egress node; however, the PLR could (provided backup egress node >is in its TED). >=20 > >11. Section 6.1.1 >* Suggest rename "Egress IPv4 address" to Egress Primary Sub LSP IPv4 >destination address > >=20 >12. Section 7.2.1. Backup LSP for One-to-One Protection: >* It's not clear what goes on from the signalling perspective post the >egress node > failure. > - will the primary S2L subLSP (to the failed egress node) persist >after the egress node failure? If so, > - will the fault (as detected by PLR) be notified back to the ingress >node, how? > - How will the change of path (after reroute) of the primary S2L >subLSP be propagated > back to the ingress? > - What happens if the primary egress node (previously failed) >recovers? > - Would the backup egress node remain backup egress post the failure? >=20 > >13. Section 7.2.1 >" > When a primary egress node of the LSP receives the Path message with > an egress backup sub LSP descriptor list, it SHOULD ignore the egress > backup sub LSP descriptor list and generate a PathErr message. >" >* I presume a transit/mid won't be allowed to act as a backup egress node >too (i.e. become > bud after FRR)? If so, can be clarified >=20 >" > If an intermediate node receives the Path message with an egress > backup sub LSP descriptor list, it MUST put the EGRESS_BACKUP_SUB_LSP > containing a backup egress into a Path message to be sent towards the > backup egress. This SHALL be done for each EGRESS_BACKUP_SUB_LSP > containing a backup egress node in the list. >" >* Not clear? is what's intended to say that intermediate node forwards >EGRESS_BACKUP_SUB_LSP in the Path unchanged? >=20 >=20 > >14. Section 7.2.2: >* Typo: satisifies -> satisfies >* The mechanisms proposed here are in violation of RFC4090 > (section 3.1): " In the one-to-one backup method, a label-switched >path is established that intersects the original LSP somewhere downstream >of the point of link or node failure." > (section 3.2): "The bypass tunnel must intersect the path of the >original LSP(s) somewhere downstream of the PLR." >=20 >" > When the previous hop node detects a failure in the primary egress, > it has to imports the traffic for the protected P2MP LSP into the > backup bypass tunnel using the backup label as the top label. >" >* statement not clear, suggest rewording. >* Not clear what's really involved in making local egress node protection >work with > facility bypass tunnel > Prior to the fault (egress node down): > 1. Will there be an S2L subLSP signaled to the backup egress node >or > not? > Post the fault (egress node down): > 2. For link-protection, the top (outer) label will be the bypass >tunnel label, and > the inner label will be the label allocated by the next hop >(backup egress > node (?)). It's not clear how this inner label is learnt back >at the PLR? > 3. If multiple primary egress nodes are being protected by same >backup egress node > and same bypass tunnel, does the backup egress node allocate a >unique label for > each? > 4. After the fault (egress node down), what happens to the >primary subLSP? >=20 > >Thanks, >Tarek > >On 2013-06-11 10:16 PM, "Ross Callon" wrote: > >>Ravi, Eric, Tarek, Lizhong; >> >>You have been selected as MPLS Review team reviewers for >>draft-chen-mpls-p2mp-egress-protection-09. >> >>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 June 26, 2013? >> >>Thanks, Ross >>(as MPLS WG chair) >> >> >> >> >> > From skraza@cisco.com Mon Jun 24 06:47:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7072F21F9B5C for ; Mon, 24 Jun 2013 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noT9oVUfwhqM for ; Mon, 24 Jun 2013 06:47:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 625A421F9B32 for ; Mon, 24 Jun 2013 06:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1819; q=dns/txt; s=iport; t=1372081621; x=1373291221; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=6UEJu5IVg7EHEL4+CqZbqDZSPfHWqEtp/5bdHs0M3SQ=; b=kd/xz8+NIcDX6TQUmia6w5YoEYSip45HAw2CRxZ4JMskkgBX6fBNxdGj 3bfQpKo50KiAVKk7YMcEbIgmgcwfjIZZaeGoNBdbmvyt8oWmBndVVPHQl d54x/WOHm4QB+aU9amhOcmo07akyXCqR7064kLqXH+0HvR0dpO5NPjdEv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAC5NyFGtJV2b/2dsb2JhbABbgwkxSb83gQMWdIIjAQEBAwE6MQMGEwQBCCIUKxclAgQBEgiIAAYMuVQEBI4JEIEBOIMCYQOpB4MQgXE3 X-IronPort-AV: E=Sophos;i="4.87,928,1363132800"; d="scan'208";a="226655317" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 24 Jun 2013 13:47:01 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5ODl0CL005171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 13:47:00 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 24 Jun 2013 08:47:00 -0500 From: "Kamran Raza (skraza)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: IPR Poll on draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOcA98mtsSm/yf4ESunGAwcNyp+JlE8zqA Date: Mon, 24 Jun 2013 13:46:59 +0000 Message-ID: In-Reply-To: <51C6EDCD.6000403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.86.240.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <11D4D866AC55BA46AD28E4C763AF6DCD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 13:47:06 -0000 Hi Loa, >> Are you aware of any IPR that applies to >>draft-wijnands-mpls-mldp-node-protection? Yes.=20 >> If so, has this IPR been disclosed in compliance with IETF IPR rules >>(see RFCs 3979, 4879, 3669 and 5378 for more details). Yes. Please refer to https://datatracker.ietf.org/ipr/1727/ [ P.S.: This is the same IPR that Ice has also disclosed ] Thx. On 2013-06-23 8:45 AM, "Loa Andersson" wrote: >Working Group, > >The authors of draft-wijnands-mpls-mldp-node-protection has 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 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-wijnands-mpls-mldp-node-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 contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > > >Thanks, Loa >(as MPLS WG co-chair) > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Mon Jun 24 07:07:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E7621E80F2; Mon, 24 Jun 2013 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sbOgFpovy2M; Mon, 24 Jun 2013 07:07:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5282011E8156; Mon, 24 Jun 2013 07:07:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130624140753.21759.10943.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 07:07:53 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-targeted-mldp-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:07:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Using LDP Multipoint Extensions on Targeted LDP Sessions Author(s) : Maria Napierala Eric C. Rosen Filename : draft-ietf-mpls-targeted-mldp-02.txt Pages : 9 Date : 2013-06-24 Abstract: As specified in RFC 6388, Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to- Multipoint (MP2MP) Label Switched Paths. However, RFC 6388 presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification (RFC 5036) allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-targeted-mldp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-targeted-mldp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-targeted-mldp-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.vigoureux@alcatel-lucent.com Mon Jun 24 07:15:04 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B217A21E8110 for ; Mon, 24 Jun 2013 07:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.449 X-Spam-Level: X-Spam-Status: No, score=-109.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dcG8X6FY-aj for ; Mon, 24 Jun 2013 07:14:56 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4D21E8103 for ; Mon, 24 Jun 2013 07:14:48 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r5OEEc8X027332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Jun 2013 09:14:39 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r5OEEaxp000585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 10:14:38 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 24 Jun 2013 10:14:28 -0400 Received: from [172.27.205.220] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 24 Jun 2013 16:13:58 +0200 Message-ID: <51C85426.20307@alcatel-lucent.com> Date: Mon, 24 Jun 2013 16:13:58 +0200 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: IJsbrand Wijnands References: <5175576A.5030700@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-wijnands-mpls-mldp-node-protection-02 and of draft-zhao-mpls-mldp-protections-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:15:04 -0000 Ice, thanks. I went through rev 3 and 4 and I am ok with the updates. Cheers, Martin Le 22/06/2013 01:40, IJsbrand Wijnands a écrit : > Hi Martin, > > Thanks, these are great comments, see my response inline. > >> >> In order to protect node N, all the members of the MP2MP must >> participate in protecting node N by acting both as PLR and MPT LSR. >> >> Is it really all the members of the MP2MP LSP or only the LDP peers of the root? >> Confusion can come from the fact that figure 2 shows a very simple MP2MP LSP where all members of the LSP are also directly-connected-to-N members > > Ice: Yes, good point, its all directly connected LDP peers, I'll update the draft. > >> Section 2.3 >> s/If the PLR address on N changes for a give MP LSP/If the PLR address on N changes for a given MP LSP/ > > Ice: Ack. > >> Section 3 >> s/the PLR would have assign a Label Mapping/the PLR would have assigned a Label Mapping/ > > Ice: Ack. > >> Section 4 and Section 5 >> These sections need a bit more work to clarify the procedures and sequence of events, so as to lift potential misunderstandings. >> >> With regards to the reachability of N. Beginning of Section 4 the text says: >> When LSR1 discovered that node N is unreachable, it >> can't determine whether it is the 'LSR1 - N' link or node N that >> failed. >> but first paragraph of Section 5 says: >> The procedures following are >> depending on whether the link 'LSR1 - N' has failed or node N itself. >> The two pieces of text seem contradictory. Information should be given on how (and when?) the distinction could be made. >> >> Also, with regards to the reachability of N, it should be clarified if it is only considered through the 'LSR1 - N' link or not. >> >> Also, the two following sentences seem to contradict each other: >> If only the link >> failed, LSR2 and LSR3 will receive duplicate packets due to the two >> protection mechanisms. To prevent duplicate packets to be forwarded >> to LSR2 and LSR3, either the primary upstream LSRs or the secondary >> upstream LSRs should be forwarding MPLS packets, but never both at >> the same time. >> The first one says that duplicate packets will be received while the second says that duplicate packets should not be received. >> Strictly speaking it seems that duplicate packets will be received by LSR2 and LSR3 but be dropped and that it will be the case until label is withdrawn, and from that point on no duplicate traffic will be received. >> >> Also, in Section 4 the use of forwarding is somehow misleading. Indeed, rather than which primary or secondary LSR forwards the packets, the point seems to be more about which primary or secondary LSR do the MPTs decide to receive traffic from. > > Ice: Great points, I'll update the text to make it more clear. > >> >> >> Section 5.1 and 5.2 >> Similarly to a previous remark, it appears that LSR2 and LSR3 need to be able to make a distinction between 'LSR1 - N' link failure and node N failure. While I understand that both the capability to detect that N is unreachable and the capability to make a distinction between the two types of failures is outside of the scope of the document, I believe that the described procedures strongly depends on this capability. >> If so, I would suggest to add somewhere something like "It MUST be possible to distinguish 'LSR1 - N' link failure from node N failure". > > Ice: Its not really the case that either the upstream or downstream nodes need to determine if the link or node failed. The differentiator is really only the reachability between the protected node and the downstream nodes. The procedures on LSR1 (upstream) are the same for link or node failure. Its only the downstream nodes that also need to react of the protected node because unreachable. I'll see if I can make it more clear in the text. > > >> >> One could wonder why Section 5.1 and 5.2 are not in Section 4. > > Ice: Fixed. > >> >> >> Section 5.2 >> If N is still reachable why does LSR1 invoke the node protection mechanism? > > Ice: I think you mis-intepreted, N is reachable from the POV of LSR2 and LSR3. > >> More generally, the procedures described in the document are based on the fact that both protection mechanisms are invoked while Section 4 states that is is only a MAY. > > Ice: Strictly speaking node protection can be enabled without link protection. So its not a MUST. It makes sense to apply both, otherwise we're not protected if the link between LSR1 and N fails. So the procedures described just try to accommodate both scenarios. > >> >> >> Section 5.3 >> LSR1 will find that M is its >> new primary upstream LSR to reach the Root and LSR3 will find Q. >> >> I guess what was meant is: >> LSR2 will find that P is its >> new primary upstream LSR to reach the Root and LSR3 will find Q. > > Ice: Ack. > >> >> Also I tend to think that M should be switched to P in: >> As soon as the new primary >> upstream LSRs M and Q are activated, >> > > Ice: Ack. > >> >> Section 10.1 >> Update reference for draft-napierala-mpls-targeted-mldp > > Ice: Ack. > > Many thanks, > > Ice. > From erosen@cisco.com Mon Jun 24 07:19:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CED11E815E for ; Mon, 24 Jun 2013 07:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5tLnbIzQ7T5 for ; Mon, 24 Jun 2013 07:19:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AC0E721E8111 for ; Mon, 24 Jun 2013 07:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=175; q=dns/txt; s=iport; t=1372083557; x=1373293157; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=jTGWGjZRuB8f31VdtkIbB16y1fy9cEiLFA6p+MpzHKs=; b=ga6mw67VjGxWoI6lZ+QJR+BBkPakBYJ8TyyvQUw7sNCxYsnKpzBZTn4e IwvkgDtsSM9jAG6WTI9EgsrIF7lWnAt1gADrvk1uRHn+OU71MyjvU1CJC 0ynL2eZ9W6SU1JNmZi+KfUYJhurwaIuKiLoPFaqRrFcc9R2nyaUgYATNI w=; X-IronPort-AV: E=Sophos;i="4.87,928,1363132800"; d="scan'208";a="226755346" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jun 2013 14:19:17 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5OEJGjd001932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jun 2013 14:19:17 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r5OEJFT4004485; Mon, 24 Jun 2013 10:19:15 -0400 From: Eric Rosen To: Loa Andersson In-reply-to: Your message of Sun, 23 Jun 2013 14:45:01 +0200. <51C6EDCD.6000403@pi.nu> Date: Mon, 24 Jun 2013 10:19:15 -0400 Message-ID: <4484.1372083555@erosen-linux> Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-wijnands-mpls-mldp-node-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:19:29 -0000 > Are you aware of any IPR that applies to > draft-wijnands-mpls-mldp-node-protection? I'm not aware of any IPR other than what Ice and Kamran have already mentioned. From jeff.tantsura@ericsson.com Mon Jun 24 07:30:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1BD21E812B for ; Mon, 24 Jun 2013 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoie4gJJEn8m for ; Mon, 24 Jun 2013 07:30:47 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B239A21E812D for ; Mon, 24 Jun 2013 07:30:42 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-44-51c8580e8152 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FA.24.17537.E0858C15; Mon, 24 Jun 2013 16:30:38 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 10:30:38 -0400 From: Jeff Tantsura To: Loa Andersson Thread-Topic: IPR Poll on draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOcOXOf6+/RWL8skC6smD0l7Qq+JlE7P52 Date: Mon, 24 Jun 2013 14:30:37 +0000 Message-ID: <65B72256-09E6-42FC-8D5F-1CFA1F8E275B@ericsson.com> References: Your message of Sun, 23 Jun 2013 14:45:01 +0200. <51C6EDCD.6000403@pi.nu>,<4484.1372083555@erosen-linux> In-Reply-To: <4484.1372083555@erosen-linux> 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+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPty5fxIlAg3sL9S1+Tve1WHd3EovF v7lzmC3u7PrCavH90hIWi1tLV7I6sHm0PtvL6jHl90ZWjyVLfjJ5zJrexubx5fJntgDWKC6b lNSczLLUIn27BK6M02+jCmYzVrz7tZqpgbG6i5GTQ0LAROJ44042CFtM4sK99UA2F4eQwFFG ieu3NjJDOMsZJbYencgMUsUmYCDx/9txFhBbREBW4tq2n0wgRcwCJ5gkNl66D1YkLOAo0dz0 kxmiyEniwrxOdgjbSGLqvldgNouAqsTPlxvAbF4Be4kHNzdCrW5ilLh0vY0RJMEpoC3R/H82 WBEj0H3fT61hArGZBcQlbj2ZzwRxt4DEkj3nmSFsUYmXj/+xQtToSCzY/YkNwtaWWLbwNTPE MkGJkzOfsExgFJ2FZNQsJC2zkLTMQtKygJFlFSNHaXFqWW66kcEmRmBMHZNg093BuOel5SFG aQ4WJXHel6d2BQoJpCeWpGanphakFsUXleakFh9iZOLglGpgNLB+LWm9N9/+/78U9d8mfRWT 92b+f8pVaXbl6JOz9u9PueQVbHPwzZOS6rGz4Qop5b78JHDvZq5O2So3z8u2Afl9xlo7u1Ql c5pd7ryb9+pK17sLmZ0t03XXewQbL1tjZXu96MjzN8qL8+2VWb5e3KB+eYG14rlejw0pK/+X zJqTmaugy7daiaU4I9FQi7moOBEAtwdmQHcCAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:30:53 -0000 Hi, Same here Regards, Jeff On Jun 24, 2013, at 4:19 PM, "Eric Rosen" wrote: >> draft-wijnands-mpls-mldp-node-protection? From quintin.zhao@huawei.com Mon Jun 24 07:56:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A47E11E8164 for ; Mon, 24 Jun 2013 07:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHEa6RH+QMdx for ; Mon, 24 Jun 2013 07:56:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EDE3311E8145 for ; Mon, 24 Jun 2013 07:56:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUI29045; Mon, 24 Jun 2013 14:56:24 +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.1.323.7; Mon, 24 Jun 2013 15:55:43 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 15:56:20 +0100 Received: from QZHAO (10.212.246.132) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.7; Mon, 24 Jun 2013 07:56:13 -0700 From: Quintin Zhao To: "'Loa Andersson'" References: Your message of Sun, 23 Jun 2013 14:45:01 +0200. <51C6EDCD.6000403@pi.nu>, <4484.1372083555@erosen-linux> <65B72256-09E6-42FC-8D5F-1CFA1F8E275B@ericsson.com> In-Reply-To: <65B72256-09E6-42FC-8D5F-1CFA1F8E275B@ericsson.com> Date: Mon, 24 Jun 2013 10:56:02 -0400 Message-ID: <000001ce70ea$f4130b30$dc392190$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOcOXOf6+/RWL8skC6smD0l7Qq+JlE7P52gAAGtCA= Content-Language: zh-cn X-Originating-IP: [10.212.246.132] X-CFilter-Loop: Reflected Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-wijnands-mpls-mldp-node-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 14:56:33 -0000 Same here too. Regards, Quintin -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Sent: 2013=C4=EA6=D4=C224=C8=D5 10:31 To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-node-protection@tools.ietf.org; VIGOUREUX, = MARTIN (MARTIN); erosen@cisco.com Subject: Re: IPR Poll on draft-wijnands-mpls-mldp-node-protection Hi, Same here Regards, Jeff On Jun 24, 2013, at 4:19 PM, "Eric Rosen" wrote: >> draft-wijnands-mpls-mldp-node-protection? From eric.gray@ericsson.com Mon Jun 24 08:19:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF7521E8104 for ; Mon, 24 Jun 2013 08:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+i9yZN-L8Bu for ; Mon, 24 Jun 2013 08:19:23 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A7DD011E8146 for ; Mon, 24 Jun 2013 08:19:20 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-43-51c863777382 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 60.A7.17537.77368C15; Mon, 24 Jun 2013 17:19:20 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 11:19:18 -0400 From: Eric Gray To: Quintin Zhao , 'Loa Andersson' Thread-Topic: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOcOd4sVWVdNy18EWYO/idyohorJlFNyIA///Ci3A= Date: Mon, 24 Jun 2013 15:19:17 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60CA2F6@eusaamb107.ericsson.se> References: Your message of Sun, 23 Jun 2013 14:45:01 +0200. <51C6EDCD.6000403@pi.nu>, <4484.1372083555@erosen-linux> <65B72256-09E6-42FC-8D5F-1CFA1F8E275B@ericsson.com> <000001ce70ea$f4130b30$dc392190$@zhao@huawei.com> In-Reply-To: <000001ce70ea$f4130b30$dc392190$@zhao@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPoG5F8olAg7PTeSx+Tve1+Dd3DrPF 90tLWCxuLV3JanFiWq0Dq0fLkbesHkuW/GTymDW9jc3jy+XPbAEsUVw2Kak5mWWpRfp2CVwZ L45eYSp4ylPxZ9Y81gbG21xdjJwcEgImEh273rJA2GISF+6tZwOxhQSOMko0fuDsYuQCspcz Snxe8hKsiE1AQ+LYnbWMILaIgLvEqgmvmUCKmAVuMko8+biUHSQhLOAh8e/OKVaIIk+JOVO7 gZo5gGwriT9/eUHCLAKqEmsWTQGbySvgLXHk1XF2iGVvGSVOda0Bu4JTwE5i8qRPYDYj0HXf T61hArGZBcQlbj2ZzwRxtYDEkj3nmSFsUYmXj/+xQtjKEkue7GeBqNeX2DPxFJStLbFs4Wtm iMWCEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzAqDomwaa7g3HPS8tD jNIcLErivC9P7QoUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKjM/OOsWpRA3VJnziTFoOZ1 W/uF53Px3Tvbbmd2NOWZ0JIzeqUhy/9Or7yaOfcD403BzdtmlcXIbdvBN3/5nJPzniy8f2+J cLxvxd3w8yqvBV5O6XC7/JWXOeDNoj9lGx7cYQ0RjjzbXn5i8iLmL9vkV+aynMk4lB7ivy/u ed3ivdEW7u8/lisosRRnJBpqMRcVJwIA+IYA+HgCAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 15:19:29 -0000 Quintin, I am reasonably certain that this is an indirect response to the mail whic= h=20 Eric Rosen sent which included the following: "> Are you aware of any IPR that applies to=20 "> draft-wijnands-mpls-mldp-node-protection? "I'm not aware of any IPR other than what Ice and Kamran have already menti= oned." Unfortunately, the text that you're agreeing to was not in the mail messag= e. Could you just re-affirm that you are saying that you are unaware of any I= PR beyond that which has been mentioned already? Thanks! -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Qui= ntin Zhao Sent: Monday, June 24, 2013 10:56 AM To: 'Loa Andersson' Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-nod= e-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Same here too. Regards, Quintin -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] Sent: 2013=1B$BG/=1B(B6=1B$B7n=1B(B24=1B$BF|=1B(B 10:31 To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-nod= e-protection@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); erosen@cisco.com Subject: Re: IPR Poll on draft-wijnands-mpls-mldp-node-protection Hi, Same here Regards, Jeff On Jun 24, 2013, at 4:19 PM, "Eric Rosen" wrote: >> draft-wijnands-mpls-mldp-node-protection? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From quintin.zhao@huawei.com Mon Jun 24 08:40:58 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A6621E810F for ; Mon, 24 Jun 2013 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tODEY4j-AbWa for ; Mon, 24 Jun 2013 08:40:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0677321E80FA for ; Mon, 24 Jun 2013 08:40:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUI32434; Mon, 24 Jun 2013 15:40:43 +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.1.323.7; Mon, 24 Jun 2013 16:40:00 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 16:40:37 +0100 Received: from QZHAO (10.212.246.132) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.7; Mon, 24 Jun 2013 08:40:31 -0700 From: Quintin Zhao To: "'Eric Gray'" , "'Loa Andersson'" References: Your message of Sun, 23 Jun 2013 14:45:01 +0200. <51C6EDCD.6000403@pi.nu>, <4484.1372083555@erosen-linux> <65B72256-09E6-42FC-8D5F-1CFA1F8E275B@ericsson.com> <000001ce70ea$f4130b30$dc392190$@zhao@huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF60CA2F6@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF60CA2F6@eusaamb107.ericsson.se> Date: Mon, 24 Jun 2013 11:40:26 -0400 Message-ID: <000201ce70f1$272d1be0$758753a0$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOcOd4sVWVdNy18EWYO/idyohorJlFNyIA///Ci3CAAAaDgA== Content-Language: zh-cn X-Originating-IP: [10.212.246.132] X-CFilter-Loop: Reflected Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-wijnands-mpls-mldp-node-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 15:40:59 -0000 Eric, Thanks and here it is: > Are you aware of any IPR that applies to=20 > draft-wijnands-mpls-mldp-node-protection? I'm not aware of any IPR other than what Ice and Kamran have already mentioned. Quintin -----Original Message----- From: Eric Gray [mailto:eric.gray@ericsson.com]=20 Sent: 2013=C4=EA6=D4=C224=C8=D5 11:19 To: Quintin Zhao; 'Loa Andersson' Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-node-protection@tools.ietf.org Subject: RE: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Quintin, I am reasonably certain that this is an indirect response to the mail which Eric Rosen sent which included the following: "> Are you aware of any IPR that applies to "> draft-wijnands-mpls-mldp-node-protection? "I'm not aware of any IPR other than what Ice and Kamran have already mentioned." Unfortunately, the text that you're agreeing to was not in the mail message. Could you just re-affirm that you are saying that you are unaware of any IPR beyond that which has been mentioned already? Thanks! -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Quintin Zhao Sent: Monday, June 24, 2013 10:56 AM To: 'Loa Andersson' Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-node-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Same here too. Regards, Quintin -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] Sent: 2013=C4=EA6=D4=C224=C8=D5 10:31 To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-node-protection@tools.ietf.org; VIGOUREUX, = MARTIN (MARTIN); erosen@cisco.com Subject: Re: IPR Poll on draft-wijnands-mpls-mldp-node-protection Hi, Same here Regards, Jeff On Jun 24, 2013, at 4:19 PM, "Eric Rosen" wrote: >> draft-wijnands-mpls-mldp-node-protection? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Mon Jun 24 08:45:18 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59111E814C for ; Mon, 24 Jun 2013 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htFO5EM1oq9R for ; Mon, 24 Jun 2013 08:45:13 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 08B6721E80E9 for ; Mon, 24 Jun 2013 08:45:12 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-a6-51c869882b90 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E1.59.17537.88968C15; Mon, 24 Jun 2013 17:45:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 11:45:12 -0400 From: Eric Gray To: Quintin Zhao , 'Loa Andersson' Thread-Topic: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOcOd4sVWVdNy18EWYO/idyohorJlFNyIA///Ci3CAAAaDgIAAAZag Date: Mon, 24 Jun 2013 15:45:11 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60CB34E@eusaamb107.ericsson.se> References: Your message of Sun, 23 Jun 2013 14:45:01 +0200. <51C6EDCD.6000403@pi.nu>, <4484.1372083555@erosen-linux> <65B72256-09E6-42FC-8D5F-1CFA1F8E275B@ericsson.com> <000001ce70ea$f4130b30$dc392190$@zhao@huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF60CA2F6@eusaamb107.ericsson.se> <000201ce70f1$272d1be0$758753a0$@zhao@huawei.com> In-Reply-To: <000201ce70f1$272d1be0$758753a0$@zhao@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXSPt25H5olAg98P9Sx+Tve1+Dd3DrPF 90tLWCxuLV3JanFiWq0Dq0fLkbesHkuW/GTymDW9jc3jy+XPbAEsUVw2Kak5mWWpRfp2CVwZ X2bcYSqYIVJxYwZPA2OLYBcjB4eEgInEvF9uXYycQKaYxIV769m6GLk4hASOMko8aNwH5Sxn lFg44QYjSBWbgIbEsTtrwWwRAXeJVRNeM4EUMQvcZJR48nEpO0hCWMBD4t+dU6wQRZ4Sc6Z2 s0DYbhJT5s9kBrFZBFQl2tf3g8V5Bbwlbs24zwix7TGTxKP/F9lAEpwCdhLbpjaDbWMEuu/7 qTVMIDazgLjErSfzmSDuFpBYsuc8M4QtKvHy8T9WCFtZYsmT/SwQ9foSeyaegrK1JZYtfM0M sVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmSwiREYVcck2HR3MO55aXmI UZqDRUmc9+WpXYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGBeul70bxxq1Ue6HmZhMxaLf 92NvyYoe/v3MvKDZZ00Ny2Z/Oe95GpuerZd4f3X5/ZdGG87n6Fqkb5e++qBObVZX+d64UJX7 HJ35AgqbnE1ZIxzeZup/kT6+a9p8I+9PG+c+ZPp1+0jeJcbIg08Cqp8fa0r8XmTkvvtl59FJ Dk5msedZT/brJyqxFGckGmoxFxUnAgBevrd8eAIAAA== Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 15:45:18 -0000 Thanks! :-) -----Original Message----- From: Quintin Zhao [mailto:quintin.zhao@huawei.com]=20 Sent: Monday, June 24, 2013 11:40 AM To: Eric Gray; 'Loa Andersson' Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-nod= e-protection@tools.ietf.org Subject: RE: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Importance: High Eric, Thanks and here it is: > Are you aware of any IPR that applies to=20 > draft-wijnands-mpls-mldp-node-protection? I'm not aware of any IPR other than what Ice and Kamran have already mentio= ned. Quintin -----Original Message----- From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: 2013=1B$BG/=1B(B6=1B$B7n=1B(B24=1B$BF|=1B(B 11:19 To: Quintin Zhao; 'Loa Andersson' Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-nod= e-protection@tools.ietf.org Subject: RE: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Quintin, I am reasonably certain that this is an indirect response to the mail whic= h Eric Rosen sent which included the following: "> Are you aware of any IPR that applies to "> draft-wijnands-mpls-mldp-nod= e-protection? "I'm not aware of any IPR other than what Ice and Kamran have already menti= oned." Unfortunately, the text that you're agreeing to was not in the mail messag= e. Could you just re-affirm that you are saying that you are unaware of any I= PR beyond that which has been mentioned already? Thanks! -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Qui= ntin Zhao Sent: Monday, June 24, 2013 10:56 AM To: 'Loa Andersson' Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-nod= e-protection@tools.ietf.org Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Same here too. Regards, Quintin -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] Sent: 2013=1B$BG/=1B(B6=1B$B7n=1B(B24=1B$BF|=1B(B 10:31 To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-nod= e-protection@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); erosen@cisco.com Subject: Re: IPR Poll on draft-wijnands-mpls-mldp-node-protection Hi, Same here Regards, Jeff On Jun 24, 2013, at 4:19 PM, "Eric Rosen" wrote: >> draft-wijnands-mpls-mldp-node-protection? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Mon Jun 24 09:18:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8345F21F946C for ; Mon, 24 Jun 2013 09:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKtmB4-bKgPr for ; Mon, 24 Jun 2013 09:18:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64621F9446 for ; Mon, 24 Jun 2013 09:17:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASU63099; Mon, 24 Jun 2013 16:17: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.1.323.7; Mon, 24 Jun 2013 17:17:07 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 17:17:55 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 09:17:48 -0700 From: Huaimo Chen To: Lizhong Jin , Ross Callon Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHOcB28thOt3kgIPkCotNKnZ4jMnZlEyj7w Date: Mon, 24 Jun 2013 16:17:48 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.131] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4451E05FAdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , Raveendra Torvi , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 16:18:09 -0000 --_000_5316A0AB3C851246A7CA5758973207D4451E05FAdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Thanks much for your good comments and questions! My answers/explanations are inline below. Best Regards, Huaimo From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Liz= hong Jin Sent: Sunday, June 23, 2013 10:27 AM To: Ross Callon Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2mp-egress-protection@= tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi authors, I have been asked to review draft-chen-mpls-p2mp-egress-protection-09. Over= ally, there are some points that need to be discussed before WG adoption. A= nd I would appreciate if the authors could help to clarify. 1. If I understand the draft correctly, the primary and backup egress node = address should be two different address. But actually, the egress node is c= losely related with many customer service configurations (e.g, mvpn and p2m= p pw). Anycast address based protection has been proved to be an efficient = way for MVPN and other service over RSVP-TE P2MP. Then if anycast address i= s applied for egress node protection, FRR defined in RFC4090 could be reuse= d, right? Huaimo: It seems that anycast address based protection depends on IP routin= g. Thus the traffic interruption (or switch over) time will be much longer= when the primary egress fails since it relies on the IP routing convergenc= e. If it is applied for egress node protection, both the primary egress and= the backup egress should have a same anycast IP address, a CE should conne= ct to these two egresses and have a routing table entry with two items. One= item for the route (i.e., the anycast IP address) to the primary egress w= ith a smaller metric, the other for the route to the backup egress with a b= igger metric. Thus, the CE receives the traffic from the primary egress in = normal operations. When the primary egress fails, the route to the backup = egress becomes the best one after IP routing convergence and the CE switche= s to receive the traffic from the backup egress. In order for the CE to ge= t the traffic from the backup egress after the primary egress fails, the tr= affic should be sent to the backup egress before or when the primary egress= fails. A P2MP LSP with these two egresses (i.e., the primary egress and th= e backup egress as its normal two egresses) can send the traffic to both th= e primary egress and the backup egress at the same time. It seems that FRR = defined in RFC 4090 can not be reused directly here to switch the traffic t= o the backup egress from the primary egress when the primary egress fails. = Using the egress node protection proposed in the draft have two advantages = over the anycast address based protection. One is that the traffic interrup= tion (or switch over) time will be much shorter (tens of ms) when the prim= ary egress fails; the other is that the bandwidth used for sending the traf= fic to the backup egress is saved. Is my understanding of anycast based pr= otection consistent with yours? 2. section 7.2.2. I doubt if the facility proction could work in the egress= protection. The backup egress node does not know the P2MP lable allocated = by the primary egress node. And it is very likely that the P2MP lable recei= ved by backup egress node has already been allocated for other purpose. Or = is there any sychronization mechanism between primary and backup node. Huaimo: In some cases, there is no need for any label. For example, if the = second last hop label pop is enabled, the previous hop (or upstream) node o= f the primary egress does not need any P2MP LSP label from the backup egres= s. In the case that the previous hop (or upstream) node of the primary egre= ss needs a P2MP LSP label from the backup egress, there are a few of ways t= o get the label. One way is to let the previous hop (or upstream) node send= the object containing the backup egress to the primary egress, which "ext= ends" the P2MP LSP to the backup egress. It sends a path message to the bac= kup egress, gets a resv message with a P2MP LSP label from the backup egres= s and then sends a resv message with this label to the previous hop (or ups= tream) node. Note that the primary egress will not create any forwarding e= ntry with this label for sending the traffic to the backup egress. The prev= ious hop (or upstream) node can provide the primary egress node protection = using this label in a way similar to the one that it provides an intermedia= te node protection. We will address this in the next version of the draft. Regards Lizhong On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon > wrote: Ravi, Eric, Tarek, Lizhong; You have been selected as MPLS Review team reviewers for draft-chen-mpls-p2mp-egress-protection-09. 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 June 26, 2013? Thanks, Ross (as MPLS WG chair) --_000_5316A0AB3C851246A7CA5758973207D4451E05FAdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

 <= /p>

Thanks much for your good comments and questions!

My answers/explanations are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Sunday, June 23, 2013 10:27 AM
To: Ross Callon
Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2mp-egress-prot= ection@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi authors,

I have been asked to review draft-chen-mpls-p2mp-egr= ess-protection-09. Overally, there are some points that need to be discusse= d before WG adoption. And I would appreciate if the authors could help to c= larify.

 

1. If I underst= and the draft correctly, the primary and backup egress node address should&= nbsp;be two different address. But actually, the egress node is closel= y related with many customer service configurations (e.g, mvpn and p2mp pw). Anycast address based protection has been pr= oved to be an efficient way for MVPN and other service over RSVP-TE P2MP. T= hen if anycast address is applied for egress node protection, FRR defined i= n RFC4090 could be reused, right?

 

Huaimo: It seems that any= cast address based protection depends on IP routing. Thus the traffic inter= ruption (or switch over)  time will be much longer when the primary egress fails since it relies on the IP routing convergence. If= it is applied for egress node protection, both the primary egress and the = backup egress should have a same anycast IP address, a CE should connect to= these two egresses and have a routing table entry with two items. One item for the route (i.e., the anycast IP a= ddress) to the primary egress  with a smaller metric, the other for th= e route to the backup egress with a bigger metric. Thus, the CE receives th= e traffic from the primary egress in normal operations.  When the primary egress fails, the route to the b= ackup egress becomes the best one after IP routing convergence and the CE s= witches to receive the traffic from the backup egress.  In order for t= he CE to get the traffic from the backup egress after the primary egress fails, the traffic should be sent to the backup e= gress before or when the primary egress fails. A P2MP LSP with these two eg= resses (i.e., the primary egress and the backup egress as its normal two eg= resses) can send the traffic to both the primary egress and the backup egress at the same time. It seems t= hat FRR defined in RFC 4090 can not be reused directly here to switch the t= raffic to the backup egress from the primary egress when the primary egress= fails. Using the egress node protection proposed in the draft have two advantages over the anycast address based p= rotection. One is that the traffic interruption (or switch over)  time= will be much shorter (tens of ms) when the primary egress fails; the other= is that the bandwidth used for sending the traffic to the backup egress is saved.  Is my understanding of an= ycast based protection consistent with yours?

 <= /p>

2. section 7.2.2. I doubt if the facility proction c= ould work in the egress protection. The backup egress node does not know th= e P2MP lable allocated by the primary egress node. And it is very likely th= at the P2MP lable received by backup egress node has already been allocated for other purpose. Or is there any = sychronization mechanism between primary and backup node.

 

Huaimo: In some cases, th= ere is no need for any label. For example, if the second last hop label pop= is enabled, the previous hop (or upstream) node of the primary egress does not need any P2MP LSP label from the backup egress. In= the case that the previous hop (or upstream) node of the primary egress ne= eds a P2MP LSP label from the backup egress, there are a few of ways to get= the label. One way is to let the previous hop (or upstream) node send the object containing the backup egre= ss to the primary egress,  which “extends” the P2MP LSP to= the backup egress. It sends a path message to the backup egress, gets a re= sv message with a P2MP LSP label from the backup egress and then sends a resv message with this label to the previous hop (= or upstream) node.  Note that the primary egress will not create any f= orwarding entry with this label for sending the traffic to the backup egres= s. The previous hop (or upstream) node can provide the primary egress node protection using this label in a way s= imilar to the one that it provides an intermediate node protection. We will= address this in the next version of the draft.

 <= /p>

Regards

Lizhong

On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <rcallon@juniper.net<= /a>> wrote:

Ravi, Eric, Tarek, Li= zhong;

You have been selected as MPLS Review team reviewers for
draft-chen-mpls-p2mp-egress-protection-09.

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 June 26, 2013?

Thanks, Ross
(as MPLS WG chair)



 

--_000_5316A0AB3C851246A7CA5758973207D4451E05FAdfweml509mbxchi_-- From rtorvi@juniper.net Mon Jun 24 14:57:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9D21E8132 for ; Mon, 24 Jun 2013 14:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.534 X-Spam-Level: ** X-Spam-Status: No, score=2.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFTM4-BhWW5s for ; Mon, 24 Jun 2013 14:57:31 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id B3CC721E810C for ; Mon, 24 Jun 2013 14:57:29 -0700 (PDT) Received: from mail145-db8-R.bigfish.com (10.174.8.236) by DB8EHSOBE013.bigfish.com (10.174.4.76) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 21:57:28 +0000 Received: from mail145-db8 (localhost [127.0.0.1]) by mail145-db8-R.bigfish.com (Postfix) with ESMTP id 13FCA1E023C for ; Mon, 24 Jun 2013 21:57:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz98dI9371Ic85fhc3f2Iec9I4015I15c7mzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail145-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=rtorvi@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail145-db8 (localhost.localdomain [127.0.0.1]) by mail145-db8 (MessageSwitch) id 1372111046219969_3621; Mon, 24 Jun 2013 21:57:26 +0000 (UTC) Received: from DB8EHSMHS004.bigfish.com (unknown [10.174.8.250]) by mail145-db8.bigfish.com (Postfix) with ESMTP id 31AFF8004C for ; Mon, 24 Jun 2013 21:57:26 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by DB8EHSMHS004.bigfish.com (10.174.4.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Jun 2013 21:57:25 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 14:57:23 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 14:57:22 -0700 Received: from DB8EHSOBE012.bigfish.com (213.199.154.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 15:00:41 -0700 Received: from mail65-db8-R.bigfish.com (10.174.8.248) by DB8EHSOBE012.bigfish.com (10.174.4.75) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 21:57:20 +0000 Received: from mail65-db8 (localhost [127.0.0.1]) by mail65-db8-R.bigfish.com (Postfix) with ESMTP id 512266C0174 for ; Mon, 24 Jun 2013 21:57:20 +0000 (UTC) Received: from mail65-db8 (localhost.localdomain [127.0.0.1]) by mail65-db8 (MessageSwitch) id 1372111037170157_12267; Mon, 24 Jun 2013 21:57:17 +0000 (UTC) Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.251]) by mail65-db8.bigfish.com (Postfix) with ESMTP id 211DCCC0046; Mon, 24 Jun 2013 21:57:17 +0000 (UTC) Received: from BY2PRD0511HT002.namprd05.prod.outlook.com (157.56.237.149) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Jun 2013 21:57:16 +0000 Received: from BY2PRD0511MB416.namprd05.prod.outlook.com ([169.254.4.128]) by BY2PRD0511HT002.namprd05.prod.outlook.com ([10.255.129.37]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 21:57:13 +0000 From: Raveendra Torvi To: Huaimo Chen , Lizhong Jin , Ross Callon Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHOcB2wXhu7Ou41qUaE6SAXznaJBJlFDIAAgAACdVA= Date: Mon, 24 Jun 2013 21:57:12 +0000 Message-ID: <41AF8A5228F88746A65052DC6DE0739B1F66A298@BY2PRD0511MB416.namprd05.prod.outlook.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_41AF8A5228F88746A65052DC6DE0739B1F66A298BY2PRD0511MB416_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 21:57:45 -0000 --_000_41AF8A5228F88746A65052DC6DE0739B1F66A298BY2PRD0511MB416_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have finished first round of review of this draft. In short, WG should ex= plore use cases and see whether signaling procedure mentioned in the draft = are applicable in real world, before accepting this as WG draft. I do not= think this draft is readily usable. Following are some issues with draft: [1] Unlike other local protection this is an ingress driven, not PLR. In i= nter-domain scenario, ingress may not have the visibility of entire network= to figure out the complete primary path, not to mention the bypass path. [2] In the presence of loose-hops, this may also yield to wrong selection o= f PLR by ingress, as one may have several hops between ingress designated P= LR and protected PE. There is no indication from Egress to ingress that egr= ess is protected. [3] 1:1 relationship between primary egress and backup egress. This will be= scalability issues especially with ring topologies. This solution is NOT extensible to 1:N protection. [4] This draft does not address interoperability with 1:N protection.. [5] Local reversion does not work Consider following example: S2L 1 : I - PH1-PE- Primary S2L 1 Backup: I - PH3 - PE-Backup S2L 2: I - PH2 - PE-Other I----PH1--------PE-Primary || PH2--------PE-Other | PH3---------- PE Backup PH - PE link comes back, PH1 sends traffic PE Primary and how & when does P= H2 stop sending traffic to PH3? [6] According to Section 4.4, in order to detect PE-CE link down, this sol= ution needs a BFD session from a P router to CE device, which is a non-star= ter as P router may not have any state to reach CE, at least draft does not= go deep enough to explain this point. [7] This solution addresses P2MP LSPs only. The approach cannot be extended= to apply for P2P LSPs, in which case it must be ensured that the back egre= ss know how to handle inner label (i.e. service label). Regards Ravi From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Monday, June 24, 2013 12:18 PM To: Lizhong Jin; Ross Callon Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2mp-egress-protection@= tools.ietf.org; mpls-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi Lizhong, Thanks much for your good comments and questions! My answers/explanations are inline below. Best Regards, Huaimo From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Liz= hong Jin Sent: Sunday, June 23, 2013 10:27 AM To: Ross Callon Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2mp-egress-protection@= tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi authors, I have been asked to review draft-chen-mpls-p2mp-egress-protection-09. Over= ally, there are some points that need to be discussed before WG adoption. A= nd I would appreciate if the authors could help to clarify. 1. If I understand the draft correctly, the primary and backup egress node = address should be two different address. But actually, the egress node is c= losely related with many customer service configurations (e.g, mvpn and p2m= p pw). Anycast address based protection has been proved to be an efficient = way for MVPN and other service over RSVP-TE P2MP. Then if anycast address i= s applied for egress node protection, FRR defined in RFC4090 could be reuse= d, right? Huaimo: It seems that anycast address based protection depends on IP routin= g. Thus the traffic interruption (or switch over) time will be much longer= when the primary egress fails since it relies on the IP routing convergenc= e. If it is applied for egress node protection, both the primary egress and= the backup egress should have a same anycast IP address, a CE should conne= ct to these two egresses and have a routing table entry with two items. One= item for the route (i.e., the anycast IP address) to the primary egress w= ith a smaller metric, the other for the route to the backup egress with a b= igger metric. Thus, the CE receives the traffic from the primary egress in = normal operations. When the primary egress fails, the route to the backup = egress becomes the best one after IP routing convergence and the CE switche= s to receive the traffic from the backup egress. In order for the CE to ge= t the traffic from the backup egress after the primary egress fails, the tr= affic should be sent to the backup egress before or when the primary egress= fails. A P2MP LSP with these two egresses (i.e., the primary egress and th= e backup egress as its normal two egresses) can send the traffic to both th= e primary egress and the backup egress at the same time. It seems that FRR = defined in RFC 4090 can not be reused directly here to switch the traffic t= o the backup egress from the primary egress when the primary egress fails. = Using the egress node protection proposed in the draft have two advantages = over the anycast address based protection. One is that the traffic interrup= tion (or switch over) time will be much shorter (tens of ms) when the prim= ary egress fails; the other is that the bandwidth used for sending the traf= fic to the backup egress is saved. Is my understanding of anycast based pr= otection consistent with yours? 2. section 7.2.2. I doubt if the facility proction could work in the egress= protection. The backup egress node does not know the P2MP lable allocated = by the primary egress node. And it is very likely that the P2MP lable recei= ved by backup egress node has already been allocated for other purpose. Or = is there any sychronization mechanism between primary and backup node. Huaimo: In some cases, there is no need for any label. For example, if the = second last hop label pop is enabled, the previous hop (or upstream) node o= f the primary egress does not need any P2MP LSP label from the backup egres= s. In the case that the previous hop (or upstream) node of the primary egre= ss needs a P2MP LSP label from the backup egress, there are a few of ways t= o get the label. One way is to let the previous hop (or upstream) node send= the object containing the backup egress to the primary egress, which "ext= ends" the P2MP LSP to the backup egress. It sends a path message to the bac= kup egress, gets a resv message with a P2MP LSP label from the backup egres= s and then sends a resv message with this label to the previous hop (or ups= tream) node. Note that the primary egress will not create any forwarding e= ntry with this label for sending the traffic to the backup egress. The prev= ious hop (or upstream) node can provide the primary egress node protection = using this label in a way similar to the one that it provides an intermedia= te node protection. We will address this in the next version of the draft. Regards Lizhong On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon > wrote: Ravi, Eric, Tarek, Lizhong; You have been selected as MPLS Review team reviewers for draft-chen-mpls-p2mp-egress-protection-09. 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 June 26, 2013? Thanks, Ross (as MPLS WG chair) --_000_41AF8A5228F88746A65052DC6DE0739B1F66A298BY2PRD0511MB416_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have finished first rou= nd of review of this draft. In short, WG should explore use cases and see w= hether signaling procedure mentioned in the draft are applicable in real world, before accepting this as WG draft.   I do not thi= nk this draft is readily usable.

 <= /p>

Following are some issues= with draft:

 

[1] Unlike other local protection this is an ingress= driven, not PLR.  In inter-domain scenario, ingress may not have the = visibility of entire network to figure out the complete primary path, not t= o mention the bypass path.

 

[2] In the presence of loose-hops, this may also yie= ld to wrong selection of PLR by ingress, as one may have several hops betwe= en ingress designated PLR and protected PE. There is no indication from Egr= ess to ingress that egress is protected.

 

[3] 1:1 relationship between primary egress and back= up egress. This will be scalability issues especially with ring topologies.=  

   This solution is NOT extensible to= 1:N protection.

 

[4] This draft does not address interoperability wit= h 1:N protection..

 

[5] Local reversion does not work

  

 Consider following example:

 

S2L 1 :  I – PH1—PE- Primary

S2L 1 Backup:  I – PH3 – PE-Backup<= o:p>

S2L 2: I – PH2 – PE-Other

  

      I----PH1--------= PE-Primary

        &nbs= p;       ||

        &nbs= p;      PH2--------PE-Other

         &nb= sp;      |

        &nbs= p;      PH3---------- PE Backup

 

PH – PE link comes back, PH1 sends traffic PE = Primary and how & when does PH2 stop sending traffic to PH3?

 

[6] According to Section 4.4,  in order to dete= ct PE-CE link down, this solution needs a BFD session from a P router to CE= device, which is a non-starter as P router may not have any state to reach= CE, at least draft does not go deep enough to explain this point.

 <= /p>

[7] This solution addresses P2MP LSPs only. The appr= oach cannot be extended to apply for P2P LSPs, in which case it must be ens= ured that the back egress know how to handle inner label (i.e. service labe= l).

 

Regards

Ravi

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Monday, June 24, 2013 12:18 PM
To: Lizhong Jin; Ross Callon
Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2mp-egress-prot= ection@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi Lizhong,

 <= /p>

Thanks much for your good comments and questions!

My answers/explanations are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Sunday, June 23, 2013 10:27 AM
To: Ross Callon
Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2mp-egress-prot= ection@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi authors,

I have been asked to review draft-chen-mpls-p2mp-egr= ess-protection-09. Overally, there are some points that need to be discusse= d before WG adoption. And I would appreciate if the authors could help to c= larify.

 

1. If I underst= and the draft correctly, the primary and backup egress node address should&= nbsp;be two different address. But actually, the egress node is closel= y related with many customer service configurations (e.g, mvpn and p2mp pw). Anycast address based protection has been pr= oved to be an efficient way for MVPN and other service over RSVP-TE P2MP. T= hen if anycast address is applied for egress node protection, FRR defined i= n RFC4090 could be reused, right?

 

Huaimo: It seems that any= cast address based protection depends on IP routing. Thus the traffic inter= ruption (or switch over)  time will be much longer when the primary egress fails since it relies on the IP routing convergence. If= it is applied for egress node protection, both the primary egress and the = backup egress should have a same anycast IP address, a CE should connect to= these two egresses and have a routing table entry with two items. One item for the route (i.e., the anycast IP a= ddress) to the primary egress  with a smaller metric, the other for th= e route to the backup egress with a bigger metric. Thus, the CE receives th= e traffic from the primary egress in normal operations.  When the primary egress fails, the route to the b= ackup egress becomes the best one after IP routing convergence and the CE s= witches to receive the traffic from the backup egress.  In order for t= he CE to get the traffic from the backup egress after the primary egress fails, the traffic should be sent to the backup e= gress before or when the primary egress fails. A P2MP LSP with these two eg= resses (i.e., the primary egress and the backup egress as its normal two eg= resses) can send the traffic to both the primary egress and the backup egress at the same time. It seems t= hat FRR defined in RFC 4090 can not be reused directly here to switch the t= raffic to the backup egress from the primary egress when the primary egress= fails. Using the egress node protection proposed in the draft have two advantages over the anycast address based p= rotection. One is that the traffic interruption (or switch over)  time= will be much shorter (tens of ms) when the primary egress fails; the other= is that the bandwidth used for sending the traffic to the backup egress is saved.  Is my understanding of an= ycast based protection consistent with yours?

 <= /p>

2. section 7.2.2. I doubt if the facility proction c= ould work in the egress protection. The backup egress node does not know th= e P2MP lable allocated by the primary egress node. And it is very likely th= at the P2MP lable received by backup egress node has already been allocated for other purpose. Or is there any = sychronization mechanism between primary and backup node.

 

Huaimo: In some cases, th= ere is no need for any label. For example, if the second last hop label pop= is enabled, the previous hop (or upstream) node of the primary egress does not need any P2MP LSP label from the backup egress. In= the case that the previous hop (or upstream) node of the primary egress ne= eds a P2MP LSP label from the backup egress, there are a few of ways to get= the label. One way is to let the previous hop (or upstream) node send the object containing the backup egre= ss to the primary egress,  which “extends” the P2MP LSP to= the backup egress. It sends a path message to the backup egress, gets a re= sv message with a P2MP LSP label from the backup egress and then sends a resv message with this label to the previous hop (= or upstream) node.  Note that the primary egress will not create any f= orwarding entry with this label for sending the traffic to the backup egres= s. The previous hop (or upstream) node can provide the primary egress node protection using this label in a way s= imilar to the one that it provides an intermediate node protection. We will= address this in the next version of the draft.

 <= /p>

Regards

Lizhong

On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <rcallon@juniper.net<= /a>> wrote:

Ravi, Eric, Tarek, Li= zhong;

You have been selected as MPLS Review team reviewers for
draft-chen-mpls-p2mp-egress-protection-09.

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 June 26, 2013?

Thanks, Ross
(as MPLS WG chair)


 

--_000_41AF8A5228F88746A65052DC6DE0739B1F66A298BY2PRD0511MB416_-- From loa@pi.nu Tue Jun 25 02:49:50 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C1221F9FC4 for ; Tue, 25 Jun 2013 02:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WuwHZCdbk5y for ; Tue, 25 Jun 2013 02:49:45 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0A121F9F86 for ; Tue, 25 Jun 2013 02:49:45 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8719D1800272; Tue, 25 Jun 2013 11:49:43 +0200 (CEST) Message-ID: <51C967B9.2020205@pi.nu> Date: Tue, 25 Jun 2013 11:49:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Gray , Jeff Tantsura References: Your message of Sun, 23 Jun 2013 14:45:01 +0200. <51C6EDCD.6000403@pi.nu>, <4484.1372083555@erosen-linux> <65B72256-09E6-42FC-8D5F-1CFA1F8E275B@ericsson.com> <000001ce70ea$f4130b30$dc392190$@zhao@huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF60CA2F6@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF60CA2F6@eusaamb107.ericsson.se> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" , Quintin Zhao Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 09:49:50 -0000 Eric, tnx for this - actually Quitin's mail was in response to Jeff's mail that was in response to Eric's; so the same goes for Jeff. The text that included the statement on the IPR's in Eric mail was not in Jeff's either. Jeff, Can you please update the same way as Quintin did. /Loia On 2013-06-24 17:19, Eric Gray wrote: > Quintin, > > I am reasonably certain that this is an indirect response to the mail which > Eric Rosen sent which included the following: > > "> Are you aware of any IPR that applies to > "> draft-wijnands-mpls-mldp-node-protection? > > "I'm not aware of any IPR other than what Ice and Kamran have already mentioned." > > Unfortunately, the text that you're agreeing to was not in the mail message. > > Could you just re-affirm that you are saying that you are unaware of any IPR > beyond that which has been mentioned already? > > Thanks! > -- > Eric > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Quintin Zhao > Sent: Monday, June 24, 2013 10:56 AM > To: 'Loa Andersson' > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-node-protection@tools.ietf.org > Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection > > > Same here too. > > Regards, > > Quintin > > > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: 2013$BG/(B6$B7n(B24$BF|(B 10:31 > To: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-wijnands-mpls-mldp-node-protection@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); erosen@cisco.com > Subject: Re: IPR Poll on draft-wijnands-mpls-mldp-node-protection > > Hi, > > Same here > > Regards, > Jeff > > On Jun 24, 2013, at 4:19 PM, "Eric Rosen" wrote: > >>> draft-wijnands-mpls-mldp-node-protection? > > _______________________________________________ > 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 jeff.tantsura@ericsson.com Tue Jun 25 02:52:10 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB41521F9733 for ; Tue, 25 Jun 2013 02:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP-VAK1bV9as for ; Tue, 25 Jun 2013 02:52:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD7B21F9605 for ; Tue, 25 Jun 2013 02:52:05 -0700 (PDT) X-AuditID: c6180641-b7fba6d000003daf-54-51c968424ae1 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B9.D1.15791.24869C15; Tue, 25 Jun 2013 11:52:02 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 05:52:02 -0400 From: Jeff Tantsura To: Loa Andersson , Eric Gray Thread-Topic: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection Thread-Index: AQHOcOXOf6+/RWL8skC6smD0l7Qq+JlE7P52gAAGtCCAAEnygIABNkOA//+LTQA= Date: Tue, 25 Jun 2013 09:52:01 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748393BCA06@eusaamb109.ericsson.se> In-Reply-To: <51C967B9.2020205@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <7BC4E8BE7C888E4AA1531D5CA882F4F4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPiK5TxslAg8fPLS1+Tve1+Dd3DrPF 90tLWCxuLV3JanFiWq0Dq0fLkbesHkuW/GTymDW9jc3jy+XPbAEsUVw2Kak5mWWpRfp2CVwZ 11ZJFrwVr1j7dAdrA+Np4S5GTg4JAROJ5t0/2CFsMYkL99azdTFycQgJHGWU+HjlBQuEs5xR Ys+jRUwgVWwCBhL/vx1nAbFFBBwlLi5fD1bELNDIJLFy6z3mLkYODmEBD4nPa00hajwl5kzt hqr3k9j+/jQziM0ioCpxftdhRhCbV8Bb4vyNuawgNidQfOL/HWD1jEAXfT+1Bmwvs4C4xK0n 85kgLhWQWLLnPDOELSrx8vE/sF5RAT2JtmNnoL5RlljyZD8LRK++xJ6Jp6Bsa4mWuRegbG2J ZQtfM0PcIChxcuYTlgmM4rOQrJuFpH0WkvZZSNpnIWlfwMi6ipGjtDi1LDfdyHATIzAGj0mw Oe5gXPDJ8hCjNAeLkjjv+1O7AoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwsj/qCZAX+vA9 7cZlkV6lusRljYY1sr1B3oFywRc0bj8+opax6dMy9ta8o09XcFWenbrpxOSE9HP/VrmkHOj3 kGVbxG0ys+Jt+M59ATrFAoqx5dWCpg2L17h7OpxceNN2bwGrmxHHGZnuGIv9d56aPVun2JXm omo6TU5q7V+JgsPvfd/WMl5QYinOSDTUYi4qTgQAKc8FTY8CAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" , Quintin Zhao Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 09:52:11 -0000 Loa, I'm not aware of any IPR other than what Ice has already mentioned, sorry for the confusion. Cheers, Jeff -----Original Message----- From: Loa Andersson Date: Tuesday, June 25, 2013 2:49 AM To: Eric Gray , Jeff Tantsura Cc: Quintin Zhao , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-wijnands-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection >Eric, > >tnx for this - actually Quitin's mail was in response to Jeff's mail >that was in response to Eric's; so the same goes for Jeff. The text >that included the statement on the IPR's in Eric mail was not in Jeff's >either. > >Jeff, > >Can you please update the same way as Quintin did. > >/Loia > >On 2013-06-24 17:19, Eric Gray wrote: >> Quintin, >>=20 >> I am reasonably certain that this is an indirect response to the mail >>which >> Eric Rosen sent which included the following: >>=20 >> "> Are you aware of any IPR that applies to >> "> draft-wijnands-mpls-mldp-node-protection? >>=20 >> "I'm not aware of any IPR other than what Ice and Kamran have already >>mentioned." >>=20 >> Unfortunately, the text that you're agreeing to was not in the mail >>message. >>=20 >> Could you just re-affirm that you are saying that you are unaware of >>any IPR >> beyond that which has been mentioned already? >>=20 >> Thanks! >> -- >> Eric >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>Quintin Zhao >> Sent: Monday, June 24, 2013 10:56 AM >> To: 'Loa Andersson' >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; >>draft-wijnands-mpls-mldp-node-protection@tools.ietf.org >> Subject: Re: [mpls] IPR Poll on draft-wijnands-mpls-mldp-node-protection >>=20 >>=20 >> Same here too. >>=20 >> Regards, >>=20 >> Quintin >>=20 >>=20 >> -----Original Message----- >> From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >> Sent: 2013=1B$BG/=1B(B6=1B$B7n=1B(B24=1B$BF|=1B(B 10:31 >> To: Loa Andersson >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; >>draft-wijnands-mpls-mldp-node-protection@tools.ietf.org; VIGOUREUX, >>MARTIN (MARTIN); erosen@cisco.com >> Subject: Re: IPR Poll on draft-wijnands-mpls-mldp-node-protection >>=20 >> Hi, >>=20 >> Same here >>=20 >> Regards, >> Jeff >>=20 >> On Jun 24, 2013, at 4:19 PM, "Eric Rosen" wrote: >>=20 >>>> draft-wijnands-mpls-mldp-node-protection? >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=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 loa@pi.nu Tue Jun 25 03:44:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60B221F9D9C for ; Tue, 25 Jun 2013 03:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCKqQn1M0R9U for ; Tue, 25 Jun 2013 03:44:26 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1821F9C6D for ; Tue, 25 Jun 2013 03:44:25 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 388341800272; Tue, 25 Jun 2013 12:44:24 +0200 (CEST) Message-ID: <51C9748A.30802@pi.nu> Date: Tue, 25 Jun 2013 12:44:26 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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-targeted-mldp@tools.ietf.org Subject: [mpls] working group lst call on draft-ietf-mpls-targeted-mldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 10:44:31 -0000 Working Groups, PWE3 working group, Working Group, this is to start a two week Working Group last call on draft-ietf-mpls-targeted-mldp-02.txt. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and if you are happy with the document as is also indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPRs applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on July 9, 2013. /Loa for the 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 Tue Jun 25 05:26:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E967821E8063 for ; Tue, 25 Jun 2013 05:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju9it1v9gHEi for ; Tue, 25 Jun 2013 05:26:22 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7716E11E80EA for ; Tue, 25 Jun 2013 05:25:58 -0700 (PDT) Received: from [109.58.236.61] (109.58.236.61.bredband.tre.se [109.58.236.61]) (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 67FA81800272; Tue, 25 Jun 2013 14:25:56 +0200 (CEST) Message-ID: <51C98C55.6080608@pi.nu> Date: Tue, 25 Jun 2013 14:25:57 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" References: <51C9748A.30802@pi.nu> In-Reply-To: <51C9748A.30802@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-targeted-mldp@tools.ietf.org Subject: [mpls] Correction - Re: working group lst call on draft-ietf-mpls-targeted-mldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:26:28 -0000 WG, There is a cut and paste error from an earlier working group last call that we copied to the pwe3 wg. This one is for the mpls wg. It should say: Working Group, this is to start a two week Working Group last call on draft-ietf-mpls-targeted-mldp-02.txt. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and if you are happy with the document as is also indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPRs applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on July 9, 2013. /Loa for the wg co-chairs On 2013-06-25 12:44, Loa Andersson wrote: > Working Groups, > > PWE3 working group, > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-targeted-mldp-02.txt. > > Please send your comments to the mpls working group > mailing list (mpls@ietf.org). > > Please send both technical comments, and if you are happy > with the document as is also indications of support. > > There are no IPR claims against this draft. > > The co-authors have earlier stated that they are not aware > of any IPRs applicable to this draft. > > If anyone else in the working group are aware of IPRs claims against > this draft, the time to disclose that is now. > > This working group last call will end on July 9, 2013. > > /Loa > for the 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 adrian@olddog.co.uk Tue Jun 25 05:27:26 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0678F21F8EAE for ; Tue, 25 Jun 2013 05:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQyeoHT8e-zE for ; Tue, 25 Jun 2013 05:27:21 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id A4C0721F84AA for ; Tue, 25 Jun 2013 05:27:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5PCQp85016697; Tue, 25 Jun 2013 13:26:51 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5PCQmn8016637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 13:26:49 +0100 From: "Adrian Farrel" To: "'Ross Callon'" , References: <62CCD4C52ACDAD4481149BD5D8A72FD316CEA3B4@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316CEA3B4@CH1PRD0510MB355.namprd05.prod.outlook.com> Date: Tue, 25 Jun 2013 13:26:46 +0100 Message-ID: <0e9101ce719f$436a9400$ca3fbc00$@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: AQGmRi0gLtI3tW9YPga9z3+tVrbti5mWr32g Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] Request an early allocation of a UDP port for MPLS-in-UDP encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:27:26 -0000 Ross, This registry (http://www.iana.org/assignments/service-names-port-numbers) describes the allocation for User Ports... | User Ports | are assigned by IANA using the "IETF Review" process, the "IESG | Approval" process, or the "Expert Review" process, as per | [RFC6335]. There is no provision for early allocation on this registry, but you can apply for a user port under expert review. That is what you should do if you want a port before this document becomes an RFC. Please read RFC 6335 to see what information is required to support the expert review. Adrian > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: 21 June 2013 18:29 > To: iana@iana.org; adrian@olddog.co.uk > Cc: Xuxiaohu; mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: Request an early allocation of a UDP port for MPLS-in-UDP encapsulation > > IANA; > > We would like to request an early allocation of a UDP port for MPLS-in-UDP > encapsulation, as described in the email below and in the referenced Internet > Draft. My understanding of the process is that Adrian needs to approve this as AD > for the MPLS WG. > > Thanks, Ross > (as MPLS WG co-chair) > > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > Sent: Friday, June 21, 2013 6:13 AM > To: mpls-chairs@tools.ietf.org > Subject: Request an early allocation of an UDP port for MPLS-in-UDP > encapsulation > > Hi MPLS WG Chairs: > > We co-authors of draft-ietf-mpls-in-udp want to ask for an early allocation of an > UDP port from the User Ports Range according to RFC4020 and RFC6335 and > therefore request the MPLS wg chairs to initiate the procedures for this. > > The following is the information for an early allocation: > > Service Name : MPLS-in-UDP > Transport Protocol(s) : UDP > Assignee: Xiaohu Xu > Contact : Xiaohu Xu > Description : Encapsulate MPLS packets in UDP tunnels for load balancing > purpose. > Reference : draft-ietf-mpls-in-udp (MPLS wg document) > Motivation: The motivation and usage of MPLS-in-UDP is described in [draft-ietf- > mpls-in-udp]. The reason why using a port number in the Dynamic Ports range is > unsuitable is: some applications of MPLS-in-UDP (e.g., PWE3) don't have any > mechanism for announcing the dynamic port number. In addition, IP-layer > broadcast, multicast, or anycast communication would not be used in the > application of MPLS-in-UDP. > Port Number : a number from the User Ports range > > Best regards, > Xiaohu > > From lizho.jin@gmail.com Tue Jun 25 08:10:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F3B21F9DC0 for ; Tue, 25 Jun 2013 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2v3W3RCLn82 for ; Tue, 25 Jun 2013 08:10:36 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6DD21F9D64 for ; Tue, 25 Jun 2013 08:10:36 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so7283910qcx.40 for ; Tue, 25 Jun 2013 08:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q2QER1r5dRnFlMZZJyEVh3cW8EPMpjGl8+bGySaVThw=; b=P0IbP32GhfsurYE15azt4tcDrBuOtOrz6yyoyAR0jFuVoVIzMzzE+G2k28dto7NBIN hEtV8JkTv0yILYY7KgNrqMzrIoTY9MeRdi8g6PmtPytLKOKU/dsPamGHsVBI0OIrEUZ2 xiEWjjrEA0QJ09rdH9hgMXEW+x3saER6O82gpnIgzJL4bjLOtnX++686Gm4fUYoUkn3x cQQ6Licyd+sEtOWm6pHLFdGWnrDI8U1i+OL44C1rMeXQT9/OoBB+irmybUgRFG4pzIEZ SZT1X76VWQsLgcO/39bYErsllN43My8jqsx/QzESJBGnx1bMSd10cK5KyI60/L5M7bSz mxoQ== MIME-Version: 1.0 X-Received: by 10.229.78.213 with SMTP id m21mr5558926qck.55.1372173035776; Tue, 25 Jun 2013 08:10:35 -0700 (PDT) Received: by 10.49.65.35 with HTTP; Tue, 25 Jun 2013 08:10:35 -0700 (PDT) In-Reply-To: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> Date: Tue, 25 Jun 2013 23:10:35 +0800 Message-ID: From: Lizhong Jin To: Huaimo Chen Content-Type: multipart/alternative; boundary=485b3918ade45e3a5f04dffbee91 Cc: Ross Callon , "mpls@ietf.org" , Raveendra Torvi , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 15:10:38 -0000 --485b3918ade45e3a5f04dffbee91 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Huaimo, Please see inline below. Regards Lizhong On Tue, Jun 25, 2013 at 12:17 AM, Huaimo Chen wrote= : > Hi Lizhong,**** > > ** ** > > Thanks much for your good comments and questions!**** > > My answers/explanations are inline below.**** > > ** ** > > Best Regards,**** > > Huaimo**** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Lizhong Jin > *Sent:* Sunday, June 23, 2013 10:27 AM > *To:* Ross Callon > *Cc:* mpls@ietf.org; Raveendra Torvi; > draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; > mpls-chairs@tools.ietf.org > *Subject:* Re: [mpls] MPLS-RT review of > draft-chen-mpls-p2mp-egress-protection**** > > ** ** > > Hi authors,**** > > I have been asked to review draft-chen-mpls-p2mp-egress-protection-09. > Overally, there are some points that need to be discussed before WG > adoption. And I would appreciate if the authors could help to clarify.***= * > > **** > > 1. If I understand the draft correctly, the primary and backup egress > node address should be two different address. But actually, the egress no= de > is closely related with many customer service configurations (e.g, mvpn a= nd > p2mp pw). Anycast address based protection has been proved to be an > efficient way for MVPN and other service over RSVP-TE P2MP. Then if anyca= st > address is applied for egress node protection, FRR defined in RFC4090 cou= ld > be reused, right? **** > > ** ** > > Huaimo: It seems that anycast address based protection depends on IP > routing. Thus the traffic interruption (or switch over) time will be muc= h > longer when the primary egress fails since it relies on the IP routing > convergence. If it is applied for egress node protection, both the primar= y > egress and the backup egress should have a same anycast IP address, a CE > should connect to these two egresses and have a routing table entry with > two items. One item for the route (i.e., the anycast IP address) to the > primary egress with a smaller metric, the other for the route to the > backup egress with a bigger metric. Thus, the CE receives the traffic fro= m > the primary egress in normal operations. When the primary egress fails, > the route to the backup egress becomes the best one after IP routing > convergence and the CE switches to receive the traffic from the backup > egress. In order for the CE to get the traffic from the backup egress > after the primary egress fails, the traffic should be sent to the backup > egress before or when the primary egress fails. A P2MP LSP with these two > egresses (i.e., the primary egress and the backup egress as its normal tw= o > egresses) can send the traffic to both the primary egress and the backup > egress at the same time. It seems that FRR defined in RFC 4090 can not be > reused directly here to switch the traffic to the backup egress from the > primary egress when the primary egress fails. Using the egress node > protection proposed in the draft have two advantages over the anycast > address based protection. One is that the traffic interruption (or switch > over) time will be much shorter (tens of ms) when the primary egress > fails; the other is that the bandwidth used for sending the traffic to th= e > backup egress is saved. Is my understanding of anycast based protection > consistent with yours? > [Lizhong] After more consideration, let me explain my understanding in detail. The previous node will see the primary and backup egress as one egress node with the anycast address. Since there is one egress node for the previous node, then FRR defined in RFC4090 could be reused. But there should be some synchronization mechanism between primary and backup egress, to negotiate a common label that could be used by both primary and backup egress. That could be potentially achieved by MP-BGP. The switching time and BW usage would be the same as FRR. Using anycast address would ease the implementation of the client service (e.g mvpn). > **** > > ** ** > > 2. section 7.2.2. I doubt if the facility proction could work in the > egress protection. The backup egress node does not know the P2MP lable > allocated by the primary egress node. And it is very likely that the P2MP > lable received by backup egress node has already been allocated for other > purpose. Or is there any sychronization mechanism between primary and > backup node.**** > > **** > > Huaimo: In some cases, there is no need for any label. For example, if th= e > second last hop label pop is enabled, the previous hop (or upstream) node > of the primary egress does not need any P2MP LSP label from the backup > egress. In the case that the previous hop (or upstream) node of the prima= ry > egress needs a P2MP LSP label from the backup egress, there are a few of > ways to get the label. One way is to let the previous hop (or upstream) > node send the object containing the backup egress to the primary egress, > which =93extends=94 the P2MP LSP to the backup egress. It sends a path m= essage > to the backup egress, gets a resv message with a P2MP LSP label from the > backup egress and then sends a resv message with this label to the previo= us > hop (or upstream) node. Note that the primary egress will not create any > forwarding entry with this label for sending the traffic to the backup > egress. The previous hop (or upstream) node can provide the primary egres= s > node protection using this label in a way similar to the one that it > provides an intermediate node protection. We will address this in the nex= t > version of the draft. > [Lizhong] But why do you think there is a link between the primary and backup egress? What if there is no directly connection between the two? > **** > > ** ** > > Regards**** > > Lizhong**** > > On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon wrote= : > **** > > Ravi, Eric, Tarek, Lizhong; > > You have been selected as MPLS Review team reviewers for > draft-chen-mpls-p2mp-egress-protection-09. > > 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 June 26, 2013? > > Thanks, Ross > (as MPLS WG chair) > > > > **** > > ** ** > --485b3918ade45e3a5f04dffbee91 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Huaimo,
Please see inline below.
=A0
Regards
Lizhong

On Tue, Jun 25, 2013 at 12:17 AM, Huaimo Chen <huaimo.chen@huawei.com> wrote:

Hi Lizhong,

=A0

Thank= s much for your good comments and questions!

My an= swers/explanations are inline below.

=A0

Best Regards,

Huaimo

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.= org] On Behalf Of Lizhong Jin
Sent: Sunday, June 23, 2013 10:27 AM
To: Ross Callon
Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p2mp-egress-protection= @tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

=A0

Hi authors,

I have been asked to review draft-chen-mpls-p2mp-egr= ess-protection-09. Overally, there are some points that need to be discusse= d before WG adoption. And I would appreciate if the authors could help to c= larify.

=A0

1. If I underst= and the draft correctly, the primary and backup egress node address should= =A0be two different=A0address. But actually, the egress node is closely rel= ated with many customer service=A0configurations (e.g, mvpn and p2mp pw).= =A0Anycast address based protection has been proved to be an efficient way = for MVPN and other service over RSVP-TE P2MP. Then if anycast address is ap= plied for egress node protection, FRR defined in RFC4090 could be reused, r= ight?

=A0

Huaimo: It seems that anycast a= ddress based protection depends on IP routing. Thus the traffic interruptio= n (or switch over) =A0time will be much longer when the primary egress fail= s since it relies on the IP routing convergence. If it is applied for egres= s node protection, both the primary egress and the backup egress should hav= e a same anycast IP address, a CE should connect to these two egresses and = have a routing table entry with two items. One item for the route (i.e., th= e anycast IP address) to the primary egress =A0with a smaller metric, the o= ther for the route to the backup egress with a bigger metric. Thus, the CE = receives the traffic from the primary egress in normal operations. =A0When = the primary egress fails, the route to the backup egress becomes the best o= ne after IP routing convergence and the CE switches to receive the traffic = from the backup egress. =A0In order for the CE to get the traffic from the = backup egress after the primary egress fails, the traffic should be sent to= the backup egress before or when the primary egress fails. A P2MP LSP with= these two egresses (i.e., the primary egress and the backup egress as its = normal two egresses) can send the traffic to both the primary egress and th= e backup egress at the same time. It seems that FRR defined in RFC 4090 can= not be reused directly here to switch the traffic to the backup egress fro= m the primary egress when the primary egress fails. Using the egress node p= rotection proposed in the draft have two advantages over the anycast addres= s based protection. One is that the traffic interruption (or switch over) = =A0time will be much shorter (tens of ms) when the primary egress fails; th= e other is that the bandwidth used for sending the traffic to the backup eg= ress is saved. =A0Is my understanding of anycast based protection consisten= t with yours?

[Lizhong] After more consideration, let me explain my understanding in= detail. The previous node will see the primary and backup egress as one eg= ress node with the anycast address. Since there is one egress node for the = previous node, then FRR defined in RFC4090 could be reused.=A0But there sho= uld be some synchronization mechanism between primary and backup egress, to= negotiate a common=A0label that could be used by both primary and backup e= gress. That could be potentially achieved by MP-BGP. The switching time and= BW usage would be the same as FRR. Using anycast address would ease the im= plementation of the client service (e.g mvpn).
=A0

=A0

2. section 7.2.2. I doubt if the facility proction c= ould work in the egress protection. The backup egress node does not know th= e P2MP lable allocated by the primary egress node. And it is very likely th= at the P2MP lable received by backup egress node has already been allocated= for other purpose. Or is there any sychronization mechanism between primar= y and backup node.

=A0

Huaimo: In some cases, there is= no need for any label. For example, if the second last hop label pop is en= abled, the previous hop (or upstream) node of the primary egress does not n= eed any P2MP LSP label from the backup egress. In the case that the previou= s hop (or upstream) node of the primary egress needs a P2MP LSP label from = the backup egress, there are a few of ways to get the label. One way is to = let the previous hop (or upstream) node send the object containing the back= up egress to the primary egress, =A0which =93extends=94 the P2MP LSP to the= backup egress. It sends a path message to the backup egress, gets a resv m= essage with a P2MP LSP label from the backup egress and then sends a resv m= essage with this label to the previous hop (or upstream) node. =A0Note that= the primary egress will not create any forwarding entry with this label fo= r sending the traffic to the backup egress. The previous hop (or upstream) = node can provide the primary egress node protection using this label in a w= ay similar to the one that it provides an intermediate node protection. We = will address this in the next version of the draft.

[Lizhong] But why do you think there is a link between the primary and= backup egress? What if there is no directly connection between the two?
=A0

=A0

Regards

Lizhong

On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <rcallon@juniper.net<= /a>> wrote:

Ravi, Eric, Tarek, Lizh= ong;

You have been selected as MPLS Review team reviewers for
dra= ft-chen-mpls-p2mp-egress-protection-09.

Note to authors: You have be= en CC'd on this email so that you can know
that this review is going on. However, please do not review your own
doc= ument.

Reviews should comment on whether the document is coherent, i= s it
useful (ie, is it likely to be actually useful in operational
networks), and is the document technically sound? =A0Also, is the text
a= nd grammar understandable (it doesn't need to be perfect at this
poi= nt, but should be reasonably clear). We are interested in knowing
whethe= r 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
st= art).

Reviews should be sent to the document authors, WG co-chairs a= nd
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 t= o review this draft by June 26, 2013?

Thanks, Ross
(as MPLS WG ch= air)



=A0

<= /blockquote>

--485b3918ade45e3a5f04dffbee91-- From huaimo.chen@huawei.com Thu Jun 27 16:31:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECECA11E8127 for ; Thu, 27 Jun 2013 16:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2AI2cSjq87U for ; Thu, 27 Jun 2013 16:31:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2033C11E8115 for ; Thu, 27 Jun 2013 16:31:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUL84150; Thu, 27 Jun 2013 23:31:19 +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.1.323.7; Fri, 28 Jun 2013 00:30:21 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 00:31:18 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Thu, 27 Jun 2013 16:31:13 -0700 From: Huaimo Chen To: Lizhong Jin Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHOcB28thOt3kgIPkCotNKnZ4jMnZlEyj7wgAI3KICAAteHsA== Date: Thu, 27 Jun 2013 23:31:13 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.169] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4451E102Ddfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ross Callon , "mpls@ietf.org" , Raveendra Torvi , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 23:31:29 -0000 --_000_5316A0AB3C851246A7CA5758973207D4451E102Ddfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Thanks much for your second round comments! My responses are inline below. Best Regards, Huaimo From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Lizhong Jin Sent: Sunday, June 23, 2013 10:27 AM To: Ross Callon Cc: mpls@ietf.org; Raveendra Torvi; draft-chen-mpls-p= 2mp-egress-protection@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n Hi authors, I have been asked to review draft-chen-mpls-p2mp-egress-protection-09. Over= ally, there are some points that need to be discussed before WG adoption. A= nd I would appreciate if the authors could help to clarify. 1. If I understand the draft correctly, the primary and backup egress node = address should be two different address. But actually, the egress node is c= losely related with many customer service configurations (e.g, mvpn and p2m= p pw). Anycast address based protection has been proved to be an efficient = way for MVPN and other service over RSVP-TE P2MP. Then if anycast address i= s applied for egress node protection, FRR defined in RFC4090 could be reuse= d, right? Huaimo: It seems that anycast address based protection depends on IP routin= g. Thus the traffic interruption (or switch over) time will be much longer= when the primary egress fails since it relies on the IP routing convergenc= e. If it is applied for egress node protection, both the primary egress and= the backup egress should have a same anycast IP address, a CE should conne= ct to these two egresses and have a routing table entry with two items. One= item for the route (i.e., the anycast IP address) to the primary egress w= ith a smaller metric, the other for the route to the backup egress with a b= igger metric. Thus, the CE receives the traffic from the primary egress in = normal operations. When the primary egress fails, the route to the backup = egress becomes the best one after IP routing convergence and the CE switche= s to receive the traffic from the backup egress. In order for the CE to ge= t the traffic from the backup egress after the primary egress fails, the tr= affic should be sent to the backup egress before or when the primary egress= fails. A P2MP LSP with these two egresses (i.e., the primary egress and th= e backup egress as its normal two egresses) can send the traffic to both th= e primary egress and the backup egress at the same time. It seems that FRR = defined in RFC 4090 can not be reused directly here to switch the traffic t= o the backup egress from the primary egress when the primary egress fails. = Using the egress node protection proposed in the draft have two advantages = over the anycast address based protection. One is that the traffic interrup= tion (or switch over) time will be much shorter (tens of ms) when the prim= ary egress fails; the other is that the bandwidth used for sending the traf= fic to the backup egress is saved. Is my understanding of anycast based pr= otection consistent with yours? [Lizhong] After more consideration, let me explain my understanding in deta= il. The previous node will see the primary and backup egress as one egress = node with the anycast address. Since there is one egress node for the previ= ous node, then FRR defined in RFC4090 could be reused. But there should be = some synchronization mechanism between primary and backup egress, to negoti= ate a common label that could be used by both primary and backup egress. Th= at could be potentially achieved by MP-BGP. The switching time and BW usage= would be the same as FRR. Using anycast address would ease the implementat= ion of the client service (e.g mvpn). [Huaimo] Physically the primary egress node and the backup egress node are = two different nodes even though they have a same anycast address. To protec= t the primary egress node of a primary (P2MP or P2P) LSP, the previous hop = (or upstream) node of the primary egress node needs to create a backup LSP = to the backup egress node (i.e., the physical backup egress node, which is = different from the physical primary egress node). Since there is not any p= rimary LSP path segment after the primary egress node, the FRR defined in R= FC4090 could not be reused directly. In order to use the FRR defined in RFC= 4090 for protecting a node B, the previous hop (or upstream) node (say node= A) of the node B needs to create a backup LSP that intersects the primary = LSP somewhere downstream of the node B. See the following descriptions from= RFC4090: In section 3.1 One-to-One Backup, "In the one-to-one backup method, a l= abel-switched path is established that intersects the original LSP somewher= e downstream of the point of link or node failure. ... " In section 3.2 Facility Backup, the second paragraph: "The bypass tunnel mu= st intersect the path of the original LSP(s) somewhere downstream of the PL= R. ... " In the case that the node B is the primary egress node, node A (i.e., the p= revious hop/upstream node of the primary egress node) can not create any ba= ckup LSP intersecting the primary LSP somewhere downstream of the node B (i= .e., the primary egress node). There is not any primary LSP after the node = B (i.e., the primary egress node). To protect the primary egress node of a primary LSP, some special protocol = extensions are needed. The objective of this draft is to define these speci= al extensions. Regarding to the service label, it seems out scope of this draft. The servi= ce label such as VPN label should be handled by others such as BGP. We will= provide some descriptions about this in details in the next version of the= draft. In the client side, using anycast address may be easier. The egress node p= rotection in the core side should work with the anycast address protection = in the client side. We will address this in the next version of the draft. 2. section 7.2.2. I doubt if the facility proction could work in the egress= protection. The backup egress node does not know the P2MP lable allocated = by the primary egress node. And it is very likely that the P2MP lable recei= ved by backup egress node has already been allocated for other purpose. Or = is there any sychronization mechanism between primary and backup node. Huaimo: In some cases, there is no need for any label. For example, if the = second last hop label pop is enabled, the previous hop (or upstream) node o= f the primary egress does not need any P2MP LSP label from the backup egres= s. In the case that the previous hop (or upstream) node of the primary egre= ss needs a P2MP LSP label from the backup egress, there are a few of ways t= o get the label. One way is to let the previous hop (or upstream) node send= the object containing the backup egress to the primary egress, which "ext= ends" the P2MP LSP to the backup egress. It sends a path message to the bac= kup egress, gets a resv message with a P2MP LSP label from the backup egres= s and then sends a resv message with this label to the previous hop (or ups= tream) node. Note that the primary egress will not create any forwarding e= ntry with this label for sending the traffic to the backup egress. The prev= ious hop (or upstream) node can provide the primary egress node protection = using this label in a way similar to the one that it provides an intermedia= te node protection. We will address this in the next version of the draft. [Lizhong] But why do you think there is a link between the primary and back= up egress? What if there is no directly connection between the two? [Huaimo] We can have another way for the previous hop (or upstream) node of= the primary egress to get the label from the backup egress node. The previ= ous hop (or upstream) node may "extend" the P2MP LSP to the backup egress. = It sends a path message to the backup egress, gets a resv message with a P2= MP LSP label from the backup egress and then provides the primary egress no= de protection using this label. Note that the previous hop (or upstream) n= ode will not create any forwarding entry with this label for sending the tr= affic to the backup egress. We may call the LSP (segment) extended from the= primary LSP an empty primary LSP since it will not transport any traffic. The first way requires that there be a link between the primary egress and = the backup egress. The second way does not have this requirement. The first= way may reuse the existing FRR procedures more. The figures below show som= e details about these two ways. The first way: Link **** Primary LSP $ ---- Backup LSP $ [R2]****[R3]*****[L1] Empty Primary LSP $ * \ *)$ $ *) * \ *)$ $[CE1] *) * \ *)$ $ *) * \__[La] * [R1]****[R4]***[R5]*****[L2] $ \ *)$ $ $ \ *)$ $[CE2] [S] \ *)$ $ \__[Lb] Link between primary egress (L1) and backup egress (La) is required Primary egress (L1) signals empty primary LSP to backup egress (La) Previous hop (R3) reuses FRR to protect primary egress (L1) The second way: Link **** Primary LSP $ ---- Backup LSP $ [R2]****[R3]*****[L1] Empty Primary LSP $ * *)\ $ *) * *)\ $[CE1] *) * *)\ $ *) * *)\__[La] * [R1]****[R4]***[R5]*****[L2] $ *)\ $ $ *)\ $[CE2] [S] *)\ $ *)\__[Lb] Previous hop (R3) signals empty primary LSP to backup egress (La) Previous hop (R3) uses a bypass LSP to protect primary egress (L1) Regards Lizhong On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon > wrote: Ravi, Eric, Tarek, Lizhong; You have been selected as MPLS Review team reviewers for draft-chen-mpls-p2mp-egress-protection-09. 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 June 26, 2013? Thanks, Ross (as MPLS WG chair) --_000_5316A0AB3C851246A7CA5758973207D4451E102Ddfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

 <= /p>

    Thanks= much for your second round comments!

My responses are inline below.

 

Best Regards,

Huaimo

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Sunday, June 23, 2013 10:27 AM
To: Ross Callon
Cc: mpls@ietf.org= ; Raveendra Torvi; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

Hi authors,

I have been asked to review draft-chen-mpls-p2mp-egress-protection= -09. Overally, there are some points that need to be discussed before WG ad= option. And I would appreciate if the authors could help to clarify.

 

1. If I understand the draft correctly, the primary and backup egress n= ode address should be two different address. But actually, the eg= ress node is closely related with many customer service configurations= (e.g, mvpn and p2mp pw). Anycast address based protection has been proved to be an efficient way for MVPN and other servi= ce over RSVP-TE P2MP. Then if anycast address is applied for egress node pr= otection, FRR defined in RFC4090 could be reused, right?

 

Huaimo: It seems that anycast address b= ased protection depends on IP routing. Thus the traffic interruption (or switch over)  time will be much longer when the primary egress fa= ils since it relies on the IP routing convergence. If it is applied for egr= ess node protection, both the primary egress and the backup egress should h= ave a same anycast IP address, a CE should connect to these two egresses and have a routing table entry with two item= s. One item for the route (i.e., the anycast IP address) to the primary egr= ess  with a smaller metric, the other for the route to the backup egre= ss with a bigger metric. Thus, the CE receives the traffic from the primary egress in normal operations.  W= hen the primary egress fails, the route to the backup egress becomes the be= st one after IP routing convergence and the CE switches to receive the traf= fic from the backup egress.  In order for the CE to get the traffic from the backup egress after the primary egr= ess fails, the traffic should be sent to the backup egress before or when t= he primary egress fails. A P2MP LSP with these two egresses (i.e., the prim= ary egress and the backup egress as its normal two egresses) can send the traffic to both the primary egres= s and the backup egress at the same time. It seems that FRR defined in RFC = 4090 can not be reused directly here to switch the traffic to the backup eg= ress from the primary egress when the primary egress fails. Using the egress node protection proposed in the= draft have two advantages over the anycast address based protection. One i= s that the traffic interruption (or switch over)  time will be much sh= orter (tens of ms) when the primary egress fails; the other is that the bandwidth used for sending the traffic to the= backup egress is saved.  Is my understanding of anycast based protect= ion consistent with yours?

[Lizhong] After more consideration, let me explain m= y understanding in detail. The previous node will see the primary and backu= p egress as one egress node with the anycast address. Since there is one eg= ress node for the previous node, then FRR defined in RFC4090 could be reused. But there should be some sync= hronization mechanism between primary and backup egress, to negotiate a com= mon label that could be used by both primary and backup egress. That c= ould be potentially achieved by MP-BGP. The switching time and BW usage would be the same as FRR. Using anycast addres= s would ease the implementation of the client service (e.g mvpn).

 

[Huaimo] Physically the p= rimary egress node and the backup egress node are two different nodes even = though they have a same anycast address. To protect the primary egress node of a primary (P2MP or P2P) LSP, the previous hop (or u= pstream) node of the primary egress node needs to create a backup LSP to th= e backup egress node (i.e., the physical backup egress node, which is diffe= rent from the physical primary egress node).  Since there is not any primary LSP path segment after the pri= mary egress node, the FRR defined in RFC4090 could not be reused directly. = In order to use the FRR defined in RFC4090 for protecting a node B, the pre= vious hop (or upstream) node (say node A) of the node B needs to create a backup LSP that intersects the primary = LSP somewhere downstream of the node B. See the foll= owing descriptions from RFC4090:

    In sec= tion 3.1 One-to-One Backup, “In the one-to-one backup method, a label= -switched path is established that intersects the original LSP somewhere do= wnstream of the point of link or node failure. … “

In section 3.2 Facility Backup, the second paragraph: “The bypass = tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR. … “

In the case that the node B is the primary egress node, node A (i.e., th= e previous hop/upstream node of the primary egress node) can not create any backup LSP intersecting the primary LSP somewhere downstrea= m of the node B (i.e., the primary egress node). There is not any primary L= SP after the node B (i.e., the primary egress node).

To protect the primary egress node of a primary LSP, some special protoc= ol extensions are needed. The objective of this draft is to define these special extensions.

Regarding to the service label, it seems out scope of this draft. The se= rvice label such as VPN label should be handled by others such as BGP. We will provide some descriptions about this in details in th= e next version of the draft.

In the client side, using anycast address may be easier.  The egres= s node protection in the core side should work with the anycast address protection in the client side. We will address this in the next ve= rsion of the draft.

 

2. section 7.2.2. I doubt if the facility proction could work in t= he egress protection. The backup egress node does not know the P2MP lable a= llocated by the primary egress node. And it is very likely that the P2MP lable received by backup egress node h= as already been allocated for other purpose. Or is there any sychronization= mechanism between primary and backup node.

 

Huaimo: In some cases, there is no need= for any label. For example, if the second last hop label pop is enabled, the previous hop (or upstream) node of the primary egress = does not need any P2MP LSP label from the backup egress. In the case that t= he previous hop (or upstream) node of the primary egress needs a P2MP LSP l= abel from the backup egress, there are a few of ways to get the label. One way is to let the previous hop (or= upstream) node send the object containing the backup egress to the primary= egress,  which “extends” the P2MP LSP to the backup egres= s. It sends a path message to the backup egress, gets a resv message with a P2MP LSP label from the backup egress and then = sends a resv message with this label to the previous hop (or upstream) node= .  Note that the primary egress will not create any forwarding entry w= ith this label for sending the traffic to the backup egress. The previous hop (or upstream) node can provide the = primary egress node protection using this label in a way similar to the one= that it provides an intermediate node protection. We will address this in = the next version of the draft.

[Lizhong] But why do you think there is a link betwe= en the primary and backup egress? What if there is no directly connection b= etween the two?

 

[Huaimo] We can have anot= her way for the previous hop (or upstream) node of the primary egress to ge= t the label from the backup egress node. The previous hop (or upstream) node may "extend" the P2MP LSP to the backup egres= s. It sends a path message to the backup egress, gets a resv message with a= P2MP LSP label from the backup egress and then provides the primary egress= node protection using this label.  Note that the previous hop (or upstream) node will not create any forwarding entry w= ith this label for sending the traffic to the backup egress. We may call th= e LSP (segment) extended from the primary LSP an empty primary LSP since it= will not transport any traffic.

The first way requires th= at there be a link between the primary egress and the backup egress. The se= cond way does not have this requirement. The first way may reuse the existing FRR procedures more. The figures below show some detail= s about these two ways.

 

The first way:

 

  &= nbsp;  Link          = ;            &n= bsp;            = ;    **** Primary LSP

     $       &nbs= p;            &= nbsp;           &nbs= p;         ---- Backup LSP

    $         [R2= ]****[R3]*****[L1]         &nb= sp;   Empty Primary LSP

   $          *&n= bsp;         \   &nb= sp; *)$  $          =   *)

            =  *            \=     *)$    $[CE1]     *)<= o:p>

            *&nbs= p;             = \   *)$  $        &n= bsp;   *)

           * &nbs= p;            &= nbsp; \__[La]

          *

       [R1]****[R4]***[R5]*****[L2]

      $      = ;            \ =     *)$  $   

     $       = ;             \=     *)$    $[CE2]

  [S]          &n= bsp;           \ &nb= sp; *)$  $

            =             &nb= sp;   \__[Lb]

 

Link between primary egress (L1) and backup egress (La) is required=

Primary egress (L1) signals empty primary LSP to backup egress (La)=

Previous hop (R3) reuses FRR to protect primary egress (L1)

 

 

The second way:

 

     Link       &= nbsp;           &nbs= p;            &= nbsp;      **** Primary LSP

     $       &nbs= p;            &= nbsp;           &nbs= p;         ---- Backup LSP

    $         [R2= ]****[R3]*****[L1]         &nb= sp;   Empty Primary LSP

   $         = ; *        *)\    &n= bsp;     $       &nb= sp;    *)

            =  *          *)\ &nbs= p;         $[CE1]   =   *)

            *&nbs= p;           *)\ &nb= sp;      $      &nbs= p;     *)

           * &nbs= p;            *)\__[= La]

          *

       [R1]****[R4]***[R5]*****[L2]

      $      = ;          *)\  &nbs= p;       $   

     $       = ;           *)\ &nbs= p;         $[CE2]=

  [S]          &n= bsp;         *)\    =     $

            =             &nb= sp; *)\__[Lb]

 

 

Previous hop (R3) signals empty primary LSP to backup egress (La)

Previous hop (R3) uses a bypass LSP to protect primary egress (L1)<= /o:p>

    

 

Regards

Lizhong

On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <rcallon@juniper.net> wrote:=

Ravi, Eric, Tarek, Lizhong;

You have been selected as MPLS Review team reviewers for
draft-chen-mpls-p2mp-egress-protection-09.

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 June 26, 2013?

Thanks, Ross
(as MPLS WG chair)


 

 

--_000_5316A0AB3C851246A7CA5758973207D4451E102Ddfweml509mbxchi_-- From huaimo.chen@huawei.com Thu Jun 27 18:58:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724B811E8111 for ; Thu, 27 Jun 2013 18:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4S0g9NrR7rQ for ; Thu, 27 Jun 2013 18:58:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4821F9BF4 for ; Thu, 27 Jun 2013 18:58:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUL90249; Fri, 28 Jun 2013 01:58:15 +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.1.323.7; Fri, 28 Jun 2013 02:57:16 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 02:58:13 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Thu, 27 Jun 2013 18:58:08 -0700 From: Huaimo Chen To: Raveendra Torvi , Ross Callon Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHOcB28thOt3kgIPkCotNKnZ4jMnZlEyj7wgAEWbgCABFw5kA== Date: Fri, 28 Jun 2013 01:58:06 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451E109B@dfweml509-mbx.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <41AF8A5228F88746A65052DC6DE0739B1F66A298@BY2PRD0511MB416.namprd05.prod.outlook.com> In-Reply-To: <41AF8A5228F88746A65052DC6DE0739B1F66A298@BY2PRD0511MB416.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.169] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4451E109Bdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 01:58:24 -0000 --_000_5316A0AB3C851246A7CA5758973207D4451E109Bdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ravi, Thanks much for your very helpful comments! My responses are inline below. Best Regards, Huaimo From: Raveendra Torvi [mailto:rtorvi@juniper.net] Sent: Monday, June 24, 2013 5:57 PM To: Huaimo Chen; Lizhong Jin; Ross Callon Cc: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; m= pls-chairs@tools.ietf.org Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protectio= n I have finished first round of review of this draft. In short, WG should ex= plore use cases and see whether signaling procedure mentioned in the draft = are applicable in real world, before accepting this as WG draft. I do not= think this draft is readily usable. [Huaimo] This draft is initially written for a real use case, which has bee= n presented in the WG meetings. A prototype has been developed to verify so= me of the ideas in the draft. The running results have showed that they wor= k as expected. Following are some issues with draft: [1] Unlike other local protection this is an ingress driven, not PLR. In i= nter-domain scenario, ingress may not have the visibility of entire network= to figure out the complete primary path, not to mention the bypass path. [Huaimo] Can we focus on one domain scenario for our discussions first? Oth= er local protection and the egress node protection may need help from other= s such as PCE in inter-domain scenarios. The ingress of an LSP just provides the minimum amount of information for p= rotecting primary egress nodes. The protection for every primary egress nod= e is then driven by the PLR (i.e., the previous hop node of the primary egr= ess node). For facility backup protection, the ingress of the LSP just needs to give a= backup egress node for every primary egress node to be protected (plus som= e constraints if needed, which are the same as other local protection defin= ed in RFC4090). The previous hop node (i.e., PLR) selects or creates a bypa= ss backup tunnel from itself to the backup egress node for protecting the p= rimary egress node. If there is a bypass backup tunnel from the PLR to the = backup egress node that satisfies the constraints, then this tunnel is sele= cted; otherwise, a new bypass backup tunnel to the backup egress node will = be created. A path for the backup bypass tunnel will be computed by the PLR= and then the backup bypass is signaled along the path computed. If a backup S2L sub LSP is used to protect a primary egress node of a P2MP = LSP, the ingress of the LSP needs to provide a path from the previous hop o= f the primary egress to the backup egress node. In one domain scenario, the= re is no issue for the ingress to provide this path. [2] In the presence of loose-hops, this may also yield to wrong selection o= f PLR by ingress, as one may have several hops between ingress designated P= LR and protected PE. There is no indication from Egress to ingress that egr= ess is protected. [Huaimo] The ingress of an LSP does not select any PLR (i.e., the previous = hop node of the primary egress node) for protecting the primary egress node= . In order to protect a primary egress node of the LSP, the ingress just gi= ves the backup egress (designated to protect the primary egress). When a no= de determines that it is the previous hop node of the primary egress node, = it will act as the PLR to provide protection for the primary egress node. The status of the egress node protection is sent to the ingress in the RRO = of the RESV message. There are some descriptions about this in the draft (s= ee the paragraph below). "The previous hop node of the primary egress node sets the protection flags= in the RRO IPv4/IPv6 Sub-object for the primary egress node according to t= he status of the primary egress node and the backup LSP protecting the prim= ary egress node. For example, it will set the node protection bit to one in= dicating that the primary egress node is protected when the backup LSP to t= he backup egress node is set up for protecting the primary egress node." [3] 1:1 relationship between primary egress and backup egress. This will be= scalability issues especially with ring topologies. This solution is NOT extensible to 1:N protection. [Huaimo] It seems typical that one primary egress (PE) pairs with a backup = egress (PE) and a CE is dual home to two egresses (PEs). I do not see any s= calability issue here. Can you give more details about the scalability issu= es regarding to the 1:1 relationship between primary egress and backup egre= ss? The facility backup protection proposed in the draft can provide 1:N protec= tion. Multiple (N) LSPs going through the previous hop node to the primary = egress node can be protected for their primary egress node failure at the s= ame time by one (1) bypass tunnel from the previous hop node to the backup = egress node. Does this address the issue "This solution is NOT extensible t= o 1:N protection."? [4] This draft does not address interoperability with 1:N protection.. [Huaimo] Can you give some more details about "interoperability with 1:N pr= otection"? [5] Local reversion does not work Consider following example: S2L 1 : I - PH1-PE- Primary S2L 1 Backup: I - PH3 - PE-Backup S2L 2: I - PH2 - PE-Other I----PH1--------PE-Primary || PH2--------PE-Other | PH3---------- PE Backup PH - PE link comes back, PH1 sends traffic PE Primary and how & when does P= H2 stop sending traffic to PH3? [Huaimo] For using backup S2L sub LSP to protect the primary egress node, t= he path from the previous hop node of the primary egress node to the backup= egress node will not intersect with the path of the LSP. For the example a= bove, S2L 1 Backup will not go through PH2 (see figure below). Thus local r= eversion may work. S2L 1: I -- PH1 -- PE-Primary S2L 1 Backup: I -- PH1 -- PH3 -- PE-Backup S2L 2: I -- PH1 -- PH2 -- PE-Other I----PH1--------PE-Primary | \ | PH2--------PE-Other \__ PH3---------- PE-Backup When PE-Primary (i.e., the primary egress node) fails, PH1 switches the tra= ffic to the PE-Backup (i.e., the backup egress node). When PE-Primary comes back, PH1 may switch the traffic back to PE-Primary a= fter re-signaling S2L 1 if the local revertive mode is used. [6] According to Section 4.4, in order to detect PE-CE link down, this sol= ution needs a BFD session from a P router to CE device, which is a non-star= ter as P router may not have any state to reach CE, at least draft does not= go deep enough to explain this point. [Huaimo] We will focus on detecting the failure of the primary egress node = in the next version of the draft. [7] This solution addresses P2MP LSPs only. The approach cannot be extended= to apply for P2P LSPs, in which case it must be ensured that the back egre= ss know how to handle inner label (i.e. service label). [Huaimo] The following is a possible approach in which the solution propose= d in the draft is "extended" to protect the egress of a P2P LSP. To protect the primary egress node of a P2P LSP, the ingress of the LSP add= s the object containing the primary egress and the backup egress in the PAT= H message. This object has the same format as the object EGRESS_BACKUP_SUB_= LSP used for protecting a primary egress node of a P2MP LSP. If one-to-one backup is used, the previous hop node of the primary egress n= ode creates a backup LSP from itself to the backup egress for protecting th= e primary egress of the P2P LSP in a way similar to the one for creating a = backup sub LSP to protect a primary egress of a P2MP LSP. If facility backup is used, the previous hop node of the primary egress nod= e selects or creates a backup bypass tunnel from itself to the backup egres= s for protecting the primary egress. In the case that the previous hop (or upstream) node of the primary egress = needs a P2P LSP label from the backup egress (i.e., the inner label used by= the PLR to put into the bypass tunnel), there are a few of ways to get the= label. One way is that the previous hop (or upstream) node "extends" the P= 2P LSP to the backup egress. It sends a path message towards the backup egr= ess along the path computed and gets a resv message with a P2P LSP label fr= om the backup egress. Note that the previous hop (or upstream) node will n= ot create any forwarding entry with this label for sending the traffic to t= he backup egress. The previous hop (or upstream) node can provide the prima= ry egress node protection using this label in a way similar to the one that= it provides an intermediate node protection. Regarding to the service label, it seems that it is out scope of this draft= . The service label such as VPN label should be handled by others such as B= GP. Regards Ravi --_000_5316A0AB3C851246A7CA5758973207D4451E109Bdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ravi,

 

     Tha= nks much for your very helpful comments!

     My = responses are inline below.

 

Best Regards,

Huaimo

 <= /p>

From: Raveendr= a Torvi [mailto:rtorvi@juniper.net]
Sent: Monday, June 24, 2013 5:57 PM
To: Huaimo Chen; Lizhong Jin; Ross Callon
Cc: mpls@ietf.org; draft-chen-mpls-p2mp-egress-protection@tools.ietf= .org; mpls-chairs@tools.ietf.org
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

 

I have finished first rou= nd of review of this draft. In short, WG should explore use cases and see w= hether signaling procedure mentioned in the draft are applicable in real world, before accepting this as WG draft.   I do not thi= nk this draft is readily usable.

 <= /p>

[Huaimo] This draft is initi= ally written for a real use case, which has been presented in the WG meetin= gs. A prototype has been developed to verify some of the ideas in the draft. The running results have showed that they work as expe= cted.

 <= /p>

Following are some issues= with draft:

 

[1] Unlike other local protection this is an ingress= driven, not PLR.  In inter-domain scenario, ingress may not have the = visibility of entire network to figure out the complete primary path, not t= o mention the bypass path.

 <= /p>

[Huaimo] Can we focus on one= domain scenario for our discussions first? Other local protection and the = egress node protection may need help from others such as PCE in inter-domain scenarios.  

The ingress of an LSP just p= rovides the minimum amount of information for protecting primary egress nod= es. The protection for every primary egress node is then driven by the PLR (i.e., the previous hop node of the primary egress node)= .

For facility backup protecti= on, the ingress of the LSP just needs to give a backup egress node for ever= y primary egress node to be protected (plus some constraints if needed, which are the same as other local protection defined in RFC4090= ). The previous hop node (i.e., PLR) selects or creates a bypass backup tun= nel from itself to the backup egress node for protecting the primary egress= node. If there is a bypass backup tunnel from the PLR to the backup egress node that satisfies the constrain= ts, then this tunnel is selected; otherwise, a new bypass backup tunnel to = the backup egress node will be created. A path for the backup bypass tunnel= will be computed by the PLR and then the backup bypass is signaled along the path computed.

If a backup S2L sub LSP is u= sed to protect a primary egress node of a P2MP LSP, the ingress of the LSP = needs to provide a path from the previous hop of the primary egress to the backup egress node. In one domain scenario, there is no issu= e for the ingress to provide this path.

 <= /p>

 

[2] In the presence of loose-hops, this may also yie= ld to wrong selection of PLR by ingress, as one may have several hops betwe= en ingress designated PLR and protected PE. There is no indication from Egr= ess to ingress that egress is protected.

 <= /p>

[Huaimo] The ingress of an L= SP does not select any PLR (i.e., the previous hop node of the primary egre= ss node) for protecting the primary egress node. In order to protect a primary egress node of the LSP, the ingress just gives the ba= ckup egress (designated to protect the primary egress). When a node determi= nes that it is the previous hop node of the primary egress node, it will ac= t as the PLR to provide protection for the primary egress node.

The status of the egress nod= e protection is sent to the ingress in the RRO of the RESV message. There a= re some descriptions about this in the draft (see the paragraph below).

 

“The previous hop node of the primary egress node se= ts the protection flags in the RRO IPv4/IPv6 Sub-object for the primary egr= ess node according to the status of the primary egress node and the backup LSP protecting the primary egress node. For example, i= t will set the node protection bit to one indicating that the primary egres= s node is protected when the backup LSP to the backup egress node is set up= for protecting the primary egress node.”

 <= /p>

 

[3] 1:1 relationship between primary egress and back= up egress. This will be scalability issues especially with ring topologies.=  

   This solution is NOT extensible to= 1:N protection.

 

[Huaimo] It seems typical th= at one primary egress (PE) pairs with a backup egress (PE) and a CE is dual= home to two egresses (PEs). I do not see any scalability issue here. Can you give more details about the scalability issues regardi= ng to the 1:1 relationship between primary egress and backup egress?

The facility backup protecti= on proposed in the draft can provide 1:N protection. Multiple (N) LSPs goin= g through the previous hop node to the primary egress node can be protected for their primary egress node failure at the same time by= one (1) bypass tunnel from the previous hop node to the backup egress node= . Does this address the issue “This solution is NOT extensible to 1:N= protection.”?

 <= /p>

 <= /p>

[4] This draft does not address interoperability wit= h 1:N protection..

 

[Huaimo] Can you give some m= ore details about “interoperability with 1:N protection”?<= /o:p>

 <= /p>

 <= /p>

[5] Local reversion does not work

  

 Consider following example:

 

S2L 1 :  I – PH1—PE- Primary

S2L 1 Backup:  I – PH3 – PE-Backup<= o:p>

S2L 2: I – PH2 – PE-Other

  

      I----PH1--------= PE-Primary

        &nbs= p;       ||

        &nbs= p;      PH2--------PE-Other

         &nb= sp;      |

        &nbs= p;      PH3---------- PE Backup

 

PH – PE link comes back, PH1 sends traffic PE = Primary and how & when does PH2 stop sending traffic to PH3?

 <= /p>

[Huaimo] For using backup S2= L sub LSP to protect the primary egress node, the path from the previous ho= p node of the primary egress node to the backup egress node will not intersect with the path of the LSP. For the example above, S2L 1 = Backup will not go through PH2 (see figure below). Thus local reversion may= work.

 

S2L 1:  I –- PH1 -— PE-Primary

S2L 1 Backup:  I -– PH1 -- PH3 -– PE-Backup<= /span>

S2L 2: I –- PH1 -- PH2 -– PE-Other

 

      I----PH1--------PE-Primary

           |  \ <= o:p>

           | = ;  PH2--------PE-Other

            \__&n= bsp;  

            =    PH3---------- PE-Backup

 

When PE-Primary (i.e., the p= rimary egress node) fails, PH1 switches the traffic to the PE-Backup (i.e.,= the backup egress node).

When PE-Primary comes back, = PH1 may switch the traffic back to PE-Primary after re-signaling S2L 1 if t= he local revertive mode is used. 

 <= /p>

 

[6] According to Section 4.4,  in order to dete= ct PE-CE link down, this solution needs a BFD session from a P router to CE= device, which is a non-starter as P router may not have any state to reach= CE, at least draft does not go deep enough to explain this point.

 <= /p>

[Huaimo] We will focus on de= tecting the failure of the primary egress node in the next version of the d= raft.

 <= /p>

 <= /p>

[7] This solution addresses P2MP LSPs only. The appr= oach cannot be extended to apply for P2P LSPs, in which case it must be ens= ured that the back egress know how to handle inner label (i.e. service labe= l).

 

[Huaimo] The following is a = possible approach in which the solution proposed in the draft is “ext= ended” to protect the egress of a P2P LSP.

To protect the primary egres= s node of a P2P LSP, the ingress of the LSP adds the object containing the = primary egress and the backup egress in the PATH message. This object has the same format as the object EGRESS_BACKUP_SUB_LSP used f= or protecting a primary egress node of a P2MP LSP.

If one-to-one backup is used= , the previous hop node of the primary egress node creates a backup LSP fro= m itself to the backup egress for protecting the primary egress of the P2P LSP in a way similar to the one for creating a backup su= b LSP to protect a primary egress of a P2MP LSP.

If facility backup is used, = the previous hop node of the primary egress node selects or creates a backu= p bypass tunnel from itself to the backup egress for protecting the primary egress.

In the case that the previou= s hop (or upstream) node of the primary egress needs a P2P LSP label from t= he backup egress (i.e., the inner label used by the PLR to put into the bypass tunnel), there are a few of ways to get the label. = One way is that the previous hop (or upstream) node “extends” t= he P2P LSP to the backup egress. It sends a path message towards the backup= egress along the path computed and gets a resv message with a P2P LSP label from the backup egress.  Note that the p= revious hop (or upstream) node will not create any forwarding entry with th= is label for sending the traffic to the backup egress. The previous hop (or= upstream) node can provide the primary egress node protection using this label in a way similar to the one that i= t provides an intermediate node protection.

Regarding to the service lab= el, it seems that it is out scope of this draft. The service label such as = VPN label should be handled by others such as BGP.

 <= /p>

 <= /p>

 <= /p>

Regards

Ravi=

--_000_5316A0AB3C851246A7CA5758973207D4451E109Bdfweml509mbxchi_-- From huaimo.chen@huawei.com Thu Jun 27 19:43:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5724411E814D for ; Thu, 27 Jun 2013 19:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJVpOUmGKLNe for ; Thu, 27 Jun 2013 19:43:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 695A021F9922 for ; Thu, 27 Jun 2013 19:43:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASX74096; Fri, 28 Jun 2013 02:43:02 +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.1.323.7; Fri, 28 Jun 2013 03:41:50 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 03:42:47 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 27 Jun 2013 19:42:42 -0700 From: Huaimo Chen To: "Tarek Saad (tsaad)" , Ross Callon Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: AQHObgjRXhu7Ou41qUaE6SAXznaJBJlFS4Qw Date: Fri, 28 Jun 2013 02:42:40 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451E10BA@dfweml509-mbx.china.huawei.com> References: <2170E89B881FEA48B3A35413AB6FC4300FB39746@xmb-aln-x08.cisco.com> In-Reply-To: <2170E89B881FEA48B3A35413AB6FC4300FB39746@xmb-aln-x08.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 02:43:21 -0000 Hi Tarek, Thanks much for very useful comments and good questions! My answers/explanations are inline below. Best Regards, Huaimo -----Original Message----- From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com]=20 Sent: Thursday, June 20, 2013 6:52 PM To: Ross Callon; Raveendra Torvi; Eric Gray; Lizhong Jin Cc: mpls-chairs@tools.ietf.org; draft-chen-mpls-p2mp-egress-protection@tool= s.ietf.org; Martin Vigoureux; mpls@ietf.org Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Hi all, =20 I have been asked to the review the below document/draft: Extensions to RSVP-TE for P2MP LSP Egress Local Protection, http://www.ietf= .org/id/draft-chen-mpls-p2mp-egress-protection-09.txt =20 Overall, the draft is well written, the motivation is clear, and the propos= al is sound. I think the document should be considered for WG adoption, but= more discussions and input will be needed from the group on the proposed m= echanisms. =20 More comments below: 1. Suggest a change to the draft outline for easier flow of the draft, e.g.: - Applicability of Local Repair Techniques - One-to-one Backup - Facility Backup - RSVP extensions - Headend Behavior - PLR behavior - Signaling of Backup sub-LSP - .. - Behavior of All LSRs =20 Huaimo: We will re-organize the next version of the draft accordingly. 2. Is the draft also intendeds to cover locally protecting egress nodes tha= t act as transits/mids (aka P2MP bud LSR nodes)? Either way, could be helpf= ul if it mentioned it. Huaimo: Yes. We will add descriptions about this in the next version. =20 3. Section 1: "An existing method for protecting the egress nodes of a P2MP LSP sets up a= backup P2MP LSP from a backup ingress node to the backup egress nodes." * the backup P2MP LSP can also originate from same ingress node to the set = of backup egress nodes. * a variant would be to graft another primary S2L sub-LSP to the "backup" egress node. Traffic flows on to both egress nodes, and receiver can select= traffic from either based on route to source via RPF. Huaimo: You are right. We will mention these in the next version. =20 4. Section 4.1: Typo: follwing -> following =20 Huaimo: Thanks much for your very careful reading! We will correct it. 5. Consider PLR +--+--+ | | | A B C / | \ / + \ / / \ \ CE1---+ +--- CE2 =20 * If the same backup egress node (e.g. B) is used to protect two or more pr= imary egress nodes (e.g. A and C), when PLR reroutes traffic onto the backu= p (detour or bypass tunnel via B) due to a failure of one of the primary eg= ress nodes (eg. A), the receiver(s) connected to other primary egress node(= s) (e.g. CE2) starts to receive duplicated traffic (via C and via B). Huaimo: We may try to avoid this case. For a primary egress node of a P2MP = LSP, there will be a different backup egress node dedicated to protect it. = Thus two different primary egress nodes (e.g., A and C) of the LSP will hav= e two different backup egress nodes (e.g., B and another node D). See figur= e below for reference. (P L R) / | | \ / | | \ / | | \ A B C D \ / \ / \ / \ / CE1 CE2=20 =20 6. Section 4.2: "The previous hop node of the primary egress node sets up a backup sub LSP = from itself" * Arguably, a PLR is one that usually provisions/assigns backup (detour or = bypass). Personally, favour using the term upstream node PLR over previous = hop node (used extensively in the draft). =20 Huaimo: We will consider this in the next version. 7. Section 4.3: "After receiving the RSVP-TE RESV message for the backup sub LSP, the previ= ous hop node creates a forwarding entry with an inactive state or flag call= ed inactive forwarding entry." * which flag is being referred to? I presume non-signalled flag, or mere im= plementation detail? Huaimo: You are right. The forwarding entry for a backup LSP is a local imp= lementation issue. It is not related to signaling protocol. In one device, = it may have an inactive state or flag. In another device, the implementatio= n may be different. We will re-write this part in the next version. =20 =20 8. Section 4.4: " The previous hop node of the primary egress node SHALL detect the failure= of the link between the primary egress node and its destination node (e.g.= the failure of the link between L1 and CE1 in Figure 1). =20 .. =20 Failure of the destination node and the link between the primary egress nod= e and the destination node CAN be detected by a BFD session between the pre= vious hop node and the destination node." * Not typical to trigger TE FRR on failures beyond the TE (sub)LSP path (be= yond the PE egress node).. Is it meant to cover slow routing convergence (f= rom PE to CE)? * AFAIK, the multihop BFD session will detect reachability from prev hop no= de to the destination node (not just L1-CE1 link liveliness). Huaimo: We will focus on the failure in the primary egress in the next vers= ion. We were thinking to cover slow routing convergence. =20 " When we use the egress local protection to protect a primary egress node, we SHOULD NOT use any fast re-route to protect the link between the primary egress node and its previous hop node. The failure of the link is protected by the egress protection. " * While this may work for protecting subLSPs terminating on the primary egr= ess node, there's still need to protect subLSPs transitting the primary egr= ess node (in case of primary bud node). For example, consider case of facil= ity bypass, one could potentially have 2 bypass tunnels (1 terminates on ba= ckup egress node) and another on PLR NHOP (regular NHOP pass) to protect th= e transit subLSPs. Huaimo: You are right. In the case that the primary egress node is also a t= ransit node, the previous hop (or upstream) node of the primary egress node= MUST provide protections for those subLSPs going through the primary egres= s node. We will address this in the next version. =20 9. Section 5: * Typo: FFR -> FRR =20 Huaimo: Thanks much for your very careful reading! We will correct it. =20 10. Section 6: "6. Representation of a Backup Sub LSP" * rfc4090 defines two ways to identify backup subLSP (sender-template and p= ath specific).. I assume both apply, if so could mention this Huaimo: We will mention this in the next version. * What about the backup subLSP sub-group fields (sub-group ID and sub-group= originator)? Are these assigned/set by the PLR since it originates the Path message? Huaimo: Yes. They are assigned/set by the PLR. We will add descriptions abo= ut this in the next version. =20 " An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to specify the explicit route of a backup sub LSP that is from a previous hop node to a backup egress node. The EB-SERO is defined in the following section. " * I'm not sure if the ingress really needs to compose and signal the backup= subLSP SERO, given: 1. From rf4090, a PLR can independently (and optionally using constraints= set in the FAST_REROUTE object) route and signal the detour or bypass tunn= el. 2. In some cases (ingress resides in a different IGP area/domain), the in= gress may not have the visibility to compute the path from PLR to the backu= p egress node; however, the PLR could (provided backup egress node is in it= s TED). Huaimo: The ingress does not need to provide any explicit path for the bypa= ss or detour tunnel (defined in RFC4090) from a previous hop node to a back= up egress node. The PLR (i.e., the previous hop node) of the primary egress= can compute a path for the tunnel.=20 Another option is that PLR may use a sub LSP from the PLR to the backup egr= ess. This sub LSP is a special branch of the primary P2MP LSP. Except for t= hat the PLR does not forward any traffic to this branch in normal operation= , this special branch is the same as a regular branch of the primary P2MP L= SP. If this option is used, the ingress needs to provide an explicit path f= rom the PLR to the backup egress because the ingress knows the path that P2= MP LSP traverses and can provide the explicit path not intersecting the P2M= P LSP path. The PLR may not have the information about the P2MP LSP path. T= he path computed by the PLR may intersect with the P2MP LSP path. In the case that the ingress resides in a different IGP area/domain, it may= need help from others such as PCE. With the help from PCE, the ingress can= get the whole path crossing different areas/domains. It can also get the p= ath from the previous hop node to a backup egress node. =20 11. Section 6.1.1 * Suggest rename "Egress IPv4 address" to Egress Primary Sub LSP IPv4 desti= nation address Huaimo: We will consider renaming it in the next version. =20 12. Section 7.2.1. Backup LSP for One-to-One Protection: * It's not clear what goes on from the signalling perspective post the egre= ss node failure. - will the primary S2L subLSP (to the failed egress node) persist after= the egress node failure? If so, Huaimo: The upstream part of the primary S2L subLSP will stay after the pri= mary egress fails. The part downstream from the previous hop to the primary= egress should be removed. - will the fault (as detected by PLR) be notified back to the ingress n= ode, how? Huaimo: Yes. The PLR will notify the ingress about the fault of the primary= egress node in the same way as a PLR notifies the ingress about the fault = of an intermediate node.=20 - How will the change of path (after reroute) of the primary S2L subLSP= be propagated back to the ingress? Huaimo: The PLR (i.e., the upstream node of the primary egress node) will u= pdate the RRO in the resv message to be sent upwards to the ingress. The pa= th change is in the RRO. - What happens if the primary egress node (previously failed) recovers? - Would the backup egress node remain backup egress post the failure? Huaimo: This depends on the revertive behavior. In local revertive mode, th= e PLR re-signals the primary LSP (i.e., the S2L sub LSP to the primary egre= ss node) after the primary egress node recovers and switches the traffic ba= ck to the primary LSP. We will add some detailed descriptions about this in= the next version. =20 13. Section 7.2.1 " When a primary egress node of the LSP receives the Path message with an egress backup sub LSP descriptor list, it SHOULD ignore the egress backup sub LSP descriptor list and generate a PathErr message. " * I presume a transit/mid won't be allowed to act as a backup egress node t= oo (i.e. become bud after FRR)? If so, can be clarified Huaimo: We will add more descriptions to clarify this in the next version. =20 " If an intermediate node receives the Path message with an egress backup sub LSP descriptor list, it MUST put the EGRESS_BACKUP_SUB_LSP containing a backup egress into a Path message to be sent towards the backup egress. This SHALL be done for each EGRESS_BACKUP_SUB_LSP containing a backup egress node in the list. " * Not clear? is what's intended to say that intermediate node forwards EGRE= SS_BACKUP_SUB_LSP in the Path unchanged? =20 Huaimo: When an intermediate node splits the Path message into a few of Pat= h messages to be sent downstream, it MUST split the backup sub LSP descript= or list accordingly. (e.g., when the Path message is split into two Path me= ssages, one goes to a downstream node A towards a primary egress node PEa a= nd the other goes to another downstream node B towards another primary egre= ss node PEb, the intermediate node MUST put the EGRESS_BACKUP_SUB_LSP for t= he primary egress node PEa into the first Path message and the one for the = primary egress node PEb into the second Path message.) We will re-write thi= s to make it clear.=20 =20 14. Section 7.2.2: * Typo: satisifies -> satisfies Huaimo: Thanks much for your very careful reading! We will correct it. * The mechanisms proposed here are in violation of RFC4090 (section 3.1): " In the one-to-one backup method, a label-switched path= is established that intersects the original LSP somewhere downstream of th= e point of link or node failure." (section 3.2): "The bypass tunnel must intersect the path of the origin= al LSP(s) somewhere downstream of the PLR." Huaimo: The mechanisms proposed here can be considered as some special exte= nsions to RFC4090. RFC4090 covers protections for intermediate nodes of an = LSP. For protecting any intermediate node, the above two statements apply. = A primary egress node without any next hops (i.e., a non bud egress) does n= ot have any original LSP somewhere downstream the primary egress node. Thus= RFC4090 can not be directly applied to protect the primary egress. =20 " When the previous hop node detects a failure in the primary egress, it has to imports the traffic for the protected P2MP LSP into the backup bypass tunnel using the backup label as the top label. " * statement not clear, suggest rewording. * Not clear what's really involved in making local egress node protection w= ork with facility bypass tunnel Prior to the fault (egress node down): 1. Will there be an S2L subLSP signaled to the backup egress node o= r not? Huaimo: One way to get a label from the backup egress node is to signal an = empty S2L subLSP to the backup egress node before the primary egress node f= ails.=20 It sends a path message to the backup egress, gets a resv message with a P2= MP LSP label from the backup egress and then provides the primary egress no= de protection using this label. Note that the previous hop (or upstream) n= ode will not create any forwarding entry with this label for sending the tr= affic to the backup egress. We may call this S2L sub LSP (segment) extended= from the primary LSP an empty primary LSP since it will not transport any = traffic. See the figure below for reference. One way: Link **** Primary LSP $ ---- Backup LSP $ [R2]****[R3]*****[L1] Empty Primary LSP=20 $ * *)\ $ *)=20 * *)\ $[CE1] *) * *)\ $ *) * *)\__[La] * [R1]****[R4]***[R5]*****[L2]=20 $ *)\ $ =20 $ *)\ $[CE2] [S] *)\ $=20 *)\__[Lb] Previous hop (R3) signals empty primary LSP to backup egress (La) Previous hop (R3) uses a bypass LSP to protect primary egress (L1) Previous hop (R3) does not sends control traffic by bypass LSP when primary= egress fails Another way: Link **** Primary LSP $ ---- Backup LSP $ [R2]****[R3]*****[L1] Empty Primary LSP $ * \ *)$ $ *)=20 * \ *)$ $[CE1] *) * \ *)$ $ *) * \__[La] * [R1]****[R4]***[R5]*****[L2]=20 $ \ *)$ $ =20 $ \ *)$ $[CE2] [S] \ *)$ $=20 \__[Lb] Link between primary egress (L1) and backup egress (La) is required Primary egress (L1) signals empty primary LSP to backup egress (La) Previous hop (R3) partially reuses FRR to protect primary egress (L1) Previous hop (R3) does not sends control traffic by bypass LSP when primary= egress fails Post the fault (egress node down): 2. For link-protection, the top (outer) label will be the bypass tu= nnel label, and the inner label will be the label allocated by the next hop (bac= kup egress node (?)). It's not clear how this inner label is learnt back at= the PLR? Huaimo: The previous hop (or upstream) node gets a label from the backup e= gress node in one of the ways mentioned above before the primary egress nod= e fails.=20 It will use this label as the inner label after the primary egress node fai= ls.=20 3. If multiple primary egress nodes are being protected by same bac= kup egress node and same bypass tunnel, does the backup egress node allocate a u= nique label for each? Huaimo: It is not allowed for one (same) backup egress node to protect mult= iple primary egress nodes of one (same) LSP. As you mentioned in comment 5,= there will be duplicated traffic on CEs when one of the primary egress nod= es fails. We will add some descriptions about this in the next version. 4. After the fault (egress node down), what happens to the primary = subLSP? =20 Huaimo: The upstream part of the primary subLSP will stay after the primary= egress node fails. The part downstream from the previous hop of the primar= y egress node should be removed. Huaimo: We will add more details about all these in the next version. Thanks, Tarek On 2013-06-11 10:16 PM, "Ross Callon" wrote: >Ravi, Eric, Tarek, Lizhong; > >You have been selected as MPLS Review team reviewers for=20 >draft-chen-mpls-p2mp-egress-protection-09. > >Note to authors: You have been CC'd on this email so that you can know=20 >that this review is going on. However, please do not review your own=20 >document. > >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=20 >and grammar understandable (it doesn't need to be perfect at this=20 >point, but should be reasonably clear). We are interested in knowing=20 >whether the document is ready to be considered for WG adoption (ie, it=20 >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=20 >secretary, and CC'd to the MPLS WG email list. If necessary, Comments=20 >may be sent privately to only the WG chairs. > >Are you able to review this draft by June 26, 2013? > >Thanks, Ross >(as MPLS WG chair) > > > > > From liushucheng@huawei.com Thu Jun 27 21:58:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCECA21F9E28 for ; Thu, 27 Jun 2013 21:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5poBAEKMszPK for ; Thu, 27 Jun 2013 21:58:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 446BD21F9E23 for ; Thu, 27 Jun 2013 21:58:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASX82140; Fri, 28 Jun 2013 04:58:52 +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.1.323.7; Fri, 28 Jun 2013 05:57:35 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 05:58:24 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.95]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Fri, 28 Jun 2013 12:58:21 +0800 From: "Will Liu (Shucheng)" To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-manral-mpls-rfc3811bis-03.txt Thread-Index: AQHOc7uYKhG/0cWI9U+GlW326uEnWJlKj9AQ Date: Fri, 28 Jun 2013 04:58:20 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 04:58:57 -0000 SGkgRm9sa3MsDQoNCldlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gdG8gYWRkcmVzcyB0aGUgY29t bWVudHMgYWJvdXQgTXBsc0xTUElEIGRlc2NyaXB0aW9uIGFzIGJlbG93LiBXZSBhcmUgbG9va2lu ZyBmb3J3YXJkIHRvIHlvdXIgZnVydGhlciBjb21tZW50cy4gVGhhbmtzLg0KDQpDaGVlcnMsDQpX aWxsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5 LCBKdW5lIDI4LCAyMDEzIDEyOjU0IFBNDQpUbzogVGluYSBUU09VOyBXaWxsIExpdSAoU2h1Y2hl bmcpOyBGcmFuY2VzY28gRm9uZGVsbGk7IFZpc2h3YXMgTWFucmFsOyBXaWxsIExpdSAoU2h1Y2hl bmcpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1hbnJhbC1t cGxzLXJmYzM4MTFiaXMtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1h bnJhbC1tcGxzLXJmYzM4MTFiaXMtMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFZpc2h3YXMgTWFucmFsIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnku DQoNCkZpbGVuYW1lOgkgZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcw0KUmV2aXNpb246CSAw Mw0KVGl0bGU6CQkgRGVmaW5pdGlvbnMgb2YgVGV4dHVhbCBDb252ZW50aW9ucyAoVENzKSBmb3Ig TXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIE1hbmFnZW1lbnQNCkNyZWF0aW9u IGRhdGU6CSAyMDEzLTA2LTI4DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJl ciBvZiBwYWdlczogMjINClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcy0wMy50eHQNClN0YXR1czog ICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYW5yYWwtbXBs cy1yZmMzODExYmlzDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LW1hbnJhbC1tcGxzLXJmYzM4MTFiaXMtMDMNCkRpZmY6ICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcy0w Mw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgbWVtbyBkZWZpbmVzIGEgTWFuYWdlbWVudCBJbmZvcm1h dGlvbiBCYXNlIChNSUIpIG1vZHVsZSB3aGljaA0KICAgY29udGFpbnMgVGV4dHVhbCBDb252ZW50 aW9ucyB0byByZXByZXNlbnQgY29tbW9ubHkgdXNlZCBNdWx0aXByb3RvY29sDQogICBMYWJlbCBT d2l0Y2hpbmcgKE1QTFMpIG1hbmFnZW1lbnQgaW5mb3JtYXRpb24uICBUaGUgaW50ZW50IGlzIHRo YXQNCiAgIHRoZXNlIFRFWFRVQUwgQ09OVkVOVElPTlMgKFRDcykgd2lsbCBiZSBpbXBvcnRlZCBh bmQgdXNlZCBpbiBNUExTDQogICByZWxhdGVkIE1JQiBtb2R1bGVzIHRoYXQgd291bGQgb3RoZXJ3 aXNlIGRlZmluZSB0aGVpciBvd24NCiAgIHJlcHJlc2VudGF0aW9ucy4NCg0KICAgVGhpcyBkb2N1 bWVudCBvYnNvbGV0ZXMgUkZDMzgxMSBhcyBpdCBhZGRyZXNzZXMgdGhlIG5lZWQgdG8gc3VwcG9y dA0KICAgSVB2NiBleHRlbmRlZCBUdW5uZWxJRCdzIGJ5IGRlZmluaW5nIGEgbmV3IFRDLQ0KICAg TXBsc05ld0V4dGVuZGVkVHVubmVsSUQgd2hpY2ggc3VnZ2VzdHMgdXNpbmcgSVB2NCBhZGRyZXNz IG9mIHRoZQ0KICAgaW5ncmVzcyBvciBlZ3Jlc3MgTFNSIGZvciB0aGUgdHVubmVsIGZvciBhbiBJ UHY2IG5ldHdvcmsuICBDaGFuZ2VzDQogICBmcm9tIFJGQzM4MTEgYW5kIHRoZSBlZmZlY3Qgb2Yg dGhlIG5ldyBUQyB0byBvdGhlciByZWxhdGVkIGRvY3VtZW50cw0KICAgYXJlIHN1bW1hcml6ZWQg aW4gU2VjdGlvbiA0IGFuZCA1LCByZXNwZWN0aXZlbHkuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From loa@pi.nu Fri Jun 28 03:26:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66F221F9C33; Fri, 28 Jun 2013 03:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 241VtN9ZKmQ8; Fri, 28 Jun 2013 03:25:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E64BF21F9C0A; Fri, 28 Jun 2013 03:25:37 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C46351800272; Fri, 28 Jun 2013 12:25:36 +0200 (CEST) Message-ID: <51CD64A1.4010408@pi.nu> Date: Fri, 28 Jun 2013 12:25:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "pwe3@ietf.org" References: <51B9BE97.2090103@pi.nu> In-Reply-To: <51B9BE97.2090103@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 10:26:00 -0000 Folks (chair hat off), I was just about to close the wg last call, but remembered that I've one nitty type of comment. The draft is about retiring the possibility to have TLVs in the GACh header, that is fine and I support that. However TLVs might be carried in the GACh messages, the disticnction is not entirely clear in the draft, can the authors please make this clear. /Loa On 2013-06-13 14:44, Loa Andersson wrote: > Working Groups, > > PWE3 working group, > > This is to start a two week working group last call on an MPLS > document, but since it will be of interest to the PWE3 group also > the chairs agreed to copy it to the PWE3 mailing list as well. > Please keep the discussion on the mpls working group mailing list. > > MPLS working group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-retire-ach-tlv-01. > > Please send your comments to the mpls working group > mailing list (mpls@ietf.org). > > Please send both technical comments, and if you are happy > with the document as is also indications of support. > > There are no IPR claims against this draft. > > The co-authors have earlier stated that they are not aware > of any IPRs applicable to this draft. > > If anyone else in the working group are aware of IPRs claims against > this draft, the time to disclose that is now. > > This working group last call will end on June 27, 2013. > > /Loa > for the 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 Fri Jun 28 03:29:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7604321F9CAB; Fri, 28 Jun 2013 03:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jZJJ4ulJ4u4; Fri, 28 Jun 2013 03:29:21 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE2F21F9C4D; Fri, 28 Jun 2013 03:29:21 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2EE491800272; Fri, 28 Jun 2013 12:29:20 +0200 (CEST) Message-ID: <51CD6580.3080901@pi.nu> Date: Fri, 28 Jun 2013 12:29:20 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "pwe3@ietf.org" References: <51B9BE97.2090103@pi.nu> In-Reply-To: <51B9BE97.2090103@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: [mpls] Closed - Re: Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 10:29:33 -0000 Working Group, this working group last call, very few comments, can the authors please make the updates needed; and tell the the wg and wg chairs that the draft is ready to be sent to the IESG with a request for publication. Testing the water: We can't see that an implementation poll on this draft is necessary. Anyone that think we need to do that? /Loa for the wg chairs On 2013-06-13 14:44, Loa Andersson wrote: > Working Groups, > > PWE3 working group, > > This is to start a two week working group last call on an MPLS > document, but since it will be of interest to the PWE3 group also > the chairs agreed to copy it to the PWE3 mailing list as well. > Please keep the discussion on the mpls working group mailing list. > > MPLS working group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-retire-ach-tlv-01. > > Please send your comments to the mpls working group > mailing list (mpls@ietf.org). > > Please send both technical comments, and if you are happy > with the document as is also indications of support. > > There are no IPR claims against this draft. > > The co-authors have earlier stated that they are not aware > of any IPRs applicable to this draft. > > If anyone else in the working group are aware of IPRs claims against > this draft, the time to disclose that is now. > > This working group last call will end on June 27, 2013. > > /Loa > for the 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 adrian@olddog.co.uk Fri Jun 28 05:25:39 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6138921F9546; Fri, 28 Jun 2013 05:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfy-U4e8o1Mf; Fri, 28 Jun 2013 05:25:28 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 135A421F847A; Fri, 28 Jun 2013 05:25:27 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SCPQFv008067; Fri, 28 Jun 2013 13:25:26 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SCPPYA008018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jun 2013 13:25:26 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , , References: <51B9BE97.2090103@pi.nu> <51CD64A1.4010408@pi.nu> In-Reply-To: <51CD64A1.4010408@pi.nu> Date: Fri, 28 Jun 2013 13:25:21 +0100 Message-ID: <001401ce73fa$8f45d620$add18260$@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: AQHW5VCOalYSNbB9yB8pqvNYs+N7SwKMkCermSXElDA= Content-Language: en-gb Cc: mpls-chairs@tools.ietf.org, pwe3-chairs@tools.ietf.org Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 12:25:39 -0000 > However TLVs might be carried in the GACh messages, the disticnction > is not entirely clear in the draft, can the authors please make > this clear. Happily. The current version defines "ACH TLV" as "TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message." Thus, retiring ACH TLVs, obviously means only removing this concept and not any other TLV-related concept. I would propose to change the last sentence of Section 1 as follows: OLD This document states that ACH TLVs as specified in RFC 5586 are not useful and might be harmful. It updates RFC 5586 by deprecating the ACH TLV and updating the associated IANA registries as described in Section 4 of this document. NEW This document states that ACH TLVs as specified in RFC 5586 are not useful and might be harmful. It updates RFC 5586 by deprecating the ACH TLV and updating the associated IANA registries as described in Section 4 of this document. This document makes no comment about the use of TLVs in other places. In particular, proposals to use TLVs within ACH messages, or as an appendage to ACH messages are not in scope of this document. END Does that work? Thanks, Adrian From adrian@olddog.co.uk Fri Jun 28 05:32:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7754021F9634; Fri, 28 Jun 2013 05:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpiS1oN8GIXW; Fri, 28 Jun 2013 05:32:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id E45E821F9DD4; Fri, 28 Jun 2013 05:32:03 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SCW1vT018357; Fri, 28 Jun 2013 13:32:02 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SCVwfM018292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jun 2013 13:31:59 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , , References: <51B9BE97.2090103@pi.nu> <51CD6580.3080901@pi.nu> In-Reply-To: <51CD6580.3080901@pi.nu> Date: Fri, 28 Jun 2013 13:31:54 +0100 Message-ID: <001801ce73fb$7ad1d300$70757900$@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: AQHW5VCOalYSNbB9yB8pqvNYs+N7SwMSMUR2mSGZoKA= Content-Language: en-gb Cc: mpls-chairs@tools.ietf.org, pwe3-chairs@tools.ietf.org Subject: Re: [mpls] Closed - Re: Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 12:32:19 -0000 > Working Group, > > this working group last call, very few comments, can the authors > please make the updates needed; and tell the the wg and wg chairs > that the draft is ready to be sent to the IESG with a request for > publication. Working on this. I see comments from Loa (separate response sent). I believe all other comments came in before WG last call (e.g. review team comments) and were addressed. If anyone disagrees, please shout. > Testing the water: > > We can't see that an implementation poll on this draft is necessary. > Anyone that think we need to do that? That's amusing. I can confirm I have 237 implementations of not using the ACH TLV :-) They do not all interoperate! In particular, I am having trouble to get my refrigerator to television with my cat (people who know me well will understand why this is). Thanks, Adrian From loa@pi.nu Fri Jun 28 05:59:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798AB21F938E; Fri, 28 Jun 2013 05:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9g8ocC4hIwY; Fri, 28 Jun 2013 05:59:02 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id DF90F21F93B9; Fri, 28 Jun 2013 05:51:02 -0700 (PDT) Received: from [95.209.167.247] (95.209.167.247.mobile.tre.se [95.209.167.247]) (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 1F8681800272; Fri, 28 Jun 2013 14:51:02 +0200 (CEST) Message-ID: <51CD86B5.3060606@pi.nu> Date: Fri, 28 Jun 2013 14:51:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <51B9BE97.2090103@pi.nu> <51CD64A1.4010408@pi.nu> <001401ce73fa$8f45d620$add18260$@olddog.co.uk> In-Reply-To: <001401ce73fa$8f45d620$add18260$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, pwe3@ietf.org, pwe3-chairs@tools.ietf.org Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 12:59:13 -0000 Adrian, Yes this works for me. /Loa On 2013-06-28 14:25, Adrian Farrel wrote: >> However TLVs might be carried in the GACh messages, the disticnction >> is not entirely clear in the draft, can the authors please make >> this clear. > > Happily. > > The current version defines "ACH TLV" as "TLV constructs that can be carried in > messages on the G-ACh by placing them in the ACH between the fixed header fields > and the G-ACh message." > > Thus, retiring ACH TLVs, obviously means only removing this concept and not any > other TLV-related concept. > > I would propose to change the last sentence of Section 1 as follows: > > OLD > This document states that ACH TLVs as specified in RFC 5586 are not > useful and might be harmful. It updates RFC 5586 by deprecating the > ACH TLV and updating the associated IANA registries as described in > Section 4 of this document. > NEW > This document states that ACH TLVs as specified in RFC 5586 are not > useful and might be harmful. It updates RFC 5586 by deprecating the > ACH TLV and updating the associated IANA registries as described in > Section 4 of this document. This document makes no comment about the > use of TLVs in other places. In particular, proposals to use TLVs > within ACH messages, or as an appendage to ACH messages are not in > scope of this document. > END > > Does that work? > > Thanks, > Adrian > -- 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 Fri Jun 28 06:47:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD1B21F8265; Fri, 28 Jun 2013 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.109 X-Spam-Level: X-Spam-Status: No, score=-102.109 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juSukWrX6Mk4; Fri, 28 Jun 2013 06:47:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B4421F8201; Fri, 28 Jun 2013 06:47:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628134706.26169.85116.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 06:47:06 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-retire-ach-tlv-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 13:47:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Retiring TLVs from the Associated Channel Header of the = MPLS Generic Associated Channel Author(s) : Adrian Farrel Stewart Bryant Filename : draft-ietf-mpls-retire-ach-tlv-02.txt Pages : 5 Date : 2013-06-28 Abstract: The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-retire-ach-tlv-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-retire-ach-tlv-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Fri Jun 28 06:50:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA5D21F8445 for ; Fri, 28 Jun 2013 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGXKmKRjaOmO for ; Fri, 28 Jun 2013 06:50:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0CC21F8419 for ; Fri, 28 Jun 2013 06:50:27 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SDoOo9018241 for ; Fri, 28 Jun 2013 14:50:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SDoNiX018233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 28 Jun 2013 14:50:24 +0100 From: "Adrian Farrel" To: References: <20130628134706.26169.27958.idtracker@ietfa.amsl.com> In-Reply-To: <20130628134706.26169.27958.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 14:50:19 +0100 Message-ID: <004401ce7406$6e0cee10$4a26ca30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzpw0rEe/dWSuDadhcHnV98+Vp+pkAvo9g Content-Language: en-gb Subject: [mpls] FW: New Version Notification for draft-ietf-mpls-retire-ach-tlv-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 13:50:33 -0000 New version posted as discussed. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 28 June 2013 14:47 > To: Adrian Farrel; Stewart Bryant > Subject: New Version Notification for = draft-ietf-mpls-retire-ach-tlv-02.txt >=20 >=20 > A new version of I-D, draft-ietf-mpls-retire-ach-tlv-02.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-ietf-mpls-retire-ach-tlv > Revision: 02 > Title: Retiring TLVs from the Associated Channel Header of the MPLS > Generic Associated Channel > Creation date: 2013-06-28 > Group: mpls > Number of pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-mpls-retire-ach-tlv- > 02.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv > Htmlized: = http://tools.ietf.org/html/draft-ietf-mpls-retire-ach-tlv-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-retire-ach-tlv-02 >=20 > Abstract: > The MPLS Generic Associated Channel (G-ACh) is a generalization of > the applicability of the Pseudowire (PW) Associated Channel Header > (ACH). RFC 5586 defines the concept of TLV constructs that can be > carried in messages on the G-ACh by placing them in the ACH between > the fixed header fields and the G-ACh message. These TLVs are = called > ACH TLVs >=20 > No Associated Channel Type yet defined uses an ACH TLV. = Furthermore, > it is believed that handling TLVs in hardware introduces = significant > problems to the fast-path, and since G-ACh messages are intended to > be processed substantially in hardware, the use of ACH TLVs is > undesirable. >=20 > This document updates RFC 5586 by retiring ACH TLVs and removing = the > associated registry. >=20 >=20 >=20 >=20 > The IETF Secretariat From lizho.jin@gmail.com Fri Jun 28 08:22:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17C121F9BAB for ; Fri, 28 Jun 2013 08:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhLdUyiCAcHS for ; Fri, 28 Jun 2013 08:22:11 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF421F9BC2 for ; Fri, 28 Jun 2013 08:22:02 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so719085qej.25 for ; Fri, 28 Jun 2013 08:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G9/oZrz+k6w0h17OauTgAFVEacB9u1eKL9a21kUOu84=; b=QrcXQIzmAt5VaRnPQowqiLwB1rtw7ZfIZ5wgPeo1rrrHHLV3UTZHt62gPeNAu0CQfR URF12356AM371z1eRqRglxJUr3sObpMbsgNKxmef1hCjP2hau5s/A6JX00MvVpr6QU96 7hfPyo8S/S0eBqI6cqGBDfvwPDQiv2l7R2XNgQdYP8Fj0bMuCWP1gaTS0gDGJXEVUJ+5 02Wr/C0NEZ2//VUKaBHUQbJZqjh1XXZdsQP6rZ41rZfrG/GnXyjcx8+QVb2gCwW1dZAo T1vW2sYkvX3r2D3VwHIZMHMGBCHBtbdjQRJF8ILyTzeIguWzzv6MMqJhQX3S4N/WsMxs 6J1Q== MIME-Version: 1.0 X-Received: by 10.224.151.137 with SMTP id c9mr18842451qaw.107.1372432920494; Fri, 28 Jun 2013 08:22:00 -0700 (PDT) Received: by 10.49.65.35 with HTTP; Fri, 28 Jun 2013 08:22:00 -0700 (PDT) In-Reply-To: <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D4451E05FA@dfweml509-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D4451E102D@dfweml509-mbx.china.huawei.com> Date: Fri, 28 Jun 2013 23:22:00 +0800 Message-ID: From: Lizhong Jin To: Huaimo Chen Content-Type: multipart/alternative; boundary=089e01494bb0b4491004e0387097 Cc: Ross Callon , "mpls@ietf.org" , Raveendra Torvi , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 15:22:14 -0000 --089e01494bb0b4491004e0387097 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Huaimo, Thank you for the detail discussion. See inline below. Regards Lizhong On Fri, Jun 28, 2013 at 7:31 AM, Huaimo Chen wrote= : > Hi Lizhong,**** > > ** ** > > Thanks much for your second round comments!**** > > My responses are inline below.**** > > ** ** > > Best Regards,**** > > Huaimo**** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Lizhong Jin > *Sent:* Sunday, June 23, 2013 10:27 AM > *To:* Ross Callon > *Cc:* mpls@ietf.org; Raveendra Torvi; > draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; > mpls-chairs@tools.ietf.org > *Subject:* Re: [mpls] MPLS-RT review of > draft-chen-mpls-p2mp-egress-protection**** > > **** > > Hi authors,**** > > I have been asked to review draft-chen-mpls-p2mp-egress-protection-09. > Overally, there are some points that need to be discussed before WG > adoption. And I would appreciate if the authors could help to clarify.***= * > > **** > > 1. If I understand the draft correctly, the primary and backup egress > node address should be two different address. But actually, the egress no= de > is closely related with many customer service configurations (e.g, mvpn a= nd > p2mp pw). Anycast address based protection has been proved to be an > efficient way for MVPN and other service over RSVP-TE P2MP. Then if anyca= st > address is applied for egress node protection, FRR defined in RFC4090 cou= ld > be reused, right? **** > > **** > > Huaimo: It seems that anycast address based protection depends on IP > routing. Thus the traffic interruption (or switch over) time will be muc= h > longer when the primary egress fails since it relies on the IP routing > convergence. If it is applied for egress node protection, both the primar= y > egress and the backup egress should have a same anycast IP address, a CE > should connect to these two egresses and have a routing table entry with > two items. One item for the route (i.e., the anycast IP address) to the > primary egress with a smaller metric, the other for the route to the > backup egress with a bigger metric. Thus, the CE receives the traffic fro= m > the primary egress in normal operations. When the primary egress fails, > the route to the backup egress becomes the best one after IP routing > convergence and the CE switches to receive the traffic from the backup > egress. In order for the CE to get the traffic from the backup egress > after the primary egress fails, the traffic should be sent to the backup > egress before or when the primary egress fails. A P2MP LSP with these two > egresses (i.e., the primary egress and the backup egress as its normal tw= o > egresses) can send the traffic to both the primary egress and the backup > egress at the same time. It seems that FRR defined in RFC 4090 can not be > reused directly here to switch the traffic to the backup egress from the > primary egress when the primary egress fails. Using the egress node > protection proposed in the draft have two advantages over the anycast > address based protection. One is that the traffic interruption (or switch > over) time will be much shorter (tens of ms) when the primary egress > fails; the other is that the bandwidth used for sending the traffic to th= e > backup egress is saved. Is my understanding of anycast based protection > consistent with yours? **** > > [Lizhong] After more consideration, let me explain my understanding in > detail. The previous node will see the primary and backup egress as one > egress node with the anycast address. Since there is one egress node for > the previous node, then FRR defined in RFC4090 could be reused. But there > should be some synchronization mechanism between primary and backup egres= s, > to negotiate a common label that could be used by both primary and backup > egress. That could be potentially achieved by MP-BGP. The switching time > and BW usage would be the same as FRR. Using anycast address would ease t= he > implementation of the client service (e.g mvpn).**** > > **** > > [Huaimo] Physically the primary egress node and the backup egress node ar= e > two different nodes even though they have a same anycast address. To > protect the primary egress node of a primary (P2MP or P2P) LSP, the > previous hop (or upstream) node of the primary egress node needs to creat= e > a backup LSP to the backup egress node (i.e., the physical backup egress > node, which is different from the physical primary egress node). Since > there is not any primary LSP path segment after the primary egress node, > the FRR defined in RFC4090 could not be reused directly. In order to use > the FRR defined in RFC4090 for protecting a node B, the previous hop (or > upstream) node (say node A) of the node B needs to create a backup LSP th= at > intersects the primary LSP somewhere downstream of the node B. See the > following descriptions from RFC4090:**** > > In section 3.1 One-to-One Backup, =93In the one-to-one backup method,= a > label-switched path is established that intersects the original LSP > somewhere downstream of the point of link or node failure. =85 =93**** > > In section 3.2 Facility Backup, the second paragraph: =93The bypass tunne= l > must intersect the path of the original LSP(s) somewhere downstream of th= e > PLR. =85 =93**** > > In the case that the node B is the primary egress node, node A (i.e., the > previous hop/upstream node of the primary egress node) can not create any > backup LSP intersecting the primary LSP somewhere downstream of the node = B > (i.e., the primary egress node). There is not any primary LSP after the > node B (i.e., the primary egress node).**** > > To protect the primary egress node of a primary LSP, some special protoco= l > extensions are needed. The objective of this draft is to define these > special extensions. > [Lizhong] It seems we are not aligned yet here. Let's say node C as the backup node. Since node A and C has same anycast address, node B will see the two nodes as one in its TE-DB (a virtual node). Then B will have a backup path to this virtual node (node C), which is the end-point of the primary LSP. And as I said in previous email, there should be a synchronization mechanism existed between A and C. **** > > Regarding to the service label, it seems out scope of this draft. The > service label such as VPN label should be handled by others such as BGP. = We > will provide some descriptions about this in details in the next version = of > the draft.**** > > In the client side, using anycast address may be easier. The egress node > protection in the core side should work with the anycast address protecti= on > in the client side. We will address this in the next version of the draft= . > > 2. section 7.2.2. I doubt if the facility proction could work in the > egress protection. The backup egress node does not know the P2MP lable > allocated by the primary egress node. And it is very likely that the P2MP > lable received by backup egress node has already been allocated for other > purpose. Or is there any sychronization mechanism between primary and > backup node.**** > > **** > > Huaimo: In some cases, there is no need for any label. For example, if th= e > second last hop label pop is enabled, the previous hop (or upstream) node > of the primary egress does not need any P2MP LSP label from the backup > egress. In the case that the previous hop (or upstream) node of the prima= ry > egress needs a P2MP LSP label from the backup egress, there are a few of > ways to get the label. One way is to let the previous hop (or upstream) > node send the object containing the backup egress to the primary egress, > which =93extends=94 the P2MP LSP to the backup egress. It sends a path m= essage > to the backup egress, gets a resv message with a P2MP LSP label from the > backup egress and then sends a resv message with this label to the previo= us > hop (or upstream) node. Note that the primary egress will not create any > forwarding entry with this label for sending the traffic to the backup > egress. The previous hop (or upstream) node can provide the primary egres= s > node protection using this label in a way similar to the one that it > provides an intermediate node protection. We will address this in the nex= t > version of the draft.**** > > [Lizhong] But why do you think there is a link between the primary and > backup egress? What if there is no directly connection between the two? *= * > ** > > ** ** > > [Huaimo] We can have another way for the previous hop (or upstream) node > of the primary egress to get the label from the backup egress node. The > previous hop (or upstream) node may "extend" the P2MP LSP to the backup > egress. It sends a path message to the backup egress, gets a resv message > with a P2MP LSP label from the backup egress and then provides the primar= y > egress node protection using this label. Note that the previous hop (or > upstream) node will not create any forwarding entry with this label for > sending the traffic to the backup egress. We may call the LSP (segment) > extended from the primary LSP an empty primary LSP since it will not > transport any traffic.**** > > The first way requires that there be a link between the primary egress an= d > the backup egress. The second way does not have this requirement. The fir= st > way may reuse the existing FRR procedures more. The figures below show so= me > details about these two ways.**** > > ** ** > > The first way:**** > > ** ** > > Link **** Primary LSP**** > > $ ---- Backup LSP**** > > $ [R2]****[R3]*****[L1] Empty Primary LSP**** > > $ * \ *)$ $ *) **** > > * \ *)$ $[CE1] *)**** > > * \ *)$ $ *)**** > > * \__[La]**** > > ***** > > [R1]****[R4]***[R5]*****[L2] **** > > $ \ *)$ $ **** > > $ \ *)$ $[CE2]**** > > [S] \ *)$ $ **** > > \__[Lb]**** > > ** ** > > Link between primary egress (L1) and backup egress (La) is required**** > > Primary egress (L1) signals empty primary LSP to backup egress (La)**** > > Previous hop (R3) reuses FRR to protect primary egress (L1) > [Lizhong] My concern for the empty LSP is the waste of signaling resources in the network. The RSVP is a soft-state protocol hop by hop and relies on the refresh of signaling message. We could investigate it in more detail to see if any better solution exists. > **** > > ** ** > > ** ** > > The second way:**** > > ** ** > > Link **** Primary LSP**** > > $ ---- Backup LSP**** > > $ [R2]****[R3]*****[L1] Empty Primary LSP **** > > $ * *)\ $ *) **** > > * *)\ $[CE1] *)**** > > * *)\ $ *)**** > > * *)\__[La]**** > > ***** > > [R1]****[R4]***[R5]*****[L2] **** > > $ *)\ $ **** > > $ *)\ $[CE2]**** > > [S] *)\ $ **** > > *)\__[Lb]**** > > ** ** > > ** ** > > Previous hop (R3) signals empty primary LSP to backup egress (La)**** > > Previous hop (R3) uses a bypass LSP to protect primary egress (L1)**** > > **** > > **** > > Regards**** > > Lizhong**** > > On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon wrote= : > **** > > Ravi, Eric, Tarek, Lizhong; > > You have been selected as MPLS Review team reviewers for > draft-chen-mpls-p2mp-egress-protection-09. > > 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 June 26, 2013? > > Thanks, Ross > (as MPLS WG chair) > > > **** > > **** > > ** ** > --089e01494bb0b4491004e0387097 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Huaimo,
Thank you for the detail discussion. See in= line below.

Regards
Lizhong


On Fri, Jun 28, 2013= at 7:31 AM, Huaimo Chen <huaimo.chen@huawei.com> wrote= :

Hi Lizhong,=

=A0<= /p>

=A0=A0=A0 Thanks much for= your second round comments!

My responses are inline below.

=A0

Best Regards,

Huaimo

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Sunday, June 23, 2013 10:27 AM
To: Ross Callon
Cc: mpls@ietf.org= ; Raveendra Torvi; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-pr= otection

=A0

Hi authors,

I have been asked to review draft-chen-mpls-p2mp-egr= ess-protection-09. Overally, there are some points that need to be discusse= d before WG adoption. And I would appreciate if the authors could help to clarify.

=A0

1. If I understand the draft correctly, the primary and backup egress n= ode address should=A0be two different=A0address. But actually, the egress n= ode is closely related with many customer service=A0configurations (e.g, mv= pn and p2mp pw).=A0Anycast address based protection has been proved to be an efficient way for MVPN and other servi= ce over RSVP-TE P2MP. Then if anycast address is applied for egress node pr= otection, FRR defined in RFC4090 could be reused, right?

=A0

Huaimo: It seems that any= cast address based protection depends on IP routing. Thus the traffic inter= ruption (or switch over) =A0time will be much longer when the primary egress fails= since it relies on the IP routing convergence. If it is applied for egress= node protection, both the primary egress and the backup egress should have= a same anycast IP address, a CE should connect to these two egresses and have a routing table entry with two item= s. One item for the route (i.e., the anycast IP address) to the primary egr= ess =A0with a smaller metric, the other for the route to the backup egress = with a bigger metric. Thus, the CE receives the traffic from the primary egress in normal operations. =A0When= the primary egress fails, the route to the backup egress becomes the best = one after IP routing convergence and the CE switches to receive the traffic= from the backup egress. =A0In order for the CE to get the traffic from the backup egress after the primary egr= ess fails, the traffic should be sent to the backup egress before or when t= he primary egress fails. A P2MP LSP with these two egresses (i.e., the prim= ary egress and the backup egress as its normal two egresses) can send the traffic to both the primary egres= s and the backup egress at the same time. It seems that FRR defined in RFC = 4090 can not be reused directly here to switch the traffic to the backup eg= ress from the primary egress when the primary egress fails. Using the egress node protection proposed in the= draft have two advantages over the anycast address based protection. One i= s that the traffic interruption (or switch over) =A0time will be much short= er (tens of ms) when the primary egress fails; the other is that the bandwidth used for sending the traffic to the= backup egress is saved. =A0Is my understanding of anycast based protection= consistent with yours?

[Lizhong] After more consideration, let me explain m= y understanding in detail. The previous node will see the primary and backu= p egress as one egress node with the anycast address. Since there is one eg= ress node for the previous node, then FRR defined in RFC4090 could be reused.=A0But there should be some synchro= nization mechanism between primary and backup egress, to negotiate a common= =A0label that could be used by both primary and backup egress. That could b= e potentially achieved by MP-BGP. The switching time and BW usage would be the same as FRR. Using anycast addres= s would ease the implementation of the client service (e.g mvpn).=

=A0

[Huaimo] Physically the p= rimary egress node and the backup egress node are two different nodes even = though they have a same anycast address. To protect the primary egress node of a primary (P2MP or P2P) LSP, the previous hop (or u= pstream) node of the primary egress node needs to create a backup LSP to th= e backup egress node (i.e., the physical backup egress node, which is diffe= rent from the physical primary egress node).=A0 Since there is not any primary LSP path segment after the primar= y egress node, the FRR defined in RFC4090 could not be reused directly. In = order to use the FRR defined in RFC4090 for protecting a node B, the previo= us hop (or upstream) node (say node A) of the node B needs to create a backup LSP that intersects the primary = LSP somewhere downstream of the node B. See the foll= owing descriptions from RFC4090:

=A0=A0=A0 In section 3.1 = One-to-One Backup, =93In the one-to-one backup method, a label-switched pat= h is established that intersects the original LSP somewhere downstream of the point of link or node failure. =85 =93

In section 3.2 Facility Backup, the second paragraph: =93The bypass tunn= el must intersect the path of the original LSP(s) somewhere downstream of the PLR. =85 =93

In the case that the node B is the primary egress node, node A (i.e., th= e previous hop/upstream node of the primary egress node) can not create any backup LSP intersecting the primary LSP somewhere downstrea= m of the node B (i.e., the primary egress node). There is not any primary L= SP after the node B (i.e., the primary egress node).

To protect the primary egress node of a primary LSP, some special protoc= ol extensions are needed. The objective of this draft is to define these special extensions.

[Lizhong] It seems we are not aligned yet here. Let's say no= de C as the backup node. Since node A and C has same anycast address, node = B will see the two nodes as one in its TE-DB (a virtual node). Then B will = have a backup path to this virtual node (node C), which is the end-point of= the primary LSP. And as I said in previous email, there should be a synchr= onization mechanism existed between A and C.=A0

Regarding to the service label, it seems out scope of this draft. The se= rvice label such as VPN label should be handled by others such as BGP. We will provide some descriptions about this in details in th= e next version of the draft.

In the client side, using anycast address may be easier.=A0 The egress n= ode protection in the core side should work with the anycast address protection in the client side. We will address this in the next ve= rsion of the draft.

=A0=

2. section 7.2.2. I doubt i= f the facility proction could work in the egress protection. The backup egr= ess node does not know the P2MP lable allocated by the primary egress node. And it is very likely that the P2MP lable received by backup egress node h= as already been allocated for other purpose. Or is there any sychronization= mechanism between primary and backup node.

=A0

Huaimo: In some cases, th= ere is no need for any label. For example, if the second last hop label pop is enabled, the previous hop (or upstream) node of the primary egress = does not need any P2MP LSP label from the backup egress. In the case that t= he previous hop (or upstream) node of the primary egress needs a P2MP LSP l= abel from the backup egress, there are a few of ways to get the label. One way is to let the previous hop (or= upstream) node send the object containing the backup egress to the primary= egress, =A0which =93extends=94 the P2MP LSP to the backup egress. It sends= a path message to the backup egress, gets a resv message with a P2MP LSP label from the backup egress and then = sends a resv message with this label to the previous hop (or upstream) node= . =A0Note that the primary egress will not create any forwarding entry with= this label for sending the traffic to the backup egress. The previous hop (or upstream) node can provide the = primary egress node protection using this label in a way similar to the one= that it provides an intermediate node protection. We will address this in = the next version of the draft.

[Lizhong] But why do you think there is a link betwe= en the primary and backup egress? What if there is no directly connection b= etween the two?

=A0

[Huaimo] We can have anot= her way for the previous hop (or upstream) node of the primary egress to ge= t the label from the backup egress node. The previous hop (or upstream) node may "extend" the P2MP LSP to the backup egres= s. It sends a path message to the backup egress, gets a resv message with a= P2MP LSP label from the backup egress and then provides the primary egress= node protection using this label.=A0 Note that the previous hop (or upstream) node will not create any forwarding entry w= ith this label for sending the traffic to the backup egress. We may call th= e LSP (segment) extended from the primary LSP an empty primary LSP since it= will not transport any traffic.

The first way requires th= at there be a link between the primary egress and the backup egress. The se= cond way does not have this requirement. The first way may reuse the existing FRR procedures more. The figures below show some detail= s about these two ways.

=A0

The first way:

=A0

=A0=A0=A0=A0 Link=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 **** Primary LSP

=A0=A0=A0=A0 $=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ---- Backup LSP

=A0=A0=A0 $=A0=A0=A0= =A0=A0=A0=A0=A0 [R2]****[R3]*****[L1]=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 E= mpty Primary LSP

=A0=A0 $=A0=A0=A0=A0= =A0=A0=A0=A0=A0 *=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0=A0=A0 *)$=A0 $=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 *)

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0*=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0\=A0=A0=A0 *)$=A0= =A0=A0 $[CE1]=A0=A0=A0=A0 *)

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 *=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0 *)$=A0 $= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 *=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \__[La]<= u>

=A0=A0=A0=A0=A0=A0= =A0=A0=A0 *

=A0=A0=A0=A0=A0=A0 [= R1]****[R4]***[R5]*****[L2]

=A0=A0=A0=A0=A0=A0$= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0=A0=A0 *)$=A0 $= =A0=A0=A0

=A0=A0=A0=A0=A0$=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0=A0 *)$=A0=A0= =A0 $[CE2]

=A0 [S]=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0 *)$=A0 $

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\__[Lb]

=A0

Link between primary= egress (L1) and backup egress (La) is required

Primary egress (L1) = signals empty primary LSP to backup egress (La)

Previous hop (R3) re= uses FRR to protect primary egress (L1)

<= /blockquote>
[Lizhong] My concern for the empty LSP is the waste of sig= naling resources in the network. The RSVP is a soft-state protocol hop by h= op and relies on the refresh of signaling message. We could investigate it = in more detail to see if any better solution exists.

=A0

=A0

The second way:

=A0

=A0=A0=A0=A0 Link=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 **** Primary LSP<= /p>

=A0=A0=A0=A0 $=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ---- Backup LSP

=A0=A0=A0 $=A0=A0=A0= =A0=A0=A0=A0=A0 [R2]****[R3]*****[L1]=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 E= mpty Primary LSP

=A0=A0=A0$=A0=A0=A0= =A0=A0=A0=A0=A0=A0 *=A0=A0=A0=A0=A0=A0=A0 *)\=A0=A0=A0=A0=A0=A0=A0=A0=A0 $= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0*=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)\=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 $[CE1]=A0=A0=A0=A0 *)

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 *=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)\=A0=A0=A0=A0=A0=A0=A0= $=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 *=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)\__[La]

=A0=A0=A0=A0=A0=A0= =A0=A0=A0 *

=A0=A0=A0=A0=A0=A0 [= R1]****[R4]***[R5]*****[L2]

=A0=A0=A0=A0=A0=A0$= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)\=A0=A0=A0=A0=A0=A0=A0=A0= =A0 $=A0=A0=A0

=A0=A0=A0=A0=A0$=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)\=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 $[CE2]

=A0 [S]=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *)\=A0=A0=A0 =A0=A0=A0=A0$

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0*)\__[Lb]

=A0

=A0

Previous hop (R3) si= gnals empty primary LSP to backup egress (La)

Previous hop (R3) us= es a bypass LSP to protect primary egress (L1)

=A0=A0=A0=A0

=A0<= /p>

Regards

Lizhong=

On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <rcallon@juniper.net<= /a>> wrote:

Ravi, Eric, Tarek, Li= zhong;

You have been selected as MPLS Review team reviewers for
draft-chen-mpls-p2mp-egress-protection-09.

Note to authors: You have been CC'd on this email so that you can know<= br> 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? =A0Also, 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 June 26, 2013?

Thanks, Ross
(as MPLS WG chair)


=A0

=A0


--089e01494bb0b4491004e0387097-- From eric.gray@ericsson.com Fri Jun 28 12:10:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A2A21F9CA1 for ; Fri, 28 Jun 2013 12:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KV2cHb+f+bx for ; Fri, 28 Jun 2013 12:09:58 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B4CAC21F9CA0 for ; Fri, 28 Jun 2013 12:09:58 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-ad-51cddf850052 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DD.1E.31362.68FDDC15; Fri, 28 Jun 2013 21:09:58 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 15:09:57 -0400 From: Eric Gray To: "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" , Ross Callon Thread-Topic: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac50Mh07iSU7UfzJQqGKfUntuV/+uw== Date: Fri, 28 Jun 2013 19:09:56 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60CDB11@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyuXRPrG7b/bOBBjOOi1r0zt7OaPH90hIW i1tLV7Ja/F1xhcWBxWPJkp9MHtebrrJ7fLn8mS2AOYrLJiU1J7MstUjfLoEr43TXHqaCXcwV 3fc+sjUwXmfqYuTkkBAwkVix9AAbhC0mceHeeiCbi0NI4CijxIIr79khnOWMEjOnnwHrYBPQ kDh2Zy0jSEJEYBajxPrTV1hBEswCCRKvV24BSnBwCAs4Ssx7kAliigi4SXQtkYQw9SQW/wWb wiKgKnFx6Q92EJtXwFvi+tcfYHFGoBu+n1rDBDFQXOLWk/lQdwpILNlznhnCFpV4+fgfK4St LPF9ziMWiHodiQW7P7FB2NoSyxa+ZoaYLyhxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYuQo LU4ty003MtzECIyIYxJsjjsYF3yyPMQozcGiJM67Qe9MoJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQZGqX1cso/nRbfdDbmwOFa1SP7OF98dVzd/36aa8C3x6wx3V8209uOyvraF54XWf+Zc wv7l9roZ08ui5txuT+n14u1sYb4p+ji1xcNkscd8gWvTV0+Z7nOj9/e7l2tT96rzLdZ0T075 eXmV+LM4Lu4lftPncIQ6PytlaKq7eGVbgOC9jy8UHbZnK7EUZyQaajEXFScCAOJ1eZlWAgAA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 19:10:14 -0000 Authors, I have been asked to review draft-chen-mpls-p2mp-egress-protection-09 with = a view toward whether or not this draft should be adopted by the MPLS working grou= p. I find there is some work left to do but that - overall - the draft is usef= ul and reasonably=20 coherent and - if this is work the MPLS working group wants to undertake th= is work - this draft is a very good start in the right direction. -- Eric From quintin.zhao@huawei.com Fri Jun 28 13:27:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E222A21F99C9 for ; Fri, 28 Jun 2013 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv5vbRbhCYZf for ; Fri, 28 Jun 2013 13:27:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8ED21F93D4 for ; Fri, 28 Jun 2013 13:27:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASY44415; Fri, 28 Jun 2013 20:27:22 +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.1.323.7; Fri, 28 Jun 2013 21:26:20 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 21:27:20 +0100 Received: from QZHAO (10.212.246.192) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.7; Fri, 28 Jun 2013 13:27:13 -0700 From: Quintin Zhao To: , References: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> In-Reply-To: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> Date: Fri, 28 Jun 2013 16:27:15 -0400 Message-ID: <001e01ce743d$e2314570$a693d050$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5cNCgiJktZy4yHS4OzgkeQ0sBzMAX/lpqg Content-Language: zh-cn X-Originating-IP: [10.212.246.192] X-CFilter-Loop: Reflected Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 20:27:31 -0000 Hello Adrian, Thanks for your very detailed and very helpful review comments and we = are in the process of updating it based on your review comments and detailed suggestions. Here are a few points we would like to discuss them with you further. (1) One key point in your comment is about the MT ID assignment = allocations and we would like to discuss it further to finalize the MT ID = assignment. Based on your suggestion, we have:=20 Range/Value Purpose =20 ----------- ------------------------------------- =20 0 Default/standard topology in IS-IS 1 IPv4 in-band management in IS-IS ..... =20 4096 Default/standard topology in OSPF 4097 Default multicast topology in OSPF=20 4098 IPv4 in-band management in OSPF ...... When both the both ISIS and OSPF routes exist at the same time, LDP = will ends up with two MT-ID. But we what we need is one LDP-MT ID when the = routes referenced by LDP are the optimal routes among the ISIS routes and OSPF routes. So we want change this assignment to: Range/Value Purpose =20 ----------- ------------------------------------- =20 0 Default/standard topology in IS-IS and in OSPF 1 IPv4 in-band management in IS-IS ....... 4096 Default multicast topology in OSPF=20 4097 IPv4 in-band management in OSPF ...... (2) Regarding to the Manageability Considerations, it is indeed as what = you suggested here that the function being added here is not simple to = manage or operate, and will have impact on the way that the network is run. We are thinking to have a separate document to detail these considerations = late. Will this be OK? Thanks again for your time! Quintin -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: 2013=C4=EA5=D4=C229=C8=D5 2:18 To: draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org Cc: mpls@ietf.org Subject: AD review of draft-ietf-mpls-ldp-multi-topology Hi authors, Thanks for this document. I have done my usual AD review which is intended to catch any issues = that I see, and to smooth out the wrinkles before the I-D goes to IETF last = call and IESG review. As you will see below, I have a number of editorial comments (nits and larger changes) and also a few questions/issues. The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. I suggest you read the comments against those sections all together.=20 Note that in my comment for section 9, I think I have worked out what = you need to do, and so the resolution to the comments for 3.4 and 3.8 may = simply be documenting this change to the IANA registry. As usual, all my comments are up for discussion, so please don't feel = you are required to make changes if you think there is a good reason why = things are the way they are. At the moment it looks like a new revision will be needed to address the review, so I have set the flag in the datatracker. Please work with your document shepherd to produce and post a new revision. Thanks, Adrian =3D=3D=3D The document seems to end with a spurious page header. --- The index seems to be considerably adrift from reality. In particular, there is no Appendix in this document. --- Why do you say that this updates RFC 4379? Is it your belief that an implementation of RFC 4379 will not be complete/conformant without these extensions? Or are you just defining extensions which an implementation = in an MPLS-MT environment will need to support? I note that you (in my view, correctly) do not say that this document updates RFC 5036, yet it defines extensions to LDP in a similar way. =20 --- Please expand all acronyms on first use unless they show with an = asterisk in the RFC Editor's list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt I see: CSP LSP QoS --- Abstract and Introduction "IGP protocol" is bad because the "P" in "IGP" is "protocol". --- The RFC Editor prefers documents to have the Introduction as Section 1. You may prefer to make this change yourself, because it will possibly = cause some expansions of terms and acronyms that the RFC Editor might so in a = way you don't like. --- In section 1, the term "MT Topology" is odd because the "T" of "MT" stands for "Topology". Surely you don't mean "Multi Topology Topology"? --- Section 3.1 s/infers/implies/ --- Section 3.2 I prefer that you don't repeat protocol encodings that are defined elsewhere. This can cause nasty problems if you make a mistake or if the original definition is updated. It is enough for you to write... The LDP base specification [RFC5036] (Section 4.1) defines the "Prefix" FEC Element. The "Prefix" encoding is defined for a given "Address Family" (AF), and has length (in bits) specified by the "PreLen" field. To extend IP address families for MT, two new Address Families named "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes within a topology scope. --- Section 3.2 Figure 2 This figure gives the impression that both IPv4 and IPv6 addresses are = four bytes long! I think you need: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MT IP Address Family Format ...and... Where "IP Address" is a variable length field padded to a four octet boundary and containing an IPv4 or IPv6 address/prefix for the "MT IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to the 16-bit Topology ID for given address. ...but you need to check I got that right! However, before doing this work, see my comment on Section 3.3 --- Section 3.2 The proposed FEC Elements with "MT IP" Address Family can be used in You are not proposing any more, you are defining! See also section 3.6, 3.8, 4.1, 4.3, and 8 --- Section 3.2 [RFC5036] does not specify the handling of "Unknown" Address Families. Therefore, [RFC5036] will need to be updated to include the handling procedure for unknown address families. Ouch! This had me really worried because it implied that you are breaking = existing LDP deployments. But I discussed it with Loa, and he pointed me at = Section 3.4.1.1 of RFC 5036 "If in decoding a FEC TLV an LSR encounters a FEC Element with an Address Family it does not support, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unsupported Address Family" Notification message to its LDP peer signaling an error. If it encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error." So I think you can just delete this paragraph. Furthermore, Section 3.5 defines a capability advertisement that enables = you to know whether it is safe to use one of the new AFs. So surely you = should also say "MUST NOT send an MT AF unless the peer has said it can handle = it." See my re-write in the next comment. --- Section 3.3 appears to be repeating a lot of Section 3.2, but in a = better and more concise way. For example, Figure 3 nicely shows how the Prefix = FEC element works with the new AFs. This leads me to think that Section 3.2 could be reduced to just a few = lines that say... The LDP base specification [RFC5036] (Section 4.1) defines the the use of an "Address Family" (AF) field in FEC Elements to indicate the encoding of the "Prefix" or "Address" that follows, and to indicate how the FEC should be interpreted. This document defines two new AF values named "MT IP" and "MT IPv6" that are used to specify the use of IPv4 or IPv6 within a topology scope. The data associated with these new AFs includes an "MT-ID" field that carries the 16-bit Topology ID for a topology. The value of MT-ID=3D0 corresponds to default topology and MUST be ignored on receipt so as to not cause any conflict/confusion with existing non-MT procedures. FEC Elements with the new AFs can be used in any LDP message and procedures that currently specify and allow the use of FEC Elements with the IP or IPv6 AFs, but MUST NOT be used unless the peer has indicated it can handle them as described in Section 3.5. Note that behavior by an LDP speaker that receives a FEC element containing an unknown AF is described in Section 3.4.1.1 of [RFC5036]. --- Section 3.4 is perfectly clear except it doesn't say what "reserved", "special", and "translating" mean. This opens up a number of questions including why you need a registry at all. Presumably the "translation" needed is to ensure that the values = used in LDP have the same meaning as they do in the IGP. If that is the case, = why not simply use exactly the same value? And looking at the registry further, it seems to say that only values allocated by IANA and stored in the registry can be used. That means = that an operator that wants to use MT in their network cannot just assign values = to the MT-IDs for the topologies because the registry has no space for this = to happen. Now, it is possible that you have simply used the wrong words in the registry in section 9, and failed to provide any explanation in the = text. Note that "unassigned" means "not yet assigned, but available to be = assigned by IANA". And "Reserved" means "Do not assign until a new RFC defines = how they should be used." But there are other questions: Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? I guess 16 is convenient to hold either, but how are the top 4 bits to = be handled? How do you handle the case where there are multiple instances of an IGP = (or different IGPs) running? If you *do* expect there to be a mapping function between IGP MT-ID and = LDP MT-ID, how do you ensure the same function is used at both ends of an = LDP session? But Section 3.8 really does seem to say that only MT-IDs in the registry = are allowed, which seems to make this I-D almost useless because you have = only defined "default" (which we have already), "ISIS IPv6", and "all". Isn't = an operator allowed to partition their network into topologies? So... I think what you need in Section 9 is... o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP Parameter" namespace. The allocation policies for this registry are: Range Registration Policy ------ ------------------- 0-3995 Expert Review 3996-4095 Private Use 4096-4127 Expert Review 4128-4255 Private Use 4256-4351 Reserved (IANA does not assign) 4352-4511 Expert Review 4512-65535 Private Use IANA is requested to populate this registry as follows: Range/Value Purpose Reference ----------- ------------------------------------- --------- 0 Default/standard topology in IS-IS [This.I-D]=20 1 IPv4 in-band management in IS-IS [This.I-D] 2 IPv6 routing topology in IS-IS [This.I-D] 3 IPv4 multicast topology in IS-IS [This.I-D] 4 IPv6 multicast topology in IS-IS [This.I-D] 5 IPv6 in-band management in IS-IS [This.I-D] 6-3995 Unassigned (intended to mirror IS-IS) =20 3996-4095 Reserved for private use (from IS-IS) [This.I-D] 4096 Default/standard topology in OSPF [This.I-D]=20 4097 Default multicast topology in OSPF [This.I-D] 4098 IPv4 in-band management in OSPF [This.I-D] 4099-4127 Unassigned (intended to mirror OSPF) =20 4128-4255 Reserved for private use (from OSPF) [This.I-D] 4256-4351 Reserved (IANA does not assign) [This.I-D] 4352-4511 Unassigned =20 4512-65535 Reserved for Private Use [This.I-D] This would address many of the issues in Sections 3.4 and 3.8, and needs = to be discussed in those sections. --- In Section 3.5 o Length: The length (in octets) of TLV. Are you sure it is not just the length in octets of the value? Compare with RFC 5036 Section 3.3 --- Sections 3.5 and 3.6 need to be more closely grouped. Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 --- Section 3.6 To announce its MT capability for an IP address family, LDP FEC type, and Multi Topology, an LDP speaker MAY send an "MT Capability" including the exact Typed Wildcard FEC element with corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To announce its MT capability for both IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi Topologies, an LDP speaker MAY send "MT Capability" with one or more MT Typed FEC elements in it. I don't think this is "MAY" in either case. This *is* how the LDP = speaker announces it. There is no other way to announce it. So... To announce its MT capability for an IP address family, LDP FEC type, and Multi Topology, an LDP speaker sends an "MT Capability" including the exact Typed Wildcard FEC element with corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To announce its MT capability for both IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi Topologies, an LDP speaker sends "MT Capability" with one or more MT Typed FEC elements in it. --- Section 3.6 o If an LSR has not advertised MT capability, its peer must not send messages that include MT identifier to this LSR. Isn't that "MUST NOT"? --- Section 3.8 Certain MT topologies are assigned to serve predetermined purposes: It is not the topology that is assigned, but the MT-ID. Should read: Certain MT-ID values are assigned to indicate specific meanings: --- Section 3.8 It is not helpful to "propose" numbers in this section and then to also reference Section 9 for the definitive numbers. I suggest you remove = all numbers from this section and simply point at Section 9. --- Section 4.2 This MAY allow an LDP speaker to signal its IP convergence... What does 2119 MAY mean in this context? --- Section 4.3 [RFC4379] defines procedures to detect data-plane failures in MPLS LSPs via LSP ping. The specification defines a "Target FEC Stack" TLV that describes the FEC stack being tested. Ha, ha! You got me :-) s/The specification/That specification/ --- Section 4.3.1 Sub-Type Length Value Field -------- ------ ----------------- TBA5 5 MT LDP IPv4 prefix TBA6 17 MT LDP IPv6 prefix Are you sure you don't mean 8 and 20? --- Section 4.3.4 When detect data plane failures using LSP Ping for a specific topoly, the router will intiate an LSP Ping request with the targer FEC stack I think=20 s/When/To/ s/topoly/topology/ s/intiate/initiate/ s/targer/target/ --- Section 4.3.4 For the case that the LSP ping with return path not specified , the reply packet may go through the default topology instead of the topology where the Echo Request goes through. Is that really "the default" or "any"? If you mean "the default" then I think you need some "MUST NOT" text to = talk about other topologies. --- Section 5 The extensions defined in this document utilise the existing LDP error handling defined in [RFC5036]. If an LSR receives an error notification from a peer for an MPLS-MT session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all MT-ID label mappings learned via the session. There is nothing wrong with this text, but it does open a question that = is not addressed anywhere in the document: what is the relationship between = LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? This is somewhat assumable from the discussion of multiple MT-ID = wildcard FEC elements in the Multi-Topology Capability TLV, but it is not = explicit. --- Shouldn't Section 6 comment on how each of the new protocol elements = will not be seen by a legacy implementation because they are only used after successful capability negotiation? But you do need to describe how a legacy node will react to attempted MT capability negotiation. You could also restate the reference to RFC 5036 section 3.4.1.1 since = this issue seemed to be a question for you. --- I'm slightly doubtful about the value of Section 7, but I note that the point you are trying to convey is not quite worded correctly. You have: and the specified signaling mechanisms do not provide any way for the data plane to associate a given packet with a context-specific label space. I don't think the signaling mechanism is relevant, and I think "context- specific" hides what you are trying to say. Perhaps you should have: and there is no way for the data plane to associate a received packet with any one topology, meaning that topology-specific label spaces cannot be used. --- Section 9 o New Status Code: "Multi-Topology Capability not supported" (requested code point: TBA2 from LDP registry "Status Code Name Space"). This status code does not appear to be mentioned in the draft. How is it used? Is an implementation that does not know the new MT Capability TLV supposed to generate this status code? Or are you referencing an = existing error code: in which case it should not appear in this section. o New Status Code: "Unknown Address Family" (requested code point: TBA4 from LDP registry "Status Code Name Space"). This status code does not appear to be mentioned in the draft. How is it used? Is a legacy implementation that does not know either of your new = MT AFs supposed to generate this status code? But I suspect you are just referencing an existing error code (see Section 3.2) as defined in RFC = 5036, and so you should not mention it in this section. Figure 10 does not show either of these status codes. --- Figure 10 shows a specific value for the new status code. Is this a = request or demand? I don't think it has already been allocated. --- Section 9 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP Parameter" namespace. This registry is discussed earlier in my notes. but please be aware that = you will need to define the allocation policy because it is a new registry. --- Section 9 I want to ask Loa Andersson to look again at the LSP Ping TLV = allocations to check that they conform to the work he is currently doing with that registry. --- It would help considerably to add a Manageability Considerations section = to this document because the function being added here is not simple to = manage or operate, and will have impact on the way that the network is run. = Good guidance on such sections can be found in RFC 5706. Appendix A is particularly helpful at summarising things to consider. -------------------- From quintin.zhao@huawei.com Fri Jun 28 13:40:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8470521F9C8E for ; Fri, 28 Jun 2013 13:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VaCZFl9m6KR for ; Fri, 28 Jun 2013 13:40:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2621F9C8B for ; Fri, 28 Jun 2013 13:40:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASY44951; Fri, 28 Jun 2013 20:40:47 +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.1.323.7; Fri, 28 Jun 2013 21:39:58 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 28 Jun 2013 21:40:46 +0100 Received: from QZHAO (10.212.246.192) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.7; Fri, 28 Jun 2013 13:40:43 -0700 From: Quintin Zhao To: "'Alia Atlas'" References: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> In-Reply-To: Date: Fri, 28 Jun 2013 16:40:46 -0400 Message-ID: <001f01ce743f$c5771340$506539c0$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CE741E.3E657340" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5ca3LxGOETTG06TW+c4AKz/vDp4gX0ozOQ Content-Language: zh-cn X-Originating-IP: [10.212.246.192] X-CFilter-Loop: Reflected Cc: mpls@ietf.org, draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2013 20:40:56 -0000 ------=_NextPart_000_0020_01CE741E.3E657340 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello Alia, =20 Thanks for your review and suggestions. =20 Indeed we need to allocate a MT ID range for the applications such as = MRT so that MT ID can be the same for OSPF, ISIS and LDP.=20 =20 We need decide how big this range should be for the applications such as MRT. What is your recommendation for this range? =20 This is what we have now from ISIS-MT(RFC5120): =20 =20 - MT ID #0: Equivalent to the "standard" topology. - MT ID #1: Reserved for IPv4 in-band management purposes. - MT ID #2: Reserved for IPv6 routing topology. - MT ID #3: Reserved for IPv4 multicast routing topology. - MT ID #4: Reserved for IPv6 multicast routing topology. - MT ID #5: Reserved for IPv6 in-band management purposes. - MT ID #6-#3995: Reserved for IETF consensus. - MT ID #3996-#4095: Reserved for development, experimental and proprietary features [RFC3692]. =20 This is what have now from OSPF-MT(RFC4915) =20 0 - Reserved for advertising the metric associated with the default topology (see Section 4.2) 1 - Reserved for advertising the metric associated with the default multicast topology 2 - Reserved for IPv4 in-band management purposes 3-31 - Reserved for assignments by IANA 32-127 - Reserved for development, experimental and proprietary features [RFC3692] 128-255 - Invalid and SHOULD be ignored =20 The range which is available for us to use is from 6 -127. =20 Thanks, Quintin =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: 2013=C4=EA5=D4=C229=C8=D5 8:52 To: Adrian Farrel Cc: draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org; mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology =20 Hi Adrian & authors, =20 I have a couple comments on the IANA registry and number overlapping. =20 First, it would be useful to have a range that is clearly intended to be = the same for OSPF, ISIS and LDP. Given the extremely limited range for OSPF multi-topology routing (http://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of 3-127, it'd be very useful to have that range specifically set aside for cases where it matters that it be the same.=20 =20 One use that I see for this draft is for MRT, which is doing = multi-topology forwarding but not multi-topology routing. This means that the MT-IDs used do not need to overlap with those in OSPF or ISIS. = It would be good to ensure that there's a reasonable range in LDP for such purposes. LDP is one of the few mechanisms that easily lends itself to multi-topology forwarding. =20 Alia =20 P.S. Having the same values for mLDP and PIM may also be very useful = for interworking. PIM doesn't actually have an IANA registry for MT-ID and leaves the meaning of the values up to the = network operator. =20 On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel = wrote: Hi authors, Thanks for this document. I have done my usual AD review which is intended to catch any issues that I see, and to smooth out the wrinkles before the I-D goes to IETF last call and IESG review. As you will see below, I have a number of editorial comments (nits and larger changes) and also a few questions/issues. The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. I suggest you read the comments against those sections all together. Note that in my comment for section 9, I think I have worked out what you need to do, and so the resolution to the comments for 3.4 and 3.8 may simply be documenting this change to the IANA registry. As usual, all my comments are up for discussion, so please don't feel you are required to make changes if you think there is a good reason why things are the way they are. At the moment it looks like a new revision will be needed to address the review, so I have set the flag in the datatracker. Please work with your document shepherd to produce and post a new revision. Thanks, Adrian =3D=3D=3D The document seems to end with a spurious page header. --- The index seems to be considerably adrift from reality. In particular, there is no Appendix in this document. --- Why do you say that this updates RFC 4379? Is it your belief that an implementation of RFC 4379 will not be complete/conformant without these extensions? Or are you just defining extensions which an implementation in an MPLS-MT environment will need to support? I note that you (in my view, correctly) do not say that this document updates RFC 5036, yet it defines extensions to LDP in a similar way. --- Please expand all acronyms on first use unless they show with an asterisk in the RFC Editor's list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt I see: CSP LSP QoS --- Abstract and Introduction "IGP protocol" is bad because the "P" in "IGP" is "protocol". --- The RFC Editor prefers documents to have the Introduction as Section 1. You may prefer to make this change yourself, because it will possibly cause some expansions of terms and acronyms that the RFC Editor might so in a way you don't like. --- In section 1, the term "MT Topology" is odd because the "T" of "MT" stands for "Topology". Surely you don't mean "Multi Topology Topology"? --- Section 3.1 s/infers/implies/ --- Section 3.2 I prefer that you don't repeat protocol encodings that are defined elsewhere. This can cause nasty problems if you make a mistake or if the original definition is updated. It is enough for you to write... The LDP base specification [RFC5036] (Section 4.1) defines the "Prefix" FEC Element. The "Prefix" encoding is defined for a given "Address Family" (AF), and has length (in bits) specified by the "PreLen" field. To extend IP address families for MT, two new Address Families named "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes within a topology scope. --- Section 3.2 Figure 2 This figure gives the impression that both IPv4 and IPv6 addresses are four bytes long! I think you need: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MT IP Address Family Format ...and... Where "IP Address" is a variable length field padded to a four octet boundary and containing an IPv4 or IPv6 address/prefix for the "MT IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to the 16-bit Topology ID for given address. ...but you need to check I got that right! However, before doing this work, see my comment on Section 3.3 --- Section 3.2 The proposed FEC Elements with "MT IP" Address Family can be used in You are not proposing any more, you are defining! See also section 3.6, 3.8, 4.1, 4.3, and 8 --- Section 3.2 [RFC5036] does not specify the handling of "Unknown" Address Families. Therefore, [RFC5036] will need to be updated to include the handling procedure for unknown address families. Ouch! This had me really worried because it implied that you are breaking existing LDP deployments. But I discussed it with Loa, and he pointed me at Section 3.4.1.1 of RFC 5036 "If in decoding a FEC TLV an LSR encounters a FEC Element with an Address Family it does not support, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unsupported Address Family" Notification message to its LDP peer signaling an error. If it encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error." So I think you can just delete this paragraph. Furthermore, Section 3.5 defines a capability advertisement that enables you to know whether it is safe to use one of the new AFs. So surely you should also say "MUST NOT send an MT AF unless the peer has said it can handle it." See my re-write in the next comment. --- Section 3.3 appears to be repeating a lot of Section 3.2, but in a better and more concise way. For example, Figure 3 nicely shows how the Prefix FEC element works with the new AFs. This leads me to think that Section 3.2 could be reduced to just a few lines that say... The LDP base specification [RFC5036] (Section 4.1) defines the the use of an "Address Family" (AF) field in FEC Elements to indicate the encoding of the "Prefix" or "Address" that follows, and to indicate how the FEC should be interpreted. This document defines two new AF values named "MT IP" and "MT IPv6" that are used to specify the use of IPv4 or IPv6 within a topology scope. The data associated with these new AFs includes an "MT-ID" field that carries the 16-bit Topology ID for a topology. The value of MT-ID=3D0 corresponds to default topology and MUST be ignored on receipt so as to not cause any conflict/confusion with existing non-MT procedures. FEC Elements with the new AFs can be used in any LDP message and procedures that currently specify and allow the use of FEC Elements with the IP or IPv6 AFs, but MUST NOT be used unless the peer has indicated it can handle them as described in Section 3.5. Note that behavior by an LDP speaker that receives a FEC element containing an unknown AF is described in Section 3.4.1.1 of [RFC5036]. --- Section 3.4 is perfectly clear except it doesn't say what "reserved", "special", and "translating" mean. This opens up a number of questions including why you need a registry at all. Presumably the "translation" needed is to ensure that the values used in LDP have the same meaning as they do in the IGP. If that is the case, why not simply use exactly the same value? And looking at the registry further, it seems to say that only values allocated by IANA and stored in the registry can be used. That means that an operator that wants to use MT in their network cannot just assign values to the MT-IDs for the topologies because the registry has no space for this to happen. Now, it is possible that you have simply used the wrong words in the registry in section 9, and failed to provide any explanation in the text. Note that "unassigned" means "not yet assigned, but available to be assigned by IANA". And "Reserved" means "Do not assign until a new RFC defines how they should be used." But there are other questions: Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? I guess 16 is convenient to hold either, but how are the top 4 bits to be handled? How do you handle the case where there are multiple instances of an IGP (or different IGPs) running? If you *do* expect there to be a mapping function between IGP MT-ID and LDP MT-ID, how do you ensure the same function is used at both ends of an LDP session? But Section 3.8 really does seem to say that only MT-IDs in the registry are allowed, which seems to make this I-D almost useless because you have only defined "default" (which we have already), "ISIS IPv6", and "all". Isn't an operator allowed to partition their network into topologies? So... I think what you need in Section 9 is... o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP Parameter" namespace. The allocation policies for this registry are: Range Registration Policy ------ ------------------- 0-3995 Expert Review 3996-4095 Private Use 4096-4127 Expert Review 4128-4255 Private Use 4256-4351 Reserved (IANA does not assign) 4352-4511 Expert Review 4512-65535 Private Use IANA is requested to populate this registry as follows: Range/Value Purpose Reference ----------- ------------------------------------- --------- 0 Default/standard topology in IS-IS [This.I-D] 1 IPv4 in-band management in IS-IS [This.I-D] 2 IPv6 routing topology in IS-IS [This.I-D] 3 IPv4 multicast topology in IS-IS [This.I-D] 4 IPv6 multicast topology in IS-IS [This.I-D] 5 IPv6 in-band management in IS-IS [This.I-D] 6-3995 Unassigned (intended to mirror IS-IS) 3996-4095 Reserved for private use (from IS-IS) [This.I-D] 4096 Default/standard topology in OSPF [This.I-D] 4097 Default multicast topology in OSPF [This.I-D] 4098 IPv4 in-band management in OSPF [This.I-D] 4099-4127 Unassigned (intended to mirror OSPF) 4128-4255 Reserved for private use (from OSPF) [This.I-D] 4256-4351 Reserved (IANA does not assign) [This.I-D] 4352-4511 Unassigned 4512-65535 Reserved for Private Use [This.I-D] This would address many of the issues in Sections 3.4 and 3.8, and needs to be discussed in those sections. --- In Section 3.5 o Length: The length (in octets) of TLV. Are you sure it is not just the length in octets of the value? Compare with RFC 5036 Section 3.3 --- Sections 3.5 and 3.6 need to be more closely grouped. Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 --- Section 3.6 To announce its MT capability for an IP address family, LDP FEC type, and Multi Topology, an LDP speaker MAY send an "MT Capability" including the exact Typed Wildcard FEC element with corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To announce its MT capability for both IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi Topologies, an LDP speaker MAY send "MT Capability" with one or more MT Typed FEC elements in it. I don't think this is "MAY" in either case. This *is* how the LDP speaker announces it. There is no other way to announce it. So... To announce its MT capability for an IP address family, LDP FEC type, and Multi Topology, an LDP speaker sends an "MT Capability" including the exact Typed Wildcard FEC element with corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To announce its MT capability for both IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi Topologies, an LDP speaker sends "MT Capability" with one or more MT Typed FEC elements in it. --- Section 3.6 o If an LSR has not advertised MT capability, its peer must not send messages that include MT identifier to this LSR. Isn't that "MUST NOT"? --- Section 3.8 Certain MT topologies are assigned to serve predetermined purposes: It is not the topology that is assigned, but the MT-ID. Should read: Certain MT-ID values are assigned to indicate specific meanings: --- Section 3.8 It is not helpful to "propose" numbers in this section and then to also reference Section 9 for the definitive numbers. I suggest you remove all numbers from this section and simply point at Section 9. --- Section 4.2 This MAY allow an LDP speaker to signal its IP convergence... What does 2119 MAY mean in this context? --- Section 4.3 [RFC4379] defines procedures to detect data-plane failures in MPLS LSPs via LSP ping. The specification defines a "Target FEC Stack" TLV that describes the FEC stack being tested. Ha, ha! You got me :-) s/The specification/That specification/ --- Section 4.3.1 Sub-Type Length Value Field -------- ------ ----------------- TBA5 5 MT LDP IPv4 prefix TBA6 17 MT LDP IPv6 prefix Are you sure you don't mean 8 and 20? --- Section 4.3.4 When detect data plane failures using LSP Ping for a specific topoly, the router will intiate an LSP Ping request with the targer FEC stack I think s/When/To/ s/topoly/topology/ s/intiate/initiate/ s/targer/target/ --- Section 4.3.4 For the case that the LSP ping with return path not specified , the reply packet may go through the default topology instead of the topology where the Echo Request goes through. Is that really "the default" or "any"? If you mean "the default" then I think you need some "MUST NOT" text to talk about other topologies. --- Section 5 The extensions defined in this document utilise the existing LDP error handling defined in [RFC5036]. If an LSR receives an error notification from a peer for an MPLS-MT session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all MT-ID label mappings learned via the session. There is nothing wrong with this text, but it does open a question that is not addressed anywhere in the document: what is the relationship between LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? This is somewhat assumable from the discussion of multiple MT-ID wildcard FEC elements in the Multi-Topology Capability TLV, but it is not explicit. --- Shouldn't Section 6 comment on how each of the new protocol elements will not be seen by a legacy implementation because they are only used after successful capability negotiation? But you do need to describe how a legacy node will react to attempted MT capability negotiation. You could also restate the reference to RFC 5036 section 3.4.1.1 since this issue seemed to be a question for you. --- I'm slightly doubtful about the value of Section 7, but I note that the point you are trying to convey is not quite worded correctly. You have: and the specified signaling mechanisms do not provide any way for the data plane to associate a given packet with a context-specific label space. I don't think the signaling mechanism is relevant, and I think "context- specific" hides what you are trying to say. Perhaps you should have: and there is no way for the data plane to associate a received packet with any one topology, meaning that topology-specific label spaces cannot be used. --- Section 9 o New Status Code: "Multi-Topology Capability not supported" (requested code point: TBA2 from LDP registry "Status Code Name Space"). This status code does not appear to be mentioned in the draft. How is it used? Is an implementation that does not know the new MT Capability TLV supposed to generate this status code? Or are you referencing an existing error code: in which case it should not appear in this section. o New Status Code: "Unknown Address Family" (requested code point: TBA4 from LDP registry "Status Code Name Space"). This status code does not appear to be mentioned in the draft. How is it used? Is a legacy implementation that does not know either of your new MT AFs supposed to generate this status code? But I suspect you are just referencing an existing error code (see Section 3.2) as defined in RFC 5036, and so you should not mention it in this section. Figure 10 does not show either of these status codes. --- Figure 10 shows a specific value for the new status code. Is this a request or demand? I don't think it has already been allocated. --- Section 9 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP Parameter" namespace. This registry is discussed earlier in my notes. but please be aware that you will need to define the allocation policy because it is a new registry. --- Section 9 I want to ask Loa Andersson to look again at the LSP Ping TLV allocations to check that they conform to the work he is currently doing with that registry. --- It would help considerably to add a Manageability Considerations section to this document because the function being added here is not simple to manage or operate, and will have impact on the way that the network is run. Good guidance on such sections can be found in RFC 5706. Appendix A is particularly helpful at summarising things to consider. -------------------- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ------=_NextPart_000_0020_01CE741E.3E657340 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hello = Alia,

 

Thanks for = your review and suggestions.

 

Indeed we = need to allocate a MT ID range for the applications such as MRT so that = MT ID can be the same for OSPF, ISIS and LDP.

 

We need = decide how big this range should be for the applications such as MRT. = What is your recommendation for this range?

 

This is what = we have now from ISIS-MT(RFC5120):

 

 

   = -  MT ID #0:          = Equivalent to the "standard" topology.

   = -  MT ID #1:          = Reserved for IPv4 in-band management

  &n= bsp;           &nb= sp;         =         purposes.

   = -  MT ID #2:          = Reserved for IPv6 routing topology.

   = -  MT ID #3:          = Reserved for IPv4 multicast routing topology.

   = -  MT ID #4:          = Reserved for IPv6 multicast routing topology.

   = -  MT ID #5:          = Reserved for IPv6 in-band management

  &n= bsp;           &nb= sp;         =          purposes.

   = -  MT ID #6-#3995:    Reserved for IETF = consensus.

   = -  MT ID #3996-#4095: Reserved for development, experimental = and

  &n= bsp;           &nb= sp;          =             &= nbsp;  proprietary features [RFC3692].

 

This is what = have now from OSPF-MT(RFC4915)

 

  &n= bsp;         = 0      - Reserved for advertising the metric = associated

  &n= bsp;           &nb= sp;      with the default topology (see Section = 4.2)

  &n= bsp;         = 1      - Reserved for advertising the metric = associated

  &n= bsp;           &nb= sp;      with the default multicast = topology

  &n= bsp;         = 2      - Reserved for IPv4 in-band management = purposes

  &n= bsp;        3-31    - = Reserved for assignments by IANA

  &n= bsp;        32-127  - Reserved = for development, experimental and

  &n= bsp;           &nb= sp;      proprietary features = [RFC3692]

  &n= bsp;        128-255 - Invalid and = SHOULD be ignored

 

The range = which is available for us to use is from 6 -127.

 =

Thanks,

Quintin

 

From:= Alia Atlas = [mailto:akatlas@gmail.com]
Sent: 2013=C4=EA5=D4=C229=C8=D5 = 8:52
To: Adrian Farrel
Cc: = draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org; = mpls@ietf.org
Subject: Re: [mpls] AD review of = draft-ietf-mpls-ldp-multi-topology

 

Hi Adrian & = authors,

 

I have a couple comments on the = IANA registry and number overlapping.

 

First, it would be useful to have a = range that is clearly intended to be the same for OSPF, ISIS and LDP. =  Given the

extremely limited range for OSPF = multi-topology routing (http://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of

 

On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

Hi = authors,

Thanks for this document.

I have done my usual AD = review which is intended to catch any issues
that I see, and to = smooth out the wrinkles before the I-D goes to IETF
last call and = IESG review.

As you will see below, I have a number of editorial = comments (nits and
larger changes) and also a few = questions/issues.

The biggest issue concerns the MT-ID and spans = sections 3.4, 3.8, and 9.
I suggest you read the comments against = those sections all together.
Note that in my comment for section 9, I = think I have worked out what
you need to do, and so the resolution to = the comments for 3.4 and 3.8
may simply be documenting this change to = the IANA registry.

As usual, all my comments are up for = discussion, so please don't feel
you are required to make changes if = you think there is a good reason why
things are the way they = are.

At the moment it looks like a new revision will be needed to = address the
review, so I have set the flag in the datatracker. Please = work with your
document shepherd to produce and post a new = revision.

Thanks,
Adrian

=3D=3D=3D

The document = seems to end with a spurious page header.

---

The index = seems to be considerably adrift from reality.
In particular, there is = no Appendix in this document.

---

Why do you say that this = updates RFC 4379? Is it your belief that an
implementation of RFC = 4379 will not be complete/conformant without these
extensions? Or are = you just defining extensions which an implementation
in an MPLS-MT = environment will need to support?

I note that you (in my view, = correctly) do not say that this document
updates RFC 5036, yet it = defines extensions to LDP in a similar way.

---

Please = expand all acronyms on first use unless they show with an
asterisk in = the RFC Editor's list at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expans= ion.txt

I = see:
CSP
LSP
QoS

---

Abstract and = Introduction

"IGP protocol" is bad because the = "P" in "IGP" is = "protocol".

---

The RFC Editor prefers documents = to have the Introduction as Section 1.

You may prefer to make = this change yourself, because it will possibly
cause some expansions = of terms and acronyms that the RFC Editor might
so in a way you don't = like.

---

In section 1, the term "MT Topology" = is odd because the "T" of "MT"
stands for = "Topology". Surely you don't mean "Multi Topology = Topology"?

---

Section = 3.1

s/infers/implies/

---

Section 3.2

I = prefer that you don't repeat protocol encodings that are = defined
elsewhere. This can cause nasty problems if you make a = mistake or if
the original definition is updated.

It is enough = for you to write...

   The LDP base specification = [RFC5036] (Section 4.1) defines the
   "Prefix" = FEC Element.  The "Prefix" encoding is defined for a = given
   "Address Family" (AF), and has length = (in bits) specified by the
   "PreLen" = field.

   To extend IP address families for MT, two new = Address Families named
   "MT IP" and "MT = IPv6" are used to specify IPv4 and IPv6 prefixes
  =  within a topology scope.

---

Section 3.2 Figure = 2

This figure gives the impression that both IPv4 and IPv6 = addresses are
four bytes long!

I think you need:

  =     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
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ~               =       IP Address           =                     =  ~
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |          Reserved =             |       =  MT-ID                 =  |
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  =  Figure 2: MT IP Address Family = Format

...and...

   Where "IP Address" = is a variable length field padded to a four octet
  =  boundary and containing an IPv4 or IPv6 address/prefix for the = "MT
   IP" and "MT IPv6" AFs = respectively.  The field "MT-ID" corresponds to
  =  the 16-bit Topology ID for given address.

...but you need = to check I got that right!

However, before doing this work, see = my comment on Section 3.3

---

Section 3.2

  =  The proposed FEC Elements with "MT IP" Address Family = can be used in

You are not proposing any more, you are = defining!

See also section 3.6, 3.8, 4.1, 4.3, and = 8

---

Section 3.2

   [RFC5036] does not = specify the handling of "Unknown" Address
  =  Families.  Therefore, [RFC5036] will need to be updated to = include
   the handling procedure for unknown address = families.

Ouch!

This had me really worried because it = implied that you are breaking
existing LDP deployments. But I = discussed it with Loa, and he pointed me
at Section 3.4.1.1 of RFC = 5036

   "If in decoding a FEC TLV an LSR = encounters a FEC Element with an
    Address Family it does = not support, it SHOULD stop decoding the FEC
    TLV, abort = processing the message containing the TLV, and send an
    = "Unsupported Address Family" Notification message to its LDP = peer
    signaling an error.

    If it = encounters a FEC Element type it cannot decode, it SHOULD stop
  =   decoding the FEC TLV, abort processing the message containing = the
    TLV, and send an "Unknown FEC" = Notification message to its LDP peer
    signaling an = error."

So I think you can just delete this = paragraph.

Furthermore, Section 3.5 defines a capability = advertisement that enables
you to know whether it is safe to use one = of the new AFs.  So surely you
should also say "MUST NOT = send an MT AF unless the peer has said it can
handle = it."

See my re-write in the next = comment.

---

Section 3.3 appears to be repeating a lot of = Section 3.2, but in a
better and more concise way. For example, = Figure 3 nicely shows how the
Prefix FEC element works with the new = AFs.

This leads me to think that Section 3.2 could be reduced to = just a few
lines that say...

   The LDP base = specification [RFC5036] (Section 4.1) defines the
   the = use of an "Address Family" (AF) field in FEC Elements to = indicate
   the encoding of the "Prefix" or = "Address" that follows, and to
   indicate how = the FEC should be interpreted.

   This document defines = two new AF values named "MT IP" and "MT = IPv6"
   that are used to specify the use of IPv4 or = IPv6 within a topology
   scope.  The data associated = with these new AFs includes an "MT-ID"
   field = that carries the 16-bit Topology ID for a topology.

  =  The value of MT-ID=3D0 corresponds to default topology and MUST = be
   ignored on receipt so as to not cause any = conflict/confusion with
   existing non-MT = procedures.

   FEC Elements with the new AFs can be = used in any LDP message and
   procedures that currently = specify and allow the use of FEC Elements
   with the IP or = IPv6 AFs, but MUST NOT be used unless the peer has
  =  indicated it can handle them as described in Section 3.5. =  Note that
   behavior by an LDP speaker that receives = a FEC element containing an
   unknown AF is described in = Section 3.4.1.1 of [RFC5036].

---

Section 3.4 is perfectly = clear except it doesn't say what = "reserved",
"special", and = "translating" mean.

This opens up a number of questions = including why you need a registry
at all.  Presumably the = "translation" needed is to ensure that the
values used in = LDP have the same meaning as they do in the IGP. If that
is the case, = why not simply use exactly the same value?

And looking at the = registry further, it seems to say that only values
allocated by IANA = and stored in the registry can be used. That means
that an operator = that wants to use MT in their network cannot just
assign values to = the MT-IDs for the topologies because the registry
has no space for = this to happen.

Now, it is possible that you have simply used the = wrong words in the
registry in section 9, and failed to provide any = explanation in the
text.  Note that "unassigned" means = "not yet assigned, but available
to be assigned by IANA". =  And "Reserved" means "Do not assign until
a new = RFC defines how they should be used."

But there are other = questions:

Why do you need 16 bits when ISIS has only 12 bits and = OSPF only 8 bits?
I guess 16 is convenient to hold either, but how = are the top 4 bits to
be handled?

How do you handle the case = where there are multiple instances of an IGP
(or different IGPs) = running?

If you *do* expect there to be a mapping function = between IGP MT-ID and
LDP MT-ID, how do you ensure the same function = is used at both ends of
an LDP session?

But Section 3.8 really = does seem to say that only MT-IDs in the registry
are allowed, which = seems to make this I-D almost useless because you
have only defined = "default" (which we have already), "ISIS IPv6", = and
"all". Isn't an operator allowed to partition their = network into
topologies?

So...

I think what you need in = Section 9 is...

   o  New registry "LDP = Multi-Topology (MT) ID Name Space" under "LDP
    =   Parameter" namespace.  The allocation policies for this = registry
      are:

      Range =           Registration Policy
    =   ------         =  -------------------
      0-3995     =      Expert Review
      3996-4095 =       Private Use
      4096-4127 =       Expert Review
      4128-4255 =       Private Use
      4256-4351 =       Reserved (IANA does not assign)
    =   4352-4511       Expert Review
    =   4512-65535      Private Use

    =   IANA is requested to populate this registry as = follows:


      Range/Value   =  Purpose                 =                 = Reference
      -----------   =  -------------------------------------   ---------
  =     0             =  Default/standard topology in IS-IS     =  [This.I-D]
      1         =      IPv4 in-band management in IS-IS     =    [This.I-D]
      2       =        IPv6 routing topology in IS-IS     =      [This.I-D]
      3     =          IPv4 multicast topology in IS-IS =        [This.I-D]
      4   =            IPv6 multicast topology in = IS-IS        [This.I-D]
      5 =              IPv6 in-band management = in IS-IS        [This.I-D]
      = 6-3995         Unassigned (intended to mirror = IS-IS)
      3996-4095      Reserved = for private use (from IS-IS)   [This.I-D]
      = 4096           Default/standard topology in = OSPF       [This.I-D]
      4097   =         Default multicast topology in OSPF   =    [This.I-D]
      4098     =       IPv4 in-band management in OSPF     =     [This.I-D]
      4099-4127     =  Unassigned (intended to mirror OSPF)
      = 4128-4255      Reserved for private use (from OSPF) =    [This.I-D]
      4256-4351     =  Reserved (IANA does not assign)         = [This.I-D]
      4352-4511     =  Unassigned
      4512-65535     = Reserved for Private Use             =    [This.I-D]

This would address many of the issues in = Sections 3.4 and 3.8, and needs
to be discussed in those = sections.

---

In Section 3.5

   o =  Length: The length (in octets) of TLV.

Are you sure it is = not just the length in octets of the value?
Compare with RFC 5036 = Section 3.3

---

Sections 3.5 and 3.6 need to be more = closely grouped.

Suggest moving most of 3.5 into 3.5.1 and moving = 3.6 into 3.5.2

---

Section 3.6

   To = announce its MT capability for an IP address family, LDP FEC = type,
   and Multi Topology, an LDP speaker MAY send an = "MT Capability"
   including the exact Typed = Wildcard FEC element with corresponding
  =  "AddressFamily" field (i.e., set to "MT IP" = for IPv4 and set to "MT
   IPv6" for IPv6 address = family), corresponding "FEC Type" field (i.e.,
  =  set to "P2P", "P2MP", "MP2MP"), and = corresponding "MT-ID".  To
   announce its = MT capability for both IPv4 and IPv6 address family, or
  =  for multiple FEC types, or for multiple Multi Topologies, an = LDP
   speaker MAY send "MT Capability" with one = or more MT Typed FEC
   elements in it.

I don't = think this is "MAY" in either case. This *is* how the = LDP
speaker announces it. There is no other way to announce it. = So...

   To announce its MT capability for an IP = address family, LDP FEC type,
   and Multi Topology, an LDP = speaker sends an "MT Capability" including
   the = exact Typed Wildcard FEC element with corresponding
  =  "AddressFamily" field (i.e., set to "MT IP" = for IPv4 and set to "MT
   IPv6" for IPv6 address = family), corresponding "FEC Type" field (i.e.,
  =  set to "P2P", "P2MP", "MP2MP"), and = corresponding "MT-ID".  To
   announce its = MT capability for both IPv4 and IPv6 address family, or
  =  for multiple FEC types, or for multiple Multi Topologies, an = LDP
   speaker sends "MT Capability" with one or = more MT Typed FEC elements
   in = it.

---

Section 3.6

   o  If an LSR = has not advertised MT capability, its peer must not send
  =     messages that include MT identifier to this = LSR.

Isn't that "MUST NOT"?

---

Section = 3.8

   Certain MT topologies are assigned to serve = predetermined purposes:

It is not the topology that is assigned, = but the MT-ID. Should read:

   Certain MT-ID values are = assigned to indicate specific meanings:

---

Section = 3.8

It is not helpful to "propose" numbers in this = section and then to
also reference Section 9 for the definitive = numbers.  I suggest you
remove all numbers from this section and = simply point at Section 9.

---

Section 4.2

  =  This MAY allow an LDP speaker to signal its IP = convergence...

What does 2119 MAY mean in this = context?

---

Section 4.3

   [RFC4379] = defines procedures to detect data-plane failures in MPLS
  =  LSPs via LSP ping.  The specification defines a "Target = FEC Stack"
   TLV that describes the FEC stack being = tested.

Ha, ha! You got me :-)
s/The specification/That = specification/

---

Section 4.3.1

    =      Sub-Type       Length     =        Value Field
        =  --------       ------         =    -----------------
          =    TBA5            5   =          MT LDP IPv4 prefix
    =          TBA6         =   17            MT LDP IPv6 = prefix

Are you sure you don't mean 8 and = 20?

---

Section 4.3.4

   When detect data = plane failures using LSP Ping for a specific topoly,
   the = router will intiate an LSP Ping request with the targer FEC = stack

I = think

s/When/To/

s/topoly/topology/

s/intiate/initia= te/

s/targer/target/

---

Section = 4.3.4

   For the case that the LSP ping with return = path not specified , the
   reply packet may go through the = default topology instead of the
   topology where the Echo = Request goes through.

Is that really "the default" or = "any"?
If you mean "the default" then I think you = need some "MUST NOT" text to
talk about other = topologies.

---

Section 5

   The = extensions defined in this document utilise the existing LDP
  =  error handling defined in [RFC5036].  If an LSR receives an = error
   notification from a peer for an MPLS-MT session, = it terminates the
   LDP session by closing the TCP = transport connection for the session
   and discarding all = MT-ID label mappings learned via the session.

There is nothing = wrong with this text, but it does open a question that
is not = addressed anywhere in the document: what is the relationship
between = LDP sessions and MT-IDs?  1:1, 1:n, n:1, n:m?

This is = somewhat assumable from the discussion of multiple MT-ID
wildcard FEC = elements in the Multi-Topology Capability TLV, but it is
not = explicit.

---

Shouldn't Section 6 comment on how each of = the new protocol elements
will not be seen by a legacy implementation = because they are only used
after successful capability = negotiation?

But you do need to describe how a legacy node will = react to attempted
MT capability negotiation.

You could also = restate the reference to RFC 5036 section 3.4.1.1 since
this issue = seemed to be a question for you.

---

I'm slightly doubtful = about the value of Section 7, but I note that the
point you are = trying to convey is not quite worded correctly. You have:

  =  and the specified
   signaling mechanisms do not = provide any way for the data plane to
   associate a given = packet with a context-specific label space.

I don't think the = signaling mechanism is relevant, and I think = "context-
specific" hides what you are trying to say. =  Perhaps you should have:

   and there is no = way
   for the data plane to associate a received packet = with any one
   topology, meaning that topology-specific = label spaces cannot be used.

---

Section 9

  =  o  New Status Code: "Multi-Topology Capability not = supported"
      (requested code point: TBA2 from = LDP registry "Status Code Name
      = Space").

This status code does not appear to be mentioned in = the draft. How is
it used? Is an implementation that does not know = the new MT Capability
TLV supposed to generate this status code? Or = are you referencing an
existing error code: in which case it should = not appear in this section.

   o  New Status Code: = "Unknown Address Family" (requested code point:
  =     TBA4 from LDP registry "Status Code Name = Space").

This status code does not appear to be mentioned in = the draft. How is
it used? Is a legacy implementation that does not = know either of your
new MT AFs supposed to generate this status code? = But I suspect you are
just referencing an existing error code (see = Section 3.2) as defined in
RFC 5036, and so you should not mention it = in this section.

Figure 10 does not show either of these status = codes.

---

Figure 10 shows a specific value for the new = status code. Is this a
request or demand? I don't think it has = already been allocated.

---

Section 9

  =  o  New registry "LDP Multi-Topology (MT) ID Name = Space" under "LDP
      Parameter" = namespace.

This registry is discussed earlier in my notes. but = please be aware that
you will need to define the allocation policy = because it is a new
registry.

---

Section 9

I = want to ask Loa Andersson to look again at the LSP Ping = TLV
allocations to check that they conform to the work he is = currently
doing with that registry.

---

It would help = considerably to add a Manageability Considerations section
to this = document because the function being added here is not simple = to
manage or operate, and will have impact on the way that the = network is
run. Good guidance on such sections can be found in RFC = 5706. Appendix A
is particularly helpful at summarising things to = consider.

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

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

 

------=_NextPart_000_0020_01CE741E.3E657340-- From internet-drafts@ietf.org Sun Jun 30 18:49:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4F121F9EC1; Sun, 30 Jun 2013 18:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iXkU4mVKmfh; Sun, 30 Jun 2013 18:49:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DA321F9EBC; Sun, 30 Jun 2013 18:49:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701014958.25493.39837.idtracker@ietfa.amsl.com> Date: Sun, 30 Jun 2013 18:49:58 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-zhao-mpls-mldp-protections-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 01:49:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : P2MP Based mLDP Node Protection Mechanisms for mLDP LSP Author(s) : Quintin Zhao Tao Chou Boris Zhang Emily Chen Filename : draft-zhao-mpls-mldp-protections-04.txt Pages : 18 Date : 2013-06-30 Abstract: This document outlines the procedures and protocol extensions for the protection of mLDP nodes within Multi-Protocol Label Switching (MPLS) networks using P2MP-based backup LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zhao-mpls-mldp-protections There's also a htmlized version available at: http://tools.ietf.org/html/draft-zhao-mpls-mldp-protections-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-zhao-mpls-mldp-protections-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From quintin.zhao@huawei.com Sun Jun 30 19:09:43 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C9B21F9D1F for ; Sun, 30 Jun 2013 19:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.925 X-Spam-Level: X-Spam-Status: No, score=-3.925 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDGg2Axf5PCL for ; Sun, 30 Jun 2013 19:09:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7208321F9EC3 for ; Sun, 30 Jun 2013 19:09:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUN88508; Mon, 01 Jul 2013 02:09:37 +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.1.323.7; Mon, 1 Jul 2013 03:08:34 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 03:09:28 +0100 Received: from QZHAO (10.212.244.160) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.7; Sun, 30 Jun 2013 19:09:24 -0700 From: Quintin Zhao To: Date: Sun, 30 Jun 2013 22:09:09 -0400 Message-ID: <001501ce75ff$fa178a00$ee469e00$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac51/VE2WwORUpPkRYCo+J5167EA0gAAA1/w Content-Language: zh-cn X-Originating-IP: [10.212.244.160] X-CFilter-Loop: Reflected Subject: [mpls] FW: New Version Notification for draft-zhao-mpls-mldp-protections-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 02:09:43 -0000 Hi All, A new version draft-zhao-mpls-mldp-protections is published because the = earlier=20 version has expired, and we are also waiting for feedbacks on the = resolution of the=20 MPLS-RT comments.=20 Thanks, Quintin -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 2013=E5=B9=B46=E6=9C=8830=E6=97=A5 21:50 To: Quintin Zhao; Boris Zhang; Tao Chou; Emily Chen; Telus = Communications Subject: New Version Notification for = draft-zhao-mpls-mldp-protections-04.txt A new version of I-D, draft-zhao-mpls-mldp-protections-04.txt has been successfully submitted by Quintin Zhao and posted to the IETF = repository. Filename: draft-zhao-mpls-mldp-protections Revision: 04 Title: P2MP Based mLDP Node Protection Mechanisms for mLDP LSP Creation date: 2013-06-30 Group: mpls Number of pages: 18 URL: = http://www.ietf.org/internet-drafts/draft-zhao-mpls-mldp-protections-04.t= xt Status: = http://datatracker.ietf.org/doc/draft-zhao-mpls-mldp-protections Htmlized: = http://tools.ietf.org/html/draft-zhao-mpls-mldp-protections-04 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-zhao-mpls-mldp-protections-04 Abstract: This document outlines the procedures and protocol extensions for the protection of mLDP nodes within Multi-Protocol Label Switching (MPLS) networks using P2MP-based backup LSPs. = =20 The IETF Secretariat