From alessandro.dalessandro@telecomitalia.it Thu Apr 1 04:02:25 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DBB3A67F4 for ; Thu, 1 Apr 2010 04:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.369 X-Spam-Level: *** X-Spam-Status: No, score=3.369 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxE4KjHaLwk8 for ; Thu, 1 Apr 2010 04:02:24 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by core3.amsl.com (Postfix) with ESMTP id 6D1E23A67AE for ; Thu, 1 Apr 2010 04:02:23 -0700 (PDT) Received: from GRFHUB704RM001.griffon.local (10.19.3.67) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 1 Apr 2010 13:02:52 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by GRFHUB704RM001.griffon.local ([10.19.9.237]) with mapi; Thu, 1 Apr 2010 13:02:52 +0200 From: D'Alessandro Alessandro Gerardo To: "BRUNGARD, DEBORAH A (ATTLABS)" , "Manuel.Paul@telekom.de" , "eric.gray@ericsson.com" , "lieven.levrau@alcatel-lucent.com" , "benjamin.niven-jenkins@bt.com" , "italo.busi@alcatel-lucent.com" , "rfc-editor@rfc-editor.org" , "malcolm.betts@huawei.com" , "nurit.sprecher@nsn.com" , "satoshi.ueno@ntt.com" , "rcallon@juniper.net" , "adrian.farrel@huawei.com" , "swallow@cisco.com" , "loa@pi.nu" Date: Thu, 1 Apr 2010 13:02:50 +0200 Thread-Topic: [mpls] [Editorial Errata Reported] RFC5654 (2073) Thread-Index: AcrCAkHBrFEh2c5tSYKoFyPNIqhp2wFfAt/QAArSAoMB80oe0AABal5QAAF5gjAAVSjbIAAbZfAgABDJTRA= Message-ID: References: <20100312162629.1F53FE0720@rfc-editor.org>, <6FD21B53861BF44AA90A288402036AB40300EFB5@FRVELSMBS21.ad2.ad.alcatel.com><9C31FA6F6F10D641B0B16A91BC374187B8FACA043D@RDW083V001RVA1.domain1.systemhost.net> <40FB0FFB97588246A1BEFB05759DC8A004215DD3@S4DE9JSAANI.ost.t-com.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 11:02:25 -0000 I agree with Manuel's comment (some feedback to the operator shall be consi= dered). About the correct word to be used, I'm fine with either "reject" or "discar= d" clarifying the previous point. Regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport & OPB Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of BRU= NGARD, DEBORAH A (ATTLABS) Sent: gioved=EC 1 aprile 2010 5.18 To: Manuel.Paul@telekom.de; eric.gray@ericsson.com; lieven.levrau@alcatel-l= ucent.com; benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; rf= c-editor@rfc-editor.org; malcolm.betts@huawei.com; nurit.sprecher@nsn.com; = satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; swallo= w@cisco.com; loa@pi.nu Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) It depends if you are specifying the data plane or mibs. Always, if selecti= ng one sentence out of many, it is not complete (as Eric says). This senten= ce from RFC5654 was more from the data plane view using the familiar packet= term "dropped" vs. transport's G.808.1 "discarded". I also agree we don't want to load this too much. "Reject" is not familiar = wording. Suggest using then wording from G808.1: "External commands which are preempted or denied by other higher priority c= onditions, states or requests, are discarded." I think the choices are: "denied" or "discarded". -----Original Message----- From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] Sent: Wednesday, March 31, 2010 9:42 AM To: eric.gray@ericsson.com; lieven.levrau@alcatel-lucent.com; benjamin.nive= n-jenkins@bt.com; italo.busi@alcatel-lucent.com; rfc-editor@rfc-editor.org;= BRUNGARD, DEBORAH A (ATTLABS); malcolm.betts@huawei.com; nurit.sprecher@ns= n.com; satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com;= swallow@cisco.com; loa@pi.nu Cc: mpls@ietf.org Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) I also believe that we need to phrase it stronger than just saying "drop" o= r "ignore" - to imply that some (whatever) kind of feedback to the "request= er" needs to be considered as well. Using "reject" makes sense for me. Regards, Manuel > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Eric Gray > Sent: Tuesday, March 30, 2010 2:53 PM > To: LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins@bt.com; > BUSI,ITALO (ITALO); rfc-editor@rfc-editor.org; > dbrungard@att.com; malcolm.betts@huawei.com; > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > rcallon@juniper.net; adrian.farrel@huawei.com; > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > I think that there is some consensus developing both in this > discussion > and elsewhere. There is (of course) some confusion over the > meaning of > certain terms, and the way things might be specified in the IETF - as > opposed to elsewhere. > > Essentially, a reasonable implementation will not quite ignore a user > instruction (users would doubtless resent that rather severely). It > is not quite clear what it means to "not quite ignore" instructions > from the user. The idea is that only the highest-priority input at > any given instant in time will result in a state-change for equipment > (services, or the network). > > In my opinion, we don't really want to get bogged down in terminology > issues or detailed over-specification - particularly after the fact > (this is an already published RFC, after all). > > The reason why I created this errata in the first place is that - in > other work in progress - we feel almost compelled to perpetuate the > exiting wording even though it is clearly incorrect. Specifically, > in the MPLS-TP CP draft, we captured requirements from a number of > drafts (unfortunately including this already published RFC). In the > process, it came to light that it makes no sense to "drop" a command > - yet this is what the referenced source document says. > > So, either we take some steps to correct the error, or we find our > selves constrained to perpetuate it. > > I think there is some agreement developing around using "reject" as > a repalcement for either "drop" or "ignore" - as long as we can do > this without creating the ripple-down effect of being compelled to > define exactly what we mean by "reject"... > > -----Original Message----- > From: LEVRAU, LIEVEN (LIEVEN) > [mailto:lieven.levrau@alcatel-lucent.com] > Sent: Monday, March 29, 2010 4:16 PM > To: Eric Gray; benjamin.niven-jenkins@bt.com; BUSI, ITALO > (ITALO); rfc-editor@rfc-editor.org; dbrungard@att.com; > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > Importance: High > > Eric to the your point... (snippet) > > : > > > > "The NE rejects the operator's command and behave like the > command has > > never been requested." > > > > IMHO, acting as if a command has not been given is exactly the > > same thing as ignoring it. > > > I think there should be some logic behind it that the request > was indeed received, parsed and ignored so that it is > eventually a traceable event. > ./ > Lieven > > > > -- > > Eric > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf Of > > benjamin.niven-jenkins@bt.com > > Sent: Friday, March 19, 2010 5:18 PM > > To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org; > > dbrungard@att.com; malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > Rejected implies to me that the NE actively informs the > Operator that > > the attempt by the Operator to execute the external command was > > unsuccessful, is this the case? Otherwise how about "MUST NOT be > > honored"? > > > > Ben > > > > ________________________________________ > > From: BUSI ITALO [Italo.Busi@alcatel-lucent.com] > > Sent: 19 March 2010 16:11 > > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; > dbrungard@att.com; > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > satoshi.ueno@ntt.com; > > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; > > loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I understand the source of the confusion that the word "dropped" can > > create in a packet world. > > > > The term "ignored" is not semantically equivalent to the > intent of the > > original word "dropped". I would therefore propose the following > > rephrase: > > > > A. External controls overruled by higher priority requests > > (e.g., administrative requests and requests due to > > link/node > > failures) or unable to be signaled to the > remote end (e.g., > > due to a coordination failure of the protection > state) MUST > > be rejected. > > > > The NE rejects the operator's command and behave like the > command has > > never been requested. > > > > Italo > > > > P.S. Please note my new email address, > Italo.Busi@alcatel-lucent.com, > > effective since 1 November 2009. > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > Behalf Of RFC Errata System > > > Sent: venerd=EC 12 marzo 2010 17.26 > > > To: benjamin.niven-jenkins@bt.com; dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org; rfc-editor@rfc-editor.org > > > Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > > The following errata report has been submitted for RFC5654, > > > "Requirements of an MPLS Transport Profile". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata_search.php?rfc=3D5654&eid=3D2073 > > > > > > -------------------------------------- > > > Type: Editorial > > > Reported by: Eric Gray > > > > > > Section: 2.5.4 > > > > > > Original Text > > > ------------- > > > 83 The external controls as defined in [RFC4427] MUST be > supported. > > > > > > A. External controls overruled by higher priority requests > > > (e.g., administrative requests and requests due to > > > link/node > > > failures) or unable to be signaled to the remote end > > (e.g., > > > due to a coordination failure of the protection state) > > MUST > > > be dropped. > > > > > > > > > Corrected Text > > > -------------- > > > 83 The external controls as defined in [RFC4427] MUST be > supported. > > > > > > A. External controls overruled by higher priority requests > > > (e.g., administrative requests and requests due to > > > link/node > > > failures) or unable to be signaled to the remote end > > (e.g., > > > due to a coordination failure of the protection state) > > MUST > > > be ignored. > > > > > > > > > Notes > > > ----- > > > Dropping a control is meaningless. The original intent may > > > have been to say "control messages", but this requirement is > > > stated in the section "Management-Plane Operation of > > > Protection and Restoration" > > > > > > In any case, using "ignored" instead of "dropped" fixes the > > > problem regardless of the original intention. > > > > > > 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. > > > > > > -------------------------------------- > > > RFC5654 (draft-ietf-mpls-tp-requirements-10) > > > -------------------------------------- > > > Title : Requirements of an MPLS Transport Profile > > > Publication Date : September 2009 > > > Author(s) : B. Niven-Jenkins, Ed., D. Brungard, > > > Ed., M. Betts, Ed., N. Sprecher, S. Ueno > > > Category : PROPOSED STANDARD > > > Source : Multiprotocol Label Switching > > > Area : Routing > > > Stream : IETF > > > Verifying Party : IESG > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From Italo.Busi@alcatel-lucent.com Thu Apr 1 08:25:58 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1853A6896 for ; Thu, 1 Apr 2010 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.819 X-Spam-Level: X-Spam-Status: No, score=-4.819 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcd0+hewQ7gH for ; Thu, 1 Apr 2010 08:25:55 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 2322F3A68DB for ; Thu, 1 Apr 2010 08:25:54 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o31FQ0fd031627; Thu, 1 Apr 2010 17:26:06 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 17:25:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2010 17:29:24 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B1928@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [Editorial Errata Reported] RFC5654 (2073) Thread-Index: AcrCAkHBrFEh2c5tSYKoFyPNIqhp2wFfAt/QAArSAoMB80oe0AABal5QAAF5gjAAVSjbIAAbZfAgABDJTRAACgKKoA== References: <20100312162629.1F53FE0720@rfc-editor.org>, <6FD21B53861BF44AA90A288402036AB40300EFB5@FRVELSMBS21.ad2.ad.alcatel.com><9C31FA6F6F10D641B0B16A91BC374187B8FACA043D@RDW083V001RVA1.domain1.systemhost.net><40FB0FFB97588246A1BEFB05759DC8A004215DD3@S4DE9JSAANI.ost.t-com.de> From: "BUSI ITALO" To: "D'Alessandro Alessandro Gerardo" , "BRUNGARD, DEBORAH A (ATTLABS)" , , , "LEVRAU LIEVEN" , , , , , , , , , X-OriginalArrivalTime: 01 Apr 2010 15:25:57.0990 (UTC) FILETIME=[A0C00060:01CAD1AF] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:25:58 -0000 I understand that Deborah has some issues with "reject". Therefore it looks like that we can converge on "discard". Is "discard" acceptable? For me it is fine. Thanks, Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: D'Alessandro Alessandro Gerardo=20 > [mailto:alessandro.dalessandro@telecomitalia.it]=20 > Sent: gioved=EC 1 aprile 2010 13.03 > To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul@telekom.de;=20 > eric.gray@ericsson.com; LEVRAU LIEVEN;=20 > benjamin.niven-jenkins@bt.com; BUSI ITALO;=20 > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com;=20 > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com;=20 > rcallon@juniper.net; adrian.farrel@huawei.com;=20 > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) >=20 > I agree with Manuel's comment (some feedback to the operator=20 > shall be considered). > About the correct word to be used, I'm fine with either=20 > "reject" or "discard" clarifying the previous point. >=20 > Regards, > Alessandro > ------------------------------------------------------------------ > Telecom Italia > Alessandro D'Alessandro > Transport & OPB Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of BRUNGARD, DEBORAH A (ATTLABS) > Sent: gioved=EC 1 aprile 2010 5.18 > To: Manuel.Paul@telekom.de; eric.gray@ericsson.com;=20 > lieven.levrau@alcatel-lucent.com;=20 > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com;=20 > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com;=20 > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com;=20 > rcallon@juniper.net; adrian.farrel@huawei.com;=20 > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) >=20 > It depends if you are specifying the data plane or mibs.=20 > Always, if selecting one sentence out of many, it is not=20 > complete (as Eric says). This sentence from RFC5654 was more=20 > from the data plane view using the familiar packet term=20 > "dropped" vs. transport's G.808.1 "discarded". >=20 > I also agree we don't want to load this too much. "Reject" is=20 > not familiar wording. Suggest using then wording from G808.1: > "External commands which are preempted or denied by other=20 > higher priority conditions, states or requests, are discarded." >=20 > I think the choices are: "denied" or "discarded". >=20 > -----Original Message----- > From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] > Sent: Wednesday, March 31, 2010 9:42 AM > To: eric.gray@ericsson.com; lieven.levrau@alcatel-lucent.com;=20 > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com;=20 > rfc-editor@rfc-editor.org; BRUNGARD, DEBORAH A (ATTLABS);=20 > malcolm.betts@huawei.com; nurit.sprecher@nsn.com;=20 > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) >=20 > I also believe that we need to phrase it stronger than just=20 > saying "drop" or "ignore" - to imply that some (whatever)=20 > kind of feedback to the "requester" needs to be considered as well. > Using "reject" makes sense for me. >=20 > Regards, > Manuel >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > > Of Eric Gray > > Sent: Tuesday, March 30, 2010 2:53 PM > > To: LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins@bt.com;=20 > BUSI,ITALO=20 > > (ITALO); rfc-editor@rfc-editor.org; dbrungard@att.com;=20 > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com;=20 > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > adrian.farrel@huawei.com;=20 > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I think that there is some consensus developing both in this=20 > > discussion and elsewhere. There is (of course) some confusion over=20 > > the meaning of certain terms, and the way things might be=20 > specified in=20 > > the IETF - as opposed to elsewhere. > > > > Essentially, a reasonable implementation will not quite=20 > ignore a user=20 > > instruction (users would doubtless resent that rather=20 > severely). It=20 > > is not quite clear what it means to "not quite ignore" instructions=20 > > from the user. The idea is that only the highest-priority input at=20 > > any given instant in time will result in a state-change for=20 > equipment=20 > > (services, or the network). > > > > In my opinion, we don't really want to get bogged down in=20 > terminology=20 > > issues or detailed over-specification - particularly after the fact=20 > > (this is an already published RFC, after all). > > > > The reason why I created this errata in the first place is=20 > that - in=20 > > other work in progress - we feel almost compelled to perpetuate the=20 > > exiting wording even though it is clearly incorrect. =20 > Specifically, in=20 > > the MPLS-TP CP draft, we captured requirements from a=20 > number of drafts=20 > > (unfortunately including this already published RFC). In=20 > the process,=20 > > it came to light that it makes no sense to "drop" a command > > - yet this is what the referenced source document says. > > > > So, either we take some steps to correct the error, or we find our=20 > > selves constrained to perpetuate it. > > > > I think there is some agreement developing around using=20 > "reject" as a=20 > > repalcement for either "drop" or "ignore" - as long as we=20 > can do this=20 > > without creating the ripple-down effect of being compelled=20 > to define=20 > > exactly what we mean by "reject"... > > > > -----Original Message----- > > From: LEVRAU, LIEVEN (LIEVEN) > > [mailto:lieven.levrau@alcatel-lucent.com] > > Sent: Monday, March 29, 2010 4:16 PM > > To: Eric Gray; benjamin.niven-jenkins@bt.com; BUSI, ITALO (ITALO);=20 > > rfc-editor@rfc-editor.org; dbrungard@att.com;=20 > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com;=20 > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > adrian.farrel@huawei.com;=20 > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > Importance: High > > > > Eric to the your point... (snippet) > > > > : > > > > > > "The NE rejects the operator's command and behave like the > > command has > > > never been requested." > > > > > > IMHO, acting as if a command has not been given is=20 > exactly the=20 > > > same thing as ignoring it. > > > > > I think there should be some logic behind it that the request was=20 > > indeed received, parsed and ignored so that it is eventually a=20 > > traceable event. > > ./ > > Lieven > > > > > > -- > > > Eric > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On Behalf Of > > > benjamin.niven-jenkins@bt.com > > > Sent: Friday, March 19, 2010 5:18 PM > > > To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org;=20 > > > dbrungard@att.com; malcolm.betts@huawei.com;=20 > nurit.sprecher@nsn.com;=20 > > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > adrian.farrel@huawei.com;=20 > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > Rejected implies to me that the NE actively informs the > > Operator that > > > the attempt by the Operator to execute the external command was=20 > > > unsuccessful, is this the case? Otherwise how about "MUST NOT be=20 > > > honored"? > > > > > > Ben > > > > > > ________________________________________ > > > From: BUSI ITALO [Italo.Busi@alcatel-lucent.com] > > > Sent: 19 March 2010 16:11 > > > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; > > dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; > > > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com;=20 > > > loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > I understand the source of the confusion that the word=20 > "dropped" can=20 > > > create in a packet world. > > > > > > The term "ignored" is not semantically equivalent to the > > intent of the > > > original word "dropped". I would therefore propose the following > > > rephrase: > > > > > > A. External controls overruled by higher=20 > priority requests > > > (e.g., administrative requests and requests due to=20 > > > link/node > > > failures) or unable to be signaled to the > > remote end (e.g., > > > due to a coordination failure of the protection > > state) MUST > > > be rejected. > > > > > > The NE rejects the operator's command and behave like the > > command has > > > never been requested. > > > > > > Italo > > > > > > P.S. Please note my new email address, > > Italo.Busi@alcatel-lucent.com, > > > effective since 1 November 2009. > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > > > > Behalf Of RFC Errata System > > > > Sent: venerd=EC 12 marzo 2010 17.26 > > > > To: benjamin.niven-jenkins@bt.com; dbrungard@att.com;=20 > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com;=20 > > > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > > > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > > > Cc: mpls@ietf.org; rfc-editor@rfc-editor.org > > > > Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > > > > > The following errata report has been submitted for RFC5654,=20 > > > > "Requirements of an MPLS Transport Profile". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > = http://www.rfc-editor.org/errata_search.php?rfc=3D5654&eid=3D2073 > > > > > > > > -------------------------------------- > > > > Type: Editorial > > > > Reported by: Eric Gray > > > > > > > > Section: 2.5.4 > > > > > > > > Original Text > > > > ------------- > > > > 83 The external controls as defined in [RFC4427] MUST be > > supported. > > > > > > > > A. External controls overruled by higher=20 > priority requests > > > > (e.g., administrative requests and requests due to=20 > > > > link/node > > > > failures) or unable to be signaled to the remote end > > > (e.g., > > > > due to a coordination failure of the=20 > protection state) > > > MUST > > > > be dropped. > > > > > > > > > > > > Corrected Text > > > > -------------- > > > > 83 The external controls as defined in [RFC4427] MUST be > > supported. > > > > > > > > A. External controls overruled by higher=20 > priority requests > > > > (e.g., administrative requests and requests due to=20 > > > > link/node > > > > failures) or unable to be signaled to the remote end > > > (e.g., > > > > due to a coordination failure of the=20 > protection state) > > > MUST > > > > be ignored. > > > > > > > > > > > > Notes > > > > ----- > > > > Dropping a control is meaningless. The original intent=20 > may have=20 > > > > been to say "control messages", but this requirement is=20 > stated in=20 > > > > the section "Management-Plane Operation of Protection and=20 > > > > Restoration" > > > > > > > > In any case, using "ignored" instead of "dropped" fixes the=20 > > > > problem regardless of the original intention. > > > > > > > > Instructions: > > > > ------------- > > > > This errata is currently posted as "Reported". If necessary,=20 > > > > please use "Reply All" to discuss whether it should be=20 > verified or=20 > > > > rejected. When a decision is reached, the verifying=20 > party (IESG)=20 > > > > can log in to change the status and edit the report, if=20 > necessary. > > > > > > > > -------------------------------------- > > > > RFC5654 (draft-ietf-mpls-tp-requirements-10) > > > > -------------------------------------- > > > > Title : Requirements of an MPLS Transport Profile > > > > Publication Date : September 2009 > > > > Author(s) : B. Niven-Jenkins, Ed., D. Brungard, > > > > Ed., M. Betts, Ed., N. Sprecher, S. Ueno > > > > Category : PROPOSED STANDARD > > > > Source : Multiprotocol Label Switching > > > > Area : Routing > > > > Stream : IETF > > > > Verifying Party : IESG > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > 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 > Questo messaggio e i suoi allegati sono indirizzati=20 > esclusivamente alle persone indicate. La diffusione, copia o=20 > qualsiasi altra azione derivante dalla conoscenza di queste=20 > informazioni sono rigorosamente vietate. Qualora abbiate=20 > ricevuto questo documento per errore siete cortesemente=20 > pregati di darne immediata comunicazione al mittente e di=20 > provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may=20 > contain privileged information intended for the addressee(s)=20 > only. Dissemination, copying, printing or use by anybody else=20 > is unauthorised. If you are not the intended recipient,=20 > please delete this message and any attachments and advise the=20 > sender by return e-mail, Thanks. >=20 >=20 From eric.gray@ericsson.com Thu Apr 1 08:46:21 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0D33A6933 for ; Thu, 1 Apr 2010 08:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMWE-LszwtYH for ; Thu, 1 Apr 2010 08:46:20 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 06E3B3A684F for ; Thu, 1 Apr 2010 08:46:19 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o31FoJZ5019011; Thu, 1 Apr 2010 10:50:19 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 1 Apr 2010 11:46:36 -0400 From: Eric Gray To: BUSI ITALO , "D'Alessandro Alessandro Gerardo" , "BRUNGARD, DEBORAH A (ATTLABS)" , "Manuel.Paul@telekom.de" , LEVRAU LIEVEN , "benjamin.niven-jenkins@bt.com" , "rfc-editor@rfc-editor.org" , "malcolm.betts@huawei.com" , "nurit.sprecher@nsn.com" , "satoshi.ueno@ntt.com" , "rcallon@juniper.net" , "adrian.farrel@huawei.com" , "swallow@cisco.com" , "loa@pi.nu" Date: Thu, 1 Apr 2010 11:46:34 -0400 Thread-Topic: [mpls] [Editorial Errata Reported] RFC5654 (2073) Thread-Index: AcrCAkHBrFEh2c5tSYKoFyPNIqhp2wFfAt/QAArSAoMB80oe0AABal5QAAF5gjAAVSjbIAAbZfAgABDJTRAACgKKoAAAsQxQ Message-ID: References: <20100312162629.1F53FE0720@rfc-editor.org>, <6FD21B53861BF44AA90A288402036AB40300EFB5@FRVELSMBS21.ad2.ad.alcatel.com><9C31FA6F6F10D641B0B16A91BC374187B8FACA043D@RDW083V001RVA1.domain1.systemhost.net><40FB0FFB97588246A1BEFB05759DC8A004215DD3@S4DE9JSAANI.ost.t-com.de> <6FD21B53861BF44AA90A288402036AB4030B1928@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4030B1928@FRVELSMBS21.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:46:21 -0000 Discard is fine with me. -----Original Message----- From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.com] Sent: Thursday, April 01, 2010 11:29 AM To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS); Manuel.= Paul@telekom.de; Eric Gray; LEVRAU LIEVEN; benjamin.niven-jenkins@bt.com; r= fc-editor@rfc-editor.org; malcolm.betts@huawei.com; nurit.sprecher@nsn.com;= satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; swall= ow@cisco.com; loa@pi.nu Cc: mpls@ietf.org Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) Importance: High I understand that Deborah has some issues with "reject". Therefore it looks like that we can converge on "discard". Is "discard" acceptable? For me it is fine. Thanks, Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effec= tive since 1 November 2009. > -----Original Message----- > From: D'Alessandro Alessandro Gerardo > [mailto:alessandro.dalessandro@telecomitalia.it] > Sent: gioved=EC 1 aprile 2010 13.03 > To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul@telekom.de; > eric.gray@ericsson.com; LEVRAU LIEVEN; > benjamin.niven-jenkins@bt.com; BUSI ITALO; > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > rcallon@juniper.net; adrian.farrel@huawei.com; > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > I agree with Manuel's comment (some feedback to the operator > shall be considered). > About the correct word to be used, I'm fine with either > "reject" or "discard" clarifying the previous point. > > Regards, > Alessandro > ------------------------------------------------------------------ > Telecom Italia > Alessandro D'Alessandro > Transport & OPB Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of BRUNGARD, DEBORAH A (ATTLABS) > Sent: gioved=EC 1 aprile 2010 5.18 > To: Manuel.Paul@telekom.de; eric.gray@ericsson.com; > lieven.levrau@alcatel-lucent.com; > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > rcallon@juniper.net; adrian.farrel@huawei.com; > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > It depends if you are specifying the data plane or mibs. > Always, if selecting one sentence out of many, it is not > complete (as Eric says). This sentence from RFC5654 was more > from the data plane view using the familiar packet term > "dropped" vs. transport's G.808.1 "discarded". > > I also agree we don't want to load this too much. "Reject" is > not familiar wording. Suggest using then wording from G808.1: > "External commands which are preempted or denied by other > higher priority conditions, states or requests, are discarded." > > I think the choices are: "denied" or "discarded". > > -----Original Message----- > From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] > Sent: Wednesday, March 31, 2010 9:42 AM > To: eric.gray@ericsson.com; lieven.levrau@alcatel-lucent.com; > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; > rfc-editor@rfc-editor.org; BRUNGARD, DEBORAH A (ATTLABS); > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > I also believe that we need to phrase it stronger than just > saying "drop" or "ignore" - to imply that some (whatever) > kind of feedback to the "requester" needs to be considered as well. > Using "reject" makes sense for me. > > Regards, > Manuel > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of Eric Gray > > Sent: Tuesday, March 30, 2010 2:53 PM > > To: LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins@bt.com; > BUSI,ITALO > > (ITALO); rfc-editor@rfc-editor.org; dbrungard@att.com; > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I think that there is some consensus developing both in this > > discussion and elsewhere. There is (of course) some confusion over > > the meaning of certain terms, and the way things might be > specified in > > the IETF - as opposed to elsewhere. > > > > Essentially, a reasonable implementation will not quite > ignore a user > > instruction (users would doubtless resent that rather > severely). It > > is not quite clear what it means to "not quite ignore" instructions > > from the user. The idea is that only the highest-priority input at > > any given instant in time will result in a state-change for > equipment > > (services, or the network). > > > > In my opinion, we don't really want to get bogged down in > terminology > > issues or detailed over-specification - particularly after the fact > > (this is an already published RFC, after all). > > > > The reason why I created this errata in the first place is > that - in > > other work in progress - we feel almost compelled to perpetuate the > > exiting wording even though it is clearly incorrect. > Specifically, in > > the MPLS-TP CP draft, we captured requirements from a > number of drafts > > (unfortunately including this already published RFC). In > the process, > > it came to light that it makes no sense to "drop" a command > > - yet this is what the referenced source document says. > > > > So, either we take some steps to correct the error, or we find our > > selves constrained to perpetuate it. > > > > I think there is some agreement developing around using > "reject" as a > > repalcement for either "drop" or "ignore" - as long as we > can do this > > without creating the ripple-down effect of being compelled > to define > > exactly what we mean by "reject"... > > > > -----Original Message----- > > From: LEVRAU, LIEVEN (LIEVEN) > > [mailto:lieven.levrau@alcatel-lucent.com] > > Sent: Monday, March 29, 2010 4:16 PM > > To: Eric Gray; benjamin.niven-jenkins@bt.com; BUSI, ITALO (ITALO); > > rfc-editor@rfc-editor.org; dbrungard@att.com; > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > Importance: High > > > > Eric to the your point... (snippet) > > > > : > > > > > > "The NE rejects the operator's command and behave like the > > command has > > > never been requested." > > > > > > IMHO, acting as if a command has not been given is > exactly the > > > same thing as ignoring it. > > > > > I think there should be some logic behind it that the request was > > indeed received, parsed and ignored so that it is eventually a > > traceable event. > > ./ > > Lieven > > > > > > -- > > > Eric > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On Behalf Of > > > benjamin.niven-jenkins@bt.com > > > Sent: Friday, March 19, 2010 5:18 PM > > > To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org; > > > dbrungard@att.com; malcolm.betts@huawei.com; > nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > Rejected implies to me that the NE actively informs the > > Operator that > > > the attempt by the Operator to execute the external command was > > > unsuccessful, is this the case? Otherwise how about "MUST NOT be > > > honored"? > > > > > > Ben > > > > > > ________________________________________ > > > From: BUSI ITALO [Italo.Busi@alcatel-lucent.com] > > > Sent: 19 March 2010 16:11 > > > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; > > dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; > > > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; > > > loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > I understand the source of the confusion that the word > "dropped" can > > > create in a packet world. > > > > > > The term "ignored" is not semantically equivalent to the > > intent of the > > > original word "dropped". I would therefore propose the following > > > rephrase: > > > > > > A. External controls overruled by higher > priority requests > > > (e.g., administrative requests and requests due to > > > link/node > > > failures) or unable to be signaled to the > > remote end (e.g., > > > due to a coordination failure of the protection > > state) MUST > > > be rejected. > > > > > > The NE rejects the operator's command and behave like the > > command has > > > never been requested. > > > > > > Italo > > > > > > P.S. Please note my new email address, > > Italo.Busi@alcatel-lucent.com, > > > effective since 1 November 2009. > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > > Behalf Of RFC Errata System > > > > Sent: venerd=EC 12 marzo 2010 17.26 > > > > To: benjamin.niven-jenkins@bt.com; dbrungard@att.com; > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > > > Cc: mpls@ietf.org; rfc-editor@rfc-editor.org > > > > Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > > > > > The following errata report has been submitted for RFC5654, > > > > "Requirements of an MPLS Transport Profile". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D5654&eid=3D2073 > > > > > > > > -------------------------------------- > > > > Type: Editorial > > > > Reported by: Eric Gray > > > > > > > > Section: 2.5.4 > > > > > > > > Original Text > > > > ------------- > > > > 83 The external controls as defined in [RFC4427] MUST be > > supported. > > > > > > > > A. External controls overruled by higher > priority requests > > > > (e.g., administrative requests and requests due to > > > > link/node > > > > failures) or unable to be signaled to the remote end > > > (e.g., > > > > due to a coordination failure of the > protection state) > > > MUST > > > > be dropped. > > > > > > > > > > > > Corrected Text > > > > -------------- > > > > 83 The external controls as defined in [RFC4427] MUST be > > supported. > > > > > > > > A. External controls overruled by higher > priority requests > > > > (e.g., administrative requests and requests due to > > > > link/node > > > > failures) or unable to be signaled to the remote end > > > (e.g., > > > > due to a coordination failure of the > protection state) > > > MUST > > > > be ignored. > > > > > > > > > > > > Notes > > > > ----- > > > > Dropping a control is meaningless. The original intent > may have > > > > been to say "control messages", but this requirement is > stated in > > > > the section "Management-Plane Operation of Protection and > > > > Restoration" > > > > > > > > In any case, using "ignored" instead of "dropped" fixes the > > > > problem regardless of the original intention. > > > > > > > > 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. > > > > > > > > -------------------------------------- > > > > RFC5654 (draft-ietf-mpls-tp-requirements-10) > > > > -------------------------------------- > > > > Title : Requirements of an MPLS Transport Profile > > > > Publication Date : September 2009 > > > > Author(s) : B. Niven-Jenkins, Ed., D. Brungard, > > > > Ed., M. Betts, Ed., N. Sprecher, S. Ueno > > > > Category : PROPOSED STANDARD > > > > Source : Multiprotocol Label Switching > > > > Area : Routing > > > > Stream : IETF > > > > Verifying Party : IESG > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > 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 > > Questo messaggio e i suoi allegati sono indirizzati > esclusivamente alle persone indicate. La diffusione, copia o > qualsiasi altra azione derivante dalla conoscenza di queste > informazioni sono rigorosamente vietate. Qualora abbiate > ricevuto questo documento per errore siete cortesemente > pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may > contain privileged information intended for the addressee(s) > only. Dissemination, copying, printing or use by anybody else > is unauthorised. If you are not the intended recipient, > please delete this message and any attachments and advise the > sender by return e-mail, Thanks. > > From kam.lam@alcatel-lucent.com Thu Apr 1 08:48:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E473A6A25 for ; Thu, 1 Apr 2010 08:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.236 X-Spam-Level: X-Spam-Status: No, score=0.236 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwQTSQWkddKW for ; Thu, 1 Apr 2010 08:48:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B620B3A6B41 for ; Thu, 1 Apr 2010 08:48:06 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o31FmJZq009565; Thu, 1 Apr 2010 10:48:19 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o31FmJ5v019052; Thu, 1 Apr 2010 10:48:19 -0500 (CDT) Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 1 Apr 2010 10:48:19 -0500 From: "Lam, Hing-Kam (Kam)" To: "BUSI, ITALO (ITALO)" , "D'Alessandro Alessandro Gerardo" , "BRUNGARD, DEBORAH A (ATTLABS)" , "Manuel.Paul@telekom.de" , "eric.gray@ericsson.com" , "LEVRAU, LIEVEN (LIEVEN)" , "benjamin.niven-jenkins@bt.com" , "rfc-editor@rfc-editor.org" , "nurit.sprecher@nsn.com" , "satoshi.ueno@ntt.com" , "rcallon@juniper.net" , "adrian.farrel@huawei.com" , "swallow@cisco.com" , "loa@pi.nu" , "Malcolm.BETTS@zte.com.cn" Date: Thu, 1 Apr 2010 10:48:17 -0500 Thread-Topic: [mpls] [Editorial Errata Reported] RFC5654 (2073) Thread-Index: AcrCAkHBrFEh2c5tSYKoFyPNIqhp2wFfAt/QAArSAoMB80oe0AABal5QAAF5gjAAVSjbIAAbZfAgABDJTRAACgKKoAAAMm+A Message-ID: <7F76AEFB05C38145BABA0D545E3CFFD54126C294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <20100312162629.1F53FE0720@rfc-editor.org>, <6FD21B53861BF44AA90A288402036AB40300EFB5@FRVELSMBS21.ad2.ad.alcatel.com><9C31FA6F6F10D641B0B16A91BC374187B8FACA043D@RDW083V001RVA1.domain1.systemhost.net><40FB0FFB97588246A1BEFB05759DC8A004215DD3@S4DE9JSAANI.ost.t-com.de> <6FD21B53861BF44AA90A288402036AB4030B1928@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4030B1928@FRVELSMBS21.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "mpls@ietf.org" Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:48:14 -0000 If there is a choice, I prefer "reject" over "discard". Reason: to me "discard", "drop", and "ignore" are semantically equivalent. = They all imply "silently" drop/ignore/discard and therefore the requestor h= as no idea what is going on. "Reject" or "Denied" imply there is an (negati= ve) acknowledgement. But since "discard" is quoted from G.808.1, I can live with it. :-( Regards, Kam P.S. I have replaced Malcolm's former email address with the latest one. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > BUSI ITALO > Sent: Thursday, April 01, 2010 11:29 AM > To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS); > Manuel.Paul@telekom.de; eric.gray@ericsson.com; LEVRAU, LIEVEN (LIEVEN); > benjamin.niven-jenkins@bt.com; rfc-editor@rfc-editor.org; > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; > loa@pi.nu > Cc: mpls@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > I understand that Deborah has some issues with "reject". > > Therefore it looks like that we can converge on "discard". > > Is "discard" acceptable? > > For me it is fine. > > Thanks, Italo > > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, > effective since 1 November 2009. > > > > -----Original Message----- > > From: D'Alessandro Alessandro Gerardo > > [mailto:alessandro.dalessandro@telecomitalia.it] > > Sent: gioved=EC 1 aprile 2010 13.03 > > To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul@telekom.de; > > eric.gray@ericsson.com; LEVRAU LIEVEN; > > benjamin.niven-jenkins@bt.com; BUSI ITALO; > > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; > > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > > rcallon@juniper.net; adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I agree with Manuel's comment (some feedback to the operator > > shall be considered). > > About the correct word to be used, I'm fine with either > > "reject" or "discard" clarifying the previous point. > > > > Regards, > > Alessandro > > ------------------------------------------------------------------ > > Telecom Italia > > Alessandro D'Alessandro > > Transport & OPB Innovation > > Via Reiss Romoli, 274 - 10148 Torino > > phone: +39 011 228 5887 > > mobile: +39 335 766 9607 > > fax: +39 06 418 639 07 > > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf Of BRUNGARD, DEBORAH A (ATTLABS) > > Sent: gioved=EC 1 aprile 2010 5.18 > > To: Manuel.Paul@telekom.de; eric.gray@ericsson.com; > > lieven.levrau@alcatel-lucent.com; > > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; > > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; > > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > > rcallon@juniper.net; adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > It depends if you are specifying the data plane or mibs. > > Always, if selecting one sentence out of many, it is not > > complete (as Eric says). This sentence from RFC5654 was more > > from the data plane view using the familiar packet term > > "dropped" vs. transport's G.808.1 "discarded". > > > > I also agree we don't want to load this too much. "Reject" is > > not familiar wording. Suggest using then wording from G808.1: > > "External commands which are preempted or denied by other > > higher priority conditions, states or requests, are discarded." > > > > I think the choices are: "denied" or "discarded". > > > > -----Original Message----- > > From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] > > Sent: Wednesday, March 31, 2010 9:42 AM > > To: eric.gray@ericsson.com; lieven.levrau@alcatel-lucent.com; > > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; > > rfc-editor@rfc-editor.org; BRUNGARD, DEBORAH A (ATTLABS); > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I also believe that we need to phrase it stronger than just > > saying "drop" or "ignore" - to imply that some (whatever) > > kind of feedback to the "requester" needs to be considered as well. > > Using "reject" makes sense for me. > > > > Regards, > > Manuel > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On Behalf > > > Of Eric Gray > > > Sent: Tuesday, March 30, 2010 2:53 PM > > > To: LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins@bt.com; > > BUSI,ITALO > > > (ITALO); rfc-editor@rfc-editor.org; dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > adrian.farrel@huawei.com; > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > I think that there is some consensus developing both in this > > > discussion and elsewhere. There is (of course) some confusion over > > > the meaning of certain terms, and the way things might be > > specified in > > > the IETF - as opposed to elsewhere. > > > > > > Essentially, a reasonable implementation will not quite > > ignore a user > > > instruction (users would doubtless resent that rather > > severely). It > > > is not quite clear what it means to "not quite ignore" instructions > > > from the user. The idea is that only the highest-priority input at > > > any given instant in time will result in a state-change for > > equipment > > > (services, or the network). > > > > > > In my opinion, we don't really want to get bogged down in > > terminology > > > issues or detailed over-specification - particularly after the fact > > > (this is an already published RFC, after all). > > > > > > The reason why I created this errata in the first place is > > that - in > > > other work in progress - we feel almost compelled to perpetuate the > > > exiting wording even though it is clearly incorrect. > > Specifically, in > > > the MPLS-TP CP draft, we captured requirements from a > > number of drafts > > > (unfortunately including this already published RFC). In > > the process, > > > it came to light that it makes no sense to "drop" a command > > > - yet this is what the referenced source document says. > > > > > > So, either we take some steps to correct the error, or we find our > > > selves constrained to perpetuate it. > > > > > > I think there is some agreement developing around using > > "reject" as a > > > repalcement for either "drop" or "ignore" - as long as we > > can do this > > > without creating the ripple-down effect of being compelled > > to define > > > exactly what we mean by "reject"... > > > > > > -----Original Message----- > > > From: LEVRAU, LIEVEN (LIEVEN) > > > [mailto:lieven.levrau@alcatel-lucent.com] > > > Sent: Monday, March 29, 2010 4:16 PM > > > To: Eric Gray; benjamin.niven-jenkins@bt.com; BUSI, ITALO (ITALO); > > > rfc-editor@rfc-editor.org; dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > adrian.farrel@huawei.com; > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > Importance: High > > > > > > Eric to the your point... (snippet) > > > > > > : > > > > > > > > "The NE rejects the operator's command and behave like the > > > command has > > > > never been requested." > > > > > > > > IMHO, acting as if a command has not been given is > > exactly the > > > > same thing as ignoring it. > > > > > > > I think there should be some logic behind it that the request was > > > indeed received, parsed and ignored so that it is eventually a > > > traceable event. > > > ./ > > > Lieven > > > > > > > > -- > > > > Eric > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > > On Behalf Of > > > > benjamin.niven-jenkins@bt.com > > > > Sent: Friday, March 19, 2010 5:18 PM > > > > To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org; > > > > dbrungard@att.com; malcolm.betts@huawei.com; > > nurit.sprecher@nsn.com; > > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > adrian.farrel@huawei.com; > > > > swallow@cisco.com; loa@pi.nu > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > Rejected implies to me that the NE actively informs the > > > Operator that > > > > the attempt by the Operator to execute the external command was > > > > unsuccessful, is this the case? Otherwise how about "MUST NOT be > > > > honored"? > > > > > > > > Ben > > > > > > > > ________________________________________ > > > > From: BUSI ITALO [Italo.Busi@alcatel-lucent.com] > > > > Sent: 19 March 2010 16:11 > > > > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; > > > dbrungard@att.com; > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; > > > > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; > > > > loa@pi.nu > > > > Cc: mpls@ietf.org > > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > I understand the source of the confusion that the word > > "dropped" can > > > > create in a packet world. > > > > > > > > The term "ignored" is not semantically equivalent to the > > > intent of the > > > > original word "dropped". I would therefore propose the following > > > > rephrase: > > > > > > > > A. External controls overruled by higher > > priority requests > > > > (e.g., administrative requests and requests due to > > > > link/node > > > > failures) or unable to be signaled to the > > > remote end (e.g., > > > > due to a coordination failure of the protection > > > state) MUST > > > > be rejected. > > > > > > > > The NE rejects the operator's command and behave like the > > > command has > > > > never been requested. > > > > > > > > Italo > > > > > > > > P.S. Please note my new email address, > > > Italo.Busi@alcatel-lucent.com, > > > > effective since 1 November 2009. > > > > > > > > > > > > > -----Original Message----- > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > > > Behalf Of RFC Errata System > > > > > Sent: venerd=EC 12 marzo 2010 17.26 > > > > > To: benjamin.niven-jenkins@bt.com; dbrungard@att.com; > > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > > > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > > > > Cc: mpls@ietf.org; rfc-editor@rfc-editor.org > > > > > Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > > > > > > > > The following errata report has been submitted for RFC5654, > > > > > "Requirements of an MPLS Transport Profile". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D5654&eid=3D2073 > > > > > > > > > > -------------------------------------- > > > > > Type: Editorial > > > > > Reported by: Eric Gray > > > > > > > > > > Section: 2.5.4 > > > > > > > > > > Original Text > > > > > ------------- > > > > > 83 The external controls as defined in [RFC4427] MUST be > > > supported. > > > > > > > > > > A. External controls overruled by higher > > priority requests > > > > > (e.g., administrative requests and requests due to > > > > > link/node > > > > > failures) or unable to be signaled to the remote end > > > > (e.g., > > > > > due to a coordination failure of the > > protection state) > > > > MUST > > > > > be dropped. > > > > > > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > 83 The external controls as defined in [RFC4427] MUST be > > > supported. > > > > > > > > > > A. External controls overruled by higher > > priority requests > > > > > (e.g., administrative requests and requests due to > > > > > link/node > > > > > failures) or unable to be signaled to the remote end > > > > (e.g., > > > > > due to a coordination failure of the > > protection state) > > > > MUST > > > > > be ignored. > > > > > > > > > > > > > > > Notes > > > > > ----- > > > > > Dropping a control is meaningless. The original intent > > may have > > > > > been to say "control messages", but this requirement is > > stated in > > > > > the section "Management-Plane Operation of Protection and > > > > > Restoration" > > > > > > > > > > In any case, using "ignored" instead of "dropped" fixes the > > > > > problem regardless of the original intention. > > > > > > > > > > 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. > > > > > > > > > > -------------------------------------- > > > > > RFC5654 (draft-ietf-mpls-tp-requirements-10) > > > > > -------------------------------------- > > > > > Title : Requirements of an MPLS Transport Profile > > > > > Publication Date : September 2009 > > > > > Author(s) : B. Niven-Jenkins, Ed., D. Brungard, > > > > > Ed., M. Betts, Ed., N. Sprecher, S. Ueno > > > > > Category : PROPOSED STANDARD > > > > > Source : Multiprotocol Label Switching > > > > > Area : Routing > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > 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 > > > > Questo messaggio e i suoi allegati sono indirizzati > > esclusivamente alle persone indicate. La diffusione, copia o > > qualsiasi altra azione derivante dalla conoscenza di queste > > informazioni sono rigorosamente vietate. Qualora abbiate > > ricevuto questo documento per errore siete cortesemente > > pregati di darne immediata comunicazione al mittente e di > > provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may > > contain privileged information intended for the addressee(s) > > only. Dissemination, copying, printing or use by anybody else > > is unauthorised. If you are not the intended recipient, > > please delete this message and any attachments and advise the > > sender by return e-mail, Thanks. > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From alessandro.dalessandro@telecomitalia.it Thu Apr 1 08:48:46 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69F03A6B4B for ; Thu, 1 Apr 2010 08:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.18 X-Spam-Level: ** X-Spam-Status: No, score=2.18 tagged_above=-999 required=5 tests=[AWL=1.169, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHiXPP6saWpd for ; Thu, 1 Apr 2010 08:48:45 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by core3.amsl.com (Postfix) with ESMTP id 7F97F3A6A92 for ; Thu, 1 Apr 2010 08:48:41 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 1 Apr 2010 17:49:12 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub702rm001.griffon.local ([10.19.9.235]) with mapi; Thu, 1 Apr 2010 17:49:11 +0200 From: D'Alessandro Alessandro Gerardo To: Eric Gray , BUSI ITALO , "BRUNGARD, DEBORAH A (ATTLABS)" , "Manuel.Paul@telekom.de" , "LEVRAU LIEVEN" , "benjamin.niven-jenkins@bt.com" , "rfc-editor@rfc-editor.org" , "malcolm.betts@huawei.com" , "nurit.sprecher@nsn.com" , "satoshi.ueno@ntt.com" , "rcallon@juniper.net" , "adrian.farrel@huawei.com" , "swallow@cisco.com" , "loa@pi.nu" Date: Thu, 1 Apr 2010 17:49:09 +0200 Thread-Topic: [mpls] [Editorial Errata Reported] RFC5654 (2073) Thread-Index: AcrCAkHBrFEh2c5tSYKoFyPNIqhp2wFfAt/QAArSAoMB80oe0AABal5QAAF5gjAAVSjbIAAbZfAgABDJTRAACgKKoAAAsQxQAAAXVLA= Message-ID: References: <20100312162629.1F53FE0720@rfc-editor.org>, <6FD21B53861BF44AA90A288402036AB40300EFB5@FRVELSMBS21.ad2.ad.alcatel.com><9C31FA6F6F10D641B0B16A91BC374187B8FACA043D@RDW083V001RVA1.domain1.systemhost.net><40FB0FFB97588246A1BEFB05759DC8A004215DD3@S4DE9JSAANI.ost.t-com.de> <6FD21B53861BF44AA90A288402036AB4030B1928@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:48:46 -0000 For me too. ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport & OPB Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Original Message----- From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: gioved=EC 1 aprile 2010 17.47 To: BUSI ITALO; D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLA= BS); Manuel.Paul@telekom.de; LEVRAU LIEVEN; benjamin.niven-jenkins@bt.com; = rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; nurit.sprecher@nsn.com= ; satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; swal= low@cisco.com; loa@pi.nu Cc: mpls@ietf.org Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) Discard is fine with me. -----Original Message----- From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.com] Sent: Thursday, April 01, 2010 11:29 AM To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS); Manuel.= Paul@telekom.de; Eric Gray; LEVRAU LIEVEN; benjamin.niven-jenkins@bt.com; r= fc-editor@rfc-editor.org; malcolm.betts@huawei.com; nurit.sprecher@nsn.com;= satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; swall= ow@cisco.com; loa@pi.nu Cc: mpls@ietf.org Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) Importance: High I understand that Deborah has some issues with "reject". Therefore it looks like that we can converge on "discard". Is "discard" acceptable? For me it is fine. Thanks, Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effec= tive since 1 November 2009. > -----Original Message----- > From: D'Alessandro Alessandro Gerardo > [mailto:alessandro.dalessandro@telecomitalia.it] > Sent: gioved=EC 1 aprile 2010 13.03 > To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul@telekom.de; > eric.gray@ericsson.com; LEVRAU LIEVEN; > benjamin.niven-jenkins@bt.com; BUSI ITALO; > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > rcallon@juniper.net; adrian.farrel@huawei.com; > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > I agree with Manuel's comment (some feedback to the operator > shall be considered). > About the correct word to be used, I'm fine with either > "reject" or "discard" clarifying the previous point. > > Regards, > Alessandro > ------------------------------------------------------------------ > Telecom Italia > Alessandro D'Alessandro > Transport & OPB Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of BRUNGARD, DEBORAH A (ATTLABS) > Sent: gioved=EC 1 aprile 2010 5.18 > To: Manuel.Paul@telekom.de; eric.gray@ericsson.com; > lieven.levrau@alcatel-lucent.com; > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > rcallon@juniper.net; adrian.farrel@huawei.com; > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > It depends if you are specifying the data plane or mibs. > Always, if selecting one sentence out of many, it is not > complete (as Eric says). This sentence from RFC5654 was more > from the data plane view using the familiar packet term > "dropped" vs. transport's G.808.1 "discarded". > > I also agree we don't want to load this too much. "Reject" is > not familiar wording. Suggest using then wording from G808.1: > "External commands which are preempted or denied by other > higher priority conditions, states or requests, are discarded." > > I think the choices are: "denied" or "discarded". > > -----Original Message----- > From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] > Sent: Wednesday, March 31, 2010 9:42 AM > To: eric.gray@ericsson.com; lieven.levrau@alcatel-lucent.com; > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; > rfc-editor@rfc-editor.org; BRUNGARD, DEBORAH A (ATTLABS); > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > I also believe that we need to phrase it stronger than just > saying "drop" or "ignore" - to imply that some (whatever) > kind of feedback to the "requester" needs to be considered as well. > Using "reject" makes sense for me. > > Regards, > Manuel > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of Eric Gray > > Sent: Tuesday, March 30, 2010 2:53 PM > > To: LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins@bt.com; > BUSI,ITALO > > (ITALO); rfc-editor@rfc-editor.org; dbrungard@att.com; > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I think that there is some consensus developing both in this > > discussion and elsewhere. There is (of course) some confusion over > > the meaning of certain terms, and the way things might be > specified in > > the IETF - as opposed to elsewhere. > > > > Essentially, a reasonable implementation will not quite > ignore a user > > instruction (users would doubtless resent that rather > severely). It > > is not quite clear what it means to "not quite ignore" instructions > > from the user. The idea is that only the highest-priority input at > > any given instant in time will result in a state-change for > equipment > > (services, or the network). > > > > In my opinion, we don't really want to get bogged down in > terminology > > issues or detailed over-specification - particularly after the fact > > (this is an already published RFC, after all). > > > > The reason why I created this errata in the first place is > that - in > > other work in progress - we feel almost compelled to perpetuate the > > exiting wording even though it is clearly incorrect. > Specifically, in > > the MPLS-TP CP draft, we captured requirements from a > number of drafts > > (unfortunately including this already published RFC). In > the process, > > it came to light that it makes no sense to "drop" a command > > - yet this is what the referenced source document says. > > > > So, either we take some steps to correct the error, or we find our > > selves constrained to perpetuate it. > > > > I think there is some agreement developing around using > "reject" as a > > repalcement for either "drop" or "ignore" - as long as we > can do this > > without creating the ripple-down effect of being compelled > to define > > exactly what we mean by "reject"... > > > > -----Original Message----- > > From: LEVRAU, LIEVEN (LIEVEN) > > [mailto:lieven.levrau@alcatel-lucent.com] > > Sent: Monday, March 29, 2010 4:16 PM > > To: Eric Gray; benjamin.niven-jenkins@bt.com; BUSI, ITALO (ITALO); > > rfc-editor@rfc-editor.org; dbrungard@att.com; > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > Importance: High > > > > Eric to the your point... (snippet) > > > > : > > > > > > "The NE rejects the operator's command and behave like the > > command has > > > never been requested." > > > > > > IMHO, acting as if a command has not been given is > exactly the > > > same thing as ignoring it. > > > > > I think there should be some logic behind it that the request was > > indeed received, parsed and ignored so that it is eventually a > > traceable event. > > ./ > > Lieven > > > > > > -- > > > Eric > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On Behalf Of > > > benjamin.niven-jenkins@bt.com > > > Sent: Friday, March 19, 2010 5:18 PM > > > To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org; > > > dbrungard@att.com; malcolm.betts@huawei.com; > nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > Rejected implies to me that the NE actively informs the > > Operator that > > > the attempt by the Operator to execute the external command was > > > unsuccessful, is this the case? Otherwise how about "MUST NOT be > > > honored"? > > > > > > Ben > > > > > > ________________________________________ > > > From: BUSI ITALO [Italo.Busi@alcatel-lucent.com] > > > Sent: 19 March 2010 16:11 > > > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; > > dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; > > > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; > > > loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > I understand the source of the confusion that the word > "dropped" can > > > create in a packet world. > > > > > > The term "ignored" is not semantically equivalent to the > > intent of the > > > original word "dropped". I would therefore propose the following > > > rephrase: > > > > > > A. External controls overruled by higher > priority requests > > > (e.g., administrative requests and requests due to > > > link/node > > > failures) or unable to be signaled to the > > remote end (e.g., > > > due to a coordination failure of the protection > > state) MUST > > > be rejected. > > > > > > The NE rejects the operator's command and behave like the > > command has > > > never been requested. > > > > > > Italo > > > > > > P.S. Please note my new email address, > > Italo.Busi@alcatel-lucent.com, > > > effective since 1 November 2009. > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > > Behalf Of RFC Errata System > > > > Sent: venerd=EC 12 marzo 2010 17.26 > > > > To: benjamin.niven-jenkins@bt.com; dbrungard@att.com; > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > > > Cc: mpls@ietf.org; rfc-editor@rfc-editor.org > > > > Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > > > > > The following errata report has been submitted for RFC5654, > > > > "Requirements of an MPLS Transport Profile". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D5654&eid=3D2073 > > > > > > > > -------------------------------------- > > > > Type: Editorial > > > > Reported by: Eric Gray > > > > > > > > Section: 2.5.4 > > > > > > > > Original Text > > > > ------------- > > > > 83 The external controls as defined in [RFC4427] MUST be > > supported. > > > > > > > > A. External controls overruled by higher > priority requests > > > > (e.g., administrative requests and requests due to > > > > link/node > > > > failures) or unable to be signaled to the remote end > > > (e.g., > > > > due to a coordination failure of the > protection state) > > > MUST > > > > be dropped. > > > > > > > > > > > > Corrected Text > > > > -------------- > > > > 83 The external controls as defined in [RFC4427] MUST be > > supported. > > > > > > > > A. External controls overruled by higher > priority requests > > > > (e.g., administrative requests and requests due to > > > > link/node > > > > failures) or unable to be signaled to the remote end > > > (e.g., > > > > due to a coordination failure of the > protection state) > > > MUST > > > > be ignored. > > > > > > > > > > > > Notes > > > > ----- > > > > Dropping a control is meaningless. The original intent > may have > > > > been to say "control messages", but this requirement is > stated in > > > > the section "Management-Plane Operation of Protection and > > > > Restoration" > > > > > > > > In any case, using "ignored" instead of "dropped" fixes the > > > > problem regardless of the original intention. > > > > > > > > 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. > > > > > > > > -------------------------------------- > > > > RFC5654 (draft-ietf-mpls-tp-requirements-10) > > > > -------------------------------------- > > > > Title : Requirements of an MPLS Transport Profile > > > > Publication Date : September 2009 > > > > Author(s) : B. Niven-Jenkins, Ed., D. Brungard, > > > > Ed., M. Betts, Ed., N. Sprecher, S. Ueno > > > > Category : PROPOSED STANDARD > > > > Source : Multiprotocol Label Switching > > > > Area : Routing > > > > Stream : IETF > > > > Verifying Party : IESG > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > 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 > > Questo messaggio e i suoi allegati sono indirizzati > esclusivamente alle persone indicate. La diffusione, copia o > qualsiasi altra azione derivante dalla conoscenza di queste > informazioni sono rigorosamente vietate. Qualora abbiate > ricevuto questo documento per errore siete cortesemente > pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may > contain privileged information intended for the addressee(s) > only. Dissemination, copying, printing or use by anybody else > is unauthorised. If you are not the intended recipient, > please delete this message and any attachments and advise the > sender by return e-mail, Thanks. > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From eric.gray@ericsson.com Thu Apr 1 09:02:10 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0063A6933 for ; Thu, 1 Apr 2010 09:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m5CS36WqQis for ; Thu, 1 Apr 2010 09:02:09 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 081613A6B3A for ; Thu, 1 Apr 2010 09:00:37 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o31G4g5l023823; Thu, 1 Apr 2010 11:04:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 1 Apr 2010 12:00:56 -0400 From: Eric Gray To: "Lam, Hing-Kam (Kam)" , "BUSI, ITALO (ITALO)" , "D'Alessandro Alessandro Gerardo" , "BRUNGARD, DEBORAH A (ATTLABS)" , "Manuel.Paul@telekom.de" , "LEVRAU, LIEVEN (LIEVEN)" , "benjamin.niven-jenkins@bt.com" , "rfc-editor@rfc-editor.org" , "nurit.sprecher@nsn.com" , "satoshi.ueno@ntt.com" , "rcallon@juniper.net" , "adrian.farrel@huawei.com" , "swallow@cisco.com" , "loa@pi.nu" , "Malcolm.BETTS@zte.com.cn" Date: Thu, 1 Apr 2010 12:00:55 -0400 Thread-Topic: [mpls] [Editorial Errata Reported] RFC5654 (2073) Thread-Index: AcrCAkHBrFEh2c5tSYKoFyPNIqhp2wFfAt/QAArSAoMB80oe0AABal5QAAF5gjAAVSjbIAAbZfAgABDJTRAACgKKoAAAMm+AAACh7nA= Message-ID: References: <20100312162629.1F53FE0720@rfc-editor.org>, <6FD21B53861BF44AA90A288402036AB40300EFB5@FRVELSMBS21.ad2.ad.alcatel.com><9C31FA6F6F10D641B0B16A91BC374187B8FACA043D@RDW083V001RVA1.domain1.systemhost.net><40FB0FFB97588246A1BEFB05759DC8A004215DD3@S4DE9JSAANI.ost.t-com.de> <6FD21B53861BF44AA90A288402036AB4030B1928@FRVELSMBS21.ad2.ad.alcatel.com> <7F76AEFB05C38145BABA0D545E3CFFD54126C294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <7F76AEFB05C38145BABA0D545E3CFFD54126C294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:02:11 -0000 Kam, See my reply to Alessandro on this subject. -- Eric -----Original Message----- From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com] Sent: Thursday, April 01, 2010 11:48 AM To: BUSI, ITALO (ITALO); D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH= A (ATTLABS); Manuel.Paul@telekom.de; Eric Gray; LEVRAU, LIEVEN (LIEVEN); b= enjamin.niven-jenkins@bt.com; rfc-editor@rfc-editor.org; nurit.sprecher@nsn= .com; satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; = swallow@cisco.com; loa@pi.nu; Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) Importance: High If there is a choice, I prefer "reject" over "discard". Reason: to me "discard", "drop", and "ignore" are semantically equivalent. = They all imply "silently" drop/ignore/discard and therefore the requestor h= as no idea what is going on. "Reject" or "Denied" imply there is an (negati= ve) acknowledgement. But since "discard" is quoted from G.808.1, I can live with it. :-( Regards, Kam P.S. I have replaced Malcolm's former email address with the latest one. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > BUSI ITALO > Sent: Thursday, April 01, 2010 11:29 AM > To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS); > Manuel.Paul@telekom.de; eric.gray@ericsson.com; LEVRAU, LIEVEN (LIEVEN); > benjamin.niven-jenkins@bt.com; rfc-editor@rfc-editor.org; > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; > loa@pi.nu > Cc: mpls@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > I understand that Deborah has some issues with "reject". > > Therefore it looks like that we can converge on "discard". > > Is "discard" acceptable? > > For me it is fine. > > Thanks, Italo > > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, > effective since 1 November 2009. > > > > -----Original Message----- > > From: D'Alessandro Alessandro Gerardo > > [mailto:alessandro.dalessandro@telecomitalia.it] > > Sent: gioved=EC 1 aprile 2010 13.03 > > To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul@telekom.de; > > eric.gray@ericsson.com; LEVRAU LIEVEN; > > benjamin.niven-jenkins@bt.com; BUSI ITALO; > > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; > > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > > rcallon@juniper.net; adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I agree with Manuel's comment (some feedback to the operator > > shall be considered). > > About the correct word to be used, I'm fine with either > > "reject" or "discard" clarifying the previous point. > > > > Regards, > > Alessandro > > ------------------------------------------------------------------ > > Telecom Italia > > Alessandro D'Alessandro > > Transport & OPB Innovation > > Via Reiss Romoli, 274 - 10148 Torino > > phone: +39 011 228 5887 > > mobile: +39 335 766 9607 > > fax: +39 06 418 639 07 > > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf Of BRUNGARD, DEBORAH A (ATTLABS) > > Sent: gioved=EC 1 aprile 2010 5.18 > > To: Manuel.Paul@telekom.de; eric.gray@ericsson.com; > > lieven.levrau@alcatel-lucent.com; > > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; > > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; > > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > > rcallon@juniper.net; adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > It depends if you are specifying the data plane or mibs. > > Always, if selecting one sentence out of many, it is not > > complete (as Eric says). This sentence from RFC5654 was more > > from the data plane view using the familiar packet term > > "dropped" vs. transport's G.808.1 "discarded". > > > > I also agree we don't want to load this too much. "Reject" is > > not familiar wording. Suggest using then wording from G808.1: > > "External commands which are preempted or denied by other > > higher priority conditions, states or requests, are discarded." > > > > I think the choices are: "denied" or "discarded". > > > > -----Original Message----- > > From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] > > Sent: Wednesday, March 31, 2010 9:42 AM > > To: eric.gray@ericsson.com; lieven.levrau@alcatel-lucent.com; > > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; > > rfc-editor@rfc-editor.org; BRUNGARD, DEBORAH A (ATTLABS); > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I also believe that we need to phrase it stronger than just > > saying "drop" or "ignore" - to imply that some (whatever) > > kind of feedback to the "requester" needs to be considered as well. > > Using "reject" makes sense for me. > > > > Regards, > > Manuel > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On Behalf > > > Of Eric Gray > > > Sent: Tuesday, March 30, 2010 2:53 PM > > > To: LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins@bt.com; > > BUSI,ITALO > > > (ITALO); rfc-editor@rfc-editor.org; dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > adrian.farrel@huawei.com; > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > I think that there is some consensus developing both in this > > > discussion and elsewhere. There is (of course) some confusion over > > > the meaning of certain terms, and the way things might be > > specified in > > > the IETF - as opposed to elsewhere. > > > > > > Essentially, a reasonable implementation will not quite > > ignore a user > > > instruction (users would doubtless resent that rather > > severely). It > > > is not quite clear what it means to "not quite ignore" instructions > > > from the user. The idea is that only the highest-priority input at > > > any given instant in time will result in a state-change for > > equipment > > > (services, or the network). > > > > > > In my opinion, we don't really want to get bogged down in > > terminology > > > issues or detailed over-specification - particularly after the fact > > > (this is an already published RFC, after all). > > > > > > The reason why I created this errata in the first place is > > that - in > > > other work in progress - we feel almost compelled to perpetuate the > > > exiting wording even though it is clearly incorrect. > > Specifically, in > > > the MPLS-TP CP draft, we captured requirements from a > > number of drafts > > > (unfortunately including this already published RFC). In > > the process, > > > it came to light that it makes no sense to "drop" a command > > > - yet this is what the referenced source document says. > > > > > > So, either we take some steps to correct the error, or we find our > > > selves constrained to perpetuate it. > > > > > > I think there is some agreement developing around using > > "reject" as a > > > repalcement for either "drop" or "ignore" - as long as we > > can do this > > > without creating the ripple-down effect of being compelled > > to define > > > exactly what we mean by "reject"... > > > > > > -----Original Message----- > > > From: LEVRAU, LIEVEN (LIEVEN) > > > [mailto:lieven.levrau@alcatel-lucent.com] > > > Sent: Monday, March 29, 2010 4:16 PM > > > To: Eric Gray; benjamin.niven-jenkins@bt.com; BUSI, ITALO (ITALO); > > > rfc-editor@rfc-editor.org; dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > adrian.farrel@huawei.com; > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > Importance: High > > > > > > Eric to the your point... (snippet) > > > > > > : > > > > > > > > "The NE rejects the operator's command and behave like the > > > command has > > > > never been requested." > > > > > > > > IMHO, acting as if a command has not been given is > > exactly the > > > > same thing as ignoring it. > > > > > > > I think there should be some logic behind it that the request was > > > indeed received, parsed and ignored so that it is eventually a > > > traceable event. > > > ./ > > > Lieven > > > > > > > > -- > > > > Eric > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > > On Behalf Of > > > > benjamin.niven-jenkins@bt.com > > > > Sent: Friday, March 19, 2010 5:18 PM > > > > To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org; > > > > dbrungard@att.com; malcolm.betts@huawei.com; > > nurit.sprecher@nsn.com; > > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > adrian.farrel@huawei.com; > > > > swallow@cisco.com; loa@pi.nu > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > Rejected implies to me that the NE actively informs the > > > Operator that > > > > the attempt by the Operator to execute the external command was > > > > unsuccessful, is this the case? Otherwise how about "MUST NOT be > > > > honored"? > > > > > > > > Ben > > > > > > > > ________________________________________ > > > > From: BUSI ITALO [Italo.Busi@alcatel-lucent.com] > > > > Sent: 19 March 2010 16:11 > > > > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; > > > dbrungard@att.com; > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; > > > > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; > > > > loa@pi.nu > > > > Cc: mpls@ietf.org > > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > I understand the source of the confusion that the word > > "dropped" can > > > > create in a packet world. > > > > > > > > The term "ignored" is not semantically equivalent to the > > > intent of the > > > > original word "dropped". I would therefore propose the following > > > > rephrase: > > > > > > > > A. External controls overruled by higher > > priority requests > > > > (e.g., administrative requests and requests due to > > > > link/node > > > > failures) or unable to be signaled to the > > > remote end (e.g., > > > > due to a coordination failure of the protection > > > state) MUST > > > > be rejected. > > > > > > > > The NE rejects the operator's command and behave like the > > > command has > > > > never been requested. > > > > > > > > Italo > > > > > > > > P.S. Please note my new email address, > > > Italo.Busi@alcatel-lucent.com, > > > > effective since 1 November 2009. > > > > > > > > > > > > > -----Original Message----- > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > > > Behalf Of RFC Errata System > > > > > Sent: venerd=EC 12 marzo 2010 17.26 > > > > > To: benjamin.niven-jenkins@bt.com; dbrungard@att.com; > > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > > > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > > > > Cc: mpls@ietf.org; rfc-editor@rfc-editor.org > > > > > Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > > > > > > > > The following errata report has been submitted for RFC5654, > > > > > "Requirements of an MPLS Transport Profile". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D5654&eid=3D2073 > > > > > > > > > > -------------------------------------- > > > > > Type: Editorial > > > > > Reported by: Eric Gray > > > > > > > > > > Section: 2.5.4 > > > > > > > > > > Original Text > > > > > ------------- > > > > > 83 The external controls as defined in [RFC4427] MUST be > > > supported. > > > > > > > > > > A. External controls overruled by higher > > priority requests > > > > > (e.g., administrative requests and requests due to > > > > > link/node > > > > > failures) or unable to be signaled to the remote end > > > > (e.g., > > > > > due to a coordination failure of the > > protection state) > > > > MUST > > > > > be dropped. > > > > > > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > 83 The external controls as defined in [RFC4427] MUST be > > > supported. > > > > > > > > > > A. External controls overruled by higher > > priority requests > > > > > (e.g., administrative requests and requests due to > > > > > link/node > > > > > failures) or unable to be signaled to the remote end > > > > (e.g., > > > > > due to a coordination failure of the > > protection state) > > > > MUST > > > > > be ignored. > > > > > > > > > > > > > > > Notes > > > > > ----- > > > > > Dropping a control is meaningless. The original intent > > may have > > > > > been to say "control messages", but this requirement is > > stated in > > > > > the section "Management-Plane Operation of Protection and > > > > > Restoration" > > > > > > > > > > In any case, using "ignored" instead of "dropped" fixes the > > > > > problem regardless of the original intention. > > > > > > > > > > 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. > > > > > > > > > > -------------------------------------- > > > > > RFC5654 (draft-ietf-mpls-tp-requirements-10) > > > > > -------------------------------------- > > > > > Title : Requirements of an MPLS Transport Profile > > > > > Publication Date : September 2009 > > > > > Author(s) : B. Niven-Jenkins, Ed., D. Brungard, > > > > > Ed., M. Betts, Ed., N. Sprecher, S. Ueno > > > > > Category : PROPOSED STANDARD > > > > > Source : Multiprotocol Label Switching > > > > > Area : Routing > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > 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 > > > > Questo messaggio e i suoi allegati sono indirizzati > > esclusivamente alle persone indicate. La diffusione, copia o > > qualsiasi altra azione derivante dalla conoscenza di queste > > informazioni sono rigorosamente vietate. Qualora abbiate > > ricevuto questo documento per errore siete cortesemente > > pregati di darne immediata comunicazione al mittente e di > > provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may > > contain privileged information intended for the addressee(s) > > only. Dissemination, copying, printing or use by anybody else > > is unauthorised. If you are not the intended recipient, > > please delete this message and any attachments and advise the > > sender by return e-mail, Thanks. > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Thu Apr 1 09:02:27 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1043A6987 for ; Thu, 1 Apr 2010 09:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.789 X-Spam-Level: X-Spam-Status: No, score=-4.789 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggsptpm-uAJP for ; Thu, 1 Apr 2010 09:02:25 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 942433A6853 for ; Thu, 1 Apr 2010 09:00:53 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o31G4XpT023868; Thu, 1 Apr 2010 11:04:35 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 1 Apr 2010 12:00:52 -0400 From: Eric Gray To: "D'Alessandro Alessandro Gerardo" , "BRUNGARD, DEBORAH A (ATTLABS)" , "Manuel.Paul@telekom.de" , "lieven.levrau@alcatel-lucent.com" , "benjamin.niven-jenkins@bt.com" , "italo.busi@alcatel-lucent.com" , "rfc-editor@rfc-editor.org" , "malcolm.betts@huawei.com" , "nurit.sprecher@nsn.com" , "satoshi.ueno@ntt.com" , "rcallon@juniper.net" , "adrian.farrel@huawei.com" , "swallow@cisco.com" , "loa@pi.nu" Date: Thu, 1 Apr 2010 12:00:50 -0400 Thread-Topic: [mpls] [Editorial Errata Reported] RFC5654 (2073) Thread-Index: AcrCAkHBrFEh2c5tSYKoFyPNIqhp2wFfAt/QAArSAoMB80oe0AABal5QAAF5gjAAVSjbIAAbZfAgABDJTRAACrdSgA== Message-ID: References: <20100312162629.1F53FE0720@rfc-editor.org>, <6FD21B53861BF44AA90A288402036AB40300EFB5@FRVELSMBS21.ad2.ad.alcatel.com><9C31FA6F6F10D641B0B16A91BC374187B8FACA043D@RDW083V001RVA1.domain1.systemhost.net> <40FB0FFB97588246A1BEFB05759DC8A004215DD3@S4DE9JSAANI.ost.t-com.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:02:27 -0000 Alessandro, I think most people agree with this point, yet the fact that an implementer may need to implement certain "usability" features is not the point in defining protocol standards. More and more in the IETF, we tend to do this anyway, because it is important to the customers. However, while this tendency exists, the fact remains that this is a "motherhood and apple pie" factor with not so much importance from the perspective of defining interoperable standards. From that perspective, what is important is that vendors all agree in their implementations on the fact that only the highest priority imperative present at any point in time is acted on. Put another way, if my implementation notifies the user that a specific command was ignored because of an existing higher priority imperative/condition - and vendor X's implementation does not - my implementation is likely to make my customers happier than vendor X's (at least in this one respect), but the ability of our implementations to correctly interoperate is simply not affected by this distinction. Because ambiguity on this point has no impact on interoperability, it is not as important to clarify this. -- Eric -----Original Message----- From: D'Alessandro Alessandro Gerardo [mailto:alessandro.dalessandro@teleco= mitalia.it] Sent: Thursday, April 01, 2010 7:03 AM To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul@telekom.de; Eric Gray; lieve= n.levrau@alcatel-lucent.com; benjamin.niven-jenkins@bt.com; italo.busi@alca= tel-lucent.com; rfc-editor@rfc-editor.org; malcolm.betts@huawei.com; nurit.= sprecher@nsn.com; satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@= huawei.com; swallow@cisco.com; loa@pi.nu Cc: mpls@ietf.org Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) Importance: High I agree with Manuel's comment (some feedback to the operator shall be consi= dered). About the correct word to be used, I'm fine with either "reject" or "discar= d" clarifying the previous point. Regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport & OPB Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of BRU= NGARD, DEBORAH A (ATTLABS) Sent: gioved=EC 1 aprile 2010 5.18 To: Manuel.Paul@telekom.de; eric.gray@ericsson.com; lieven.levrau@alcatel-l= ucent.com; benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com; rf= c-editor@rfc-editor.org; malcolm.betts@huawei.com; nurit.sprecher@nsn.com; = satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; swallo= w@cisco.com; loa@pi.nu Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) It depends if you are specifying the data plane or mibs. Always, if selecti= ng one sentence out of many, it is not complete (as Eric says). This senten= ce from RFC5654 was more from the data plane view using the familiar packet= term "dropped" vs. transport's G.808.1 "discarded". I also agree we don't want to load this too much. "Reject" is not familiar = wording. Suggest using then wording from G808.1: "External commands which are preempted or denied by other higher priority c= onditions, states or requests, are discarded." I think the choices are: "denied" or "discarded". -----Original Message----- From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] Sent: Wednesday, March 31, 2010 9:42 AM To: eric.gray@ericsson.com; lieven.levrau@alcatel-lucent.com; benjamin.nive= n-jenkins@bt.com; italo.busi@alcatel-lucent.com; rfc-editor@rfc-editor.org;= BRUNGARD, DEBORAH A (ATTLABS); malcolm.betts@huawei.com; nurit.sprecher@ns= n.com; satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com;= swallow@cisco.com; loa@pi.nu Cc: mpls@ietf.org Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) I also believe that we need to phrase it stronger than just saying "drop" o= r "ignore" - to imply that some (whatever) kind of feedback to the "request= er" needs to be considered as well. Using "reject" makes sense for me. Regards, Manuel > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Eric Gray > Sent: Tuesday, March 30, 2010 2:53 PM > To: LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins@bt.com; > BUSI,ITALO (ITALO); rfc-editor@rfc-editor.org; > dbrungard@att.com; malcolm.betts@huawei.com; > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; > rcallon@juniper.net; adrian.farrel@huawei.com; > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > I think that there is some consensus developing both in this > discussion > and elsewhere. There is (of course) some confusion over the > meaning of > certain terms, and the way things might be specified in the IETF - as > opposed to elsewhere. > > Essentially, a reasonable implementation will not quite ignore a user > instruction (users would doubtless resent that rather severely). It > is not quite clear what it means to "not quite ignore" instructions > from the user. The idea is that only the highest-priority input at > any given instant in time will result in a state-change for equipment > (services, or the network). > > In my opinion, we don't really want to get bogged down in terminology > issues or detailed over-specification - particularly after the fact > (this is an already published RFC, after all). > > The reason why I created this errata in the first place is that - in > other work in progress - we feel almost compelled to perpetuate the > exiting wording even though it is clearly incorrect. Specifically, > in the MPLS-TP CP draft, we captured requirements from a number of > drafts (unfortunately including this already published RFC). In the > process, it came to light that it makes no sense to "drop" a command > - yet this is what the referenced source document says. > > So, either we take some steps to correct the error, or we find our > selves constrained to perpetuate it. > > I think there is some agreement developing around using "reject" as > a repalcement for either "drop" or "ignore" - as long as we can do > this without creating the ripple-down effect of being compelled to > define exactly what we mean by "reject"... > > -----Original Message----- > From: LEVRAU, LIEVEN (LIEVEN) > [mailto:lieven.levrau@alcatel-lucent.com] > Sent: Monday, March 29, 2010 4:16 PM > To: Eric Gray; benjamin.niven-jenkins@bt.com; BUSI, ITALO > (ITALO); rfc-editor@rfc-editor.org; dbrungard@att.com; > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > satoshi.ueno@ntt.com; rcallon@juniper.net; > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > Importance: High > > Eric to the your point... (snippet) > > : > > > > "The NE rejects the operator's command and behave like the > command has > > never been requested." > > > > IMHO, acting as if a command has not been given is exactly the > > same thing as ignoring it. > > > I think there should be some logic behind it that the request > was indeed received, parsed and ignored so that it is > eventually a traceable event. > ./ > Lieven > > > > -- > > Eric > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf Of > > benjamin.niven-jenkins@bt.com > > Sent: Friday, March 19, 2010 5:18 PM > > To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org; > > dbrungard@att.com; malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > Rejected implies to me that the NE actively informs the > Operator that > > the attempt by the Operator to execute the external command was > > unsuccessful, is this the case? Otherwise how about "MUST NOT be > > honored"? > > > > Ben > > > > ________________________________________ > > From: BUSI ITALO [Italo.Busi@alcatel-lucent.com] > > Sent: 19 March 2010 16:11 > > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; > dbrungard@att.com; > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > satoshi.ueno@ntt.com; > > rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; > > loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > I understand the source of the confusion that the word "dropped" can > > create in a packet world. > > > > The term "ignored" is not semantically equivalent to the > intent of the > > original word "dropped". I would therefore propose the following > > rephrase: > > > > A. External controls overruled by higher priority requests > > (e.g., administrative requests and requests due to > > link/node > > failures) or unable to be signaled to the > remote end (e.g., > > due to a coordination failure of the protection > state) MUST > > be rejected. > > > > The NE rejects the operator's command and behave like the > command has > > never been requested. > > > > Italo > > > > P.S. Please note my new email address, > Italo.Busi@alcatel-lucent.com, > > effective since 1 November 2009. > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > Behalf Of RFC Errata System > > > Sent: venerd=EC 12 marzo 2010 17.26 > > > To: benjamin.niven-jenkins@bt.com; dbrungard@att.com; > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; rcallon@juniper.net; > > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org; rfc-editor@rfc-editor.org > > > Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > > The following errata report has been submitted for RFC5654, > > > "Requirements of an MPLS Transport Profile". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata_search.php?rfc=3D5654&eid=3D2073 > > > > > > -------------------------------------- > > > Type: Editorial > > > Reported by: Eric Gray > > > > > > Section: 2.5.4 > > > > > > Original Text > > > ------------- > > > 83 The external controls as defined in [RFC4427] MUST be > supported. > > > > > > A. External controls overruled by higher priority requests > > > (e.g., administrative requests and requests due to > > > link/node > > > failures) or unable to be signaled to the remote end > > (e.g., > > > due to a coordination failure of the protection state) > > MUST > > > be dropped. > > > > > > > > > Corrected Text > > > -------------- > > > 83 The external controls as defined in [RFC4427] MUST be > supported. > > > > > > A. External controls overruled by higher priority requests > > > (e.g., administrative requests and requests due to > > > link/node > > > failures) or unable to be signaled to the remote end > > (e.g., > > > due to a coordination failure of the protection state) > > MUST > > > be ignored. > > > > > > > > > Notes > > > ----- > > > Dropping a control is meaningless. The original intent may > > > have been to say "control messages", but this requirement is > > > stated in the section "Management-Plane Operation of > > > Protection and Restoration" > > > > > > In any case, using "ignored" instead of "dropped" fixes the > > > problem regardless of the original intention. > > > > > > 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. > > > > > > -------------------------------------- > > > RFC5654 (draft-ietf-mpls-tp-requirements-10) > > > -------------------------------------- > > > Title : Requirements of an MPLS Transport Profile > > > Publication Date : September 2009 > > > Author(s) : B. Niven-Jenkins, Ed., D. Brungard, > > > Ed., M. Betts, Ed., N. Sprecher, S. Ueno > > > Category : PROPOSED STANDARD > > > Source : Multiprotocol Label Switching > > > Area : Routing > > > Stream : IETF > > > Verifying Party : IESG > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From Manuel.Paul@telekom.de Thu Apr 1 09:31:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C623A68EA for ; Thu, 1 Apr 2010 09:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srMYYlEYJoq4 for ; Thu, 1 Apr 2010 09:31:12 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id A77073A698A for ; Thu, 1 Apr 2010 09:31:06 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 01 Apr 2010 18:31:33 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 18:31:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2010 18:12:42 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00421627C@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [Editorial Errata Reported] RFC5654 (2073) Thread-Index: AcrCAkHBrFEh2c5tSYKoFyPNIqhp2wFfAt/QAArSAoMB80oe0AABal5QAAF5gjAAVSjbIAAbZfAgABDJTRAACgKKoAAAK7MAAAC//KA= From: To: , , , , , , , , , , , , , X-OriginalArrivalTime: 01 Apr 2010 16:31:33.0015 (UTC) FILETIME=[CA352A70:01CAD1B8] Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:31:14 -0000 I also see Deborah's point if only the data plane is concerned. However, = as the chapter adresses functions for control by the operator and is = headlined "Management-Plane Operation of Protection and Restoration", I = felt it is usefull to having this as a "traceable event" (like I think = Eric called it earlier). If the majority is fine with it, however, I could live with "discard". (and I saw some mails coming in while I was typing this...) But, in case of using "discard", wouldn't we need to add the word = "requests" to the sentence as well? I.E. making it: =20 ] A. External control requests... [ =20 instead of =20 ] A. External controls ... [ Remember, up to now the RFC text says "control", not "control messages" = or "control requests". (and as I had understood, clarifying this was Eric's main motivation...) Thanks, Manuel > -----Original Message----- > From: BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.com]=20 > Sent: Thursday, April 01, 2010 5:29 PM > To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A=20 > (ATTLABS); Paul, Manuel; eric.gray@ericsson.com; LEVRAU=20 > LIEVEN; benjamin.niven-jenkins@bt.com;=20 > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com;=20 > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com;=20 > rcallon@juniper.net; adrian.farrel@huawei.com;=20 > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) >=20 > I understand that Deborah has some issues with "reject". >=20 > Therefore it looks like that we can converge on "discard". >=20 > Is "discard" acceptable? >=20 > For me it is fine. >=20 > Thanks, Italo >=20 > P.S. Please note my new email address,=20 > Italo.Busi@alcatel-lucent.com, effective since 1 November 2009. > =20 >=20 > > -----Original Message----- > > From: D'Alessandro Alessandro Gerardo=20 > > [mailto:alessandro.dalessandro@telecomitalia.it]=20 > > Sent: gioved=EC 1 aprile 2010 13.03 > > To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul@telekom.de;=20 > > eric.gray@ericsson.com; LEVRAU LIEVEN;=20 > > benjamin.niven-jenkins@bt.com; BUSI ITALO;=20 > > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com;=20 > > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com;=20 > > rcallon@juniper.net; adrian.farrel@huawei.com;=20 > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > >=20 > > I agree with Manuel's comment (some feedback to the operator=20 > > shall be considered). > > About the correct word to be used, I'm fine with either=20 > > "reject" or "discard" clarifying the previous point. > >=20 > > Regards, > > Alessandro > > ------------------------------------------------------------------ > > Telecom Italia > > Alessandro D'Alessandro > > Transport & OPB Innovation > > Via Reiss Romoli, 274 - 10148 Torino > > phone: +39 011 228 5887 > > mobile: +39 335 766 9607 > > fax: +39 06 418 639 07 > >=20 > >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > > Behalf Of BRUNGARD, DEBORAH A (ATTLABS) > > Sent: gioved=EC 1 aprile 2010 5.18 > > To: Manuel.Paul@telekom.de; eric.gray@ericsson.com;=20 > > lieven.levrau@alcatel-lucent.com;=20 > > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com;=20 > > rfc-editor@rfc-editor.org; malcolm.betts@huawei.com;=20 > > nurit.sprecher@nsn.com; satoshi.ueno@ntt.com;=20 > > rcallon@juniper.net; adrian.farrel@huawei.com;=20 > > swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > >=20 > > It depends if you are specifying the data plane or mibs.=20 > > Always, if selecting one sentence out of many, it is not=20 > > complete (as Eric says). This sentence from RFC5654 was more=20 > > from the data plane view using the familiar packet term=20 > > "dropped" vs. transport's G.808.1 "discarded". > >=20 > > I also agree we don't want to load this too much. "Reject" is=20 > > not familiar wording. Suggest using then wording from G808.1: > > "External commands which are preempted or denied by other=20 > > higher priority conditions, states or requests, are discarded." > >=20 > > I think the choices are: "denied" or "discarded". > >=20 > > -----Original Message----- > > From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] > > Sent: Wednesday, March 31, 2010 9:42 AM > > To: eric.gray@ericsson.com; lieven.levrau@alcatel-lucent.com;=20 > > benjamin.niven-jenkins@bt.com; italo.busi@alcatel-lucent.com;=20 > > rfc-editor@rfc-editor.org; BRUNGARD, DEBORAH A (ATTLABS);=20 > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com;=20 > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > Cc: mpls@ietf.org > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > >=20 > > I also believe that we need to phrase it stronger than just=20 > > saying "drop" or "ignore" - to imply that some (whatever)=20 > > kind of feedback to the "requester" needs to be considered as well. > > Using "reject" makes sense for me. > >=20 > > Regards, > > Manuel > >=20 > >=20 > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > > On Behalf=20 > > > Of Eric Gray > > > Sent: Tuesday, March 30, 2010 2:53 PM > > > To: LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins@bt.com;=20 > > BUSI,ITALO=20 > > > (ITALO); rfc-editor@rfc-editor.org; dbrungard@att.com;=20 > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com;=20 > > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > > adrian.farrel@huawei.com;=20 > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > I think that there is some consensus developing both in this=20 > > > discussion and elsewhere. There is (of course) some=20 > confusion over=20 > > > the meaning of certain terms, and the way things might be=20 > > specified in=20 > > > the IETF - as opposed to elsewhere. > > > > > > Essentially, a reasonable implementation will not quite=20 > > ignore a user=20 > > > instruction (users would doubtless resent that rather=20 > > severely). It=20 > > > is not quite clear what it means to "not quite ignore"=20 > instructions=20 > > > from the user. The idea is that only the=20 > highest-priority input at=20 > > > any given instant in time will result in a state-change for=20 > > equipment=20 > > > (services, or the network). > > > > > > In my opinion, we don't really want to get bogged down in=20 > > terminology=20 > > > issues or detailed over-specification - particularly=20 > after the fact=20 > > > (this is an already published RFC, after all). > > > > > > The reason why I created this errata in the first place is=20 > > that - in=20 > > > other work in progress - we feel almost compelled to=20 > perpetuate the=20 > > > exiting wording even though it is clearly incorrect. =20 > > Specifically, in=20 > > > the MPLS-TP CP draft, we captured requirements from a=20 > > number of drafts=20 > > > (unfortunately including this already published RFC). In=20 > > the process,=20 > > > it came to light that it makes no sense to "drop" a command > > > - yet this is what the referenced source document says. > > > > > > So, either we take some steps to correct the error, or we=20 > find our=20 > > > selves constrained to perpetuate it. > > > > > > I think there is some agreement developing around using=20 > > "reject" as a=20 > > > repalcement for either "drop" or "ignore" - as long as we=20 > > can do this=20 > > > without creating the ripple-down effect of being compelled=20 > > to define=20 > > > exactly what we mean by "reject"... > > > > > > -----Original Message----- > > > From: LEVRAU, LIEVEN (LIEVEN) > > > [mailto:lieven.levrau@alcatel-lucent.com] > > > Sent: Monday, March 29, 2010 4:16 PM > > > To: Eric Gray; benjamin.niven-jenkins@bt.com; BUSI, ITALO=20 > (ITALO);=20 > > > rfc-editor@rfc-editor.org; dbrungard@att.com;=20 > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com;=20 > > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > > adrian.farrel@huawei.com;=20 > > > swallow@cisco.com; loa@pi.nu > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > Importance: High > > > > > > Eric to the your point... (snippet) > > > > > > : > > > > > > > > "The NE rejects the operator's command and behave like the > > > command has > > > > never been requested." > > > > > > > > IMHO, acting as if a command has not been given is=20 > > exactly the=20 > > > > same thing as ignoring it. > > > > > > > I think there should be some logic behind it that the request was=20 > > > indeed received, parsed and ignored so that it is eventually a=20 > > > traceable event. > > > ./ > > > Lieven > > > > > > > > -- > > > > Eric > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > > On Behalf Of > > > > benjamin.niven-jenkins@bt.com > > > > Sent: Friday, March 19, 2010 5:18 PM > > > > To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org;=20 > > > > dbrungard@att.com; malcolm.betts@huawei.com;=20 > > nurit.sprecher@nsn.com;=20 > > > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > > adrian.farrel@huawei.com;=20 > > > > swallow@cisco.com; loa@pi.nu > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > Rejected implies to me that the NE actively informs the > > > Operator that > > > > the attempt by the Operator to execute the external command was=20 > > > > unsuccessful, is this the case? Otherwise how about=20 > "MUST NOT be=20 > > > > honored"? > > > > > > > > Ben > > > > > > > > ________________________________________ > > > > From: BUSI ITALO [Italo.Busi@alcatel-lucent.com] > > > > Sent: 19 March 2010 16:11 > > > > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; > > > dbrungard@att.com; > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com; > > > satoshi.ueno@ntt.com; > > > > rcallon@juniper.net; adrian.farrel@huawei.com;=20 > swallow@cisco.com;=20 > > > > loa@pi.nu > > > > Cc: mpls@ietf.org > > > > Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > I understand the source of the confusion that the word=20 > > "dropped" can=20 > > > > create in a packet world. > > > > > > > > The term "ignored" is not semantically equivalent to the > > > intent of the > > > > original word "dropped". I would therefore propose the following > > > > rephrase: > > > > > > > > A. External controls overruled by higher=20 > > priority requests > > > > (e.g., administrative requests and requests due to=20 > > > > link/node > > > > failures) or unable to be signaled to the > > > remote end (e.g., > > > > due to a coordination failure of the protection > > > state) MUST > > > > be rejected. > > > > > > > > The NE rejects the operator's command and behave like the > > > command has > > > > never been requested. > > > > > > > > Italo > > > > > > > > P.S. Please note my new email address, > > > Italo.Busi@alcatel-lucent.com, > > > > effective since 1 November 2009. > > > > > > > > > > > > > -----Original Message----- > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > > > > > Behalf Of RFC Errata System > > > > > Sent: venerd=EC 12 marzo 2010 17.26 > > > > > To: benjamin.niven-jenkins@bt.com; dbrungard@att.com;=20 > > > > > malcolm.betts@huawei.com; nurit.sprecher@nsn.com;=20 > > > > > satoshi.ueno@ntt.com; rcallon@juniper.net;=20 > > > > > adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu > > > > > Cc: mpls@ietf.org; rfc-editor@rfc-editor.org > > > > > Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073) > > > > > > > > > > > > > > > The following errata report has been submitted for RFC5654,=20 > > > > > "Requirements of an MPLS Transport Profile". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > = http://www.rfc-editor.org/errata_search.php?rfc=3D5654&eid=3D2073 > > > > > > > > > > -------------------------------------- > > > > > Type: Editorial > > > > > Reported by: Eric Gray > > > > > > > > > > Section: 2.5.4 > > > > > > > > > > Original Text > > > > > ------------- > > > > > 83 The external controls as defined in [RFC4427] MUST be > > > supported. > > > > > > > > > > A. External controls overruled by higher=20 > > priority requests > > > > > (e.g., administrative requests and requests due to=20 > > > > > link/node > > > > > failures) or unable to be signaled to the=20 > remote end > > > > (e.g., > > > > > due to a coordination failure of the=20 > > protection state) > > > > MUST > > > > > be dropped. > > > > > > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > 83 The external controls as defined in [RFC4427] MUST be > > > supported. > > > > > > > > > > A. External controls overruled by higher=20 > > priority requests > > > > > (e.g., administrative requests and requests due to=20 > > > > > link/node > > > > > failures) or unable to be signaled to the=20 > remote end > > > > (e.g., > > > > > due to a coordination failure of the=20 > > protection state) > > > > MUST > > > > > be ignored. > > > > > > > > > > > > > > > Notes > > > > > ----- > > > > > Dropping a control is meaningless. The original intent=20 > > may have=20 > > > > > been to say "control messages", but this requirement is=20 > > stated in=20 > > > > > the section "Management-Plane Operation of Protection and=20 > > > > > Restoration" > > > > > > > > > > In any case, using "ignored" instead of "dropped" fixes the=20 > > > > > problem regardless of the original intention. > > > > > > > > > > Instructions: > > > > > ------------- > > > > > This errata is currently posted as "Reported". If necessary,=20 > > > > > please use "Reply All" to discuss whether it should be=20 > > verified or=20 > > > > > rejected. When a decision is reached, the verifying=20 > > party (IESG)=20 > > > > > can log in to change the status and edit the report, if=20 > > necessary. > > > > > > > > > > -------------------------------------- > > > > > RFC5654 (draft-ietf-mpls-tp-requirements-10) > > > > > -------------------------------------- > > > > > Title : Requirements of an MPLS=20 > Transport Profile > > > > > Publication Date : September 2009 > > > > > Author(s) : B. Niven-Jenkins, Ed., D. Brungard, > > > > > Ed., M. Betts, Ed., N. Sprecher, S. Ueno > > > > > Category : PROPOSED STANDARD > > > > > Source : Multiprotocol Label Switching > > > > > Area : Routing > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > 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 > > Questo messaggio e i suoi allegati sono indirizzati=20 > > esclusivamente alle persone indicate. La diffusione, copia o=20 > > qualsiasi altra azione derivante dalla conoscenza di queste=20 > > informazioni sono rigorosamente vietate. Qualora abbiate=20 > > ricevuto questo documento per errore siete cortesemente=20 > > pregati di darne immediata comunicazione al mittente e di=20 > > provvedere alla sua distruzione, Grazie. > >=20 > > This e-mail and any attachments is confidential and may=20 > > contain privileged information intended for the addressee(s)=20 > > only. Dissemination, copying, printing or use by anybody else=20 > > is unauthorised. If you are not the intended recipient,=20 > > please delete this message and any attachments and advise the=20 > > sender by return e-mail, Thanks. > >=20 > >=20 >=20 From annamaria.fulignoli@ericsson.com Thu Apr 1 11:58:36 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6603A6862; Thu, 1 Apr 2010 11:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R02p9RL+0drT; Thu, 1 Apr 2010 11:58:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5168E3A6816; Thu, 1 Apr 2010 11:58:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-5b-4bb4ecfafe90 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 29.29.23532.AFCE4BB4; Thu, 1 Apr 2010 20:59:06 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 20:59:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2010 20:59:05 +0200 Message-ID: <93DFCD4B101EB440B5B72997456C5F94051E0F85@esealmw118.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Choice of BFD mechanism/mode for proactive CV/CC Thread-Index: AcrQ7WbcXjmat2ZfRSWhgVVfvYFOGAAg9QqQ References: <787be2781003251455j16112172tf907b7a3084e0ea@mail.gmail.com> From: "Annamaria Fulignoli" To: "Greg Mirsky" , , , , "David Ward" , , , , X-OriginalArrivalTime: 01 Apr 2010 18:59:06.0547 (UTC) FILETIME=[6752F030:01CAD1CD] X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:58:36 -0000 Hi Greg, sorry for the delay in answering. You wrote:=20 "what are reasons considered to select only unidirectional BFD (based on = BFD for multipoint networks work) for proactive CV/CC" The unidirectional BFD allows to have one solution, one behavior, for = all transport entities ( p2p bidirectional, p2p unidirectional, p2mp ) = and it satisfies all MPLS-TP transport requirement for the proactive = CV/CC, including also the unidirectional failure; it is very simple and = fast tool as transport operator require. As it could be critical to support, the group is still working together = to converge asap to a common agreed solution. We'll be glad to receive your useful comments next draft update. Thanks =20 Best Regards Annamaria=20 ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: mercoled=EC 31 marzo 2010 18.16 To: Annamaria Fulignoli; sboutros@cisco.com; = martin.vigoureux@alcatel-lucent.com; swallow@cisco.com; David Ward; = wardd@cisco.com; msiva@cisco.com; mpls@ietf.org; mpls-tp@ietf.org Subject: Re: Choice of BFD mechanism/mode for proactive CV/CC I haven't seen any response from authors thus assuming that it didn't = make to the list the first time. On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky = wrote: Dear Authors and All, I would like to ask several questions related to the subject I've asked = at the meeting today: =09 * what are reasons considered to select only unidirectional BFD (based = on BFD for multipoint networks work) for proactive CV/CC=20 * what capabilities of BFD for multipoint networks required for use as = CV/CC in MPLS-TP=20 * what of capabilities are optional (can and may)=20 * are there any capabilities that would not be supported (should not = and must not)=20 As was demonstrated in presentation of David's analysis by Rahul today, = within BFD for MPLS one can create unidirectional BFD session already, = assuming that the DCN exists in some form. Thus it leave p2mp LSP that = can benefit from use of BFD for multipoint networks mechanism. Or a root = can "pretend" that p2mp LSP is p2p and send after first exchange of = Discriminator, and ignore Discrminators from other, late-joiner leaves. =09 Regards, Greg =09 From Attila.Takacs@ericsson.com Thu Apr 1 23:53:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014533A693C for ; Thu, 1 Apr 2010 23:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt68UeuVyh6p for ; Thu, 1 Apr 2010 23:53:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BD3673A6905 for ; Thu, 1 Apr 2010 23:53:12 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-b4-4bb594786926 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A3.C1.23740.87495BB4; Fri, 2 Apr 2010 08:53:44 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.93]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 2 Apr 2010 08:53:43 +0200 From: Attila Takacs To: Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Fri, 2 Apr 2010 08:53:43 +0200 Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOA Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> References: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> In-Reply-To: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 06:53:14 -0000 Hi Matthew and George, Please find some comments/questions below. -In Section 5.1 you have: Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num?=20 Is it there to support associated unidirectional Tunnels/LSPs? If so it sho= uld be called out in the text.=20 Same applies to the globally unique case. -In Section 5.2 you simply append one LSP_Num to the above. This is a bit c= onfusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums would be= needed too, wouldn't it? -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tunnel_Num.= So this means that we may have two different tunnels identified with Src-N= ode_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this intentional, e= .g., the associated unidirectional case? This should be clarified. Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. -Section 7 has a note saying to be aligned with the OAM fwk, is this still = to be done? -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel lev= el and not at the LSP level? Do we need Tunnel MEG_IDs as defined in 7.1.2.1? -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. -Section 8 talks about open issues? When will these be addressed? Thanks, Attila=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Friday, March 12, 2010 12:33 AM > To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >=20 > All, >=20 > this is to start an MPLS working group last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > There is a discussion on the OAM model for MS-PWs where we=20 > haven't been able to come to conclusion. Once we reach=20 > agreement the document will be updated. Comments in this area=20 > are welcome during the working group last call. >=20 >=20 > Please send your comments to the mpls-tp@ietf.org mailing list. >=20 > The working group last ends eob April 2nd. >=20 > /Loa >=20 > -- >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager > Ericsson /// > phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 > email: loa.andersson@ericsson.com > loa@pi.nu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From diego.caviglia@ericsson.com Thu Apr 1 23:58:32 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64B43A692E; Thu, 1 Apr 2010 23:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=3.177, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm8kszJm9Wo6; Thu, 1 Apr 2010 23:58:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 027A43A68DD; Thu, 1 Apr 2010 23:58:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-2b-4bb595b6f965 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 96.D3.23532.6B595BB4; Fri, 2 Apr 2010 08:59:02 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 08:58:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2010 08:58:01 +0200 Message-ID: In-Reply-To: <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAAAvpBA= References: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> From: "Diego Caviglia" To: "Attila Takacs" , "Loa Andersson" , , , , X-OriginalArrivalTime: 02 Apr 2010 06:58:02.0837 (UTC) FILETIME=[D68E7050:01CAD231] X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 06:58:32 -0000 Hi, Some more comments from me more ore less on the same route as Attila. =B7 Section 1.1 o PSC is also used as Packet Switching Capable for OSPF-TE=20 =B7 Section 2 o Tunnel I think that here a reference to the actual identifier = of the quoted entity could help I mean a reference to Section 5 =B7 Section 4=20 o would be good to have a short explanation why numbered = interfaces are not in the scope of MPLS-TP=20 =B7 Section 5 o Even if section 2 points to 3209 than the Tunnel Identifier = chosen is different from what is defined in 3209, Extended Tunnel ID = field is missing while there are two different Tunnel Num that is not = clear how they works. I think here the same convention used in 3209 and = in GMPLS signaling would be good to avoid to have two or more Tunnel = identifiers for MPLS-TP networks using GMPLS.=20 o Why MPLS-TP tunnels must be associated to a LIH? Why MPLS-TP = tunnels need to be configured as FA? Does that imply that in case = OSPF-TE is used it must advertise MPLS-TP tunnels as FA each time a new = tunnel is created? =B7 Section 5.2 I think that sentence "The format of a Tunnel_ID = is:" should be "The format of a LSP_ID is:" same for the globally unique = case. =B7 Section 5.3 addresses some of my above concern about usage = of tunnel and lsp identifiers even if is not a 1:1 mapping given that = the Dst-Tunnel_Num is not mapped in GMPLS Tunnel ID =B7 Remaining of the docs is still WP =20 BR Diego line DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 Ericsson This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Attila Takacs Sent: venerd=EC 2 aprile 2010 8.54 To: Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; = ccamp@ietf.org Subject: Re: [mpls] mpls wg last call on = draft-ietf-mpls-tp-identifiers-01 Hi Matthew and George, Please find some comments/questions below. -In Section 5.1 you have: Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num What is the reason of having a Dst-Tunnel_Num besides the = Src-Tunnel_Num?=20 Is it there to support associated unidirectional Tunnels/LSPs? If so it = should be called out in the text.=20 Same applies to the globally unique case. -In Section 5.2 you simply append one LSP_Num to the above. This is a = bit confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums = would be needed too, wouldn't it? -In Section 5.3 Mapping to GMPLS signaling does not use the = Dst-Tunnel_Num. So this means that we may have two different tunnels = identified with = Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this = intentional, e.g., the associated unidirectional case? This should be = clarified. Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. -Section 7 has a note saying to be aligned with the OAM fwk, is this = still to be done? -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel = level and not at the LSP level? Do we need Tunnel MEG_IDs as defined in 7.1.2.1? -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. -Section 8 talks about open issues? When will these be addressed? Thanks, Attila=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Friday, March 12, 2010 12:33 AM > To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >=20 > All, >=20 > this is to start an MPLS working group last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > There is a discussion on the OAM model for MS-PWs where we=20 > haven't been able to come to conclusion. Once we reach=20 > agreement the document will be updated. Comments in this area=20 > are welcome during the working group last call. >=20 >=20 > Please send your comments to the mpls-tp@ietf.org mailing list. >=20 > The working group last ends eob April 2nd. >=20 > /Loa >=20 > -- >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager > Ericsson /// > phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 > email: loa.andersson@ericsson.com > loa@pi.nu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Italo.Busi@alcatel-lucent.com Fri Apr 2 00:53:56 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABC83A69CC; Fri, 2 Apr 2010 00:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ozLtVmHXV5Z; Fri, 2 Apr 2010 00:53:56 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id B0DA63A6955; Fri, 2 Apr 2010 00:53:55 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o327sG6G003941; Fri, 2 Apr 2010 09:54:21 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 09:54:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2010 09:57:49 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B19E9@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <64A8011F-1A3F-4EA9-8CC5-2F0CF97E73C1@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Choice of BFD mechanism/mode for proactive CV/CC Thread-Index: AcrQ78RiTb4mk2XZROmS1Vem8f3WygAvQ+aw References: <787be2781003251455j16112172tf907b7a3084e0ea@mail.gmail.com> <64A8011F-1A3F-4EA9-8CC5-2F0CF97E73C1@juniper.net> From: "BUSI ITALO" To: "David Ward" , "Greg Mirsky" X-OriginalArrivalTime: 02 Apr 2010 07:54:20.0977 (UTC) FILETIME=[B415B210:01CAD239] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: mpls@ietf.org, "David Ward \(wardd\)" , "Siva Sivabalan\(msiva\)" , mpls-tp@ietf.org, Sami Boutros Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 07:53:57 -0000 Dave, Greg, I think we are mixing different aspect of requirements, solutions and = consequences if requirements are not met. The requirements have been expressed more than once but I think that = "repetita juvant": - we need a very simple and lightweight protocol that check continuity = and connectivity ("are you there?" question with a "yes/no" answer) - this check must be performed at a rate that is fully controlled by the = operator (and not by the network) - the rate must not change in any condition (only the operator can = change it) - the return path is required only on bidirectional p2p paths (either = associated or co-routed) just to carry the RDI indication There are many consequences if the requirements are not met. One of these consequences is described in the last slide of Annamaria's = presentation done in Anaheim: http://tools.ietf.org/agenda/77/slides/mpls-24.ppt Unidirectional BFD is not the only solution to address this requirement. An alternative solution was also presented in = draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of David Ward > Sent: mercoled=EC 31 marzo 2010 18.33 > To: Greg Mirsky > Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward; Sami=20 > Boutros; David Ward (wardd); mpls-tp@ietf.org > Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC >=20 > Greg - >=20 > On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote: >=20 > I haven't seen any response from authors thus assuming that=20 > it didn't make to the list the first time. >=20 > On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky=20 > > wrote: > Dear Authors and All, > I would like to ask several questions related to the subject=20 > I've asked at the meeting today: >=20 > * what are reasons considered to select only=20 > unidirectional BFD (based on BFD for multipoint networks=20 > work) for proactive CV/CC >=20 > DW: This requirement has been bantered back and forth by the=20 > group. Although not completely explained, it's been deemed=20 > critical to support by those well versed in transport network=20 > architectures. >=20 >=20 >=20 > * what capabilities of BFD for multipoint networks=20 > required for use as CV/CC in MPLS-TP >=20 > DW: Certainly in the MP scenario. As discussed in the preso=20 > by Rahul at the meeting it can also be used if there is no=20 > return path (odd network design). >=20 >=20 > * what of capabilities are optional (can and may) >=20 > DW: As you saw in the preso, many capabilities and scenarios=20 > were presented.The point of the preso was they there were all=20 > optional and that if any of the options were *ever* desired=20 > then pure unidirectional MP BFD was not a good choice. >=20 >=20 > * are there any capabilities that would not be supported=20 > (should not and must not) >=20 > As was demonstrated in presentation of David's analysis by=20 > Rahul today, within BFD for MPLS one can create=20 > unidirectional BFD session already, assuming that the DCN=20 > exists in some form. >=20 > DW: And really only useful if there is never, ever a return path. >=20 > Thus it leave p2mp LSP that can benefit from use of BFD for=20 > multipoint networks mechanism. Or a root can "pretend" that=20 > p2mp LSP is p2p and send after first exchange of=20 > Discriminator, and ignore Discrminators from other,=20 > late-joiner leaves. >=20 > Regards, > Greg >=20 >=20 >=20 > HIH >=20 > -DWard >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From loa@pi.nu Fri Apr 2 01:19:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928DF3A68B7; Fri, 2 Apr 2010 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-sJgX0PSAsv; Fri, 2 Apr 2010 01:19:16 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 6D9F63A677D; Fri, 2 Apr 2010 01:19:16 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 8F83ED404F; Fri, 2 Apr 2010 10:19:47 +0200 (CEST) Message-ID: <4BB5A8A2.508@pi.nu> Date: Fri, 02 Apr 2010 10:19:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "mpls-tp@ietf.org" , MPLS-TP ad hoc team , mpls@ietf.org, pwe3@ietf.org, CCAMP References: <4BAD5B78.5000808@pi.nu> In-Reply-To: <4BAD5B78.5000808@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-oam-framework has ended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 08:19:18 -0000 All, the mpls wg last call on draft-ietf-mpls-tp-oam-framework has ended. Could the authors please address the comments and re-publish the document. /Loa On 2010-03-27 02:12, Loa Andersson wrote: > Working Group(s), Ad Hoc Team > > Offline the mpls-tp working group chairs, ADs and for part of the > time the ITU-T SG15 Rapporteurs attending the meeting in Anaheim > have spent time during the IETF week on the issue how to get a > high-quality standard out of the joint mpls-tp project. The > IETF leadership still see great value in keeping to the schedule > we've been working on for the last 9 months and is quite optimistic > about getting a high-quality work done on time. > > The working group chairs have agreed to extend the working group > last call schedule. > > We have made the following extensions/changes for the mpls-tp > project drafts that is currently in (or soon will be) in mpls > wg last call: > > > OAM Acronyms draft-ietf-opsawg-mpls-tp-oam-def > The OPSAWG wg last call will start on March 29 and end on April 18 > > > MPLS-TP Framework draft-ietf-mpls-tp-framework > The MPLS wg last call will start on April 5 and end on April 18 > > > MPLS-TP OAM Framework draft-ietf-mpls-tp-oam-framework > The ongoing MPLS wg last call will end on April 1 > > MPLS-TP Survivability Framework draft-ietf-mpls-tp-survive-fwk > The ongoing MPLS working group last call will end on April 11 > > > MPLS-TP Data plane draft-ietf-mpls-tp-data-plane > The ongoing MPLS working group last call will end on April 11 > > > ACH-TLV structure draft-ietf-mpls-tp-ach-tlv > The ongoing MPLS wg last call will end on April 12 > > > MPLS-TP Identifiers draft-ietf-mpls-tp-identifiers-00 > The ongoing MPLS wg last call will end on April 11 > > The latest version of a excel schedule that has been discussed > is included in this mail. I'd lake to poll for working group(s) > for comments on the schedule. As usual send these comments to > the mpls-tp mailing list only. > > /Loa > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From Italo.Busi@alcatel-lucent.com Fri Apr 2 01:29:16 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06E03A69A9; Fri, 2 Apr 2010 01:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsBQXMMIpXOt; Fri, 2 Apr 2010 01:29:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 6CE663A6803; Fri, 2 Apr 2010 01:29:11 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o328TFTT015479; Fri, 2 Apr 2010 10:29:32 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 10:29:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2010 10:32:56 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B1A08@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls-tp] [mpls]Term"PSC" indraft-ietf-mpls-tp-linear-protection-01 Thread-Index: AcrL9dLsI+DY3otSR3yV+LTQo2ejFABORLkg References: <8bf39341003231036w3ceaac70l18ee403c034da761@mail.gmail.com><8bf39341003240120r554b72j3f6b924475a11d3c@mail.gmail.com><8bf39341003240227i7fe1e00en9edbe2269b3953cf@mail.gmail.com><4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com><4BAA4873.3020706@chello.nl> From: "BUSI ITALO" To: "Adrian Farrel" , , "Cecil Byles" X-OriginalArrivalTime: 02 Apr 2010 08:29:27.0968 (UTC) FILETIME=[9BF30200:01CAD23E] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: mpls@ietf.org, CCAMP@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] [mpls-tp] Term"PSC" indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 08:29:17 -0000 Adrian, I think that this thread discussion is actually proving that the idea to = re-define a new term for what everybody in the world known as APS was = not a good idea. We therefore better come back and adopt the widely known concept rather = than inventing a new term and confuse the whole industry. Regarding your references, I think it is worth clarifying that: - APS is a generic term for the coordination protocol and does not imply = any specific protocol implementation; - Ethernet APS is a specific protocol specification of APS in Ethernet = networks and it is defined in G.8031; - SONET/SDH APS is a specific protocol specification of APS in SONET/SDH = networks and it is defined in G.841; - OTN APS is a specific protocol specification of APS in OTN networks = and it is defined in G.873.1 What IETF actually should define the specific realization of APS in = MPLS-TP networks. I do not see any value in calling PSC such a specific realization while = I can see a huge value in calling it as "MPLS-TP APS". Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Adrian Farrel > Sent: gioved=EC 25 marzo 2010 1.33 > To: hhelvoort@chello.nl; Cecil Byles > Cc: mpls@ietf.org; CCAMP@ietf.org; mpls-tp@ietf.org > Subject: Re: [CCAMP] [mpls-tp] [mpls]Term"PSC"=20 > indraft-ietf-mpls-tp-linear-protection-01 >=20 > Huub, >=20 > You will note that the comment in the liaison you reference said: >=20 > "The acronyms PSC and APS are used, in ITU-T APS is a generic=20 > term used in different methodologies and does not provide a solution." >=20 > This was neither a question nor a request for any change. And=20 > it is not really clear that it is a "concern". >=20 > APS is an abstract protocol (G.808.1) with specific=20 > characteristics and behaviors. >=20 > The Survivability Framework deliberately does not prejudge=20 > the abstract protocol or solution protocol that is required.=20 > Instead, it picked another acronym to avoid any assumptions.=20 > This frees the people working in the solution space to choose=20 > the necessary abstract model for the problems they need to=20 > solve, and to develop a protocol realisation that meets the model.=20 > This neither precludes nor forces the use of APS. >=20 > If you like, PSC is simply a generalisation that allows=20 > freedom of interpretation. Viz. >=20 > In some protection switching schemes (such as bidirectional > protection switching), it is necessary to coordinate the protection > state between the edges of the recovery domain. An MPLS-TP > Protection State Coordination (PSC) protocol may be used as an in- > band (i.e., data plane-based) control protocol to align=20 > both ends of > the protected domain. Control plane-based mechanism can=20 > also be used > to coordinate the protection states between the edges of the > protection domain. >=20 > In the view of the authors, the term "APS" has become=20 > synonymous with specific protocol realisations. For example,=20 > in the working copy of G.8131 I have infront of me, section=20 > 10 describes the "APS Protocol" setting out byte formats and=20 > defining messages to go on the wire. While we can interpret=20 > "APS Protocol" as the technology-specific realisation of=20 > "APS", there are sufficient overtones that if the=20 > Survivability Framework used the term "APS"=20 > it might be construed as support for a specific protocol=20 > realisation. Y.1731 defines APS PDUs for Ethernet which gives=20 > us another competing interpretation of the term. (It is=20 > notable that the term "APS Protocol" is used in G.870 to mean=20 > the abstract protocol, which is subtly different from its use=20 > in G.8131 and Y.1731.) >=20 > Surely the working group would prefer to derive the correct=20 > protocol solution without being constrained except at a=20 > functional level? >=20 > Adrian >=20 >=20 > ----- Original Message ----- > From: "Huub van Helvoort" > To: "Cecil Byles" > Cc: ; ; > Sent: Wednesday, March 24, 2010 5:14 PM > Subject: Re: [CCAMP] [mpls-tp] [mpls] Term"PSC"=20 > indraft-ietf-mpls-tp-linear-protection-01 >=20 >=20 > Hello Cecil, >=20 > You wrote: >=20 > > Can I therefore also asked how PSC "Protection State=20 > Coordination" in the=20 > > MPLS-TP parlance align with ITU-T 808.1 recommendation that=20 > "defines the=20 > > generic functional models, characteristics and processes=20 > associated with=20 > > various linear protection schemes for connection-oriented=20 > layer networks;=20 > > e.g., Optical Transport Networks (OTN), Synchronous Digital=20 > Hierarchy=20 > > (SDH) networks and Asynchronous Transfer Mode (ATM)=20 > networks" and the=20 > > sections covering Terms and Definitions as well as=20 > Abbreviations. IMO=20 > > all transport engineers and the general telecom community=20 > understand that=20 > > 1+1 or 1:1 are either SNCP or APS. Hence why introduce a=20 > new TLA (three=20 > > letter abbreviation) cover the same function and feature=20 > for MPLS-TP. I=20 > > can only agree that this will only cause confusion. >=20 > I agree with you. >=20 > In addition to that: > The ITU-T experts that reviewed the survivability draft had the same > concerns, and expressed that in their reply liaison for the review of > this draft: https://datatracker.ietf.org/liaison/618/ that was > sent in november last year. > This concern has not been addressed yet. >=20 > Regards, Huub. >=20 >=20 > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From neil.2.harrison@bt.com Fri Apr 2 01:55:25 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A497B3A67B2; Fri, 2 Apr 2010 01:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-1.833, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjRokBrnRZTI; Fri, 2 Apr 2010 01:55:24 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id C31523A6840; Fri, 2 Apr 2010 01:54:44 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 09:55:17 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2010 09:55:13 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05C64B06@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4030B19E9@FRVELSMBS21.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Choice of BFD mechanism/mode for proactive CV/CC Thread-Index: AcrQ78RiTb4mk2XZROmS1Vem8f3WygAvQ+awACPdhCA= From: To: , , X-OriginalArrivalTime: 02 Apr 2010 08:55:17.0071 (UTC) FILETIME=[37495DF0:01CAD242] Cc: mpls@ietf.org, mpls-tp@ietf.org, sboutros@cisco.com, msiva@cisco.com, wardd@cisco.com Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 08:55:25 -0000 Italo,=20 Many years ago when drafting Y.1710/1711 I pointed out that having = different CV rates in a network would cause 'alarm cycling' problems = under cases of misconnectivity, eg a trail with a CV rate of 1 per = minute misconnected (ie merged) into a trail with a CV rate of 1 per sec = will cause a behaviour of (i) declare defect and take consequent actions = at t=3DT (eg could include invoking prot-sw as per Anamaria's slide), = (ii) declare defect cleared at t=3DT+3 and remove all consequent actions = (maybe even switch traffic back to old path at some point?), (iii) = declare defect again at t=3DT+60...and continue to repeat this cycle. If there are N different CV rates in a network then there will be a = number of 'select 2 from N' combinatorial defect cases to deal = with....not a great idea, so I would strongly suggest that the CV rate = be consistent in a given layer network. BTW - if you set the CV rate too fast you run the danger of declaring = defects, and taking unnecessary consequent actions, on error bursts that = could clear of their own accord. Defect detection OAM should always be unidirectional in nature in co = mode layer networks....the p2mp case clearly shows why this is = required......noting that consequent actions are also unidirectional in = nature and taken at the trail sink, eg activation/suspension of perf = counters, raise local alarm, etc. The CV (or BFD) packet should contain the proper trail source address = for that layer network...not some arbitrary source generated identifier. = This does assume of course that the layer network being considered has = been given decent addressing in the first place.....not the case with = MPLS and for sure not with PWs! One can piggy-back BDI flag in CV for the p2p case but not the p2mp = case. I would also advise forward-looking caution and clarity on these points: 1 Before committing to any TCM be very clear how nested TCM levels are = configured and activated/deactivated (including synchronisation of any = perf mon counts) across failure and restore events. Only the true end = points of trails always remain invariant across failure/restore events. 2 Note that in a transport network if one direction enters the = unavailable state then both directions are deemed unavailable. The key = point here is that any perf monitoring for SLAs must be suspended in = both directions for the duration of the unavailability event. And from = above point, this applies to all nested TCM levels. =20 3 From transparency considerations a (parent) connection should only = have a single CoS for its (child) traffic units. However, it seems = possible that this arch requirement could be violated. In such a case = there will be a need to consider how the entry/exit criteria of the = unavailable state (and all the consequent actions that would apply) is = to be defined for the (parent) connection based on some weighted = combinatorial of loss/delay in the (child) traffic units of each CoS. = .....I have mentioned some of these consequential action considerations = above wrt to suspending perf mon counts in both directions and across = all nested TCM levels. The right answer here of course is don't create = this problem in the first place, ie a connection should only have a = single CoS level. regards, Neil > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of BUSI ITALO > Sent: 02 April 2010 08:58 > To: David Ward; Greg Mirsky > Cc: mpls@ietf.org; David Ward (wardd); Siva Sivabalan(msiva);=20 > mpls-tp@ietf.org; Sami Boutros > Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC >=20 > Dave, Greg, >=20 > I think we are mixing different aspect of requirements,=20 > solutions and consequences if requirements are not met. >=20 > The requirements have been expressed more than once but I=20 > think that "repetita juvant": >=20 > - we need a very simple and lightweight protocol that check=20 > continuity and connectivity ("are you there?" question with a=20 > "yes/no" answer) >=20 > - this check must be performed at a rate that is fully=20 > controlled by the operator (and not by the network) >=20 > - the rate must not change in any condition (only the=20 > operator can change it) >=20 > - the return path is required only on bidirectional p2p paths=20 > (either associated or co-routed) just to carry the RDI indication >=20 > There are many consequences if the requirements are not met. >=20 > One of these consequences is described in the last slide of=20 > Annamaria's presentation done in Anaheim: >=20 > http://tools.ietf.org/agenda/77/slides/mpls-24.ppt >=20 > Unidirectional BFD is not the only solution to address this=20 > requirement. >=20 > An alternative solution was also presented in=20 > draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi. >=20 > Italo >=20 > P.S. Please note my new email address,=20 > Italo.Busi@alcatel-lucent.com, effective since 1 November 2009. >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > > Of David Ward > > Sent: mercoled=EC 31 marzo 2010 18.33 > > To: Greg Mirsky > > Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward; Sami Boutros;=20 > > David Ward (wardd); mpls-tp@ietf.org > > Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC > >=20 > > Greg - > >=20 > > On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote: > >=20 > > I haven't seen any response from authors thus assuming that=20 > it didn't=20 > > make to the list the first time. > >=20 > > On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky=20 > > > wrote: > > Dear Authors and All, > > I would like to ask several questions related to the subject I've=20 > > asked at the meeting today: > >=20 > > * what are reasons considered to select only=20 > > unidirectional BFD (based on BFD for multipoint networks > > work) for proactive CV/CC > >=20 > > DW: This requirement has been bantered back and forth by the group.=20 > > Although not completely explained, it's been deemed critical to=20 > > support by those well versed in transport network architectures. > >=20 > >=20 > >=20 > > * what capabilities of BFD for multipoint networks=20 > > required for use as CV/CC in MPLS-TP > >=20 > > DW: Certainly in the MP scenario. As discussed in the preso=20 > > by Rahul at the meeting it can also be used if there is no=20 > > return path (odd network design). > >=20 > >=20 > > * what of capabilities are optional (can and may) > >=20 > > DW: As you saw in the preso, many capabilities and scenarios=20 > > were presented.The point of the preso was they there were all=20 > > optional and that if any of the options were *ever* desired=20 > > then pure unidirectional MP BFD was not a good choice. > >=20 > >=20 > > * are there any capabilities that would not be supported=20 > > (should not and must not) > >=20 > > As was demonstrated in presentation of David's analysis by=20 > > Rahul today, within BFD for MPLS one can create=20 > > unidirectional BFD session already, assuming that the DCN=20 > > exists in some form. > >=20 > > DW: And really only useful if there is never, ever a return path. > >=20 > > Thus it leave p2mp LSP that can benefit from use of BFD for=20 > > multipoint networks mechanism. Or a root can "pretend" that=20 > > p2mp LSP is p2p and send after first exchange of=20 > > Discriminator, and ignore Discrminators from other,=20 > > late-joiner leaves. > >=20 > > Regards, > > Greg > >=20 > >=20 > >=20 > > HIH > >=20 > > -DWard > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From benjamin.niven-jenkins@bt.com Fri Apr 2 04:40:40 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB923A677E; Fri, 2 Apr 2010 04:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QepXBhwLBJSx; Fri, 2 Apr 2010 04:40:39 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 6C39B3A6900; Fri, 2 Apr 2010 04:38:59 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 2 Apr 2010 12:39:15 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.222]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 2 Apr 2010 12:39:32 +0100 From: To: , Date: Fri, 2 Apr 2010 12:39:28 +0100 Thread-Topic: [CCAMP] [mpls] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 Thread-Index: AcrL8UXTy/5QKB/HSvmNL816886NAAABtBiAAZhELCQ= Message-ID: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, CCAMP@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:40:40 -0000 LOL, if only I had got around to reading this e-mail yesterday :-) Ben On 25/03/2010 08:52, "Alexander Vainshtein" wrote: > Adrian, > Lots of thanks for pointing to 5513, I've missed its publication. > IMHO and FWIW (which are not covered by 5513) it is extremely relevant fo= r the > MPLS-TP project. > Do you consider 5513bis to cover MPLS-TP? >=20 > Regards, > Sasha >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, March 25, 2010 9:56 AM > To: Alexander Vainshtein; Vivien Sterling > Cc: mpls@ietf.org; CCAMP@ietf.org; mpls-tp@ietf.org > Subject: Re: [CCAMP] [mpls] Term "PSC" > indraft-ietf-mpls-tp-linear-protection-01 >=20 > For issues related to clashes of acronyms please see RFC 5513. >=20 >=20 > ----- Original Message ----- > From: "Alexander Vainshtein" > To: "Vivien Sterling" > Cc: ; ; > Sent: Wednesday, March 24, 2010 8:30 AM > Subject: Re: [CCAMP] [mpls] Term "PSC" > indraft-ietf-mpls-tp-linear-protection-01 >=20 >=20 > Vivien and all, > AFAIK, PSC stands for "Protection State Coordination" in the MPLS-TP > parlance (see MPLS-TP Survivability > Framework) > - a new fancy name for what has been known as "APS Protocol" in SONET/SDH= . >=20 > As you've noted, it has a completely different meaning in GMPLS. >=20 > Since GMPLS is going to be used with MPLS-TP, double usage of this acrony= m > looks highly problematic. >=20 > Regards, > Sasha >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Vivien Sterling > Sent: Wednesday, March 24, 2010 10:21 AM > To: CCAMP@ietf.org; mpls@ietf.org; mpls-tp@ietf.org > Subject: [mpls] Term "PSC" in draft-ietf-mpls-tp-linear-protection-01 >=20 > Dear Experts, >=20 > I'm surprised to find the term "PSC" used in this draft. I suppose the > authors are talking about data plane not control plane, right? Isn't PSC = in > GMPLS elaborated as "Packet Switch Capable" ? It's confusing :-( >=20 > -- > Cheers, > Vivien >=20 >=20 >=20 > -------------------------------------------------------------------------= ----- > -- >=20 >=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From benjamin.niven-jenkins@bt.com Fri Apr 2 04:46:02 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E897D3A683B; Fri, 2 Apr 2010 04:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRcPBOksAQNx; Fri, 2 Apr 2010 04:46:02 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id C8D283A67E7; Fri, 2 Apr 2010 04:46:01 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 2 Apr 2010 12:46:18 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.222]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 2 Apr 2010 12:46:34 +0100 From: To: , Date: Fri, 2 Apr 2010 12:46:29 +0100 Thread-Topic: [mpls] [CCAMP] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 Thread-Index: AcrMKNK8FWUFkFW/SVqIiiY2J/JcfQGMU8b4 Message-ID: In-Reply-To: <67ec4be61003250738v272809bcwd339d5771566f390@mail.gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cecil.Byles@interoute.com, mpls@ietf.org, CCAMP@ietf.org, Alexander.Vainshtein@ecitele.com, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:46:03 -0000 Zhi, Thanks, I understand you perspective. However I suspect other operators may target their existing data network operations staff to maintain and operate an MPLS-TP network! The functionality needs to be as aligned to existing practices (MPLS and Transport) as possible. Re-learning/Re-definition of existing operations processes should be minimised but given that MPLS-TP is bridging a gap between data and transport networks some relearning on both sides is inevitable. HTH Ben On 25/03/2010 14:38, "Zhi-Wei Lin" wrote: > Hi, >=20 > I like to give my perspective. As a small network company (but one of the > largest transit agencies), we have a small operating staff split into two > groups: one that handles traditional data network (Ethernet, IP), and one= that > handles transport network (SONET, WDM). >=20 > We are targeting the transport network operating staff to maintain and op= erate > the MPLS-TP network. As such, anything that will help to reduce the learn= ing > curve (less training), simplify operating, and make the MOP as consistent= as > possible between SONET and MPLS-TP would be hugely beneficial. >=20 > Obviously there will be some differences since MPLS-TP is a packet-based > transport network, but the standards groups (I don't really care for poli= tics > of IETF and ITU) should strive to make these differences easy to learn. >=20 > Thanks > Zhi >=20 >=20 > On Thu, Mar 25, 2010 at 2:09 AM, Curtis Villamizar > > wrote: >=20 > In message=20 > <4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com>> > "Cecil Byles" writes: >>=20 >>=20 >> Hi, >> Can I therefore also asked how PSC "Protection State Coordination" in >> the MPLS-TP parlance align with ITU-T 808.1 recommendation that "defines >> the generic functional models, characteristics and processes associated >> with various linear protection schemes for connection-oriented layer >> networks; e.g., Optical Transport Networks (OTN), Synchronous Digital >> Hierarchy (SDH) networks and Asynchronous Transfer Mode (ATM) networks" >> and the sections covering Terms and Definitions as well as >> Abbreviations. IMO all transport engineers and the general telecom >> community understand that 1+1 or 1:1 are either SNCP or APS. Hence why >> introduce a new TLA (three letter abbreviation) cover the same function >> and feature for MPLS-TP. I can only agree that this will only cause >> confusion. >>=20 >> Cecil Byles >=20 >=20 > Though this is joint work, this is the IETF not the ITU. We should > use ITU terms where appropriate but where there is a conflict such as > this we need to pick another term and another TLA. If the ITU wants > to update 808.1 at some later date that is up to the ITU. In the mean > time we can use another term and point out the mapping. >=20 > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From tom.nadeau@bt.com Fri Apr 2 04:56:52 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823463A6880; Fri, 2 Apr 2010 04:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.837 X-Spam-Level: *** X-Spam-Status: No, score=3.837 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSoJ8zfrB+5m; Fri, 2 Apr 2010 04:56:51 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D32FD3A683B; Fri, 2 Apr 2010 04:56:50 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 12:57:23 +0100 Received: from 217.32.164.178 ([217.32.164.178]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.147]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 11:57:22 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 02 Apr 2010 07:57:21 -0400 From: "Thomas D. Nadeau" To: , , David Ward , Message-ID: Thread-Topic: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC Thread-Index: AcrQ78RiTb4mk2XZROmS1Vem8f3WygAvQ+awACPdhCAAB9caVQ== In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C05C64B06@E03MVB2-UKBR.domain1.systemhost.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 02 Apr 2010 11:57:23.0594 (UTC) FILETIME=[A80076A0:01CAD25B] Cc: mpls@ietf.org, David Ward , msiva@cisco.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:56:52 -0000 Neil, While such mis-configuration may be a problem as you discuss, one of th= e major problems with Y.1711 was that it mandated a fixed time interval for operations. The majority of operators I worked with at the time found this to be a a non-starter. Actually their Operations people did. The operational requirements for MPLS-TP should not be to revisit this mistake again, but instead to require consistency, or mechanisms to reconcile the differences in cases where it is critical to discern them. Flexibility with consistency is what we need to aim for here. --Tom > Italo,=20 >=20 > Many years ago when drafting Y.1710/1711 I pointed out that having differ= ent > CV rates in a network would cause 'alarm cycling' problems under cases of > misconnectivity, eg a trail with a CV rate of 1 per minute misconnected (= ie > merged) into a trail with a CV rate of 1 per sec will cause a behaviour o= f (i) > declare defect and take consequent actions at t=3DT (eg could include invok= ing > prot-sw as per Anamaria's slide), (ii) declare defect cleared at t=3DT+3 an= d > remove all consequent actions (maybe even switch traffic back to old path= at > some point?), (iii) declare defect again at t=3DT+60...and continue to repe= at > this cycle. >=20 > If there are N different CV rates in a network then there will be a numbe= r of > 'select 2 from N' combinatorial defect cases to deal with....not a great = idea, > so I would strongly suggest that the CV rate be consistent in a given lay= er > network. >=20 > BTW - if you set the CV rate too fast you run the danger of declaring def= ects, > and taking unnecessary consequent actions, on error bursts that could cle= ar of > their own accord. >=20 > Defect detection OAM should always be unidirectional in nature in co mode > layer networks....the p2mp case clearly shows why this is required......n= oting > that consequent actions are also unidirectional in nature and taken at th= e > trail sink, eg activation/suspension of perf counters, raise local alarm,= etc. >=20 > The CV (or BFD) packet should contain the proper trail source address for= that > layer network...not some arbitrary source generated identifier. This doe= s > assume of course that the layer network being considered has been given d= ecent > addressing in the first place.....not the case with MPLS and for sure not= with > PWs! >=20 > One can piggy-back BDI flag in CV for the p2p case but not the p2mp case. >=20 >=20 > I would also advise forward-looking caution and clarity on these points: >=20 > 1 Before committing to any TCM be very clear how nested TCM levels are > configured and activated/deactivated (including synchronisation of any pe= rf > mon counts) across failure and restore events. Only the true end points = of > trails always remain invariant across failure/restore events. >=20 > 2 Note that in a transport network if one direction enters the unavailabl= e > state then both directions are deemed unavailable. The key point here is= that > any perf monitoring for SLAs must be suspended in both directions for the > duration of the unavailability event. And from above point, this applies= to > all nested TCM levels. >=20 > 3 From transparency considerations a (parent) connection should only have= a > single CoS for its (child) traffic units. However, it seems possible tha= t > this arch requirement could be violated. In such a case there will be a = need > to consider how the entry/exit criteria of the unavailable state (and all= the > consequent actions that would apply) is to be defined for the (parent) > connection based on some weighted combinatorial of loss/delay in the (chi= ld) > traffic units of each CoS. .....I have mentioned some of these consequen= tial > action considerations above wrt to suspending perf mon counts in both > directions and across all nested TCM levels. The right answer here of co= urse > is don't create this problem in the first place, ie a connection should o= nly > have a single CoS level. >=20 > regards, Neil >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of BUSI ITALO >> Sent: 02 April 2010 08:58 >> To: David Ward; Greg Mirsky >> Cc: mpls@ietf.org; David Ward (wardd); Siva Sivabalan(msiva); >> mpls-tp@ietf.org; Sami Boutros >> Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC >>=20 >> Dave, Greg, >>=20 >> I think we are mixing different aspect of requirements, >> solutions and consequences if requirements are not met. >>=20 >> The requirements have been expressed more than once but I >> think that "repetita juvant": >>=20 >> - we need a very simple and lightweight protocol that check >> continuity and connectivity ("are you there?" question with a >> "yes/no" answer) >>=20 >> - this check must be performed at a rate that is fully >> controlled by the operator (and not by the network) >>=20 >> - the rate must not change in any condition (only the >> operator can change it) >>=20 >> - the return path is required only on bidirectional p2p paths >> (either associated or co-routed) just to carry the RDI indication >>=20 >> There are many consequences if the requirements are not met. >>=20 >> One of these consequences is described in the last slide of >> Annamaria's presentation done in Anaheim: >>=20 >> http://tools.ietf.org/agenda/77/slides/mpls-24.ppt >>=20 >> Unidirectional BFD is not the only solution to address this >> requirement. >>=20 >> An alternative solution was also presented in >> draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi. >>=20 >> Italo >>=20 >> P.S. Please note my new email address, >> Italo.Busi@alcatel-lucent.com, effective since 1 November 2009. >>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >> On Behalf=20 >>> Of David Ward >>> Sent: mercoled=EC 31 marzo 2010 18.33 >>> To: Greg Mirsky >>> Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward; Sami Boutros; >>> David Ward (wardd); mpls-tp@ietf.org >>> Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC >>>=20 >>> Greg - >>>=20 >>> On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote: >>>=20 >>> I haven't seen any response from authors thus assuming that >> it didn't=20 >>> make to the list the first time. >>>=20 >>> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky >>> > wrote: >>> Dear Authors and All, >>> I would like to ask several questions related to the subject I've >>> asked at the meeting today: >>>=20 >>> * what are reasons considered to select only >>> unidirectional BFD (based on BFD for multipoint networks >>> work) for proactive CV/CC >>>=20 >>> DW: This requirement has been bantered back and forth by the group. >>> Although not completely explained, it's been deemed critical to >>> support by those well versed in transport network architectures. >>>=20 >>>=20 >>>=20 >>> * what capabilities of BFD for multipoint networks >>> required for use as CV/CC in MPLS-TP >>>=20 >>> DW: Certainly in the MP scenario. As discussed in the preso >>> by Rahul at the meeting it can also be used if there is no >>> return path (odd network design). >>>=20 >>>=20 >>> * what of capabilities are optional (can and may) >>>=20 >>> DW: As you saw in the preso, many capabilities and scenarios >>> were presented.The point of the preso was they there were all >>> optional and that if any of the options were *ever* desired >>> then pure unidirectional MP BFD was not a good choice. >>>=20 >>>=20 >>> * are there any capabilities that would not be supported >>> (should not and must not) >>>=20 >>> As was demonstrated in presentation of David's analysis by >>> Rahul today, within BFD for MPLS one can create >>> unidirectional BFD session already, assuming that the DCN >>> exists in some form. >>>=20 >>> DW: And really only useful if there is never, ever a return path. >>>=20 >>> Thus it leave p2mp LSP that can benefit from use of BFD for >>> multipoint networks mechanism. Or a root can "pretend" that >>> p2mp LSP is p2p and send after first exchange of >>> Discriminator, and ignore Discrminators from other, >>> late-joiner leaves. >>>=20 >>> Regards, >>> Greg >>>=20 >>>=20 >>>=20 >>> HIH >>>=20 >>> -DWard >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From wwwrun@core3.amsl.com Fri Apr 2 05:28:02 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AEE653A687F; Fri, 2 Apr 2010 05:28:02 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100402122802.AEE653A687F@core3.amsl.com> Date: Fri, 2 Apr 2010 05:28:02 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, sob@harvard.edu, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "OPSAWG working group last call on ""The OAM Acronym Soup"" (ref #025.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 12:28:02 -0000 Title: OPSAWG working group last call on ""The OAM Acronym Soup"" (ref #025.01) Submission Date: 2010-04-02 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=861 Please reply by 2010-04-20 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com sob@harvard.edu Technical Contact: loa.andersson@ericsson.com sob@harvard.edu Purpose: For action Body: OPSAWG working group last call on ""The OAM Acronym Soup"" (ref #025.01) draft-ietf-opsawg-mpls-tp-oam-def-03 SG15, Q9, Q10, Q12 and Q14 We like to to inform you that we have just started an OPSAWG working group last call on "MPLS Transport Profile Data Plane Architecture" (draft-ietf-opsawg-mpls-tp-oam-def-03). We would like to receive comments from the ITU-T by April 20th 2010. Loa Andersson on behalf of Scott Bradner and Chris Liljenstolpe OPSA Working Group co-chairs Attachment(s): No document has been attached From sriganesh.kini@ericsson.com Fri Apr 2 06:11:10 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606713A69BC; Fri, 2 Apr 2010 06:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.25 X-Spam-Level: X-Spam-Status: No, score=-5.25 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrZfnwegXu0J; Fri, 2 Apr 2010 06:11:09 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6E9F33A6845; Fri, 2 Apr 2010 06:11:09 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o32DFU2M017872; Fri, 2 Apr 2010 08:15:30 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 2 Apr 2010 09:11:41 -0400 From: Sriganesh Kini To: Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Fri, 2 Apr 2010 09:11:41 -0400 Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBc0WnZb3W+AQWTpuJTuXgXymZDgQ8Q2Qw Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F52E4835FCC@EUSAACMS0703.eamcs.ericsson.se> References: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> In-Reply-To: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 13:11:10 -0000 Hi, 1) section 5.1 - "At each endpoint a tunnel is uniquely identified by the S= ource Node_ID and a locally assigned tunnel number." a) Should "Source" be replaced by the "endpoint's" since later the "Dst-= Node_ID" is used? b) Useful to clarify the scope of "uniquely identified" before this stat= ement.=20 C) Should there be a similar identifier at each intermediate node beside= s the endpoints? 2) Section 5.2 - Does any LSR own the "LSP_num" space? If so pls state that= . Thanks - Sri =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Thursday, March 11, 2010 3:33 PM > To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >=20 > All, >=20 > this is to start an MPLS working group last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > There is a discussion on the OAM model for MS-PWs where we=20 > haven't been able to come to conclusion. Once we reach=20 > agreement the document will be updated. Comments in this area=20 > are welcome during the working group last call. >=20 >=20 > Please send your comments to the mpls-tp@ietf.org mailing list. >=20 > The working group last ends eob April 2nd. >=20 > /Loa >=20 > -- >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager > Ericsson /// > phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 > email: loa.andersson@ericsson.com > loa@pi.nu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From jwhittin@mitre.org Fri Apr 2 07:36:55 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DC13A68E0 for ; Fri, 2 Apr 2010 07:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeIVTZcABkeU for ; Fri, 2 Apr 2010 07:36:54 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id B32743A688D for ; Fri, 2 Apr 2010 07:36:54 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o32EbSYQ000314 for ; Fri, 2 Apr 2010 10:37:28 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o32EbSoF000311 for ; Fri, 2 Apr 2010 10:37:28 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 2 Apr 2010 10:37:28 -0400 From: "Whittington, Joel L." To: "mpls@ietf.org" Date: Fri, 2 Apr 2010 10:37:24 -0400 Thread-Topic: unsubscribe Thread-Index: AcrScgJCf0bWD8SsTGGisxudE+bX5A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D24C564ACEAD16459EF2526E1D7D605D0C6EB7B86BIMCMBX3MITREO_" MIME-Version: 1.0 Subject: [mpls] unsubscribe X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:36:55 -0000 --_000_D24C564ACEAD16459EF2526E1D7D605D0C6EB7B86BIMCMBX3MITREO_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_D24C564ACEAD16459EF2526E1D7D605D0C6EB7B86BIMCMBX3MITREO_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

--_000_D24C564ACEAD16459EF2526E1D7D605D0C6EB7B86BIMCMBX3MITREO_-- From neil.2.harrison@bt.com Fri Apr 2 07:47:05 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20873A6850; Fri, 2 Apr 2010 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[AWL=-1.516, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_62=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYlAphJcO8+3; Fri, 2 Apr 2010 07:47:04 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 219D43A6808; Fri, 2 Apr 2010 07:47:03 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 15:47:36 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2010 15:47:29 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05C64B45@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC Thread-Index: AcrQ78RiTb4mk2XZROmS1Vem8f3WygAvQ+awACPdhCAAB9caVQAFsRrg From: To: , , , X-OriginalArrivalTime: 02 Apr 2010 14:47:36.0414 (UTC) FILETIME=[6F511FE0:01CAD273] Cc: mpls@ietf.org, wardd@cisco.com, msiva@cisco.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:47:05 -0000 Just be a bit careful here Tom....if one has SLAs to meet then one needs = a consistent method of measurement. Maybe not such a big issue in = isolated operator layer networks, but if there is any requirement to = interwork then consistent availability and performance = metrics/objectives will need defining. However, the major point wrt the alarm cycling issue is consistent use = of CV rates within the same layer network....whatever the chosen rate. regards, Neil > -----Original Message----- > From: Nadeau,TD,Tom,DEE1 R=20 > Sent: 02 April 2010 12:57 > To: Harrison,N,Neil,DKQ7 R; Italo.Busi@alcatel-lucent.com;=20 > David Ward; gregimirsky@gmail.com > Cc: mpls@ietf.org; mpls-tp@ietf.org; msiva@cisco.com; David Ward > Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode=20 > for proactive CV/CC >=20 >=20 >=20 > Neil, >=20 > While such mis-configuration may be a problem as you=20 > discuss, one of the major problems with Y.1711 was that it=20 > mandated a fixed time interval for operations. The majority=20 > of operators I worked with at the time found this to be a a=20 > non-starter. Actually their Operations people did. >=20 > The operational requirements for MPLS-TP should not be to=20 > revisit this mistake again, but instead to require=20 > consistency, or mechanisms to reconcile the differences in=20 > cases where it is critical to discern them. > Flexibility with consistency is what we need to aim for here. >=20 > --Tom >=20 >=20 > > Italo, > >=20 > > Many years ago when drafting Y.1710/1711 I pointed out that having=20 > > different CV rates in a network would cause 'alarm cycling'=20 > problems=20 > > under cases of misconnectivity, eg a trail with a CV rate of 1 per=20 > > minute misconnected (ie > > merged) into a trail with a CV rate of 1 per sec will cause a=20 > > behaviour of (i) declare defect and take consequent actions=20 > at t=3DT (eg=20 > > could include invoking prot-sw as per Anamaria's slide),=20 > (ii) declare=20 > > defect cleared at t=3DT+3 and remove all consequent actions=20 > (maybe even=20 > > switch traffic back to old path at some point?), (iii)=20 > declare defect=20 > > again at t=3DT+60...and continue to repeat this cycle. > >=20 > > If there are N different CV rates in a network then there will be a=20 > > number of 'select 2 from N' combinatorial defect cases to deal=20 > > with....not a great idea, so I would strongly suggest that=20 > the CV rate=20 > > be consistent in a given layer network. > >=20 > > BTW - if you set the CV rate too fast you run the danger of=20 > declaring=20 > > defects, and taking unnecessary consequent actions, on error bursts=20 > > that could clear of their own accord. > >=20 > > Defect detection OAM should always be unidirectional in=20 > nature in co=20 > > mode layer networks....the p2mp case clearly shows why this is=20 > > required......noting that consequent actions are also=20 > unidirectional=20 > > in nature and taken at the trail sink, eg=20 > activation/suspension of perf counters, raise local alarm, etc. > >=20 > > The CV (or BFD) packet should contain the proper trail=20 > source address=20 > > for that layer network...not some arbitrary source generated=20 > > identifier. This does assume of course that the layer=20 > network being=20 > > considered has been given decent addressing in the first=20 > place.....not=20 > > the case with MPLS and for sure not with PWs! > >=20 > > One can piggy-back BDI flag in CV for the p2p case but not=20 > the p2mp case. > >=20 > >=20 > > I would also advise forward-looking caution and clarity on=20 > these points: > >=20 > > 1 Before committing to any TCM be very clear how nested TCM=20 > levels are=20 > > configured and activated/deactivated (including=20 > synchronisation of any=20 > > perf mon counts) across failure and restore events. Only=20 > the true end=20 > > points of trails always remain invariant across=20 > failure/restore events. > >=20 > > 2 Note that in a transport network if one direction enters the=20 > > unavailable state then both directions are deemed unavailable. The=20 > > key point here is that any perf monitoring for SLAs must be=20 > suspended=20 > > in both directions for the duration of the unavailability=20 > event. And=20 > > from above point, this applies to all nested TCM levels. > >=20 > > 3 From transparency considerations a (parent) connection=20 > should only=20 > > have a single CoS for its (child) traffic units. However, it seems=20 > > possible that this arch requirement could be violated. In=20 > such a case=20 > > there will be a need to consider how the entry/exit criteria of the=20 > > unavailable state (and all the consequent actions that=20 > would apply) is=20 > > to be defined for the (parent) connection based on some weighted=20 > > combinatorial of loss/delay in the (child) traffic units of=20 > each CoS. =20 > > .....I have mentioned some of these consequential action=20 > > considerations above wrt to suspending perf mon counts in both=20 > > directions and across all nested TCM levels. The right=20 > answer here of=20 > > course is don't create this problem in the first place, ie=20 > a connection should only have a single CoS level. > >=20 > > regards, Neil > >=20 > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > >> Of BUSI ITALO > >> Sent: 02 April 2010 08:58 > >> To: David Ward; Greg Mirsky > >> Cc: mpls@ietf.org; David Ward (wardd); Siva Sivabalan(msiva);=20 > >> mpls-tp@ietf.org; Sami Boutros > >> Subject: Re: [mpls] Choice of BFD mechanism/mode for=20 > proactive CV/CC > >>=20 > >> Dave, Greg, > >>=20 > >> I think we are mixing different aspect of requirements,=20 > solutions and=20 > >> consequences if requirements are not met. > >>=20 > >> The requirements have been expressed more than once but I=20 > think that=20 > >> "repetita juvant": > >>=20 > >> - we need a very simple and lightweight protocol that check=20 > >> continuity and connectivity ("are you there?" question with a=20 > >> "yes/no" answer) > >>=20 > >> - this check must be performed at a rate that is fully=20 > controlled by=20 > >> the operator (and not by the network) > >>=20 > >> - the rate must not change in any condition (only the operator can=20 > >> change it) > >>=20 > >> - the return path is required only on bidirectional p2p=20 > paths (either=20 > >> associated or co-routed) just to carry the RDI indication > >>=20 > >> There are many consequences if the requirements are not met. > >>=20 > >> One of these consequences is described in the last slide of=20 > >> Annamaria's presentation done in Anaheim: > >>=20 > >> http://tools.ietf.org/agenda/77/slides/mpls-24.ppt > >>=20 > >> Unidirectional BFD is not the only solution to address this=20 > >> requirement. > >>=20 > >> An alternative solution was also presented in=20 > >> draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi. > >>=20 > >> Italo > >>=20 > >> P.S. Please note my new email address,=20 > Italo.Busi@alcatel-lucent.com,=20 > >> effective since 1 November 2009. > >>=20 > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > >> On Behalf > >>> Of David Ward > >>> Sent: mercoled=EC 31 marzo 2010 18.33 > >>> To: Greg Mirsky > >>> Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward;=20 > Sami Boutros;=20 > >>> David Ward (wardd); mpls-tp@ietf.org > >>> Subject: Re: [mpls] Choice of BFD mechanism/mode for=20 > proactive CV/CC > >>>=20 > >>> Greg - > >>>=20 > >>> On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote: > >>>=20 > >>> I haven't seen any response from authors thus assuming that > >> it didn't > >>> make to the list the first time. > >>>=20 > >>> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky=20 > >>> > wrote: > >>> Dear Authors and All, > >>> I would like to ask several questions related to the subject I've=20 > >>> asked at the meeting today: > >>>=20 > >>> * what are reasons considered to select only > >>> unidirectional BFD (based on BFD for multipoint networks > >>> work) for proactive CV/CC > >>>=20 > >>> DW: This requirement has been bantered back and forth by=20 > the group. > >>> Although not completely explained, it's been deemed critical to=20 > >>> support by those well versed in transport network architectures. > >>>=20 > >>>=20 > >>>=20 > >>> * what capabilities of BFD for multipoint networks > >>> required for use as CV/CC in MPLS-TP > >>>=20 > >>> DW: Certainly in the MP scenario. As discussed in the=20 > preso by Rahul=20 > >>> at the meeting it can also be used if there is no return=20 > path (odd=20 > >>> network design). > >>>=20 > >>>=20 > >>> * what of capabilities are optional (can and may) > >>>=20 > >>> DW: As you saw in the preso, many capabilities and scenarios were=20 > >>> presented.The point of the preso was they there were all optional=20 > >>> and that if any of the options were *ever* desired then pure=20 > >>> unidirectional MP BFD was not a good choice. > >>>=20 > >>>=20 > >>> * are there any capabilities that would not be supported > >>> (should not and must not) > >>>=20 > >>> As was demonstrated in presentation of David's analysis by Rahul=20 > >>> today, within BFD for MPLS one can create unidirectional=20 > BFD session=20 > >>> already, assuming that the DCN exists in some form. > >>>=20 > >>> DW: And really only useful if there is never, ever a return path. > >>>=20 > >>> Thus it leave p2mp LSP that can benefit from use of BFD for=20 > >>> multipoint networks mechanism. Or a root can "pretend"=20 > that p2mp LSP=20 > >>> is p2p and send after first exchange of Discriminator, and ignore=20 > >>> Discrminators from other, late-joiner leaves. > >>>=20 > >>> Regards, > >>> Greg > >>>=20 > >>>=20 > >>>=20 > >>> HIH > >>>=20 > >>> -DWard > >>>=20 > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >>>=20 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >>=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 >=20 >=20 From hhelvoort@chello.nl Fri Apr 2 08:23:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919E23A6808; Fri, 2 Apr 2010 08:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.919 X-Spam-Level: ** X-Spam-Status: No, score=2.919 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlqrweHr2gVG; Fri, 2 Apr 2010 08:23:12 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id E387E3A677C; Fri, 2 Apr 2010 08:23:09 -0700 (PDT) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep17-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100402152342.NMI27633.viefep17-int.chello.at@edge04.upcmail.net>; Fri, 2 Apr 2010 17:23:42 +0200 Received: from [172.31.13.84] ([220.231.44.196]) by edge04.upcmail.net with edge id 0fPe1e03T4DxPhG04fPgzR; Fri, 02 Apr 2010 17:23:42 +0200 X-SourceIP: 220.231.44.196 Message-ID: <4BB60BFA.2010904@chello.nl> Date: Fri, 02 Apr 2010 17:23:38 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: mpls-tp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=6UHAxsHwKCW0savQ7OVzrMBW5xvCzGO/qK2+m6qSwq4= c=1 sm=0 a=Vw6OewDgDZ8A:10 a=8nJEP1OIZ-IA:10 a=trSf93moyfsz9Fhy1wsA:9 a=1fuPMvwlCh1HW2Q13D0A:7 a=PH3h_dcFEhBGQTcVlgRywvdVMDIA:4 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: mpls@ietf.org Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 15:23:14 -0000 Hello Tom, You wrote: > The operational requirements for MPLS-TP should not be to revisit this > mistake again, but instead to require consistency, or mechanisms to > reconcile the differences in cases where it is critical to discern them. The two major differences from an operational point of view are operators used to maintain an MPLS network and operators used to maintain a transport network. Reconciling these differences requires compromises that will give both of them a hard time. > Flexibility with consistency is what we need to aim for here. Consistency for each kind of operator can be addressed by designing two sets of OAM tools for MPLS-T: -- a set of tools for the MPLS operators, and -- a set of tools for the transport network operators Flexibility can be addressed by allowing the operator to select/provision only one of the two toolsets at the same time. Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From benjamin.niven-jenkins@bt.com Fri Apr 2 08:30:26 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675D73A6821; Fri, 2 Apr 2010 08:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=1.405, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alXRGzr1bARB; Fri, 2 Apr 2010 08:30:25 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id E54FB3A67DA; Fri, 2 Apr 2010 08:30:24 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 2 Apr 2010 16:30:41 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.222]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 2 Apr 2010 16:30:57 +0100 From: To: , , Date: Fri, 2 Apr 2010 16:30:52 +0100 Thread-Topic: [mpls] [CCAMP] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 Thread-Index: AcrMKNK8FWUFkFW/SVqIiiY2J/JcfQGMU8b4AAVl4mwAAnBDYw== Message-ID: In-Reply-To: <436B49B8E459C54C8B47A7826292AFB4027A09@NYCTEXVS06.transit.nyct.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cecil.Byles@interoute.com, mpls@ietf.org, CCAMP@ietf.org, Alexander.Vainshtein@ecitele.com, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 15:30:26 -0000 Zhi, I suspect your requirement is to keep the operational procedures (MOP) for MPLS-TP as closely aligned to those of your existing transport network as possible. In other words if scenario A occurs, operations need to follow steps B, C and D etc. where the functions of A, B, C and D are as similar a= s possible for MPLS-TP and your existing transport network. Whether the protection switching mechanism is called APS or FOO is a very minor point in the overall operations procedure, otherwise I suspect your operations personnel are going to really struggle with MPLS-TP with its introduction of other new acronyms Vs transport networks like LSP, PW, BFD etc ;-) Ben On 02/04/2010 15:26, "Lin, Zhi-Wei" wrote: > Hi Ben, >=20 > Yes, definitely there are other operators with different operational > considerations. I was offering my perspective and what my company plans t= o do. >=20 > However, in terms of the acronyms, even if in your company you plan to ha= ve > your data group handle MPLS-TP, whether the term is "MPLS-TP APS" or "PSC= ", > from their perspective it will be a new term and therefore no difference = which > it should be. >=20 > However, for other operators (such as us) who plans to have the transport > personnel handle MPLS-TP, then "MPLS-TP APS" would make more sense. Again= , > functionally, our transport staff will need to be trained on specific > procedures associated with MPLS-TP, but anything that keeps things "simil= ar" > is better than nothing. >=20 > As such, MPLS-TP APS would be a better term that would make more operator= s' > life easier, yes? >=20 > Thanks > Zhi >=20 >=20 > ________________________________ > From: mpls-bounces@ietf.org on behalf of benjamin.niven-jenkins@bt.com > Sent: Fri 4/2/2010 7:46 AM > To: zhiwlin@gmail.com; curtis@occnc.com > Cc: Cecil.Byles@interoute.com; mpls@ietf.org; CCAMP@ietf.org; > Alexander.Vainshtein@ecitele.com; mpls-tp@ietf.org > Subject: Re: [mpls] [CCAMP] [mpls-tp] Term > "PSC"indraft-ietf-mpls-tp-linear-protection-01 >=20 >=20 > Zhi, >=20 > Thanks, I understand you perspective. >=20 > However I suspect other operators may target their existing data network > operations staff to maintain and operate an MPLS-TP network! >=20 > The functionality needs to be as aligned to existing practices (MPLS and > Transport) as possible. Re-learning/Re-definition of existing operations > processes should be minimised but given that MPLS-TP is bridging a gap > between data and transport networks some relearning on both sides is > inevitable. >=20 > HTH > Ben >=20 >=20 >=20 > On 25/03/2010 14:38, "Zhi-Wei Lin" wrote: >=20 >> Hi, >>=20 >> I like to give my perspective. As a small network company (but one of th= e >> largest transit agencies), we have a small operating staff split into tw= o >> groups: one that handles traditional data network (Ethernet, IP), and on= e >> that >> handles transport network (SONET, WDM). >>=20 >> We are targeting the transport network operating staff to maintain and >> operate >> the MPLS-TP network. As such, anything that will help to reduce the lear= ning >> curve (less training), simplify operating, and make the MOP as consisten= t as >> possible between SONET and MPLS-TP would be hugely beneficial. >>=20 >> Obviously there will be some differences since MPLS-TP is a packet-based >> transport network, but the standards groups (I don't really care for pol= itics >> of IETF and ITU) should strive to make these differences easy to learn. >>=20 >> Thanks >> Zhi >>=20 >>=20 >> On Thu, Mar 25, 2010 at 2:09 AM, Curtis Villamizar >> > wrote: >>=20 >> In message >>=20 <4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com> 0 >> FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com>> >> "Cecil Byles" writes: >>>=20 >>>=20 >>> Hi, >>> Can I therefore also asked how PSC "Protection State Coordination" in >>> the MPLS-TP parlance align with ITU-T 808.1 recommendation that "define= s >>> the generic functional models, characteristics and processes associated >>> with various linear protection schemes for connection-oriented layer >>> networks; e.g., Optical Transport Networks (OTN), Synchronous Digital >>> Hierarchy (SDH) networks and Asynchronous Transfer Mode (ATM) networks" >>> and the sections covering Terms and Definitions as well as >>> Abbreviations. IMO all transport engineers and the general telecom >>> community understand that 1+1 or 1:1 are either SNCP or APS. Hence why >>> introduce a new TLA (three letter abbreviation) cover the same function >>> and feature for MPLS-TP. I can only agree that this will only cause >>> confusion. >>>=20 >>> Cecil Byles >>=20 >>=20 >> Though this is joint work, this is the IETF not the ITU. We should >> use ITU terms where appropriate but where there is a conflict such as >> this we need to pick another term and another TLA. If the ITU wants >> to update 808.1 at some later date that is up to the ITU. In the mean >> time we can use another term and point out the mapping. >>=20 >> Curtis >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From malcolm.betts@zte.com.cn Fri Apr 2 09:25:13 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047F43A684F; Fri, 2 Apr 2010 09:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.943 X-Spam-Level: X-Spam-Status: No, score=-97.943 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_81=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fsizg31ompu; Fri, 2 Apr 2010 09:25:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 271623A6829; Fri, 2 Apr 2010 09:25:08 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 303341911657480; Sat, 3 Apr 2010 00:23:56 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 23186.11959797249; Sat, 3 Apr 2010 00:22:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o32GPq9g053839; Sat, 3 Apr 2010 00:25:52 +0800 (CST) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C05C64B45@E03MVB2-UKBR.domain1.systemhost.net> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Fri, 2 Apr 2010 11:25:21 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-03 00:25:31, Serialize complete at 2010-04-03 00:25:31 Content-Type: multipart/alternative; boundary="=_alternative 005A358B852576F9_=" X-MAIL: mse2.zte.com.cn o32GPq9g053839 Cc: tom.nadeau@bt.com, Italo.Busi@alcatel-lucent.com, mpls@ietf.org, msiva@cisco.com, dward@juniper.net, mpls-tp-bounces@ietf.org, wardd@cisco.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 16:25:13 -0000 This is a multipart message in MIME format. --=_alternative 005A358B852576F9_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable All, I think the key point is that to avoid the alarm cycling the CV rate must=20 be consistent across the network. To achieve this the CV rate must be set = by the operator and not by negotiation along each path. Regards, Malcolm =20 Sent by: mpls-tp-bounces@ietf.org 02/04/2010 10:47 AM To , , , = cc mpls@ietf.org, wardd@cisco.com, msiva@cisco.com, mpls-tp@ietf.org Subject Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC Just be a bit careful here Tom....if one has SLAs to meet then one needs a = consistent method of measurement. Maybe not such a big issue in isolated=20 operator layer networks, but if there is any requirement to interwork then = consistent availability and performance metrics/objectives will need=20 defining. However, the major point wrt the alarm cycling issue is consistent use of=20 CV rates within the same layer network....whatever the chosen rate. regards, Neil > -----Original Message----- > From: Nadeau,TD,Tom,DEE1 R=20 > Sent: 02 April 2010 12:57 > To: Harrison,N,Neil,DKQ7 R; Italo.Busi@alcatel-lucent.com;=20 > David Ward; gregimirsky@gmail.com > Cc: mpls@ietf.org; mpls-tp@ietf.org; msiva@cisco.com; David Ward > Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode=20 > for proactive CV/CC >=20 >=20 >=20 > Neil, >=20 > While such mis-configuration may be a problem as you=20 > discuss, one of the major problems with Y.1711 was that it=20 > mandated a fixed time interval for operations. The majority=20 > of operators I worked with at the time found this to be a a=20 > non-starter. Actually their Operations people did. >=20 > The operational requirements for MPLS-TP should not be to=20 > revisit this mistake again, but instead to require=20 > consistency, or mechanisms to reconcile the differences in=20 > cases where it is critical to discern them. > Flexibility with consistency is what we need to aim for here. >=20 > --Tom >=20 >=20 > > Italo, > >=20 > > Many years ago when drafting Y.1710/1711 I pointed out that having=20 > > different CV rates in a network would cause 'alarm cycling'=20 > problems=20 > > under cases of misconnectivity, eg a trail with a CV rate of 1 per=20 > > minute misconnected (ie > > merged) into a trail with a CV rate of 1 per sec will cause a=20 > > behaviour of (i) declare defect and take consequent actions=20 > at t=3DT (eg=20 > > could include invoking prot-sw as per Anamaria's slide),=20 > (ii) declare=20 > > defect cleared at t=3DT+3 and remove all consequent actions=20 > (maybe even=20 > > switch traffic back to old path at some point?), (iii)=20 > declare defect=20 > > again at t=3DT+60...and continue to repeat this cycle. > >=20 > > If there are N different CV rates in a network then there will be a=20 > > number of 'select 2 from N' combinatorial defect cases to deal=20 > > with....not a great idea, so I would strongly suggest that=20 > the CV rate=20 > > be consistent in a given layer network. > >=20 > > BTW - if you set the CV rate too fast you run the danger of=20 > declaring=20 > > defects, and taking unnecessary consequent actions, on error bursts=20 > > that could clear of their own accord. > >=20 > > Defect detection OAM should always be unidirectional in=20 > nature in co=20 > > mode layer networks....the p2mp case clearly shows why this is=20 > > required......noting that consequent actions are also=20 > unidirectional=20 > > in nature and taken at the trail sink, eg=20 > activation/suspension of perf counters, raise local alarm, etc. > >=20 > > The CV (or BFD) packet should contain the proper trail=20 > source address=20 > > for that layer network...not some arbitrary source generated=20 > > identifier. This does assume of course that the layer=20 > network being=20 > > considered has been given decent addressing in the first=20 > place.....not=20 > > the case with MPLS and for sure not with PWs! > >=20 > > One can piggy-back BDI flag in CV for the p2p case but not=20 > the p2mp case. > >=20 > >=20 > > I would also advise forward-looking caution and clarity on=20 > these points: > >=20 > > 1 Before committing to any TCM be very clear how nested TCM=20 > levels are=20 > > configured and activated/deactivated (including=20 > synchronisation of any=20 > > perf mon counts) across failure and restore events. Only=20 > the true end=20 > > points of trails always remain invariant across=20 > failure/restore events. > >=20 > > 2 Note that in a transport network if one direction enters the=20 > > unavailable state then both directions are deemed unavailable. The=20 > > key point here is that any perf monitoring for SLAs must be=20 > suspended=20 > > in both directions for the duration of the unavailability=20 > event. And=20 > > from above point, this applies to all nested TCM levels. > >=20 > > 3 From transparency considerations a (parent) connection=20 > should only=20 > > have a single CoS for its (child) traffic units. However, it seems=20 > > possible that this arch requirement could be violated. In=20 > such a case=20 > > there will be a need to consider how the entry/exit criteria of the=20 > > unavailable state (and all the consequent actions that=20 > would apply) is=20 > > to be defined for the (parent) connection based on some weighted=20 > > combinatorial of loss/delay in the (child) traffic units of=20 > each CoS.=20 > > .....I have mentioned some of these consequential action=20 > > considerations above wrt to suspending perf mon counts in both=20 > > directions and across all nested TCM levels. The right=20 > answer here of=20 > > course is don't create this problem in the first place, ie=20 > a connection should only have a single CoS level. > >=20 > > regards, Neil > >=20 > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > >> Of BUSI ITALO > >> Sent: 02 April 2010 08:58 > >> To: David Ward; Greg Mirsky > >> Cc: mpls@ietf.org; David Ward (wardd); Siva Sivabalan(msiva);=20 > >> mpls-tp@ietf.org; Sami Boutros > >> Subject: Re: [mpls] Choice of BFD mechanism/mode for=20 > proactive CV/CC > >>=20 > >> Dave, Greg, > >>=20 > >> I think we are mixing different aspect of requirements,=20 > solutions and=20 > >> consequences if requirements are not met. > >>=20 > >> The requirements have been expressed more than once but I=20 > think that=20 > >> "repetita juvant": > >>=20 > >> - we need a very simple and lightweight protocol that check=20 > >> continuity and connectivity ("are you there?" question with a=20 > >> "yes/no" answer) > >>=20 > >> - this check must be performed at a rate that is fully=20 > controlled by=20 > >> the operator (and not by the network) > >>=20 > >> - the rate must not change in any condition (only the operator can=20 > >> change it) > >>=20 > >> - the return path is required only on bidirectional p2p=20 > paths (either=20 > >> associated or co-routed) just to carry the RDI indication > >>=20 > >> There are many consequences if the requirements are not met. > >>=20 > >> One of these consequences is described in the last slide of=20 > >> Annamaria's presentation done in Anaheim: > >>=20 > >> http://tools.ietf.org/agenda/77/slides/mpls-24.ppt > >>=20 > >> Unidirectional BFD is not the only solution to address this=20 > >> requirement. > >>=20 > >> An alternative solution was also presented in=20 > >> draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi. > >>=20 > >> Italo > >>=20 > >> P.S. Please note my new email address,=20 > Italo.Busi@alcatel-lucent.com,=20 > >> effective since 1 November 2009. > >>=20 > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > >> On Behalf > >>> Of David Ward > >>> Sent: mercoled=EC 31 marzo 2010 18.33 > >>> To: Greg Mirsky > >>> Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward;=20 > Sami Boutros;=20 > >>> David Ward (wardd); mpls-tp@ietf.org > >>> Subject: Re: [mpls] Choice of BFD mechanism/mode for=20 > proactive CV/CC > >>>=20 > >>> Greg - > >>>=20 > >>> On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote: > >>>=20 > >>> I haven't seen any response from authors thus assuming that > >> it didn't > >>> make to the list the first time. > >>>=20 > >>> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky=20 > >>> > wrote: > >>> Dear Authors and All, > >>> I would like to ask several questions related to the subject I've=20 > >>> asked at the meeting today: > >>>=20 > >>> * what are reasons considered to select only > >>> unidirectional BFD (based on BFD for multipoint networks > >>> work) for proactive CV/CC > >>>=20 > >>> DW: This requirement has been bantered back and forth by=20 > the group. > >>> Although not completely explained, it's been deemed critical to=20 > >>> support by those well versed in transport network architectures. > >>>=20 > >>>=20 > >>>=20 > >>> * what capabilities of BFD for multipoint networks > >>> required for use as CV/CC in MPLS-TP > >>>=20 > >>> DW: Certainly in the MP scenario. As discussed in the=20 > preso by Rahul=20 > >>> at the meeting it can also be used if there is no return=20 > path (odd=20 > >>> network design). > >>>=20 > >>>=20 > >>> * what of capabilities are optional (can and may) > >>>=20 > >>> DW: As you saw in the preso, many capabilities and scenarios were=20 > >>> presented.The point of the preso was they there were all optional=20 > >>> and that if any of the options were *ever* desired then pure=20 > >>> unidirectional MP BFD was not a good choice. > >>>=20 > >>>=20 > >>> * are there any capabilities that would not be supported > >>> (should not and must not) > >>>=20 > >>> As was demonstrated in presentation of David's analysis by Rahul=20 > >>> today, within BFD for MPLS one can create unidirectional=20 > BFD session=20 > >>> already, assuming that the DCN exists in some form. > >>>=20 > >>> DW: And really only useful if there is never, ever a return path. > >>>=20 > >>> Thus it leave p2mp LSP that can benefit from use of BFD for=20 > >>> multipoint networks mechanism. Or a root can "pretend"=20 > that p2mp LSP=20 > >>> is p2p and send after first exchange of Discriminator, and ignore=20 > >>> Discrminators from other, late-joiner leaves. > >>>=20 > >>> Regards, > >>> Greg > >>>=20 > >>>=20 > >>>=20 > >>> HIH > >>>=20 > >>> -DWard > >>>=20 > >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >>>=20 > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >>=20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 >=20 >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --=_alternative 005A358B852576F9_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
All,

I think the key point is that to avo= id the alarm cycling the CV rate must be consistent across the network.  = To achieve this the CV rate must be set by the operator and not by negotiation along each path.

Regards,

Malcolm




<neil.2.harrison@b= t.com>
Sent by: mpls-tp-bounces@ietf.org

02/04/2010 10:47 AM

To
<tom.nadeau@bt.com>, <Italo= .Busi@alcatel-lucent.com>, <dward@juniper.net>, <gregimirsky@gmail.com>
cc
mpls@ietf.org, wardd@cisco.com, msiv= a@cisco.com, mpls-tp@ietf.org
Subject
Re: [mpls-tp] [mpls] Choice of BFD m= echanism/mode for proactive        CV/CC





Just be a bit careful here Tom....if one has SLAs to meet then one needs a consistent method of measurement. Maybe not such a big issue in isolated operator layer networks, but if there is any requir= ement to interwork then consistent availability and performance metrics/objectives will need defining.

However, the major point wrt the alarm cycling issue is consistent use of CV rates within the same layer network....whatever the chosen rate.

regards, Neil



> -----Original Message-----
> From: Nadeau,TD,Tom,DEE1 R
> Sent: 02 April 2010 12:57
> To: Harrison,N,Neil,DKQ7 R; Italo.Busi@alcatel-lucent.com;
> David Ward; gregimirsky@gmail.com
> Cc: mpls@ietf.org; mpls-tp@ietf.org; msiva@cisco.com; David Ward
> Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode
> for proactive CV/CC
>
>
>
>     Neil,
>
>     While such mis-configuration may be a problem as you
> discuss, one of the major problems with Y.1711 was that it
> mandated a fixed time interval for operations. The majority
> of operators I worked with at the time found this to be a a
> non-starter. Actually their Operations people did.
>
>     The operational requirements for MPLS-TP should not be to
> revisit this mistake again, but instead to require
> consistency, or mechanisms to reconcile the differences in
> cases where it is critical to discern them.
> Flexibility with consistency is what we need to aim for here.
>
>     --Tom
>
>
> > Italo,
> >
> > Many years ago when drafting Y.1710/1711 I pointed out that having
> > different CV rates in a network would cause 'alarm cycling'
> problems
> > under cases of misconnectivity, eg a trail with a CV rate of 1 per
> > minute misconnected (ie
> > merged) into a trail with a CV rate of 1 per sec will cause a
> > behaviour of (i) declare defect and take consequent actions
> at t=3DT (eg
> > could include invoking prot-sw as per Anamaria's slide),
> (ii) declare
> > defect cleared at t=3DT+3 and remove all consequent actions
> (maybe even
> > switch traffic back to old path at some point?), (iii)
> declare defect
> > again at t=3DT+60...and continue to repeat this cycle.
> >
> > If there are N different CV rates in a network then there will be a
> > number of 'select 2 from N' combinatorial defect cases to deal
> > with....not a great idea, so I would strongly suggest that
> the CV rate
> > be consistent in a given layer network.
> >
> > BTW - if you set the CV rate too fast you run the danger of
> declaring
> > defects, and taking unnecessary consequent actions, on error bursts
> > that could clear of their own accord.
> >
> > Defect detection OAM should always be unidirectional in
> nature in co
> > mode layer networks....the p2mp case clearly shows why this is
> > required......noting that consequent actions are also
> unidirectional
> > in nature and taken at the trail sink, eg
> activation/suspension of perf counters, raise local alarm, etc.
> >
> > The CV (or BFD) packet should contain the proper trail
> source address
> > for that layer network...not some arbitrary source generated
> > identifier.  This does assume of course that the layer
> network being
> > considered has been given decent addressing in the first
> place.....not
> > the case with MPLS and for sure not with PWs!
> >
> > One can piggy-back BDI flag in CV for the p2p case but not
> the p2mp case.
> >
> >
> > I would also advise forward-looking caution and clarity on
> these points:
> >
> > 1 Before committing to any TCM be very clear how nested TCM
> levels are
> > configured and activated/deactivated (including
> synchronisation of any
> > perf mon counts) across failure and restore events.  Only
> the true end
> > points of trails always remain invariant across
> failure/restore events.
> >
> > 2 Note that in a transport network if one direction enters the
> > unavailable state then both directions are deemed unavailable.  The
> > key point here is that any perf monitoring for SLAs must be
> suspended
> > in both directions for the duration of the unavailability
> event.  And
> > from above point, this applies to all nested TCM levels.
> >
> > 3 From transparency considerations a (parent) connection
> should only
> > have a single CoS for its (child) traffic units.  However, it seems
> > possible that this arch requirement could be violated.  In
> such a case
> > there will be a need to consider how the entry/exit criteria of the
> > unavailable state (and all the consequent actions that
> would apply) is
> > to be defined for the (parent) connection based on some weighted
> > combinatorial of loss/delay in the (child) traffic units of
> each CoS.  
> > .....I have mentioned some of these consequential action
> > considerations above wrt to suspending perf mon counts in both
> > directions and across all nested TCM levels.  The right
> answer here of
> > course is don't create this problem in the first place, ie
> a connection should only have a single CoS level.
> >
> > regards, Neil
> >
> >> -----Original Message-----
> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]
> On Behalf
> >> Of BUSI ITALO
> >> Sent: 02 April 2010 08:58
> >> To: David Ward; Greg Mirsky
> >> Cc: mpls@ietf.org; David Ward (wardd); Siva Sivabalan(msiva);
> >> mpls-tp@ietf.org; Sami Boutros
> >> Subject: Re: [mpls] Choice of BFD mechanism/mode for
> proactive CV/CC
> >>
> >> Dave, Greg,
> >>
> >> I think we are mixing different aspect of requirements,
> solutions and
> >> consequences if requirements are not met.
> >>
> >> The requirements have been expressed more than once but I
> think that
> >> "repetita juvant":
> >>
> >> - we need a very simple and lightweight protocol that check
> >> continuity and connectivity ("are you there?" quest= ion with a
> >> "yes/no" answer)
> >>
> >> - this check must be performed at a rate that is fully
> controlled by
> >> the operator (and not by the network)
> >>
> >> - the rate must not change in any condition (only the operator can
> >> change it)
> >>
> >> - the return path is required only on bidirectional p2p
> paths (either
> >> associated or co-routed) just to carry the RDI indication
> >>
> >> There are many consequences if the requirements are not met.<= br> > >>
> >> One of these consequences is described in the last slide of
> >> Annamaria's presentation done in Anaheim:
> >>
> >> http://tools.ietf.org/agenda/77/slides/mpls-24.ppt
> >>
> >> Unidirectional BFD is not the only solution to address this
> >> requirement.
> >>
> >> An alternative solution was also presented in
> >> draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi.
> >>
> >> Italo
> >>
> >> P.S. Please note my new email address,
> Italo.Busi@alcatel-lucent.com,
> >> effective since 1 November 2009.
> >>
> >>> -----Original Message-----
> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org= ]
> >> On Behalf
> >>> Of David Ward
> >>> Sent: mercoled=EC 31 marzo 2010 18.33
> >>> To: Greg Mirsky
> >>> Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward;
> Sami Boutros;
> >>> David Ward (wardd); mpls-tp@ietf.org
> >>> Subject: Re: [mpls] Choice of BFD mechanism/mode for
> proactive CV/CC
> >>>
> >>> Greg -
> >>>
> >>> On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote:
> >>>
> >>> I haven't seen any response from authors thus assuming that
> >> it didn't
> >>> make to the list the first time.
> >>>
> >>> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky
> >>> <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com= >> wrote:
> >>> Dear Authors and All,
> >>> I would like to ask several questions related to the subject I've
> >>> asked at the meeting today:
> >>>
> >>>  *   what are reasons considered to select only
> >>> unidirectional BFD (based on BFD for multipoint networks<= br> > >>> work) for proactive CV/CC
> >>>
> >>> DW: This requirement has been bantered back and forth by
> the group.
> >>> Although not completely explained, it's been deemed criti= cal to
> >>> support by those well versed in transport network archite= ctures.
> >>>
> >>>
> >>>
> >>>  *   what capabilities of BFD for multipoint networks
> >>> required for use as CV/CC in MPLS-TP
> >>>
> >>> DW: Certainly in the MP scenario. As discussed in the
> preso by Rahul
> >>> at the meeting it can also be used if there is no return
> path (odd
> >>> network design).
> >>>
> >>>
> >>>  *   what of capabilities are optional (can and may)
> >>>
> >>> DW: As you saw in the preso, many capabilities and scenar= ios were
> >>> presented.The point of the preso was they there were all optional
> >>> and that if any of the options were *ever* desired then pure
> >>> unidirectional MP BFD was not a good choice.
> >>>
> >>>
> >>>  *   are there any capabilities that would not be supported
> >>> (should not and must not)
> >>>
> >>> As was demonstrated in presentation of David's analysis by Rahul
> >>> today, within BFD for MPLS one can create unidirectional
> BFD session
> >>> already, assuming that the DCN exists in some form.
> >>>
> >>> DW: And really only useful if there is never, ever a return path.
> >>>
> >>> Thus it leave p2mp LSP that can benefit from use of BFD for
> >>> multipoint networks mechanism. Or a root can "preten= d"
> that p2mp LSP
> >>> is p2p and send after first exchange of Discriminator, and ignore
> >>> Discrminators from other, late-joiner leaves.
> >>>
> >>> Regards,
> >>> Greg
> >>>
> >>>
> >>>
> >>> HIH
> >>>
> >>> -DWard
> >>>
> >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
> >>> mpls mailing list
> >>> mpls@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mpls
> >>>
> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> >> mpls mailing list
> >> mpls@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> > mpls-tp mailing list
> > mpls-tp@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls-tp
>
>
>
>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp
--=_alternative 005A358B852576F9_=-- From root@core3.amsl.com Fri Apr 2 09:30:01 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CF10B3A683F; Fri, 2 Apr 2010 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100402163001.CF10B3A683F@core3.amsl.com> Date: Fri, 2 Apr 2010 09:30:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-framework-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 16:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : A Framework for MPLS in Transport Networks Author(s) : M. Bocci, et al. Filename : draft-ietf-mpls-tp-framework-11.txt Pages : 57 Date : 2010-04-02 This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions - the MPLS Transport Profile (MPLS-TP) - that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bi-directional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-framework-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-02092857.I-D@ietf.org> --NextPart-- From maarten.vissers@huawei.com Fri Apr 2 10:45:47 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89833A6BAF; Fri, 2 Apr 2010 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.916 X-Spam-Level: *** X-Spam-Status: No, score=3.916 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzjh0mkivXKZ; Fri, 2 Apr 2010 10:45:45 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 18FAA3A6B66; Fri, 2 Apr 2010 10:36:14 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0900CK8FL1KB@szxga04-in.huawei.com>; Sat, 03 Apr 2010 01:36:37 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L09006FIFL1T8@szxga04-in.huawei.com>; Sat, 03 Apr 2010 01:36:37 +0800 (CST) Received: from M00900002 ([220.231.44.196]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L09008UBFL069@szxml02-in.huawei.com>; Sat, 03 Apr 2010 01:36:37 +0800 (CST) Date: Fri, 02 Apr 2010 19:36:39 +0200 From: Maarten Vissers In-reply-to: To: mpls@ietf.org, mpls-tp@ietf.org Message-id: <30472CE6A4A947B881F1BF6B7493602B@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_c1LFtDei5RB/7X8+UEWLDQ)" Thread-index: AcrSgTjbJ3tXVLzcSl2E0LjBqkPcuQABKZQA References: <2ECAA42C79676B42AEBAC11229CA7D0C05C64B45@E03MVB2-UKBR.domain1.systemhost.net> Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 17:45:47 -0000 This is a multi-part message in MIME format. --Boundary_(ID_c1LFtDei5RB/7X8+UEWLDQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable All, =20 In Ethernet OAM we deploy multiple CCM rates. Generation of CCM frames = can be enabled/disabled. =20 The rate is set by the NMS (or GMPLS) and depends on the most demanding application: =20 - 1 CCM per 10 or 1 minute, or 10 seconds: enterprise application or possible for home gateway connectivity checking - 1 CCM per 1 second: default for fault management in transport network - 1 CCM per 100 microseconds: default for performance monitoring in transport network - 1 CCM per 10 milliseconds: option for protection switching in = transport network - 1 CCM per 3.33 milliseconds: default for protection switching in = transport network. =20 To detect for inconsistent configuration between MEP functions, the = period of the CCM frame is encoded in the frame and checked by each MEP_Sk function. If there is a mismatch an alarm is raised. =20 When a misconnection connects a MEP_So function with CCM period of e.g. = 1 second with a MEP_Sk function with CCM period of e.g. 100 ms the receipt = of the first CCM frame with an incorrect MEGID will detect the MMG defect. = The MMG defect clearing algorithm uses the period value in the unexpected = CCM frame to determine the clearing of the fault condition. =20 The MMG defect detection process runs always, also when the MEG does not generate CCM frames itself. In this way a misconnection with another = VLAN will always be detected. =20 Different CCM periods and a mix of VLANs with and without CCM generation = are as such not a problem in the Ethernet networks. =20 MPLS-TP OAM should use the same periods, same configuration method and = same defect detection method. MPLS-TP OAM (for PW and LSP) and Ethernet OAM = (for VPLS and Ethernet section layers) will be used in PE nodes side by side, = and it would be bad to deploy different policies for PW/LSP and = VPLS/Ethernet sections. =20 Regards, Maarten =20 _____ =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Malcolm.BETTS@zte.com.cn Sent: vrijdag 2 april 2010 18:25 To: neil.2.harrison@bt.com Cc: Italo.Busi@alcatel-lucent.com; mpls@ietf.org; msiva@cisco.com; mpls-tp-bounces@ietf.org; wardd@cisco.com; mpls-tp@ietf.org Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC All,=20 I think the key point is that to avoid the alarm cycling the CV rate = must be consistent across the network. To achieve this the CV rate must be set = by the operator and not by negotiation along each path.=20 Regards,=20 Malcolm=20 =20 Sent by: mpls-tp-bounces@ietf.org=20 02/04/2010 10:47 AM=20 To , , = , =20 cc mpls@ietf.org, wardd@cisco.com, msiva@cisco.com, mpls-tp@ietf.org=20 Subject Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive = CV/CC =09 Just be a bit careful here Tom....if one has SLAs to meet then one needs = a consistent method of measurement. Maybe not such a big issue in isolated operator layer networks, but if there is any requirement to interwork = then consistent availability and performance metrics/objectives will need defining. However, the major point wrt the alarm cycling issue is consistent use = of CV rates within the same layer network....whatever the chosen rate. regards, Neil > -----Original Message----- > From: Nadeau,TD,Tom,DEE1 R=20 > Sent: 02 April 2010 12:57 > To: Harrison,N,Neil,DKQ7 R; Italo.Busi@alcatel-lucent.com;=20 > David Ward; gregimirsky@gmail.com > Cc: mpls@ietf.org; mpls-tp@ietf.org; msiva@cisco.com; David Ward > Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode=20 > for proactive CV/CC >=20 >=20 >=20 > Neil, >=20 > While such mis-configuration may be a problem as you=20 > discuss, one of the major problems with Y.1711 was that it=20 > mandated a fixed time interval for operations. The majority=20 > of operators I worked with at the time found this to be a a=20 > non-starter. Actually their Operations people did. >=20 > The operational requirements for MPLS-TP should not be to=20 > revisit this mistake again, but instead to require=20 > consistency, or mechanisms to reconcile the differences in=20 > cases where it is critical to discern them. > Flexibility with consistency is what we need to aim for here. >=20 > --Tom >=20 >=20 > > Italo, > >=20 > > Many years ago when drafting Y.1710/1711 I pointed out that having=20 > > different CV rates in a network would cause 'alarm cycling'=20 > problems=20 > > under cases of misconnectivity, eg a trail with a CV rate of 1 per=20 > > minute misconnected (ie > > merged) into a trail with a CV rate of 1 per sec will cause a=20 > > behaviour of (i) declare defect and take consequent actions=20 > at t=3DT (eg=20 > > could include invoking prot-sw as per Anamaria's slide),=20 > (ii) declare=20 > > defect cleared at t=3DT+3 and remove all consequent actions=20 > (maybe even=20 > > switch traffic back to old path at some point?), (iii)=20 > declare defect=20 > > again at t=3DT+60...and continue to repeat this cycle. > >=20 > > If there are N different CV rates in a network then there will be a=20 > > number of 'select 2 from N' combinatorial defect cases to deal=20 > > with....not a great idea, so I would strongly suggest that=20 > the CV rate=20 > > be consistent in a given layer network. > >=20 > > BTW - if you set the CV rate too fast you run the danger of=20 > declaring=20 > > defects, and taking unnecessary consequent actions, on error bursts=20 > > that could clear of their own accord. > >=20 > > Defect detection OAM should always be unidirectional in=20 > nature in co=20 > > mode layer networks....the p2mp case clearly shows why this is=20 > > required......noting that consequent actions are also=20 > unidirectional=20 > > in nature and taken at the trail sink, eg=20 > activation/suspension of perf counters, raise local alarm, etc. > >=20 > > The CV (or BFD) packet should contain the proper trail=20 > source address=20 > > for that layer network...not some arbitrary source generated=20 > > identifier. This does assume of course that the layer=20 > network being=20 > > considered has been given decent addressing in the first=20 > place.....not=20 > > the case with MPLS and for sure not with PWs! > >=20 > > One can piggy-back BDI flag in CV for the p2p case but not=20 > the p2mp case. > >=20 > >=20 > > I would also advise forward-looking caution and clarity on=20 > these points: > >=20 > > 1 Before committing to any TCM be very clear how nested TCM=20 > levels are=20 > > configured and activated/deactivated (including=20 > synchronisation of any=20 > > perf mon counts) across failure and restore events. Only=20 > the true end=20 > > points of trails always remain invariant across=20 > failure/restore events. > >=20 > > 2 Note that in a transport network if one direction enters the=20 > > unavailable state then both directions are deemed unavailable. The=20 > > key point here is that any perf monitoring for SLAs must be=20 > suspended=20 > > in both directions for the duration of the unavailability=20 > event. And=20 > > from above point, this applies to all nested TCM levels. > >=20 > > 3 From transparency considerations a (parent) connection=20 > should only=20 > > have a single CoS for its (child) traffic units. However, it seems=20 > > possible that this arch requirement could be violated. In=20 > such a case=20 > > there will be a need to consider how the entry/exit criteria of the=20 > > unavailable state (and all the consequent actions that=20 > would apply) is=20 > > to be defined for the (parent) connection based on some weighted=20 > > combinatorial of loss/delay in the (child) traffic units of=20 > each CoS. =20 > > .....I have mentioned some of these consequential action=20 > > considerations above wrt to suspending perf mon counts in both=20 > > directions and across all nested TCM levels. The right=20 > answer here of=20 > > course is don't create this problem in the first place, ie=20 > a connection should only have a single CoS level. > >=20 > > regards, Neil > >=20 > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > >> Of BUSI ITALO > >> Sent: 02 April 2010 08:58 > >> To: David Ward; Greg Mirsky > >> Cc: mpls@ietf.org; David Ward (wardd); Siva Sivabalan(msiva);=20 > >> mpls-tp@ietf.org; Sami Boutros > >> Subject: Re: [mpls] Choice of BFD mechanism/mode for=20 > proactive CV/CC > >>=20 > >> Dave, Greg, > >>=20 > >> I think we are mixing different aspect of requirements,=20 > solutions and=20 > >> consequences if requirements are not met. > >>=20 > >> The requirements have been expressed more than once but I=20 > think that=20 > >> "repetita juvant": > >>=20 > >> - we need a very simple and lightweight protocol that check=20 > >> continuity and connectivity ("are you there?" question with a=20 > >> "yes/no" answer) > >>=20 > >> - this check must be performed at a rate that is fully=20 > controlled by=20 > >> the operator (and not by the network) > >>=20 > >> - the rate must not change in any condition (only the operator can=20 > >> change it) > >>=20 > >> - the return path is required only on bidirectional p2p=20 > paths (either=20 > >> associated or co-routed) just to carry the RDI indication > >>=20 > >> There are many consequences if the requirements are not met. > >>=20 > >> One of these consequences is described in the last slide of=20 > >> Annamaria's presentation done in Anaheim: > >>=20 > >> http://tools.ietf.org/agenda/77/slides/mpls-24.ppt > >>=20 > >> Unidirectional BFD is not the only solution to address this=20 > >> requirement. > >>=20 > >> An alternative solution was also presented in=20 > >> draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi. > >>=20 > >> Italo > >>=20 > >> P.S. Please note my new email address,=20 > Italo.Busi@alcatel-lucent.com,=20 > >> effective since 1 November 2009. > >>=20 > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > >> On Behalf > >>> Of David Ward > >>> Sent: mercoled=EC 31 marzo 2010 18.33 > >>> To: Greg Mirsky > >>> Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward;=20 > Sami Boutros;=20 > >>> David Ward (wardd); mpls-tp@ietf.org > >>> Subject: Re: [mpls] Choice of BFD mechanism/mode for=20 > proactive CV/CC > >>>=20 > >>> Greg - > >>>=20 > >>> On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote: > >>>=20 > >>> I haven't seen any response from authors thus assuming that > >> it didn't > >>> make to the list the first time. > >>>=20 > >>> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky=20 > >>> > wrote: > >>> Dear Authors and All, > >>> I would like to ask several questions related to the subject I've=20 > >>> asked at the meeting today: > >>>=20 > >>> * what are reasons considered to select only > >>> unidirectional BFD (based on BFD for multipoint networks > >>> work) for proactive CV/CC > >>>=20 > >>> DW: This requirement has been bantered back and forth by=20 > the group. > >>> Although not completely explained, it's been deemed critical to=20 > >>> support by those well versed in transport network architectures. > >>>=20 > >>>=20 > >>>=20 > >>> * what capabilities of BFD for multipoint networks > >>> required for use as CV/CC in MPLS-TP > >>>=20 > >>> DW: Certainly in the MP scenario. As discussed in the=20 > preso by Rahul=20 > >>> at the meeting it can also be used if there is no return=20 > path (odd=20 > >>> network design). > >>>=20 > >>>=20 > >>> * what of capabilities are optional (can and may) > >>>=20 > >>> DW: As you saw in the preso, many capabilities and scenarios were=20 > >>> presented.The point of the preso was they there were all optional=20 > >>> and that if any of the options were *ever* desired then pure=20 > >>> unidirectional MP BFD was not a good choice. > >>>=20 > >>>=20 > >>> * are there any capabilities that would not be supported > >>> (should not and must not) > >>>=20 > >>> As was demonstrated in presentation of David's analysis by Rahul=20 > >>> today, within BFD for MPLS one can create unidirectional=20 > BFD session=20 > >>> already, assuming that the DCN exists in some form. > >>>=20 > >>> DW: And really only useful if there is never, ever a return path. > >>>=20 > >>> Thus it leave p2mp LSP that can benefit from use of BFD for=20 > >>> multipoint networks mechanism. Or a root can "pretend"=20 > that p2mp LSP=20 > >>> is p2p and send after first exchange of Discriminator, and ignore=20 > >>> Discrminators from other, late-joiner leaves. > >>>=20 > >>> Regards, > >>> Greg > >>>=20 > >>>=20 > >>>=20 > >>> HIH > >>>=20 > >>> -DWard > >>>=20 > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >>>=20 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >>=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 >=20 >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_c1LFtDei5RB/7X8+UEWLDQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
All,
 
In Ethernet OAM we deploy multiple CCM rates. = Generation of=20 CCM frames can be enabled/disabled.
 
The rate is set by the NMS (or GMPLS) and depends = on the most=20 demanding application:
 
- 1 CCM per 10 or 1 minute, or 10=20 seconds: enterprise application or possible for home gateway = connectivity=20 checking
- 1 CCM per 1 second: default for fault management = in=20 transport network
- 1 CCM per 100 microseconds: default for = performance=20 monitoring in transport network
- 1 CCM per 10 milliseconds: option for protection = switching=20 in transport network
- 1 CCM per 3.33 milliseconds: default for = protection=20 switching in transport network.
 
To detect for inconsistent configuration between = MEP=20 functions, the period of the CCM frame is encoded in the frame and = checked by=20 each MEP_Sk function. If there is a mismatch an alarm is=20 raised.
 
When a misconnection connects a MEP_So function = with CCM=20 period of e.g. 1 second with a MEP_Sk function with CCM period of e.g. = 100 ms=20 the receipt of the first CCM frame with an incorrect MEGID will detect = the MMG=20 defect. The MMG defect clearing algorithm uses the = period value in the=20 unexpected CCM frame to determine the clearing of the fault=20 condition.
 
The MMG defect detection process runs always, also = when the=20 MEG does not generate CCM frames itself. In this way a misconnection = with=20 another VLAN will always be detected.
 
Different CCM periods and a mix of VLANs with and = without CCM=20 generation are as such not a problem in the Ethernet=20 networks.
 
MPLS-TP OAM should use the same periods,=20 same configuration method and same defect detection method.=20 MPLS-TP OAM (for PW and LSP) and Ethernet OAM (for VPLS and = Ethernet=20 section layers) will be used in PE nodes side by side, and it would be = bad to=20 deploy different policies for PW/LSP and VPLS/Ethernet=20 sections.
 
Regards,
Maarten
 

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 Malcolm.BETTS@zte.com.cn
Sent: vrijdag 2 april 2010=20 18:25
To: neil.2.harrison@bt.com
Cc:=20 Italo.Busi@alcatel-lucent.com; mpls@ietf.org; msiva@cisco.com;=20 mpls-tp-bounces@ietf.org; wardd@cisco.com; = mpls-tp@ietf.org
Subject:=20 Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive=20 CV/CC


All, =

I think the key point is that to avoid the alarm = cycling the CV=20 rate must be consistent across the network.  To achieve this the CV = rate=20 must be set by the operator and not by negotiation along each = path.=20

Regards,

Malcolm




<neil.2.harrison@bt.com> =
Sent by: = mpls-tp-bounces@ietf.org=20

02/04/2010 10:47 AM =

To
<tom.nadeau@bt.com>,=20 <Italo.Busi@alcatel-lucent.com>, = <dward@juniper.net>,=20 <gregimirsky@gmail.com>=20
cc
mpls@ietf.org, = wardd@cisco.com,=20 msiva@cisco.com, mpls-tp@ietf.org=20
Subject
Re: [mpls-tp] [mpls] = Choice of BFD=20 mechanism/mode for proactive      =20  CV/CC

=




Just be a bit careful here Tom....if one has SLAs to meet = then one=20 needs a consistent method of measurement. Maybe not such a big issue in = isolated=20 operator layer networks, but if there is any requirement to interwork = then=20 consistent availability and performance metrics/objectives will need=20 defining.

However, the major point wrt the alarm cycling issue is = consistent use of CV rates within the same layer network....whatever the = chosen=20 rate.

regards, Neil



> -----Original=20 Message-----
> From: Nadeau,TD,Tom,DEE1 R
> Sent: 02 April = 2010=20 12:57
> To: Harrison,N,Neil,DKQ7 R; Italo.Busi@alcatel-lucent.com; =
> David Ward; gregimirsky@gmail.com
> Cc: mpls@ietf.org;=20 mpls-tp@ietf.org; msiva@cisco.com; David Ward
> Subject: Re: = [mpls-tp]=20 [mpls] Choice of BFD mechanism/mode
> for proactive CV/CC
> =
>
>
>     Neil,
>
>   =  =20 While such mis-configuration may be a problem as you
> discuss, = one of=20 the major problems with Y.1711 was that it
> mandated a fixed = time=20 interval for operations. The majority
> of operators I worked = with at the=20 time found this to be a a
> non-starter. Actually their = Operations people=20 did.
>
>     The operational requirements for = MPLS-TP=20 should not be to
> revisit this mistake again, but instead to = require=20
> consistency, or mechanisms to reconcile the differences in =
>=20 cases where it is critical to discern them.
> Flexibility with = consistency=20 is what we need to aim for here.
>
>     = --Tom
>=20
>
> > Italo,
> >
> > Many years ago = when=20 drafting Y.1710/1711 I pointed out that having
> > different = CV rates=20 in a network would cause 'alarm cycling'
> problems
> > = under=20 cases of misconnectivity, eg a trail with a CV rate of 1 per
> = >=20 minute misconnected (ie
> > merged) into a trail with a CV rate = of 1=20 per sec will cause a
> > behaviour of (i) declare defect and = take=20 consequent actions
> at t=3DT (eg
> > could include = invoking=20 prot-sw as per Anamaria's slide),
> (ii) declare
> > = defect=20 cleared at t=3DT+3 and remove all consequent actions
> (maybe = even
>=20 > switch traffic back to old path at some point?), (iii)
> = declare=20 defect
> > again at t=3DT+60...and continue to repeat this=20 cycle.
> >
> > If there are N different CV rates in a = network=20 then there will be a
> > number of 'select 2 from N' = combinatorial=20 defect cases to deal
> > with....not a great idea, so I would = strongly=20 suggest that
> the CV rate
> > be consistent in a given = layer=20 network.
> >
> > BTW - if you set the CV rate too = fast you=20 run the danger of
> declaring
> > defects, and taking=20 unnecessary consequent actions, on error bursts
> > that could = clear=20 of their own accord.
> >
> > Defect detection OAM = should=20 always be unidirectional in
> nature in co
> > mode = layer=20 networks....the p2mp case clearly shows why this is
> >=20 required......noting that consequent actions are also
> = unidirectional=20
> > in nature and taken at the trail sink, eg
>=20 activation/suspension of perf counters, raise local alarm, etc.
> = >=20
> > The CV (or BFD) packet should contain the proper trail =
>=20 source address
> > for that layer network...not some arbitrary = source=20 generated
> > identifier.  This does assume of course = that the=20 layer
> network being
> > considered has been given = decent=20 addressing in the first
> place.....not
> > the case = with MPLS=20 and for sure not with PWs!
> >
> > One can piggy-back = BDI=20 flag in CV for the p2p case but not
> the p2mp case.
> > =
> >
> > I would also advise forward-looking caution = and=20 clarity on
> these points:
> >
> > 1 Before = committing=20 to any TCM be very clear how nested TCM
> levels are
> = >=20 configured and activated/deactivated (including
> synchronisation = of any=20
> > perf mon counts) across failure and restore events. =  Only=20
> the true end
> > points of trails always remain = invariant=20 across
> failure/restore events.
> >
> > 2 = Note that=20 in a transport network if one direction enters the
> > = unavailable=20 state then both directions are deemed unavailable.  The
> = > key=20 point here is that any perf monitoring for SLAs must be
> = suspended=20
> > in both directions for the duration of the unavailability =
>=20 event.  And
> > from above point, this applies to all = nested TCM=20 levels.
> >
> > 3 From transparency considerations a = (parent)=20 connection
> should only
> > have a single CoS for its = (child)=20 traffic units.  However, it seems
> > possible that this = arch=20 requirement could be violated.  In
> such a case
> = > there=20 will be a need to consider how the entry/exit criteria of the
> = >=20 unavailable state (and all the consequent actions that
> would = apply) is=20
> > to be defined for the (parent) connection based on some = weighted=20
> > combinatorial of loss/delay in the (child) traffic units = of=20
> each CoS.  
> > .....I have mentioned some of = these=20 consequential action
> > considerations above wrt to = suspending perf=20 mon counts in both
> > directions and across all nested TCM = levels.=20  The right
> answer here of
> > course is don't = create=20 this problem in the first place, ie
> a connection should only = have a=20 single CoS level.
> >
> > regards, Neil
> > =
>=20 >> -----Original Message-----
> >> From: = mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org]
> On Behalf
> >> Of = BUSI=20 ITALO
> >> Sent: 02 April 2010 08:58
> >> To: = David=20 Ward; Greg Mirsky
> >> Cc: mpls@ietf.org; David Ward = (wardd); Siva=20 Sivabalan(msiva);
> >> mpls-tp@ietf.org; Sami = Boutros
>=20 >> Subject: Re: [mpls] Choice of BFD mechanism/mode for
> = proactive=20 CV/CC
> >>
> >> Dave, Greg,
> >> =
>=20 >> I think we are mixing different aspect of requirements, =
>=20 solutions and
> >> consequences if requirements are not=20 met.
> >>
> >> The requirements have been = expressed=20 more than once but I
> think that
> >> "repetita=20 juvant":
> >>
> >> - we need a very simple and=20 lightweight protocol that check
> >> continuity and = connectivity=20 ("are you there?" question with a
> >> "yes/no" = answer)
>=20 >>
> >> - this check must be performed at a rate that = is=20 fully
> controlled by
> >> the operator (and not by = the=20 network)
> >>
> >> - the rate must not change = in any=20 condition (only the operator can
> >> change it)
> = >>=20
> >> - the return path is required only on bidirectional = p2p=20
> paths (either
> >> associated or co-routed) just = to carry=20 the RDI indication
> >>
> >> There are many=20 consequences if the requirements are not met.
> >>
> = >>=20 One of these consequences is described in the last slide of
> = >>=20 Annamaria's presentation done in Anaheim:
> >>
> = >>=20 http://tools.ietf.org/agenda/77/slides/mpls-24.ppt
> >> =
>=20 >> Unidirectional BFD is not the only solution to address this =
>=20 >> requirement.
> >>
> >> An alternative = solution=20 was also presented in
> >>=20 draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi.
> >> =
>=20 >> Italo
> >>
> >> P.S. Please note my = new email=20 address,
> Italo.Busi@alcatel-lucent.com,
> >> = effective=20 since 1 November 2009.
> >>
> >>> = -----Original=20 Message-----
> >>> From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org]
> >> On Behalf
> = >>>=20 Of David Ward
> >>> Sent: mercoled=EC 31 marzo 2010 = 18.33
>=20 >>> To: Greg Mirsky
> >>> Cc: Siva = Sivabalan(msiva);=20 mpls@ietf.org; David Ward;
> Sami Boutros;
> >>> = David=20 Ward (wardd); mpls-tp@ietf.org
> >>> Subject: Re: [mpls] = Choice=20 of BFD mechanism/mode for
> proactive CV/CC
> >>> =
>=20 >>> Greg -
> >>>
> >>> On Mar = 31, 2010,=20 at 11:15 AM, Greg Mirsky wrote:
> >>>
> = >>> I=20 haven't seen any response from authors thus assuming that
> = >> it=20 didn't
> >>> make to the list the first time.
>=20 >>>
> >>> On Thu, Mar 25, 2010 at 2:55 PM, Greg = Mirsky=20
> >>>=20 <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> = wrote:
>=20 >>> Dear Authors and All,
> >>> I would like to = ask=20 several questions related to the subject I've
> >>> = asked at the=20 meeting today:
> >>>
> >>>  *   = what=20 are reasons considered to select only
> >>> = unidirectional BFD=20 (based on BFD for multipoint networks
> >>> work) for = proactive=20 CV/CC
> >>>
> >>> DW: This requirement = has been=20 bantered back and forth by
> the group.
> >>> = Although not=20 completely explained, it's been deemed critical to
> >>> = support=20 by those well versed in transport network architectures.
> = >>>=20
> >>>
> >>>
> >>> =  *  =20 what capabilities of BFD for multipoint networks
> >>> = required=20 for use as CV/CC in MPLS-TP
> >>>
> >>> = DW:=20 Certainly in the MP scenario. As discussed in the
> preso by = Rahul=20
> >>> at the meeting it can also be used if there is no = return=20
> path (odd
> >>> network design).
> = >>>=20
> >>>
> >>>  *   what of = capabilities=20 are optional (can and may)
> >>>
> >>> = DW: As you=20 saw in the preso, many capabilities and scenarios were
> = >>>=20 presented.The point of the preso was they there were all optional =
>=20 >>> and that if any of the options were *ever* desired then = pure=20
> >>> unidirectional MP BFD was not a good = choice.
>=20 >>>
> >>>
> >>>  *   = are=20 there any capabilities that would not be supported
> >>> = (should=20 not and must not)
> >>>
> >>> As was = demonstrated=20 in presentation of David's analysis by Rahul
> >>> = today, within=20 BFD for MPLS one can create unidirectional
> BFD session
> = >>> already, assuming that the DCN exists in some form.
> = >>>
> >>> DW: And really only useful if there = is never,=20 ever a return path.
> >>>
> >>> Thus it = leave=20 p2mp LSP that can benefit from use of BFD for
> >>> = multipoint=20 networks mechanism. Or a root can "pretend"
> that p2mp LSP =
>=20 >>> is p2p and send after first exchange of Discriminator, and = ignore=20
> >>> Discrminators from other, late-joiner = leaves.
>=20 >>>
> >>> Regards,
> >>> = Greg
>=20 >>>
> >>>
> >>>
> = >>>=20 HIH
> >>>
> >>> -DWard
> = >>>=20
> >>> = _______________________________________________
>=20 >>> mpls mailing list
> >>> = mpls@ietf.org
>=20 >>> https://www.ietf.org/mailman/listinfo/mpls
> = >>>=20
> >> = _______________________________________________
>=20 >> mpls mailing list
> >> mpls@ietf.org
> = >>=20 https://www.ietf.org/mailman/listinfo/mpls
> >>
> = >=20 _______________________________________________
> > mpls-tp = mailing=20 list
> > mpls-tp@ietf.org
> >=20 https://www.ietf.org/mailman/listinfo/mpls-tp
>
>
> =
>=20
_______________________________________________
mpls-tp mailing=20 list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp=


--Boundary_(ID_c1LFtDei5RB/7X8+UEWLDQ)-- From neil.2.harrison@bt.com Fri Apr 2 12:30:37 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0513A6B24; Fri, 2 Apr 2010 12:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.613 X-Spam-Level: X-Spam-Status: No, score=-0.613 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy6QbiLV4UZs; Fri, 2 Apr 2010 12:30:34 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5F79D3A6BD0; Fri, 2 Apr 2010 11:58:35 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 19:59:08 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD296.92B19F99" Date: Fri, 2 Apr 2010 19:59:02 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05C64B56@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <30472CE6A4A947B881F1BF6B7493602B@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC Thread-Index: AcrSgTjbJ3tXVLzcSl2E0LjBqkPcuQABKZQAAAPhtsA= From: To: , , X-OriginalArrivalTime: 02 Apr 2010 18:59:08.0777 (UTC) FILETIME=[9310F590:01CAD296] Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:30:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD296.92B19F99 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Maarten, =20 I believe the key point you are trying to make here is that when we have = a mismerge defect it is the lowest CV rate (and not simply the offending = mismerged CV rate that you state below) that should determine the defect = processing algorithm at the sink. This seem a reasonable idea on the = face of it. Or have I missed something? =20 I think reference to Ethernet or any other specific technology is not = relevant. =20 regards, Neil ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Maarten Vissers Sent: 02 April 2010 18:37 To: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive = CV/CC =09 =09 All, =20 In Ethernet OAM we deploy multiple CCM rates. Generation of CCM frames = can be enabled/disabled. =20 The rate is set by the NMS (or GMPLS) and depends on the most demanding = application: =20 - 1 CCM per 10 or 1 minute, or 10 seconds: enterprise application or = possible for home gateway connectivity checking - 1 CCM per 1 second: default for fault management in transport network - 1 CCM per 100 microseconds: default for performance monitoring in = transport network - 1 CCM per 10 milliseconds: option for protection switching in = transport network - 1 CCM per 3.33 milliseconds: default for protection switching in = transport network. =20 To detect for inconsistent configuration between MEP functions, the = period of the CCM frame is encoded in the frame and checked by each = MEP_Sk function. If there is a mismatch an alarm is raised. =20 When a misconnection connects a MEP_So function with CCM period of e.g. = 1 second with a MEP_Sk function with CCM period of e.g. 100 ms the = receipt of the first CCM frame with an incorrect MEGID will detect the = MMG defect. The MMG defect clearing algorithm uses the period value in = the unexpected CCM frame to determine the clearing of the fault = condition. =20 The MMG defect detection process runs always, also when the MEG does = not generate CCM frames itself. In this way a misconnection with another = VLAN will always be detected. =20 Different CCM periods and a mix of VLANs with and without CCM = generation are as such not a problem in the Ethernet networks. =20 MPLS-TP OAM should use the same periods, same configuration method and = same defect detection method. MPLS-TP OAM (for PW and LSP) and Ethernet = OAM (for VPLS and Ethernet section layers) will be used in PE nodes side = by side, and it would be bad to deploy different policies for PW/LSP and = VPLS/Ethernet sections. =20 Regards, Maarten =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Malcolm.BETTS@zte.com.cn Sent: vrijdag 2 april 2010 18:25 To: neil.2.harrison@bt.com Cc: Italo.Busi@alcatel-lucent.com; mpls@ietf.org; msiva@cisco.com; = mpls-tp-bounces@ietf.org; wardd@cisco.com; mpls-tp@ietf.org Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for = proactive CV/CC =09 =09 All,=20 =09 I think the key point is that to avoid the alarm cycling the CV rate = must be consistent across the network. To achieve this the CV rate must = be set by the operator and not by negotiation along each path.=20 =09 Regards,=20 =09 Malcolm=20 =09 =09 =09 =09 =09 =20 Sent by: mpls-tp-bounces@ietf.org=20 02/04/2010 10:47 AM=20 To , , = , =20 cc mpls@ietf.org, wardd@cisco.com, msiva@cisco.com, mpls-tp@ietf.org=20 Subject Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive = CV/CC=09 =09 Just be a bit careful here Tom....if one has SLAs to meet then one = needs a consistent method of measurement. Maybe not such a big issue in = isolated operator layer networks, but if there is any requirement to = interwork then consistent availability and performance = metrics/objectives will need defining. =09 However, the major point wrt the alarm cycling issue is consistent use = of CV rates within the same layer network....whatever the chosen rate. =09 regards, Neil =09 =09 =09 > -----Original Message----- > From: Nadeau,TD,Tom,DEE1 R=20 > Sent: 02 April 2010 12:57 > To: Harrison,N,Neil,DKQ7 R; Italo.Busi@alcatel-lucent.com;=20 > David Ward; gregimirsky@gmail.com > Cc: mpls@ietf.org; mpls-tp@ietf.org; msiva@cisco.com; David Ward > Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode=20 > for proactive CV/CC >=20 >=20 >=20 > Neil, >=20 > While such mis-configuration may be a problem as you=20 > discuss, one of the major problems with Y.1711 was that it=20 > mandated a fixed time interval for operations. The majority=20 > of operators I worked with at the time found this to be a a=20 > non-starter. Actually their Operations people did. >=20 > The operational requirements for MPLS-TP should not be to=20 > revisit this mistake again, but instead to require=20 > consistency, or mechanisms to reconcile the differences in=20 > cases where it is critical to discern them. > Flexibility with consistency is what we need to aim for here. >=20 > --Tom >=20 >=20 > > Italo, > >=20 > > Many years ago when drafting Y.1710/1711 I pointed out that having=20 > > different CV rates in a network would cause 'alarm cycling'=20 > problems=20 > > under cases of misconnectivity, eg a trail with a CV rate of 1 per=20 > > minute misconnected (ie > > merged) into a trail with a CV rate of 1 per sec will cause a=20 > > behaviour of (i) declare defect and take consequent actions=20 > at t=3DT (eg=20 > > could include invoking prot-sw as per Anamaria's slide),=20 > (ii) declare=20 > > defect cleared at t=3DT+3 and remove all consequent actions=20 > (maybe even=20 > > switch traffic back to old path at some point?), (iii)=20 > declare defect=20 > > again at t=3DT+60...and continue to repeat this cycle. > >=20 > > If there are N different CV rates in a network then there will be a = > > number of 'select 2 from N' combinatorial defect cases to deal=20 > > with....not a great idea, so I would strongly suggest that=20 > the CV rate=20 > > be consistent in a given layer network. > >=20 > > BTW - if you set the CV rate too fast you run the danger of=20 > declaring=20 > > defects, and taking unnecessary consequent actions, on error bursts = > > that could clear of their own accord. > >=20 > > Defect detection OAM should always be unidirectional in=20 > nature in co=20 > > mode layer networks....the p2mp case clearly shows why this is=20 > > required......noting that consequent actions are also=20 > unidirectional=20 > > in nature and taken at the trail sink, eg=20 > activation/suspension of perf counters, raise local alarm, etc. > >=20 > > The CV (or BFD) packet should contain the proper trail=20 > source address=20 > > for that layer network...not some arbitrary source generated=20 > > identifier. This does assume of course that the layer=20 > network being=20 > > considered has been given decent addressing in the first=20 > place.....not=20 > > the case with MPLS and for sure not with PWs! > >=20 > > One can piggy-back BDI flag in CV for the p2p case but not=20 > the p2mp case. > >=20 > >=20 > > I would also advise forward-looking caution and clarity on=20 > these points: > >=20 > > 1 Before committing to any TCM be very clear how nested TCM=20 > levels are=20 > > configured and activated/deactivated (including=20 > synchronisation of any=20 > > perf mon counts) across failure and restore events. Only=20 > the true end=20 > > points of trails always remain invariant across=20 > failure/restore events. > >=20 > > 2 Note that in a transport network if one direction enters the=20 > > unavailable state then both directions are deemed unavailable. The = > > key point here is that any perf monitoring for SLAs must be=20 > suspended=20 > > in both directions for the duration of the unavailability=20 > event. And=20 > > from above point, this applies to all nested TCM levels. > >=20 > > 3 From transparency considerations a (parent) connection=20 > should only=20 > > have a single CoS for its (child) traffic units. However, it seems = > > possible that this arch requirement could be violated. In=20 > such a case=20 > > there will be a need to consider how the entry/exit criteria of the = > > unavailable state (and all the consequent actions that=20 > would apply) is=20 > > to be defined for the (parent) connection based on some weighted=20 > > combinatorial of loss/delay in the (child) traffic units of=20 > each CoS. =20 > > .....I have mentioned some of these consequential action=20 > > considerations above wrt to suspending perf mon counts in both=20 > > directions and across all nested TCM levels. The right=20 > answer here of=20 > > course is don't create this problem in the first place, ie=20 > a connection should only have a single CoS level. > >=20 > > regards, Neil > >=20 > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > >> Of BUSI ITALO > >> Sent: 02 April 2010 08:58 > >> To: David Ward; Greg Mirsky > >> Cc: mpls@ietf.org; David Ward (wardd); Siva Sivabalan(msiva);=20 > >> mpls-tp@ietf.org; Sami Boutros > >> Subject: Re: [mpls] Choice of BFD mechanism/mode for=20 > proactive CV/CC > >>=20 > >> Dave, Greg, > >>=20 > >> I think we are mixing different aspect of requirements,=20 > solutions and=20 > >> consequences if requirements are not met. > >>=20 > >> The requirements have been expressed more than once but I=20 > think that=20 > >> "repetita juvant": > >>=20 > >> - we need a very simple and lightweight protocol that check=20 > >> continuity and connectivity ("are you there?" question with a=20 > >> "yes/no" answer) > >>=20 > >> - this check must be performed at a rate that is fully=20 > controlled by=20 > >> the operator (and not by the network) > >>=20 > >> - the rate must not change in any condition (only the operator can = > >> change it) > >>=20 > >> - the return path is required only on bidirectional p2p=20 > paths (either=20 > >> associated or co-routed) just to carry the RDI indication > >>=20 > >> There are many consequences if the requirements are not met. > >>=20 > >> One of these consequences is described in the last slide of=20 > >> Annamaria's presentation done in Anaheim: > >>=20 > >> http://tools.ietf.org/agenda/77/slides/mpls-24.ppt > >>=20 > >> Unidirectional BFD is not the only solution to address this=20 > >> requirement. > >>=20 > >> An alternative solution was also presented in=20 > >> draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi. > >>=20 > >> Italo > >>=20 > >> P.S. Please note my new email address,=20 > Italo.Busi@alcatel-lucent.com,=20 > >> effective since 1 November 2009. > >>=20 > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > >> On Behalf > >>> Of David Ward > >>> Sent: mercoled=EC 31 marzo 2010 18.33 > >>> To: Greg Mirsky > >>> Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward;=20 > Sami Boutros;=20 > >>> David Ward (wardd); mpls-tp@ietf.org > >>> Subject: Re: [mpls] Choice of BFD mechanism/mode for=20 > proactive CV/CC > >>>=20 > >>> Greg - > >>>=20 > >>> On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote: > >>>=20 > >>> I haven't seen any response from authors thus assuming that > >> it didn't > >>> make to the list the first time. > >>>=20 > >>> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky=20 > >>> > wrote: > >>> Dear Authors and All, > >>> I would like to ask several questions related to the subject I've = > >>> asked at the meeting today: > >>>=20 > >>> * what are reasons considered to select only > >>> unidirectional BFD (based on BFD for multipoint networks > >>> work) for proactive CV/CC > >>>=20 > >>> DW: This requirement has been bantered back and forth by=20 > the group. > >>> Although not completely explained, it's been deemed critical to=20 > >>> support by those well versed in transport network architectures. > >>>=20 > >>>=20 > >>>=20 > >>> * what capabilities of BFD for multipoint networks > >>> required for use as CV/CC in MPLS-TP > >>>=20 > >>> DW: Certainly in the MP scenario. As discussed in the=20 > preso by Rahul=20 > >>> at the meeting it can also be used if there is no return=20 > path (odd=20 > >>> network design). > >>>=20 > >>>=20 > >>> * what of capabilities are optional (can and may) > >>>=20 > >>> DW: As you saw in the preso, many capabilities and scenarios were = > >>> presented.The point of the preso was they there were all optional = > >>> and that if any of the options were *ever* desired then pure=20 > >>> unidirectional MP BFD was not a good choice. > >>>=20 > >>>=20 > >>> * are there any capabilities that would not be supported > >>> (should not and must not) > >>>=20 > >>> As was demonstrated in presentation of David's analysis by Rahul=20 > >>> today, within BFD for MPLS one can create unidirectional=20 > BFD session=20 > >>> already, assuming that the DCN exists in some form. > >>>=20 > >>> DW: And really only useful if there is never, ever a return path. > >>>=20 > >>> Thus it leave p2mp LSP that can benefit from use of BFD for=20 > >>> multipoint networks mechanism. Or a root can "pretend"=20 > that p2mp LSP=20 > >>> is p2p and send after first exchange of Discriminator, and ignore = > >>> Discrminators from other, late-joiner leaves. > >>>=20 > >>> Regards, > >>> Greg > >>>=20 > >>>=20 > >>>=20 > >>> HIH > >>>=20 > >>> -DWard > >>>=20 > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >>>=20 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >>=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 >=20 >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 =09 =09 ------_=_NextPart_001_01CAD296.92B19F99 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks = Maarten,
 
I believe the key point you are = trying to=20 make here is that when we have a mismerge defect it is the lowest CV = rate (and=20 not simply the offending mismerged CV rate that you state below) that = should=20 determine the defect processing algorithm at the sink.  This seem a = reasonable idea on the face of it.  Or have I missed=20 something?
 
I think reference to Ethernet or = any other=20 specific technology is not relevant.
 
regards, = Neil

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Maarten=20 Vissers
Sent: 02 April 2010 18:37
To: = mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: Re: [mpls] [mpls-tp] Choice of BFD = mechanism/modefor proactive CV/CC

All,
 
In Ethernet OAM we deploy multiple CCM rates. = Generation=20 of CCM frames can be enabled/disabled.
 
The rate is set by the NMS (or GMPLS) and = depends on the=20 most demanding application:
 
- 1 CCM per 10 or 1 minute, or 10=20 seconds: enterprise application or possible for home gateway = connectivity=20 checking
- 1 CCM per 1 second: default for fault = management in=20 transport network
- 1 CCM per 100 microseconds: default for = performance=20 monitoring in transport network
- 1 CCM per 10 milliseconds: option for = protection=20 switching in transport network
- 1 CCM per 3.33 milliseconds: default for = protection=20 switching in transport network.
 
To detect for inconsistent configuration = between MEP=20 functions, the period of the CCM frame is encoded in the frame and = checked by=20 each MEP_Sk function. If there is a mismatch an alarm is=20 raised.
 
When a misconnection connects a MEP_So = function with CCM=20 period of e.g. 1 second with a MEP_Sk function with CCM period of e.g. = 100 ms=20 the receipt of the first CCM frame with an incorrect MEGID will detect = the MMG=20 defect. The MMG defect clearing algorithm uses the = period value in=20 the unexpected CCM frame to determine the clearing of the fault=20 condition.
 
The MMG defect detection process runs always, = also when=20 the MEG does not generate CCM frames itself. In this way a = misconnection with=20 another VLAN will always be detected.
 
Different CCM periods and a mix of VLANs with = and without=20 CCM generation are as such not a problem in the Ethernet=20 networks.
 
MPLS-TP OAM should use the same periods,=20 same configuration method and same defect detection method.=20 MPLS-TP OAM (for PW and LSP) and Ethernet OAM (for VPLS and = Ethernet=20 section layers) will be used in PE nodes side by side, and it would be = bad to=20 deploy different policies for PW/LSP and VPLS/Ethernet=20 sections.
 
Regards,
Maarten
 

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 Malcolm.BETTS@zte.com.cn
Sent: vrijdag 2 april 2010=20 18:25
To: neil.2.harrison@bt.com
Cc:=20 Italo.Busi@alcatel-lucent.com; mpls@ietf.org; msiva@cisco.com;=20 mpls-tp-bounces@ietf.org; wardd@cisco.com; = mpls-tp@ietf.org
Subject:=20 Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive=20 CV/CC


All, =

I think the key point is that to avoid the = alarm=20 cycling the CV rate must be consistent across the network.  To = achieve=20 this the CV rate must be set by the operator and not by negotiation = along each=20 path.

Regards,=20

Malcolm =




<neil.2.harrison@bt.com>
Sent by: = mpls-tp-bounces@ietf.org=20

02/04/2010 10:47 AM =

To
<tom.nadeau@bt.com>,=20 <Italo.Busi@alcatel-lucent.com>, = <dward@juniper.net>,=20 <gregimirsky@gmail.com>=20
cc
mpls@ietf.org, = wardd@cisco.com,=20 msiva@cisco.com, mpls-tp@ietf.org=20
Subject
Re: [mpls-tp] [mpls] = Choice of=20 BFD mechanism/mode for proactive      =20  CV/CC

=




<= FONT=20 size=3D2>Just be a bit careful here Tom....if one has SLAs to meet = then one=20 needs a consistent method of measurement. Maybe not such a big issue = in=20 isolated operator layer networks, but if there is any requirement to = interwork=20 then consistent availability and performance metrics/objectives will = need=20 defining.

However, the major point wrt the alarm cycling issue = is=20 consistent use of CV rates within the same layer network....whatever = the=20 chosen rate.

regards, Neil



> -----Original=20 Message-----
> From: Nadeau,TD,Tom,DEE1 R
> Sent: 02 = April 2010=20 12:57
> To: Harrison,N,Neil,DKQ7 R; = Italo.Busi@alcatel-lucent.com;=20
> David Ward; gregimirsky@gmail.com
> Cc: mpls@ietf.org;=20 mpls-tp@ietf.org; msiva@cisco.com; David Ward
> Subject: Re: = [mpls-tp]=20 [mpls] Choice of BFD mechanism/mode
> for proactive = CV/CC
>=20
>
>
>     Neil,
>
>   =  =20 While such mis-configuration may be a problem as you
> discuss, = one of=20 the major problems with Y.1711 was that it
> mandated a fixed = time=20 interval for operations. The majority
> of operators I worked = with at=20 the time found this to be a a
> non-starter. Actually their = Operations=20 people did.
>
>     The operational = requirements for=20 MPLS-TP should not be to
> revisit this mistake again, but = instead to=20 require
> consistency, or mechanisms to reconcile the = differences in=20
> cases where it is critical to discern them.
> = Flexibility with=20 consistency is what we need to aim for here.
>
>   =  =20 --Tom
>
>
> > Italo,
> >
> > = Many=20 years ago when drafting Y.1710/1711 I pointed out that having
> = >=20 different CV rates in a network would cause 'alarm cycling'
> = problems=20
> > under cases of misconnectivity, eg a trail with a CV = rate of 1=20 per
> > minute misconnected (ie
> > merged) into a = trail=20 with a CV rate of 1 per sec will cause a
> > behaviour of = (i)=20 declare defect and take consequent actions
> at t=3DT (eg =
> >=20 could include invoking prot-sw as per Anamaria's slide),
> (ii) = declare=20
> > defect cleared at t=3DT+3 and remove all consequent = actions=20
> (maybe even
> > switch traffic back to old path at = some=20 point?), (iii)
> declare defect
> > again at = t=3DT+60...and=20 continue to repeat this cycle.
> >
> > If there are = N=20 different CV rates in a network then there will be a
> > = number of=20 'select 2 from N' combinatorial defect cases to deal
> > = with....not=20 a great idea, so I would strongly suggest that
> the CV rate =
>=20 > be consistent in a given layer network.
> >
> = > BTW -=20 if you set the CV rate too fast you run the danger of
> = declaring=20
> > defects, and taking unnecessary consequent actions, on = error=20 bursts
> > that could clear of their own accord.
> = >=20
> > Defect detection OAM should always be unidirectional in =
>=20 nature in co
> > mode layer networks....the p2mp case = clearly shows=20 why this is
> > required......noting that consequent actions = are=20 also
> unidirectional
> > in nature and taken at the = trail=20 sink, eg
> activation/suspension of perf counters, raise local = alarm,=20 etc.
> >
> > The CV (or BFD) packet should contain = the=20 proper trail
> source address
> > for that layer=20 network...not some arbitrary source generated
> > = identifier.=20  This does assume of course that the layer
> network being =
> > considered has been given decent addressing in the first =
> place.....not
> > the case with MPLS and for sure = not with=20 PWs!
> >
> > One can piggy-back BDI flag in CV for = the p2p=20 case but not
> the p2mp case.
> >
> > =
> >=20 I would also advise forward-looking caution and clarity on
> = these=20 points:
> >
> > 1 Before committing to any TCM be = very=20 clear how nested TCM
> levels are
> > configured and=20 activated/deactivated (including
> synchronisation of any =
> >=20 perf mon counts) across failure and restore events.  Only =
> the=20 true end
> > points of trails always remain invariant across =
> failure/restore events.
> >
> > 2 Note = that in a=20 transport network if one direction enters the
> > = unavailable state=20 then both directions are deemed unavailable.  The
> > = key point=20 here is that any perf monitoring for SLAs must be
> suspended =
>=20 > in both directions for the duration of the unavailability =
> event.=20  And
> > from above point, this applies to all nested = TCM=20 levels.
> >
> > 3 From transparency considerations = a=20 (parent) connection
> should only
> > have a single = CoS for=20 its (child) traffic units.  However, it seems
> > = possible that=20 this arch requirement could be violated.  In
> such a case =
> > there will be a need to consider how the entry/exit = criteria of=20 the
> > unavailable state (and all the consequent actions = that=20
> would apply) is
> > to be defined for the (parent)=20 connection based on some weighted
> > combinatorial of = loss/delay in=20 the (child) traffic units of
> each CoS.  
> > = .....I=20 have mentioned some of these consequential action
> > = considerations=20 above wrt to suspending perf mon counts in both
> > = directions and=20 across all nested TCM levels.  The right
> answer here of =
>=20 > course is don't create this problem in the first place, ie =
> a=20 connection should only have a single CoS level.
> >
> = >=20 regards, Neil
> >
> >> -----Original=20 Message-----
> >> From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org]
> On Behalf
> >> Of = BUSI=20 ITALO
> >> Sent: 02 April 2010 08:58
> >> To: = David=20 Ward; Greg Mirsky
> >> Cc: mpls@ietf.org; David Ward = (wardd); Siva=20 Sivabalan(msiva);
> >> mpls-tp@ietf.org; Sami = Boutros
>=20 >> Subject: Re: [mpls] Choice of BFD mechanism/mode for
> = proactive CV/CC
> >>
> >> Dave, Greg,
> = >>
> >> I think we are mixing different aspect of=20 requirements,
> solutions and
> >> consequences if = requirements are not met.
> >>
> >> The = requirements=20 have been expressed more than once but I
> think that
> = >>=20 "repetita juvant":
> >>
> >> - we need a very = simple=20 and lightweight protocol that check
> >> continuity and=20 connectivity ("are you there?" question with a
> >> = "yes/no"=20 answer)
> >>
> >> - this check must be = performed at a=20 rate that is fully
> controlled by
> >> the = operator (and=20 not by the network)
> >>
> >> - the rate must = not=20 change in any condition (only the operator can
> >> = change=20 it)
> >>
> >> - the return path is required = only on=20 bidirectional p2p
> paths (either
> >> associated = or=20 co-routed) just to carry the RDI indication
> >>
> = >>=20 There are many consequences if the requirements are not met.
> = >>=20
> >> One of these consequences is described in the last = slide of=20
> >> Annamaria's presentation done in Anaheim:
> = >>=20
> >> = http://tools.ietf.org/agenda/77/slides/mpls-24.ppt
>=20 >>
> >> Unidirectional BFD is not the only solution = to=20 address this
> >> requirement.
> >>
> = >>=20 An alternative solution was also presented in
> >>=20 draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi.
> >> =
>=20 >> Italo
> >>
> >> P.S. Please note my = new=20 email address,
> Italo.Busi@alcatel-lucent.com,
> = >>=20 effective since 1 November 2009.
> >>
> = >>>=20 -----Original Message-----
> >>> From: = mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org]
> >> On Behalf
> = >>>=20 Of David Ward
> >>> Sent: mercoled=EC 31 marzo 2010 = 18.33
>=20 >>> To: Greg Mirsky
> >>> Cc: Siva = Sivabalan(msiva);=20 mpls@ietf.org; David Ward;
> Sami Boutros;
> = >>> David=20 Ward (wardd); mpls-tp@ietf.org
> >>> Subject: Re: = [mpls] Choice=20 of BFD mechanism/mode for
> proactive CV/CC
> = >>>=20
> >>> Greg -
> >>>
> = >>> On Mar=20 31, 2010, at 11:15 AM, Greg Mirsky wrote:
> >>> =
>=20 >>> I haven't seen any response from authors thus assuming=20 that
> >> it didn't
> >>> make to the list = the=20 first time.
> >>>
> >>> On Thu, Mar 25, = 2010 at=20 2:55 PM, Greg Mirsky
> >>>=20 <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>=20 wrote:
> >>> Dear Authors and All,
> >>> = I would=20 like to ask several questions related to the subject I've
>=20 >>> asked at the meeting today:
> >>>
> = >>>  *   what are reasons considered to select = only
>=20 >>> unidirectional BFD (based on BFD for multipoint = networks
>=20 >>> work) for proactive CV/CC
> >>>
>=20 >>> DW: This requirement has been bantered back and forth by =
>=20 the group.
> >>> Although not completely explained, = it's been=20 deemed critical to
> >>> support by those well versed = in=20 transport network architectures.
> >>>
> = >>>=20
> >>>
> >>>  *   what = capabilities=20 of BFD for multipoint networks
> >>> required for use = as CV/CC=20 in MPLS-TP
> >>>
> >>> DW: Certainly in = the MP=20 scenario. As discussed in the
> preso by Rahul
> = >>> at=20 the meeting it can also be used if there is no return
> path = (odd=20
> >>> network design).
> >>>
>=20 >>>
> >>>  *   what of capabilities = are=20 optional (can and may)
> >>>
> >>> DW: = As you=20 saw in the preso, many capabilities and scenarios were
> = >>>=20 presented.The point of the preso was they there were all optional =
>=20 >>> and that if any of the options were *ever* desired then = pure=20
> >>> unidirectional MP BFD was not a good = choice.
>=20 >>>
> >>>
> >>>  * =   are=20 there any capabilities that would not be supported
> = >>>=20 (should not and must not)
> >>>
> >>> = As was=20 demonstrated in presentation of David's analysis by Rahul
>=20 >>> today, within BFD for MPLS one can create unidirectional =
>=20 BFD session
> >>> already, assuming that the DCN = exists in=20 some form.
> >>>
> >>> DW: And really = only=20 useful if there is never, ever a return path.
> >>> =
>=20 >>> Thus it leave p2mp LSP that can benefit from use of BFD = for=20
> >>> multipoint networks mechanism. Or a root can = "pretend"=20
> that p2mp LSP
> >>> is p2p and send after = first=20 exchange of Discriminator, and ignore
> >>> = Discrminators from=20 other, late-joiner leaves.
> >>>
> >>>=20 Regards,
> >>> Greg
> >>>
> = >>>=20
> >>>
> >>> HIH
> >>> =
>=20 >>> -DWard
> >>>
> >>>=20 _______________________________________________
> >>> = mpls=20 mailing list
> >>> mpls@ietf.org
> >>>=20 https://www.ietf.org/mailman/listinfo/mpls
> >>> =
>=20 >> _______________________________________________
> = >> mpls=20 mailing list
> >> mpls@ietf.org
> >>=20 https://www.ietf.org/mailman/listinfo/mpls
> >>
> = >=20 _______________________________________________
> > mpls-tp = mailing=20 list
> > mpls-tp@ietf.org
> >=20 https://www.ietf.org/mailman/listinfo/mpls-tp
>
> =
>=20
> =
_______________________________________________
mpls-tp=20 mailing=20 = list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp=


------_=_NextPart_001_01CAD296.92B19F99-- From zhiwlin@gmail.com Fri Apr 2 14:38:48 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE63F3A6823; Fri, 2 Apr 2010 14:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=1.970, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdPwFiBkV4fd; Fri, 2 Apr 2010 14:38:47 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4887C3A6AE7; Fri, 2 Apr 2010 14:25:57 -0700 (PDT) Received: by gwj20 with SMTP id 20so82831gwj.31 for ; Fri, 02 Apr 2010 14:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=uJgj9+2EqWGwnk4RvD39xPOzloEOPV/xpAg31FyaIi0=; b=b1ZBLOePI+eNA8nzjj9aKvLvahbDjaQTlsgKyuC5ZT0yDSuosTs+o2kre3IHEx8AgA AUg7Hrz+AqhYkFvEJ9uL1ptqVzljUi9inqi5s+WOSjOCfwdUAzhbPsIQjaIrMDVwhDKh s0uI4GJFdvgIWJF80C+63VrGuU4sNd2XepVWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QTkbuQmPEJCILd3SR3K5ex6EWY4sPm1VbMSobqRWNVDC+H+SBA9rmuYlptN9QVe4P8 FWgykfGmBkaeIoUslksstTtU8kn9sObHfecyacqC3h1i3Pzy+XQVZe+UVX4GJR+JKRmp pz/LsW81nrYJ1KnPjt04DaXLy9MaYC6HNg1nU= MIME-Version: 1.0 Received: by 10.100.47.12 with HTTP; Fri, 2 Apr 2010 14:26:27 -0700 (PDT) In-Reply-To: References: <436B49B8E459C54C8B47A7826292AFB4027A09@NYCTEXVS06.transit.nyct.com> Date: Fri, 2 Apr 2010 17:26:27 -0400 Received: by 10.101.131.15 with SMTP id i15mr6138539ann.13.1270243587490; Fri, 02 Apr 2010 14:26:27 -0700 (PDT) Message-ID: From: Zhi-Wei Lin To: benjamin.niven-jenkins@bt.com Content-Type: multipart/alternative; boundary=001636c92421cf84a2048347a154 Cc: mpls@ietf.org, Alexander.Vainshtein@ecitele.com, Cecil.Byles@interoute.com, CCAMP@ietf.org, curtis@occnc.com, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:38:48 -0000 --001636c92421cf84a2048347a154 Content-Type: text/plain; charset=UTF-8 Hi Ben, Yes, exactly! As a small network operator, we don't have the luxury that you may have in terms of a larger workforce and better funding for training. So anything that keeps things similar would be helpful, and would alleviate us struggling with terminology and fundamental technology differences. Of course there would be lots of new terms, but if we keep part of the terminology as closely coupled to transport network as possible (e.g., protection switching, manual switch, force switch, lockout, wait to restore), these would be concepts they are already familiar with and can identify. Thanks Zhi On Fri, Apr 2, 2010 at 11:30 AM, wrote: > Zhi, > > I suspect your requirement is to keep the operational procedures (MOP) for > MPLS-TP as closely aligned to those of your existing transport network as > possible. In other words if scenario A occurs, operations need to follow > steps B, C and D etc. where the functions of A, B, C and D are as similar > as > possible for MPLS-TP and your existing transport network. > > Whether the protection switching mechanism is called APS or FOO is a very > minor point in the overall operations procedure, otherwise I suspect your > operations personnel are going to really struggle with MPLS-TP with its > introduction of other new acronyms Vs transport networks like LSP, PW, BFD > etc ;-) > > Ben > > > > On 02/04/2010 15:26, "Lin, Zhi-Wei" wrote: > > > Hi Ben, > > > > Yes, definitely there are other operators with different operational > > considerations. I was offering my perspective and what my company plans > to do. > > > > However, in terms of the acronyms, even if in your company you plan to > have > > your data group handle MPLS-TP, whether the term is "MPLS-TP APS" or > "PSC", > > from their perspective it will be a new term and therefore no difference > which > > it should be. > > > > However, for other operators (such as us) who plans to have the transport > > personnel handle MPLS-TP, then "MPLS-TP APS" would make more sense. > Again, > > functionally, our transport staff will need to be trained on specific > > procedures associated with MPLS-TP, but anything that keeps things > "similar" > > is better than nothing. > > > > As such, MPLS-TP APS would be a better term that would make more > operators' > > life easier, yes? > > > > Thanks > > Zhi > > > > > > ________________________________ > > From: mpls-bounces@ietf.org on behalf of benjamin.niven-jenkins@bt.com > > Sent: Fri 4/2/2010 7:46 AM > > To: zhiwlin@gmail.com; curtis@occnc.com > > Cc: Cecil.Byles@interoute.com; mpls@ietf.org; CCAMP@ietf.org; > > Alexander.Vainshtein@ecitele.com; mpls-tp@ietf.org > > Subject: Re: [mpls] [CCAMP] [mpls-tp] Term > > "PSC"indraft-ietf-mpls-tp-linear-protection-01 > > > > > > Zhi, > > > > Thanks, I understand you perspective. > > > > However I suspect other operators may target their existing data network > > operations staff to maintain and operate an MPLS-TP network! > > > > The functionality needs to be as aligned to existing practices (MPLS and > > Transport) as possible. Re-learning/Re-definition of existing operations > > processes should be minimised but given that MPLS-TP is bridging a gap > > between data and transport networks some relearning on both sides is > > inevitable. > > > > HTH > > Ben > > > > > > > > On 25/03/2010 14:38, "Zhi-Wei Lin" wrote: > > > >> Hi, > >> > >> I like to give my perspective. As a small network company (but one of > the > >> largest transit agencies), we have a small operating staff split into > two > >> groups: one that handles traditional data network (Ethernet, IP), and > one > >> that > >> handles transport network (SONET, WDM). > >> > >> We are targeting the transport network operating staff to maintain and > >> operate > >> the MPLS-TP network. As such, anything that will help to reduce the > learning > >> curve (less training), simplify operating, and make the MOP as > consistent as > >> possible between SONET and MPLS-TP would be hugely beneficial. > >> > >> Obviously there will be some differences since MPLS-TP is a packet-based > >> transport network, but the standards groups (I don't really care for > politics > >> of IETF and ITU) should strive to make these differences easy to learn. > >> > >> Thanks > >> Zhi > >> > >> > >> On Thu, Mar 25, 2010 at 2:09 AM, Curtis Villamizar > >> > wrote: > >> > >> In message > >> > <4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com 4B2E951>> > 0 > >> FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com>> > >> "Cecil Byles" writes: > >>> > >>> > >>> Hi, > >>> Can I therefore also asked how PSC "Protection State Coordination" in > >>> the MPLS-TP parlance align with ITU-T 808.1 recommendation that > "defines > >>> the generic functional models, characteristics and processes associated > >>> with various linear protection schemes for connection-oriented layer > >>> networks; e.g., Optical Transport Networks (OTN), Synchronous Digital > >>> Hierarchy (SDH) networks and Asynchronous Transfer Mode (ATM) networks" > >>> and the sections covering Terms and Definitions as well as > >>> Abbreviations. IMO all transport engineers and the general telecom > >>> community understand that 1+1 or 1:1 are either SNCP or APS. Hence why > >>> introduce a new TLA (three letter abbreviation) cover the same function > >>> and feature for MPLS-TP. I can only agree that this will only cause > >>> confusion. > >>> > >>> Cecil Byles > >> > >> > >> Though this is joint work, this is the IETF not the ITU. We should > >> use ITU terms where appropriate but where there is a conflict such as > >> this we need to pick another term and another TLA. If the ITU wants > >> to update 808.1 at some later date that is up to the ITU. In the mean > >> time we can use another term and point out the mapping. > >> > >> Curtis > >> _______________________________________________ > >> 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 > > --001636c92421cf84a2048347a154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ben,

Yes, exactly! As a small network operator, we don't have= the luxury that you may have in terms of a larger workforce and better fun= ding for training. So anything that keeps things similar would be helpful, = and would alleviate us struggling with terminology and fundamental technolo= gy differences.

Of course there would be lots of new terms, but if we keep part of the = terminology as closely coupled to transport network as possible (e.g., prot= ection switching, manual switch, force switch, lockout, wait to restore), t= hese would be concepts they are already familiar with and can identify.

Thanks
Zhi


On Fri, Apr 2, 2010= at 11:30 AM, <benjamin.niven-jenkins@bt.com> wrote:
Zhi,

I suspect your requirement is to keep the operational procedures (MOP) for<= br> MPLS-TP as closely aligned to those of your existing transport network as possible. In other words if scenario A occurs, operations need to follow steps B, C and D etc. where the functions of A, B, C and D are as similar a= s
possible for MPLS-TP and your existing transport network.

Whether the protection switching mechanism is called APS or FOO is a very minor point in the overall operations procedure, otherwise I suspect your operations personnel are going to really struggle with MPLS-TP with its
introduction of other new acronyms Vs transport networks like LSP, PW, BFD<= br> etc ;-)

Ben



On 02/04/2010 15:26, "Lin, Zhi-Wei" <Zhi-Wei.Lin@nyct.com> wrote:

> Hi Ben,
>
> Yes, definitely there are other operators with different operational > considerations. I was offering my perspective and what my company plan= s to do.
>
> However, in terms of the acronyms, even if in your company you plan to= have
> your data group handle MPLS-TP, whether the term is "MPLS-TP APS&= quot; or "PSC",
> from their perspective it will be a new term and therefore no differen= ce which
> it should be.
>
> However, for other operators (such as us) who plans to have the transp= ort
> personnel handle MPLS-TP, then "MPLS-TP APS" would make more= sense. Again,
> functionally, our transport staff will need to be trained on specific<= br> > procedures associated with MPLS-TP, but anything that keeps things &qu= ot;similar"
> is better than nothing.
>
> As such, MPLS-TP APS would be a better term that would make more opera= tors'
> life easier, yes?
>
> Thanks
> Zhi
>
>
> ________________________________
> From: mpls-bounces@ietf.org on behalf of benjamin.n= iven-jenkins@bt.com
> Sent: Fri 4/2/2010 7:46 AM
> To: zhiwlin@gmail.com; curtis@occnc.com
> Cc: Cecil.Byles@interoute= .com; mpls@ietf.org; CCAMP@ietf.org;
> Alexander.Vainshte= in@ecitele.com; mpls-tp@ietf.org
> Subject: Re: [mpls] [CCAMP] [mpls-tp] Term
> "PSC"indraft-ietf-mpls-tp-linear-protection-01
>
>
> Zhi,
>
> Thanks, I understand you perspective.
>
> However I suspect other operators may target their existing data netwo= rk
> operations staff to maintain and operate an MPLS-TP network!
>
> The functionality needs to be as aligned to existing practices (MPLS a= nd
> Transport) as possible. Re-learning/Re-definition of existing operatio= ns
> processes should be minimised but given that MPLS-TP is bridging a gap=
> between data and transport networks some relearning on both sides is > inevitable.
>
> HTH
> Ben
>
>
>
> On 25/03/2010 14:38, "Zhi-Wei Lin" <zhiwlin@gmail.com> wrote:
>
>> Hi,
>>
>> I like to give my perspective. As a small network company (but one= of the
>> largest transit agencies), we have a small operating staff split i= nto two
>> groups: one that handles traditional data network (Ethernet, IP), = and one
>> that
>> handles transport network (SONET, WDM).
>>
>> We are targeting the transport network operating staff to maintain= and
>> operate
>> the MPLS-TP network. As such, anything that will help to reduce th= e learning
>> curve (less training), simplify operating, and make the MOP as con= sistent as
>> possible between SONET and MPLS-TP would be hugely beneficial.
>>
>> Obviously there will be some differences since MPLS-TP is a packet= -based
>> transport network, but the standards groups (I don't really ca= re for politics
>> of IETF and ITU) should strive to make these differences easy to l= earn.
>>
>> Thanks
>> Zhi
>>
>>
>> On Thu, Mar 25, 2010 at 2:09 AM, Curtis Villamizar
>> <curtis@occnc.com<ma= ilto:curtis@occnc.com>> wrote= :
>>
>> In message
>>
<4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com= <mailto:4B2E951>>
0
>> FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com>> >> "Cecil Byles" writes:
>>>
>>>
>>> Hi,
>>> Can I therefore also asked how PSC "Protection State Coor= dination" in
>>> the MPLS-TP parlance align with ITU-T 808.1 recommendation tha= t "defines
>>> the generic functional models, characteristics and processes a= ssociated
>>> with various linear protection schemes for connection-oriented= layer
>>> networks; e.g., Optical Transport Networks (OTN), Synchronous = Digital
>>> Hierarchy (SDH) networks and Asynchronous Transfer Mode (ATM) = networks"
>>> and the sections covering =C2=A0Terms and Definitions as well = as
>>> Abbreviations. =C2=A0IMO all transport engineers and the gener= al telecom
>>> community understand that 1+1 or 1:1 are either SNCP or APS. H= ence why
>>> introduce a new TLA (three letter abbreviation) cover the same= function
>>> and feature for MPLS-TP. =C2=A0I can only agree that this will= only cause
>>> confusion.
>>>
>>> Cecil Byles
>>
>>
>> Though this is joint work, this is the IETF not the ITU. =C2=A0We = should
>> use ITU terms where appropriate but where there is a conflict such= as
>> this we need to pick another term and another TLA. =C2=A0If the IT= U wants
>> to update 808.1 at some later date that is up to the ITU. =C2=A0In= the mean
>> time we can use another term and point out the mapping.
>>
>> Curtis
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org<mailto:mpls@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


--001636c92421cf84a2048347a154-- From gregimirsky@gmail.com Fri Apr 2 17:44:05 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA223A689D; Fri, 2 Apr 2010 17:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4kJl9wjfaxL; Fri, 2 Apr 2010 17:44:04 -0700 (PDT) Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.210.177]) by core3.amsl.com (Postfix) with ESMTP id A57383A686B; Fri, 2 Apr 2010 17:44:02 -0700 (PDT) Received: by yxe7 with SMTP id 7so39929yxe.19 for ; Fri, 02 Apr 2010 17:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=UY6GPAuw8R8abXf55c9ZVgFbmL6DkQ3WY/Rv1e80QmI=; b=UI/DLpcjqQhfCBOl1HYaAcp4L3hjJR2PzEkIzZj9WlS+b/pj2gW2kyXh25xOLVoLk3 pTGduuH87zANp9cBUROCIaEgYujIwVCjdckuABOP1Ojo3gaBLnDoc98au3MGaR+3BWak 9TgVibL/vU/8SuuhbV07dP8nIbK9575rVgYQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FBblknmmNVE26YwKdox6JDMEY+skGGfL1FcW1mXpjyEH35C/nJyrBGUWlX+xk9XzWT ehYSiirwiVYaDvoGn3PBR2iTjnJZ5/pm8vk7liBwrqHDBMLGGWzJ6j1Wi9fXuHnJLWF2 Gh7ODnBIp67V0+CTIDVpg1yreLjzhyjso0AeI= MIME-Version: 1.0 Received: by 10.90.106.16 with HTTP; Fri, 2 Apr 2010 17:44:33 -0700 (PDT) In-Reply-To: <6FD21B53861BF44AA90A288402036AB4030B19E9@FRVELSMBS21.ad2.ad.alcatel.com> References: <787be2781003251455j16112172tf907b7a3084e0ea@mail.gmail.com> <64A8011F-1A3F-4EA9-8CC5-2F0CF97E73C1@juniper.net> <6FD21B53861BF44AA90A288402036AB4030B19E9@FRVELSMBS21.ad2.ad.alcatel.com> Date: Fri, 2 Apr 2010 17:44:33 -0700 Received: by 10.91.50.34 with SMTP id c34mr3862440agk.44.1270255474128; Fri, 02 Apr 2010 17:44:34 -0700 (PDT) Message-ID: From: Greg Mirsky To: BUSI ITALO Content-Type: multipart/alternative; boundary=0016e64097f44f392104834a66c3 Cc: mpls@ietf.org, "Siva Sivabalan\(msiva\)" , Sami Boutros , David Ward , "David Ward \(wardd\)" , mpls-tp@ietf.org Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 00:44:05 -0000 --0016e64097f44f392104834a66c3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Italo, You wrote: "- we need a very simple and lightweight protocol that check continuity and connectivity ("are you there?" question with a "yes/no" answer)" I do agree with Neil that mechanism should be unidirectional with CV messages sent asynchronously at predetermined frequencies (can be asymmetri= c in case of bidirectional connection). And, unfortunately, we have to argument BFD with proper ID through ACH TLVs= . I think that "lightweight" can be true or not only relative to an alternative solution. Regards, Greg On Fri, Apr 2, 2010 at 12:57 AM, BUSI ITALO wrote: > Dave, Greg, > > I think we are mixing different aspect of requirements, solutions and > consequences if requirements are not met. > > The requirements have been expressed more than once but I think that > "repetita juvant": > > - we need a very simple and lightweight protocol that check continuity an= d > connectivity ("are you there?" question with a "yes/no" answer) > > - this check must be performed at a rate that is fully controlled by the > operator (and not by the network) > > - the rate must not change in any condition (only the operator can change > it) > > - the return path is required only on bidirectional p2p paths (either > associated or co-routed) just to carry the RDI indication > > There are many consequences if the requirements are not met. > > One of these consequences is described in the last slide of Annamaria's > presentation done in Anaheim: > > http://tools.ietf.org/agenda/77/slides/mpls-24.ppt > > Unidirectional BFD is not the only solution to address this requirement. > > An alternative solution was also presented in > draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi. > > Italo > > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, > effective since 1 November 2009. > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf Of David Ward > > Sent: mercoled=EC 31 marzo 2010 18.33 > > To: Greg Mirsky > > Cc: Siva Sivabalan(msiva); mpls@ietf.org; David Ward; Sami > > Boutros; David Ward (wardd); mpls-tp@ietf.org > > Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC > > > > Greg - > > > > On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote: > > > > I haven't seen any response from authors thus assuming that > > it didn't make to the list the first time. > > > > On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky > > > wrote: > > Dear Authors and All, > > I would like to ask several questions related to the subject > > I've asked at the meeting today: > > > > * what are reasons considered to select only > > unidirectional BFD (based on BFD for multipoint networks > > work) for proactive CV/CC > > > > DW: This requirement has been bantered back and forth by the > > group. Although not completely explained, it's been deemed > > critical to support by those well versed in transport network > > architectures. > > > > > > > > * what capabilities of BFD for multipoint networks > > required for use as CV/CC in MPLS-TP > > > > DW: Certainly in the MP scenario. As discussed in the preso > > by Rahul at the meeting it can also be used if there is no > > return path (odd network design). > > > > > > * what of capabilities are optional (can and may) > > > > DW: As you saw in the preso, many capabilities and scenarios > > were presented.The point of the preso was they there were all > > optional and that if any of the options were *ever* desired > > then pure unidirectional MP BFD was not a good choice. > > > > > > * are there any capabilities that would not be supported > > (should not and must not) > > > > As was demonstrated in presentation of David's analysis by > > Rahul today, within BFD for MPLS one can create > > unidirectional BFD session already, assuming that the DCN > > exists in some form. > > > > DW: And really only useful if there is never, ever a return path. > > > > Thus it leave p2mp LSP that can benefit from use of BFD for > > multipoint networks mechanism. Or a root can "pretend" that > > p2mp LSP is p2p and send after first exchange of > > Discriminator, and ignore Discrminators from other, > > late-joiner leaves. > > > > Regards, > > Greg > > > > > > > > HIH > > > > -DWard > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > --0016e64097f44f392104834a66c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Italo,
You wrote:
"- we need a very simple and lightweight = protocol that check continuity=20 and connectivity ("are you there?" question with a "yes/no&q= uot; answer)"
I do agree with Neil that mechanism should be unidire= ctional with CV messages sent asynchronously at predetermined frequencies (= can be asymmetric in case of bidirectional connection).
And, unfortunately, we have to argument BFD with proper ID through ACH TLVs= . I think that=A0 "lightweight" can be true or not only relative = to an alternative solution.

Regards,
Greg

On Fri, Apr 2, 2010 at 12:57 AM, BUSI ITALO <Italo.Busi@alcatel-lucent.com= > wrote:
Dave, Greg,

I think we are mixing different aspect of requirements, solutions and conse= quences if requirements are not met.

The requirements have been expressed more than once but I think that "= repetita juvant":

- we need a very simple and lightweight protocol that check continuity and = connectivity ("are you there?" question with a "yes/no"= answer)

- this check must be performed at a rate that is fully controlled by the op= erator (and not by the network)

- the rate must not change in any condition (only the operator can change i= t)

- the return path is required only on bidirectional p2p paths (either assoc= iated or co-routed) just to carry the RDI indication

There are many consequences if the requirements are not met.

One of these consequences is described in the last slide of Annamaria's= presentation done in Anaheim:

http://tools.ietf.org/agenda/77/slides/mpls-24.ppt

Unidirectional BFD is not the only solution to address this requirement.
An alternative solution was also presented in draft-fulignoli-mpls-tp-bfd-c= v-proactive-and-rdi.

Italo

P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effective since 1 November = 2009.

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On
> Behalf Of David Ward
> Sent: mercoled=EC 31 marzo 2010 18.33
> To: Greg Mirsky
> Cc: Siva Sivabalan(msiva); mpls@ietf.= org; David Ward; Sami
> Boutros; David Ward (wardd); mpls-= tp@ietf.org
> Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC >
> Greg -
>
> On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote:
>
> I haven't seen any response from authors thus assuming that
> it didn't make to the list the first time.
>
> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky
> <gregimirsky@gmail.com= <mailto:gregimirsky@gmail.com>> wrote:
> Dear Authors and All,
> I would like to ask several questions related to the subject
> I've asked at the meeting today:
>
> =A0* =A0 what are reasons considered to select only
> unidirectional BFD (based on BFD for multipoint networks
> work) for proactive CV/CC
>
> DW: This requirement has been bantered back and forth by the
> group. Although not completely explained, it's been deemed
> critical to support by those well versed in transport network
> architectures.
>
>
>
> =A0* =A0 what capabilities of BFD for multipoint networks
> required for use as CV/CC in MPLS-TP
>
> DW: Certainly in the MP scenario. As discussed in the preso
> by Rahul at the meeting it can also be used if there is no
> return path (odd network design).
>
>
> =A0* =A0 what of capabilities are optional (can and may)
>
> DW: As you saw in the preso, many capabilities and scenarios
> were presented.The point of the preso was they there were all
> optional and that if any of the options were *ever* desired
> then pure unidirectional MP BFD was not a good choice.
>
>
> =A0* =A0 are there any capabilities that would not be supported
> (should not and must not)
>
> As was demonstrated in presentation of David's analysis by
> Rahul today, within BFD for MPLS one can create
> unidirectional BFD session already, assuming that the DCN
> exists in some form.
>
> DW: And really only useful if there is never, ever a return path.
>
> Thus it leave p2mp LSP that can benefit from use of BFD for
> multipoint networks mechanism. Or a root can "pretend" that<= br> > p2mp LSP is p2p and send after first exchange of
> Discriminator, and ignore Discrminators from other,
> late-joiner leaves.
>
> Regards,
> Greg
>
>
>
> HIH
>
> -DWard
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

--0016e64097f44f392104834a66c3-- From neil.2.harrison@bt.com Sat Apr 3 00:35:23 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206073A693D; Sat, 3 Apr 2010 00:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH1TsMi0sRX5; Sat, 3 Apr 2010 00:35:22 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id ADB873A6870; Sat, 3 Apr 2010 00:35:21 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Apr 2010 08:35:20 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD300.36048452" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 3 Apr 2010 08:35:17 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05C64B64@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC Thread-Index: AcrSgTjbJ3tXVLzcSl2E0LjBqkPcuQABKZQAAAPhtsAADPT2kAANP67AAABp4SA= From: To: , , X-OriginalArrivalTime: 03 Apr 2010 07:35:20.0179 (UTC) FILETIME=[36877C30:01CAD300] Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 07:35:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD300.36048452 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Apologies for re-send...but got a message saying 'too big' so snipped this version. ________________________________ From: Harrison,N,Neil,DKQ7 R=20 Sent: 03 April 2010 08:31 To: 'Maarten Vissers'; mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC =09 =09 Thanks Maarten....couple of minor observations in-line: ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 03 April 2010 02:08 To: Harrison,N,Neil,DKQ7 R; mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC =09 =09 Neil, =20 See inline.. ________________________________ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 2 april 2010 20:59 To: maarten.vissers@huawei.com; mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC =09 =09 Thanks Maarten, =20 I believe the key point you are trying to make here is that when we have a mismerge defect it is the lowest CV rate (and not simply the offending mismerged CV rate that you state below) that should determine the defect processing algorithm at the sink. This seem a reasonable idea on the face of it. Or have I missed something? =20 [maarten] this is indeed the principle. To be noted in addition is that the defect setting is based on reception of the first CCM frame with unexpected MEGID value, which makes the defect setting independent of the period. Only the defect clearing is dependent on the period of the unexpected CCM frame.=20 NH=3D> Thanks. So it looks like we have a way of dealing with different CV rates. This seems a good step forward. We should not however have lots of CV rates in the same layer network as the '2 from N' combinatorial issue has not gone away, we have just stated a way to deal with it. =20 I think reference to Ethernet or any other specific technology is not relevant.=20 =20 [maarten] The principle is currently implemented in Ethernet, but can be applied generically... =20 NH=3D> Agreed. I should also have said that if we consider this a 'best-case' architectural practice then it should be the goal for the OAM of all co-ps mode technologies. =20 =20 Note - I still stand by all the other points I made in my initial response to Italo on things like transparency, CoS level relationship to a connection, etc. =20 regards, Neil =20 =20 Regards, Maarten=20 =20 =20 ------_=_NextPart_001_01CAD300.36048452 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Apologies for re-send...but got a message = saying 'too=20 big' so snipped this version.

From: Harrison,N,Neil,DKQ7 R =
Sent:=20 03 April 2010 08:31
To: 'Maarten Vissers'; mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: RE: [mpls] [mpls-tp] Choice of BFD = mechanism/modefor proactive CV/CC

Thanks Maarten....couple of = minor=20 observations in-line:

From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com]
Sent: 03 April 2010=20 02:08
To: Harrison,N,Neil,DKQ7 R; mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: RE: [mpls] [mpls-tp] Choice of = BFD=20 mechanism/modefor proactive CV/CC

Neil,
 
See inline..

From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com]
Sent: vrijdag 2 april = 2010=20 20:59
To: maarten.vissers@huawei.com; mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: RE: [mpls] [mpls-tp] Choice of = BFD=20 mechanism/modefor proactive CV/CC

Thanks = Maarten,
 
I believe the key point you = are trying to=20 make here is that when we have a mismerge defect it is the lowest CV = rate=20 (and not simply the offending mismerged CV rate that you state = below) that=20 should determine the defect processing algorithm at the sink.  = This=20 seem a reasonable idea on the face of it.  Or have I missed=20 something?
 
[maarten] this is indeed the principle. To be = noted in=20 addition is that the defect setting is based on reception of the = first CCM=20 frame with unexpected MEGID value, which makes the defect setting=20 independent of the period. Only the defect clearing is dependent on = the=20 period of the unexpected CCM frame. 
NH=3D> Thanks.  So it looks like we have a = way of=20 dealing with different CV rates.  This seems a good step=20 forward.   We should not = however have=20 lots of CV rates in the same layer network as the '2 from N' = combinatorial=20 issue has not gone away, we have just stated a way to deal with=20 it.
 
I think reference to Ethernet = or any=20 other specific technology is not relevant. 
 
[maarten] The principle is = currently implemented in=20 Ethernet, but can be applied generically...  
NH=3D> = Agreed.  I=20 should also have said that if we consider this a 'best-case' = architectural=20 practice then it should be the goal for the OAM of all co-ps mode=20 = technologies.  
=
 
Note = - I still=20 stand by all the other points I made in my initial = response to=20 Italo on things like transparency, CoS level relationship to a = connection,=20 etc.
 
regards,=20 Neil  
 
Regards,
Maarten 
 
 <SNIPPED> 
------_=_NextPart_001_01CAD300.36048452-- From loa@pi.nu Sat Apr 3 02:36:34 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF30E3A6A01; Sat, 3 Apr 2010 02:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsuVXtBwcajt; Sat, 3 Apr 2010 02:36:34 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 76DF23A6A18; Sat, 3 Apr 2010 02:31:24 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id D90B6D404F; Sat, 3 Apr 2010 11:31:20 +0200 (CEST) Message-ID: <4BB70AE7.1020605@pi.nu> Date: Sat, 03 Apr 2010 11:31:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, MPLS-TP ad hoc team , pwe3@ietf.org, CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 09:36:34 -0000 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wwwrun@core3.amsl.com Sat Apr 3 02:46:21 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 610F13A68B7; Sat, 3 Apr 2010 02:46:21 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100403094621.610F13A68B7@core3.amsl.com> Date: Sat, 3 Apr 2010 02:46:21 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 09:46:21 -0000 Title: MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01) Submission Date: 2010-04-03 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=863 Please reply by 2010-04-17 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For comment Body: MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01) draft-ietf-mpls-tp-framework-11 SG15, Q9, Q10, Q12 and Q14 We like to to inform you that the MPLS working group just started a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the previous working group last call and reviews have been correctly addressed. We would like to receive comments from the ITU-T by April 17th 2010 the latest. Loa Andersson George Swallow MPLS Working Group co-chairs Attachment(s): No document has been attached From sriganesh.kini@ericsson.com Sat Apr 3 17:08:23 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D961D3A68A3; Sat, 3 Apr 2010 17:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_99=3.5, MANGLED_LINKS=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0Er6mpQRmrx; Sat, 3 Apr 2010 17:08:20 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 445483A68DA; Sat, 3 Apr 2010 17:08:20 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o340C6WO009686; Sat, 3 Apr 2010 19:12:06 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sat, 3 Apr 2010 20:08:17 -0400 From: Sriganesh Kini To: Phil Bedard , "curtis@occnc.com" Date: Sat, 3 Apr 2010 20:08:13 -0400 Thread-Topic: [mpls] [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology Thread-Index: AcrPWAKKL4tlHC03SheySwymrw2giAEJErmQ Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F52E4836339@EUSAACMS0703.eamcs.ericsson.se> References: <201003290709.o2T791Jo002995@harbor.orleans.occnc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] Comments to Efficient FRR using Facility backup in ring topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 00:08:24 -0000 Hi Phil, pls see inline - Sri > -----Original Message----- > From: Phil Bedard [mailto:bedard.phil@gmail.com] > Sent: Monday, March 29, 2010 8:53 AM > To: curtis@occnc.com > Cc: Sriganesh Kini; mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls] [mpls-tp] Comments to Efficient FRR using > Facility backup in ring topology > > So Curtis basically drove the diagram I was thinking of and I > know it is outside the realm of a simple ring topology but > this is how our network works today. My initial reaction to > reading the draft was I was wondering how many operators > today are in a position where they are oversubscribing their > ring capacity, at least for high priority or critical > traffic? In our network, we have an overwhelming amount of > low priority data traffic, so using this optimized FRR would > probably not interest us. Losing some amount of low priority > traffic for the 500ms-2s or so it takes global path > restoration to complete is acceptable. When the traffic is low priority and loss of upto 2s is acceptable, existin= g mechanisms may suffice. You may not even need FRR and plain old IGP conve= rgence could be enough. This draft's mechanism gives a way reduce the bandwidth used for protection= while giving similar protection guarantees as FRR. The bandwidth savings c= ould be used for traffic that generates additional revenue (higher/lower pr= io). > > Also with interconnected rings of varying complexity, we run > the risk of inducing an additional protection switch event. > There is a bit of video/voice traffic where we'd like to > minimize the protection events because they induce loss or > re-ordering. > > Curtis, maybe I'm misunderstanding the draft but there would > be two "backup LSPs" built. If the path to P was > A-B-C-D-E-O-P and the bypass covering C-D was C-B-G-H-I-J-E-D > , O would not be a candidate MP for the "backup LSP" for A-P > because the bypass does not cross O. So the PLR-u would use > one bypass to cover A-K from A-J and one bypass to cover A-F > and A-P using A-E. The PLR-u would map LSPs to specific > optimized bypasses. Then alerts on the normal FRR bypass > trigger a protection switch on the PLR-u. Note that when PLR (C) has to protect against failure of node D then the by= pass for a protected LSP A-B-C-D-E-O-P would have to be C-B-G-H-I-J-E (or C= -B-L-M-N-O-E or even C-B-L-M-N-O but that is specifically for protected LSP= s that go through O). PLR-u (B) makes the protection switch more efficient = by setting up an additional backup B-G-H-I-J-E (or B-L-M-N-O) respectively.= Correct that the alert on the normal FRR bypass would trigger a protection= switch at PLR-u. > > I'd consider this a weak point in the draft, there is not > much explanation about how the additional bypass from the > PLR-u to the "MP-d" is constructed. I believe the draft just > mentions through the use of the new RSVP information (which > LSPs use which normal FRR bypass) and the TED, the new > bypasses ("backup LSPs") are built. Perhaps in the future > drafts there will be more explanation around building > multiple bypasses from the PLR-u to the MPs in a more complex > topology like you've shown. Section 4 explains how to route the additional bypass from PLR-u. Additiona= l text/figures can help to explain further. Comment accepted. We have kept the topology in Fig 1 simple for illustrative clarity. Section= 6 does explain how this translates to applicability into general topologie= s. Note that even in the simple topology in Figure 1 in the draft there wil= l be additional bypasses from PLR-u to each egress on the ring where there = is a protected LSP. This can be highlighted as well as additional complex t= opologies can be included. Comment accepted. > > I can see the motivation in the draft but it seems like a lot > of implementation work for not much gain. The amount of work is influenced by the implementation. It should not be a = lot more work when built over a node protection bypass FRR infrastructure. The gain of course depends on the nature/value of traffic carried on the ne= twork. > > > Phil > > > > On Mar 29, 2010, at 3:09 AM, Curtis Villamizar wrote: > > > > > In message > > > <5A5E55DF96F73844AF7DFB0F48721F0F52E47A7678@EUSAACMS0703.eamcs.ericsso > > n.se> > > Sriganesh Kini writes: > >> > >> Hi Curtis, see inline @ [Sri] > >> > >> > >> - Sri > > > > > > Sri, > > > > You are missing some important points regarding how FRR works. It > > works from the PLR, not the PLR-u. There can be more than one > > facilities backup LSP with different merge points. > Consider a pair of > > rings that overlap. > > > > G --- H --- I --- J --- K > > | | > > A --- B --- C -X- D --- E --- F > > | | > > L --- M --- N --- O --- P > > > > Node B can detect that a failure has occurred downstream > but the merge > > points would be different for traffic to F, K, and P. Node B would > > have to determine which LSP are affected by knowing where > the failure > > is so that it didn't route traffic destined to C or > anything connected > > to C on the protect path through D. > > > > That is not FRR as FRR is defined. FRR only acts at the PLR. > > > > Did you say how B would know that the failure is at C-D? If so I > > missed that. > > > > Also each PLR which could act as a PLR-u would need to be > able to map > > any downstream failure to the set of protects that needed to be > > activated. AFAIK no merchant silicon (Ethernet) supports a > > sufficiently flexible mapping and no designs to date (again AFAIK). > > This would require new hardware or activation in software > (slow). FRR > > activation today is done either purely or almost purely in hardware. > > > > Curtis > > > > > >> -----Original Message----- > >> From: curtis@occnc.com [mailto:curtis@occnc.com] > >> Sent: Sunday, March 28, 2010 8:36 PM > >> To: Sriganesh Kini > >> Cc: Greg Mirsky; curtis@occnc.com; mpls@ietf.org; mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility > >> backup in ring topology > >> > >> > >> In message > >> > <5A5E55DF96F73844AF7DFB0F48721F0F52E47A75CC@EUSAACMS0703.eamcs.ericss > >> on.se> > >> Sriganesh Kini writes: > >>> > >>> > >>> Facility backup FRR is a widely deployed protection > method and it is > >>> useful to make it efficient in specific cases where it is > not. Just > >>> to re-iterate (again), this draft is applicable to MPLS > and is for > >>> general topologies. > >>> > >>> How PLR determines the round-trip delay to hold off for the > >>> switchover can be treated as a study topic for the > applications that > >>> consider re-ordering for these miniscule time-scales relevant > >>> enough. The reason for the tunnel between PLR and MP is > that such a > >>> bypass exists in the current deployment and also avoids a > flag-day > >>> upgrade requirement. > >>> > >>> Regarding observations on too many moving parts to work as > >>> fast/reliable, it would be useful if you can be specific on which > >>> part it is about and what the unreliability is. If the > observation > >>> is from the point-of-view of a specific implementation, > it would be > >>> considered out of scope of this draft. > >>> > >>> > >>> - Sri > >> > >> > >> Sri, > >> > >> In the example > >> > >> G --- H --- H --- I > >> | | > >> A --- B --- C -X- D --- E --- F > >> > >> The FRR protect path is from C to the merge point at E. > The ring schemes move the protect back to B. FRR leaves the > protection at C. > >> I think you know that, just confirming. > >> > >> [Sri] Yes. A minor caveat is that if it is a link (C-D) > bypass then MP for the FRR bypass from PLR (C) is at D. > >> > >> FRR would normally protect traffic until A as ingress > rerouted the working path. In the absense of a control > plane, the management plane would do this (maybe). If there > was a further alternate besides the ring, then a protect path > for the new A-F working path would be brought up. > >> > >> [Sri] Agree. > >> > >> The question is whether the interim protection from B is > valuable. If it is much faster than the reroute from ingress > then it is valuable because less capacity is needed to > provide protection. If there is no reroute from ingress, > then it is also valuable. (That said, my preference is > facilities FRR, but I need to consider customer input - which > for us has not indicated a need for ring protection so far - > but that is only one data point). > >> > >> [Sri] Note that protection from PLR-u is also valuable due > to it being faster at higher scale. E.g consider the example > in the draft where there are a large number of protected LSPs > routed via L8->L7. If the backup LSP from PLR-u is setup as a > bypass, then all the LSPs entering/exiting the ring through > common points (and going through L8-L7) can be protected by a > single bypass (for each entry/exit point). A very simple > protection switch operation at each PLR-u can protect a large > number of LSPs. This should be faster than the ingress > re-routing each protected LSP individually. > > > > [CV] That is not what FRR does. > > > >> I was just pointing out that there are extra reorder > events and not commenting on whether that was a problem or > not. I just said it should be acknowledged in any ring > protection document that proposes such a mechanism. > >> > >> [Sri] Accepted > >> > >> Maybe I should ask you who you think is complaining about > "too many moving parts ... etc". I don't follow the "flag > day" issue you brought up. > >> > >> [Sri] The comment about "too many moving parts" was from > Greg. He also commented "And if we put all these efforts to > switch at PLR-u, what is the reason for tunnel between FRR's > PLR and MP?". There is a simpler reason for that. To protect > LSPs across the link (LSP C->D in your example above and a > LSP L8->L7 in the example in the draft). > >> > >> Curtis > >> > >> > >>> ________________________________ > >>> From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >>> Sent: Saturday, March 27, 2010 9:32 PM > >>> To: curtis@occnc.com > >>> Cc: Sriganesh Kini; mpls@ietf.org; mpls-tp@ietf.org > >>> Subject: Re: [mpls-tp] Comments to Efficient FRR using Facility > >>> backup in ring topology > >>> > >>> Hi Curtis, > >>> > >>> if I look at the protection tunnel created between PLR-u and MP-d > >>> (there's no such definition in the document so I've invented it > >>> myself to avoid convoluted definition of new merge point) I see a > >>> TCM that is terminated at ingress and egress LSRs for the > protected > >>> LSP(s). We know how to monitor segments (TCM) and > associate segment protection. > >>> Why make FRR into what it is not - segment protection? > >>> > >>> Besides, how long PLR should hold off its switchover to > let PLR-u to > >>> switch? Should PLR statistically measure round trip delay > to PLR-u? > >>> And if we put all these efforts to switch at PLR-u, what is the > >>> reason for tunnel between FRR's PLR and MP? I'm really > confused by > >>> motivation of this work. FRR - acknowledged method for local > >>> protection and, I believe, should be used as such. Trying > to combine > >>> link local fault detection, fault signaling and switchover at the > >>> headend - too many moving parts to work as fast and as > reliable as > >>> when detection and switchover are on the same node, be it > PLR, LER or headend of TCM. > >>> > >>> Regards, > >>> Greg > >>> > >>> On Sat, Mar 27, 2010 at 8:17 PM, Curtis Villamizar > > wrote: > >>> > >>> In message > >>> > <787be2781003260020m44fbf23g71387697e6d5db19@mail.gmail.com >>> 87 be2781003260020m44fbf23g71387697e6d5db19@mail.gmail.com>> > >>> Greg Mirsky writes: > >>>> > >>>> > >>>> Dear Sri, > >>>> thank you for your response. If understand correctly, > the proposed > >>>> protection mechanism is a two-phase switchover since the > switchover > >>>> first is done on PLR and then, while actual FRR's bypass > tunnel is > >>>> deployed, on PLR-u. If that is the case, then I have concern > >>>> whether this mechanism is applicable to MPLS-TP because > >>>> requirements 24 and > >>>> 44 in RFC 5654 state the MPLS-TP must avoid or minimize > impact on > >>>> transported customer's service traffic, including its reordering. > >>>> And reordering will happen because of two-phase switchover. > >>>> > >>>> Regards, > >>>> Greg > >>> > >>> > >>> Greg, > >>> > >>> If the protect path has a longer delay there is a gap in service > >>> data on failure and then reordering occurs on reversion. > It isn't > >>> practical to eliminate all reordering (except dump traffic for a > >>> predetermined period during any transition). > >>> > >>> If the PLR swtiches to a PLR-u then there is a reorder event for > >>> each such switch. Its probably best to defer these swithovers so > >>> that there is one reordering event involving the PLR-u > furthest upstream. > >>> Is that your point? If reordering is reduced to one additional > >>> event, it should be sufficient to mention the additional > reordering event. > >>> > >>> Curtis > >>> > >>> > >>>> On Thu, Mar 25, 2010 at 6:25 PM, Sriganesh Kini > >>>> > >>>>> wrote: > >>>> > >>>>> See inline @ [Sri] > >>>>> > >>>>> > >>>>> - Sri > >>>>> > >>>>> > >>>>> ------------------------------ > >>>>> *From:* Greg Mirsky > >>>>> [mailto:gregimirsky@gmail.com >>> ail.com>] > >>>>> *Sent:* Thursday, March 25, 2010 6:15 PM > >>>>> *To:* Sriganesh Kini > >>>>> *Cc:* Autumn Liu; mpls@ietf.org > >>>>> > >>>>> *Subject:* Re: Comments to Efficient FRR using Facility > backup in > >>>>> ring topology > >>>>> > >>>>> Dear Sri, > >>>>> if by reference to how PLR-u selects an end-point for > its bypass > >>>>> tunnel=3D > >>> you > >>>>> meant "The traffic should be protection switched to a > backup path > >>>>> terminating on a LSR along the protected LSP that is furthest > >>>>> downstrea=3D > >>> m > >>>>> from the MP and has the protected and bypass LSPs going in the > >>>>> opposite directions", then I might offer another formula: > >>>>> "The remote end-point of a bypass LSR must be selected at first > >>>>> common, between PLR's bypass tunnel's path and the > protected LSP, > >>>>> LSR taken in direction of the bypass tunnel." > >>>>> [Sri ] That alternate wording has already been used in the > >>>>> presentation=3D > >>> - > >>>>> see slide 4 > >>>>> > >>>>> As for reliability of the alert mechanism, I'd point that there > >>>>> are mor=3D > >>> e > >>>>> moving parts in processing a packet in Switchover scenario than > >>>>> process=3D > >>> ing > >>>>> "normal" BFD packet. Latter is very often done completely in HW > >>>>> while f=3D > >>> ormer > >>>>> in SW. Hence the possible lack of reliability in > processing while > >>>>> BFD session deemed Up. > >>>>> [Sri ] This is an implementation choice. The folks who > implement > >>>>> it rig=3D > >>> ht > >>>>> will make it reliable. > >>>>> > >>>>> Note that by deploying FRR you already create > congestion on L9-L8 > >>>>> link =3D > >>> thus > >>>>> reducing reliability of the alert mechanism. > >>>>> [Sri ] The alert mechanism is a control-packet and should be > >>>>> handled at higher priority/reliability (than a data packet). > >>>>> > >>>>> FRR is viewed as temporary solution, in large part, because > >>>>> inefficienc=3D > >>> y > >>>>> you're addressing. End-to-end protection, in many cases, is > >>>>> capable to deliver identical to protected path service > guarantees > >>>>> and might not re=3D > >>> quire > >>>>> revertive action. I think that many of deployments have > historical > >>>>> rath=3D > >>> er > >>>>> than technical explanation in which method been selected. > >>>>> [Sri ] With this in-efficiency addressed it should not > be the case. > >>>>> End-to-end protection is more expensive. Facility backup is a > >>>>> scalable widely deployed protection mechanism. > >>>>> > >>>>> > >>>>> Regards, > >>>>> Greg > >>>>> > >>>>> On Thu, Mar 25, 2010 at 5:53 PM, Sriganesh Kini < > >>>>> > sriganesh.kini@ericsson.com >> wrote: > >>>>> > >>>>>> Greg, see inline @ [Sri] > >>>>>> > >>>>>> > >>>>>> - Sri > >>>>>> > >>>>>> > >>>>>> ------------------------------ > >>>>>> *From:* Greg Mirsky > >>>>>> [mailto:gregimirsky@gmail.com >>> mail.com>] > >>>>>> *Sent:* Thursday, March 25, 2010 5:23 PM > >>>>>> *To:* Autumn Liu; Sriganesh Kini; > >>>>>> mpls@ietf.org > >>>>>> *Subject:* Re: Comments to Efficient FRR using > Facility backup in > >>>>>> ring topology > >>>>>> > >>>>>> Dear Authors, > >>>>>> please kindly consider my comments to the document: > >>>>>> > >>>>>> - in Section 4.2 following assumption being made > "Thus each LSR > >>>>>> alo=3D > >>> ng > >>>>>> the bypass receives the packet." I believe that there is no > >>>>>> guarant=3D > >>> ee that > >>>>>> each LSR along the bypass tunnel will receive the alert > >>>>>> message, ev=3D > >>> en if it > >>>>>> will be sent three times. As result of this > assumption most of > >>>>>> conc=3D > >>> lusions > >>>>>> regarding proposed solution look unfounded. > >>>>>> [Sri ] The three times is immediately on failure. It is sent > >>>>>> periodically later. If the very highly unlikely > event that all > >>>>>> thre=3D > >>> e > >>>>>> messages are dropped, then it means that there is a problem > >>>>>> sending=3D > >>> data > >>>>>> packets on the bypass and other means (such as BFD and/or > >>>>>> signaling=3D > >>> ) would > >>>>>> indicate the problem. Such packet drop problems on > the bypass > >>>>>> shoul=3D > >>> d have > >>>>>> been visible even before the failure and appropriate > rectifying > >>>>>> act=3D > >>> ions > >>>>>> would have occurred. > >>>>>> - in is not clear from the Section 4.3 Procedures at PLR > >>>>>> whether PL=3D > >>> R > >>>>>> deploys its bypass tunnel locally as well as sets FLA bit in > >>>>>> BFD me=3D > >>> ssage or > >>>>>> totally relies on actions of PLR-u's > >>>>>> [Sri ] PLR deploys the protection switch to bypass > and sets FLA > >>>>>> bit=3D > >>> . > >>>>>> - if the Merge Point of bypass tunnels set by > PLR-u's is, using > >>>>>> Fig=3D > >>> .1 > >>>>>> and scenario from Section 3, L7, then the solution > only solves > >>>>>> half=3D > >>> of the > >>>>>> problem characteristic to Facility protection in a ring > >>>>>> topology. P=3D > >>> ossible > >>>>>> congestion on link L9-L8 might be avoided, but not on link > >>>>>> L7-L6. T=3D > >>> o address > >>>>>> this congestion, the MP must be changed when PLR-u > sets its bypass. > >>>>>> [Sri ] Seems you haven't understood the text in > section 4 that > >>>>>> describes how MP is chosen for a bypass from PLR-u. Also it > >>>>>> seems y=3D > >>> ou > >>>>>> haven't read section 5 that clearly states that for traffic > >>>>>> protect=3D > >>> ion > >>>>>> switched from PLR-u, the MP is at L6. There is NO > congestion on > >>>>>> L7-=3D > >>> L6. > >>>>>> - Introduction of PLR-u for all local protections along the > >>>>>> protect=3D > >>> ed > >>>>>> LSR might create scaling problem and is not > necessary (I'll try > >>>>>> to =3D > >>> explain > >>>>>> that below). > >>>>>> [Sri ] PLR-u is created at nodes along bypass LSP. > The explanation > >>>>>> below does not clearly state the scaling parameter you are > >>>>>> concerne=3D > >>> d about. > >>>>>> > >>>>>> I still don't see value of alerting all LSR along the bypass > >>>>>> tunnel th=3D > >>> at > >>>>>> provides local protection as well as all this transient LSRs > >>>>>> being PLR=3D > >>> -u. > >>>>>> What is really needed, in my view, is end-to-end or segment > >>>>>> protection=3D > >>> and a > >>>>>> way for LER/segment's head-end to learn about the > failure along > >>>>>> the protected LSR fast enough. If one decides to run > link layer > >>>>>> OAM rather=3D > >>> than > >>>>>> end-to-end or segment/TCM, then LSR, known as PLR, > needs fast and > >>>>>> reli=3D > >>> able > >>>>>> method of notifying LER. But I don't see good > technical reason to > >>>>>> do t=3D > >>> hat > >>>>>> when there are ways to avoid this problem. > >>>>>> [Sri ] Alerting all LSRs along the bypass helps to do > protection > >>>>>> switc=3D > >>> hing > >>>>>> for all protected LSPs that are protected by the bypass. > >>>>>> End-to-end protection is not as scalable. That is why RFC4090 > >>>>>> specified the scala=3D > >>> ble > >>>>>> FRR mechanism of facility backup and it is widely > deployed. Your > >>>>>> observations on link-layer OAM, ...etc would have been > useful if > >>>>>> it ha=3D > >>> d > >>>>>> details. Again note that our draft addresses general physical > >>>>>> topologi=3D > >>> es > >>>>>> (not just ring). > >>>>>> > >>>>>> Regards, > >>>>>> Greg > >>> > >>> > >>> --_000_5A5E55DF96F73844AF7DFB0F48721F0F52E47A75CCEUSAACMS0703e_ > >>> Content-Type: text/html; charset=3D"us-ascii" > >>> Content-Transfer-Encoding: quoted-printable > >>> > >>> > >>> content=3D3D"text/html; > >>> charset=3D3Dus-ascii"> >>> name=3D3DGENERATOR>
>>> class=3D3D129390507-28032010> color=3D3D#0000ff > >>> size=3D3D2>Facility backup FRR is a widely deployed protectio=3D n > >>> method=3D20 and it is useful to make it efficient in specific cases > >>> where it is not. Ju=3D st to=3D20 re-iterate (again), this draft is > >>> applicable to MPLS and is for general=3D20 topologies. > >>>
>>> class=3D3D129390507-28032010> color=3D3D#0000ff > >>> size=3D3D2> 
> >>>
class=3D3D129390507-28032010> >>> face=3D3DA=3D rial=3D20 color=3D3D#0000ff size=3D3D2>How > PLR determines > >>> the round-trip delay to=3D20 hold off for the > switchover can be > >>> treated as a study topic for the=3D20 applications that consider > >>> re-ordering for these miniscule time-scales rele=3D vant=3D20 enough. > >>> The reason for the tunnel between PLR and MP is that > such a by=3D > >>> pass=3D20 exists in the current deployment and also avoids > a flag-day > >>> upgrade=3D20 requirement.
face=3D3DArial > >>> color=3D3D#0000ff size=3D3D2> 
>>> class=3D3D129390507-28032010> >>> size=3D3D2>Regarding observations on too many moving parts > to work as > >>> fast/re=3D liable,=3D20 it would be useful if you can be specific on > >>> which part it is about and wha=3D t the=3D20 unreliability is. If the > >>> observation is from the point-of-view of =3D ;a=3D20 > specific > >>> implementation, it would be considered out of scope of this=3D20 > >>> draft.
>>> class=3D3D129390507-28032010> >>> size=3D3D2> 

- > >>> Sri

>>> size=3D3D2> 
>>> size=3D3D2> >>> face=3D3DArial=3D20 size=3D3D2> >>> size=3D3D2>
0px">
>>> class=3D3DOutlookMessageHeader lang=3D3Den-us dir=3D3Dltr > align=3D3Dleft> > >>>
size=3D3D2>From: Greg > >>> Mirsky=3D20 [mailto:gregimirsky@gmail.com] >
Sent: Saturday, > >>> March 27, 2010 =3D 9:32=3D20 PM
To: > >>> curtis@occnc.com
Cc: Sriganesh Kini; mpls@ietf=3D > .org;=3D20 > >>> mpls-tp@ietf.org
Subject: Re: [mpls-tp] Comments to > >>> Efficient F=3D RR=3D20 using Facility backup in ring > >>> topology

Hi > Curtis,
if I look at > >>> the protection tunnel created betwe=3D en=3D20 PLR-u and > MP-d (there's > >>> no such definition in the document so I've invent=3D ed > it=3D20 myself > >>> to avoid convoluted definition of new merge point) I see > a TCM tha=3D > >>> t is=3D20 terminated at ingress and egress LSRs for the protected > >>> LSP(s). We know h=3D ow to=3D20 monitor segments (TCM) and associate > >>> segment protection. Why make FRR int=3D o=3D20 what it is > not - segment > >>> protection?
Besides, how long PLR should hold=3D off=3D20 its > >>> switchover to let PLR-u to switch? Should PLR > statistically measure > >>> r=3D ound=3D20 trip delay to PLR-u? And if we put all these > efforts to > >>> switch at PLR-u, =3D what=3D20 is the reason for tunnel > between FRR's > >>> PLR and MP? I'm really confused by=3D =3D20 motivation of this work. > >>> FRR - acknowledged method for local protection a=3D nd, > I=3D20 believe, > >>> should be used as such. Trying to combine link local fault detec=3D > >>> tion,=3D20 fault signaling and switchover at the headend - > too many > >>> moving parts to =3D work=3D20 as fast and as reliable as > when detection > >>> and switchover are on the same =3D node,=3D20 be it PLR, LER > or headend > >>> of TCM.

Regards,
Greg

>>> class=3D3Dgmail_quote>On Sat, Mar 27, 2010 at 8:17 PM, Curtis > >>> Villamiz=3D ar=3D20 < >>> href=3D3D"mailto:curtis@occnc.com">curtis@occnc.com> > >>> wrote: >>> R> > >>>
>>> style=3D3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; > BORDER-LEFT: > >>> rgb(2=3D > >>> 04,204,204) 1px solid">
In=3D20 > >>> message < >>> > >>> > href=3D3D"mailto:787be2781003260020m44fbf23g71387697e6d5db19@mail.gmail. > >>> c=3D > >>> > om">787be2781003260020m44fbf23g71387697e6d5db19@mail.gmail.com >
> >>>
Greg Mirsky > writes:
>
>
> Dear > >>> Sri, >>> R>>=3D20 > >>> thank you for your response. If understand correctly, the > >>> proposed
&=3D gt;=3D20 > >>> protection mechanism is a two-phase switchover since the > >>> switchover fir=3D st=3D20 > >>> is
> done on PLR and then, while actual FRR's > bypass tunnel is=3D20 > >>> deployed, on
> PLR-u. If that is the case, then I have > >>> concern wh=3D ether=3D20 > >>> this mechanism is
> applicable to MPLS-TP because > >>> requirements 24=3D and=3D20 > >>> 44 in RFC 5654 state the
> MPLS-TP must avoid or > minimize > >>> impact =3D on=3D20 > >>> transported customer's service
> traffic, including its > >>> reorderin=3D g.=3D20 > >>> And reordering will happen because of
> two-phase=3D20 > >>> switchover.
>
> Regards,
>=3D20 > >>> Greg


Greg,

If the protect path has a > >>> longer del=3D ay=3D20 > >>> there is a gap in service data
on failure and then > reordering > >>> occurs=3D on=3D20 > >>> reversion.  It isn't
practical to eliminate all > >>> reordering (exc=3D ept=3D20 > >>> dump traffic for a
predetermined period during any > >>> transition).
<=3D > >>> BR>If=3D20 > >>> the PLR swtiches to a PLR-u then there is a reorder event for > >>> each
s=3D uch=3D20 > >>> switch.  Its probably best to defer these swithovers so > >>> that
th=3D ere=3D20 > >>> is one reordering event involving the PLR-u furthest > >>> upstream.
Is th=3D at=3D20 > >>> your point?  If reordering is reduced to one additional > >>> event,
=3D it=3D20 > >>> should be sufficient to mention the additional reordering > >>> event.
>>> color=3D3D#888888>
Curtis
> >>>
> >>>
> >>>


> On Thu, Mar 25, 2010 at 6:25 PM, > >>> Sriganesh=3D Kini=3D20 > >>> < >>> > >>> > href=3D3D"mailto:sriganesh.kini@ericsson.com">sriganesh.kini@ericsson. > >>> co > >>> m=3D > >>>
>=3D20 > >>> > wrote:
>
> >  See inline @ > [Sri]
>=3D20 > >>> >
> >
> > - Sri
> >
> > >>> >
> =3D >=3D20 > >>>  ------------------------------
> > > *From:* Greg Mirsky=3D20 > >>> [mailto: >>> > >>> > href=3D3D"mailto:gregimirsky@gmail.com">gregimirsky@gmail.com]
> >>> &g > >>> t=3D > >>> ; >=3D20 > >>> *Sent:* Thursday, March 25, 2010 6:15 PM
> > > *To:* Sriganesh=3D20 > >>> Kini
> > *Cc:* Autumn Liu; >>> href=3D3D"mailto:mpls@ietf.org">mpls@ietf.org
> > >>> >
> &g=3D t;=3D20 > >>> *Subject:* Re: Comments to Efficient FRR using > Facility backup in=3D20 > >>> ring
> > topology
> >
> > Dear > >>> Sri,
> =3D >=3D20 > >>> if by reference to how PLR-u selects an end-point for > its bypass > >>> tunnel=3D =3D20 > >>> you
> > meant "The traffic should be > protection switched > >>> to a=3D =3D20 > >>> backup path
> > terminating on a LSR along > the protected > >>> LSP t=3D hat=3D20 > >>> is furthest downstream
> > from the MP and has the > >>> protected a=3D nd=3D20 > >>> bypass LSPs going in the opposite
> > > directions", then > >>> I migh=3D t=3D20 > >>> offer another formula:
> > "The remote end-point of a > >>> bypass L=3D SR=3D20 > >>> must be selected at first common,
> > between PLR's > >>> bypass tun=3D nel's=3D20 > >>> path and the protected LSP, LSR taken in
> > > direction > >>> of the=3D =3D20 > >>> bypass tunnel."
> > [Sri ] That alternate wording has > >>> already =3D been=3D20 > >>> used in the presentation -
> > see slide 4
> > >>> >
>=3D ;=3D20 > >>> > As for reliability of the alert mechanism, I'd point that > >>> there ar=3D e=3D20 > >>> more
> > moving parts in processing a packet in > >>> Switchover sce=3D nario=3D20 > >>> than processing
> > "normal" BFD packet. > Latter is very > >>> often =3D done=3D20 > >>> completely in HW while former
> > in SW. Hence the > >>> possible la=3D ck of=3D20 > >>> reliability in processing while BFD
> > > session deemed > >>> Up.
=3D >=3D20 > >>> > [Sri ] This is an implementation choice. The folks who > >>> implement i=3D t=3D20 > >>> right
> > will make it reliable.
> >
> > >>> > Not=3D e=3D20 > >>> that by deploying FRR you already create congestion on > L9-L8 link=3D20 > >>> thus
> > reducing reliability of the alert > >>> mechanism.
> =3D >=3D20 > >>> [Sri ] The alert mechanism is a control-packet and > should be handled=3D20 > >>> at
> > higher priority/reliability (than a data > >>> packet).
&g=3D t;=3D20 > >>> >
> > FRR is viewed as temporary solution, > in large part,=3D20 > >>> because inefficiency
> > you're addressing. > End-to-end > >>> protect=3D ion,=3D20 > >>> in many cases, is capable to
> > deliver identical to > >>> protecte=3D d=3D20 > >>> path service guarantees and might not require
> > > >>> revertive ac=3D tion.=3D20 > >>> I think that many of deployments have historical > rather
> > >>> > th=3D an=3D20 > >>> technical explanation in which method been > selected.
> > > >>> [Sri =3D ]=3D20 > >>> With this in-efficiency addressed it should not be the > >>> case.
> &g=3D t;=3D20 > >>> End-to-end protection is more expensive. Facility > backup is a=3D20 > >>> scalable
> > widely deployed protection > mechanism.
>=3D20 > >>> >
> >
> > Regards,
> > > Greg
>=3D20 > >>> >
> > On Thu, Mar 25, 2010 at 5:53 PM, > Sriganesh Kini=3D20 > >>> <
> > >>> > >>> > href=3D3D"mailto:sriganesh.kini@ericsson.com">sriganesh.kini@ericsson. > >>> co > >>> m=3D > >>> >=3D20 > >>> wrote:
> >
> >>  Greg, see inline @ > >>> [Sri]
=3D >=3D20 > >>> >>
> >>
> >> - Sri
> > >>> >>
&g=3D t;=3D20 > >>> >>
> >> > >>>  ------------------------------
>=3D > >>> =3D20 > >>> >> *From:* Greg Mirsky [mailto: >>> > >>> > href=3D3D"mailto:gregimirsky@gmail.com">gregimirsky@gmail.com]
> >>> &g > >>> t=3D > >>> ;=3D20 > >>> >> *Sent:* Thursday, March 25, 2010 5:23 PM
> > >>> >> *To:=3D *=3D20 > >>> Autumn Liu; Sriganesh Kini; >>> > href=3D3D"mailto:mpls@ietf.org">mpls@ietf.org
> >> > >>> *Subje=3D ct:*=3D20 > >>> Re: Comments to Efficient FRR using Facility backup in > >>> ring
> >=3D ;>=3D20 > >>> topology
> >>
> >>  Dear > >>> Authors,
>=3D =3D20 > >>> >> please kindly consider my comments to the > document:
>=3D20 > >>> >>
> >>    - in Section > 4.2 following > >>> assum=3D ption=3D20 > >>> being made "Thus each LSR along
> >> >    the > >>> bypas=3D s=3D20 > >>> receives the packet." I believe that there is no guarantee > >>> that
>=3D =3D20 > >>> >>    each LSR along the bypass tunnel will > >>> receive the=3D =3D20 > >>> alert message, even if it
> >>   >  will be > >>> sent th=3D ree=3D20 > >>> times. As result of this assumption most of > conclusions
> > >>> >>=3D ;=3D20 > >>>    regarding proposed solution look > unfounded.
> > >>> >&g=3D t;=3D20 > >>>    [Sri ] The three times is immediately on > failure. It is=3D20 > >>> sent
> >>    periodically later. If the > >>> very high=3D ly=3D20 > >>> unlikely event that all three
> >>   > >>>  messages ar=3D e=3D20 > >>> dropped, then it means that there is a problem sending > >>> data
> >=3D ;>=3D20 > >>>    packets on the bypass and other means > (such as BFD > >>> and/or=3D =3D20 > >>> signaling) would
> >>    indicate the > >>> problem. Su=3D ch=3D20 > >>> packet drop problems on the bypass should have
> > >> > >>>  =3D =3D20 > >>>  been visible even before the failure and > appropriate rectifying=3D20 > >>> actions
> >>    would have > >>> occurred.
> >=3D >=3D20 > >>>    - in is not clear from the Section 4.3 > Procedures at PLR=3D20 > >>> whether PLR
> >>    deploys its bypass > >>> tunnel loc=3D ally=3D20 > >>> as well as sets FLA bit in BFD message or
> > >>  =3D20 > >>>  totally relies on actions of PLR-u's
> > >>  =3D20 > >>>  [Sri ] PLR deploys the protection switch to > bypass and sets FLA=3D20 > >>> bit.
> >>    - if the Merge > Point of bypass > >>> tunne=3D ls=3D20 > >>> set by PLR-u's is, using Fig.1
> >>   >  and > >>> scenar=3D io=3D20 > >>> from Section 3, L7, then the solution only solves half > of the
>=3D20 > >>> >>    problem characteristic to Facility > >>> protection in =3D a=3D20 > >>> ring topology. Possible
> >>   >  congestion > >>> on lin=3D k=3D20 > >>> L9-L8 might be avoided, but not on link L7-L6. To > address
> > >>> >&=3D gt;=3D20 > >>>    this congestion, the MP must be changed > when PLR-u > >>> sets it=3D s=3D20 > >>> bypass.
> >>    [Sri ] Seems you haven't > >>> understo=3D od=3D20 > >>> the text in section 4 that
> >>   > >>>  describes how =3D MP is=3D20 > >>> chosen for a bypass from PLR-u. Also it seems you
> > >>> >> &nbs=3D p;=3D20 > >>>  haven't read section 5 that clearly states that > for traffic=3D20 > >>> protection
> >>    switched from > PLR-u, the > >>> MP is=3D at=3D20 > >>> L6. There is NO congestion on L7-L6.
> >> >    -=3D20 > >>> Introduction of PLR-u for all local protections along the > >>> protected
=3D >=3D20 > >>> >>    LSR might create scaling problem > and is not > >>> neces=3D sary=3D20 > >>> (I'll try to explain
> >>    that > >>> below).
>=3D =3D20 > >>> >>    [Sri ] PLR-u is created at nodes along > >>> bypass LSP=3D . The=3D20 > >>> explanation
> >>    below does > not clearly > >>> state =3D the=3D20 > >>> scaling parameter you are concerned about.
> > >>> >>
> >=3D ;>=3D20 > >>> I still don't see value of alerting all LSR along the > bypass tunnel=3D20 > >>> that
> >> provides local protection as > well as all this=3D20 > >>> transient LSRs being PLR-u.
> >> What is really > >>> needed, in =3D my=3D20 > >>> view, is end-to-end or segment protection and > a
> >> > >>> way fo=3D r=3D20 > >>> LER/segment's head-end to learn about the failure along > >>> the
> >=3D ;>=3D20 > >>> protected LSR fast enough. If one decides to run link > layer OAM > >>> rather=3D =3D20 > >>> than
> >> end-to-end or segment/TCM, then > LSR, known > >>> as PLR=3D ,=3D20 > >>> needs fast and reliable
> >> method of > notifying LER. > >>> But I=3D =3D20 > >>> don't see good technical reason to do that
> > >> when > >>> there =3D are=3D20 > >>> ways to avoid this problem.
> >> [Sri ] > Alerting all > >>> LSRs a=3D long=3D20 > >>> the bypass helps to do protection switching
> > >> for all=3D20 > >>> protected LSPs that are protected by the bypass. > >>> End-to-end
> >=3D ;>=3D20 > >>> protection is not as scalable. That is why RFC4090 > specified the=3D20 > >>> scalable
> >> FRR mechanism of facility > backup and it > >>> is wi=3D dely=3D20 > >>> deployed. Your
> >> observations on > link-layer OAM, > >>> ...etc =3D would=3D20 > >>> have been useful if it had
> >> details. > Again note > >>> that ou=3D r=3D20 > >>> draft addresses general physical topologies
> > >> (not > >>> just=3D =3D20 > >>> ring).
> >>
> >> > Regards,
> >>=3D20 > >>> Greg

> >>>
>>> style=3D3D"DISPLAY: inline; VISIBILITY: hidden">
>>> face=3D3DArial=3D20 color=3D3D#0000ff size=3D3D2> face=3D3DArial > >>> color=3D3D#0000ff=3D20 size=3D3D2>
> >>> > >>> > >>> --_000_5A5E55DF96F73844AF7DFB0F48721F0F52E47A75CCEUSAACMS0703e_-- > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From vishwas.ietf@gmail.com Sun Apr 4 17:00:00 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A993A67FC for ; Sun, 4 Apr 2010 17:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm9IynpigStL for ; Sun, 4 Apr 2010 16:59:59 -0700 (PDT) Received: from mail-yx0-f202.google.com (mail-yx0-f202.google.com [209.85.210.202]) by core3.amsl.com (Postfix) with ESMTP id 92ECB3A6782 for ; Sun, 4 Apr 2010 16:59:59 -0700 (PDT) Received: by yxe40 with SMTP id 40so405303yxe.31 for ; Sun, 04 Apr 2010 16:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pe4zd9JEuPjsvbeROmYblZpIp1sMj8hoQbCE6RW1AmU=; b=tDLxeOTOduWOUax6jEBYdI+bwrKZutWTKThlaBUd+AO3H15YQ9lkZx8UBF5GW2c4pP ustxTz4B/xqYmxBKAY5/FzP1Uzh7AKJqUjViCouaDZsjcFQkdpmtEy7+6pHzRg7TCD+6 +CBt9TuPisFT7x8/7hBIUFNErVafa7ZhHgAEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ya5qygSa1jYpijyx6YgRKOtgOkaTBBocJoyunl7+T4eMix6M3w+mrRSHT7Ese+Lnou QbWcU3bpZVOOU7Ujnli2iJX9Fz5J3UKofWDSKGvjbstNYbFxtZ2If41d/ICdF4vyLiFx J8tTE7Z3TaBRzSzuLuwi1Ql19/wMLBpmbUNXw= MIME-Version: 1.0 Received: by 10.150.147.9 with HTTP; Sun, 4 Apr 2010 16:59:55 -0700 (PDT) In-Reply-To: <77ead0ec1003282112m5190b3adic0e4b3d609db7e9c@mail.gmail.com> References: <77ead0ec1003282112m5190b3adic0e4b3d609db7e9c@mail.gmail.com> Date: Sun, 4 Apr 2010 16:59:55 -0700 Received: by 10.151.25.21 with SMTP id c21mr5956528ybj.169.1270425595473; Sun, 04 Apr 2010 16:59:55 -0700 (PDT) Message-ID: From: Vishwas Manral To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sami Boutros , msiva@cisco.com Subject: Re: [mpls] draft-boutros-mpls-lsp-ping-ttl-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 00:00:00 -0000 Hi, I think I have found some very basic issues with the draft and had mailed the same on the list. I have not heard back from you. I was wondering if you had abandoned the draft. If so I can pick it up and probably correct it. Do let us know? Thanks, Vishwas On Sun, Mar 28, 2010 at 9:12 PM, Vishwas Manral wr= ote: > Hi, > > I find the draft useful and concise. I read the draft and found a > basic issue - it cannot be used the way it is defined. I had a few > suggestions and an issue with the draft(point 3): > > 1. I think the draft can be made more generic as it can be used to > test hops in heirarchical bidirectional LSP's or even just plain > bidirectional LSP from an LSR to another LSR. > 2. Though the TLV we talk about is an LSP Ping TLV, I at first thought > it is probably a TLV in the ACH header. May be that should be made > clear. > 3. I am not sure how you can assume that a node that does not > understand the TLV will just ignore the TLV (Type value 11). RFC 4379 > which mentions that > > =A0 Types greater than or equal to 32768 (i.e., with the high-order bit > =A0 equal to 1) are optional TLVs that SHOULD be ignored if the > =A0 implementation does not understand or support them. > > In that context the statement is very interesting: > > If a receiver does not understand the TTL TLV, it can simply ignore the T= LV. > > I am not sure but it may be nice to remove the statement above instead > of making an exception. We cannot make reccomedations of what to do > with a TLV if someone does not understand the TLV as the equipment > that does not understand it is already deployed. > > Thanks, > Vishwas > From malcolm.betts@zte.com.cn Mon Apr 5 10:02:43 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C193A68DD; Mon, 5 Apr 2010 10:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.238 X-Spam-Level: X-Spam-Status: No, score=-99.238 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35pxjbDJKwtx; Mon, 5 Apr 2010 10:02:42 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3877C3A67EA; Mon, 5 Apr 2010 10:02:40 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 128641570495873; Tue, 6 Apr 2010 01:00:42 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 23186.15081851937; Tue, 6 Apr 2010 00:59:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o35H1AlZ005937; Tue, 6 Apr 2010 01:01:10 +0800 (CST) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <20100403094621.610F13A68B7@core3.amsl.com> To: loa.andersson@ericsson.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Mon, 5 Apr 2010 13:00:44 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-06 01:00:46, Serialize complete at 2010-04-06 01:00:46 Content-Type: multipart/alternative; boundary="=_alternative 005D6FD0852576FC_=" X-MAIL: mse2.zte.com.cn o35H1AlZ005937 Cc: loa.andersson@ericsson.com, mpls@ietf.org, greg.jones@itu.int, stbryant@cisco.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: Re: [mpls] New Liaison Statement, "MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 17:02:44 -0000 This is a multipart message in MIME format. --=_alternative 005D6FD0852576FC_= Content-Type: text/plain; charset="US-ASCII" Loa, The response liaison from the SG15 (ref # 15.02) on the -10 version identified 4 major open issues, it also included numerous suggested modifications and requested clarification on some issues that were not explicitly included in the draft we also indicated our intention to include these aspects in G.8110.1. We would appreciate a prompt response to that liaison indicating the disposition of the comments and confirmation that our assumptions are correct and that the IETF will support the documentation of the scenarios mentioned in our liaison in G.8110.1. Depending on the timing of your response I may need to request additional time to respond to your request - this is in parallel with 4 other WG last calls and the second week overlaps with the experts meeting on MPLS-TP. Regards, Malcolm Loa Andersson(IETF MPLS WG) 03/04/2010 05:46 AM Please respond to loa.andersson@ericsson.com To greg.jones@itu.int cc yoichi.maeda@ntt-at.co.jp, greg.jones@itu.int, ghani.abbas@ericsson.com, hhelvoort@huawei.com, malcolm.betts@zte.com.cn, hklam@alcatel-lucent.com, tsbsg15@itu.int, ahmpls-tp@lists.itu.int, dward@juniper.net, adrian.farrel@huawei.com, paf@cisco.com, stbryant@cisco.com, mpls@ietf.org, mpls-tp@ietf.org, swallow@cisco.com, loa.andersson@ericsson.com, loa.andersson@ericsson.com, swallow@cisco.com Subject New Liaison Statement, "MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01)" Title: MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01) Submission Date: 2010-04-03 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=863 Please reply by 2010-04-17 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For comment Body: MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01) draft-ietf-mpls-tp-framework-11 SG15, Q9, Q10, Q12 and Q14 We like to to inform you that the MPLS working group just started a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the previous working group last call and reviews have been correctly addressed. We would like to receive comments from the ITU-T by April 17th 2010 the latest. Loa Andersson George Swallow MPLS Working Group co-chairs Attachment(s): No document has been attached --=_alternative 005D6FD0852576FC_= Content-Type: text/html; charset="US-ASCII"
Loa,

The response liaison from the SG15 (ref # 15.02) on the -10 version identified 4 major open issues, it also included numerous suggested modifications and requested clarification on some issues that were not explicitly included in the draft we also indicated our intention to include these aspects in G.8110.1.

We would appreciate a prompt response to that liaison indicating the disposition of the comments and confirmation that our assumptions are correct and that the IETF will support the documentation of the scenarios mentioned in our liaison in G.8110.1.

Depending on the timing of your response I may need to request additional time to respond to your request - this is in parallel with 4 other WG last calls and the second week overlaps with the experts meeting on MPLS-TP.

Regards,

Malcolm



Loa Andersson(IETF MPLS WG) <loa@pi.nu>

03/04/2010 05:46 AM
Please respond to
loa.andersson@ericsson.com
To
greg.jones@itu.int
cc
yoichi.maeda@ntt-at.co.jp, greg.jones@itu.int, ghani.abbas@ericsson.com, hhelvoort@huawei.com, malcolm.betts@zte.com.cn, hklam@alcatel-lucent.com, tsbsg15@itu.int, ahmpls-tp@lists.itu.int, dward@juniper.net, adrian.farrel@huawei.com, paf@cisco.com, stbryant@cisco.com, mpls@ietf.org, mpls-tp@ietf.org, swallow@cisco.com, loa.andersson@ericsson.com, loa.andersson@ericsson.com, swallow@cisco.com
Subject
New Liaison Statement, "MPLS working group last call on "A          Framework for MPLS in Transport Networks" (ref #026.01)"






Title: MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01)
Submission Date: 2010-04-03
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=863
Please reply by 2010-04-17

From: Loa Andersson(IETF MPLS WG) <loa@pi.nu>
To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int)
Cc: yoichi.maeda@ntt-at.co.jp
greg.jones@itu.int
ghani.abbas@ericsson.com
hhelvoort@huawei.com
malcolm.betts@zte.com.cn
hklam@alcatel-lucent.com
tsbsg15@itu.int
ahmpls-tp@lists.itu.int
dward@juniper.net
adrian.farrel@huawei.com
paf@cisco.com
stbryant@cisco.com
mpls@ietf.org
mpls-tp@ietf.org
swallow@cisco.com
Reponse Contact: loa.andersson@ericsson.com
Technical Contact: loa.andersson@ericsson.com
swallow@cisco.com
Purpose: For comment
Body:



MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01)
draft-ietf-mpls-tp-framework-11

SG15, Q9, Q10, Q12 and Q14

We like to to inform you that the MPLS working group just started a short
working group last call on "A Framework for MPLS in Transport Networks"
(draft-ietf-mpls-tp-framework-11).

Please note that this wg last call is limited to verify that comments
raised during the previous working group last call and reviews have
been correctly addressed.

We would like to receive comments from the ITU-T by April 17th 2010 the latest.


Loa Andersson
George Swallow

MPLS Working Group co-chairs
Attachment(s):
No document has been attached
--=_alternative 005D6FD0852576FC_=-- From liu.guoman@zte.com.cn Tue Apr 6 01:13:43 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628BB3A67C0; Tue, 6 Apr 2010 01:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.435 X-Spam-Level: X-Spam-Status: No, score=-94.435 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CC+OgjtpZi1w; Tue, 6 Apr 2010 01:13:42 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 9D07E3A68EB; Tue, 6 Apr 2010 01:13:32 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711784411434; Tue, 6 Apr 2010 16:11:28 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 83532.5178059839; Tue, 6 Apr 2010 16:13:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o368BM3k062980; Tue, 6 Apr 2010 16:11:22 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: Vishwas Manral MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Tue, 6 Apr 2010 16:11:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-06 16:11:12, Serialize complete at 2010-04-06 16:11:12 Content-Type: multipart/alternative; boundary="=_alternative 002CFA1C482576FD_=" X-MAIL: mse2.zte.com.cn o368BM3k062980 Cc: mpls@ietf.org, Sami Boutros , mpls-bounces@ietf.org, msiva@cisco.com Subject: Re: [mpls] draft-boutros-mpls-lsp-ping-ttl-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 08:13:43 -0000 This is a multipart message in MIME format. --=_alternative 002CFA1C482576FD_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkNCkZvciB0aGlzIGRyYWZ0LCBJIGRvbid0IGtub3cgd2hhdCBtZWFuaW5nIHRvIGRvIHNvLiAN CmNhbiBpdCB2ZXJpZnkgdGhlIGNvbm5lY3Rpb24gZnJvbSBhbnkgbm9kZSB0byBhbnkgbm9kZSBp biB0aGUgTVMtUFc/DQpJZiBzbywgd2hlbiBpdCBkZXRlY3RzIHRoZSBmYWlsdXJlIGluIHRoZSBz ZWdtZW50IGJ5IExTUCBQaW5nIFRUTCBUTFYsDQp3aWxsIHRoZSBzb3VyY2Ugbm9kZSB0cmlnZ2Vy IHNlZ21lbnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmc/DQpvciBvdGhlciBhcHBseW1lbnQgZm9yIExT UCBQaW5nIFRUTCBUTFY/DQoNCkkgZG9uJ3Qga25vdy4gdGhhbmsgeW91IQ0KDQpiZXN0IHJlZ2Fy ZHMNCmxpdQ0KDQoNCg0KDQoNCg0KDQoNClZpc2h3YXMgTWFucmFsIDx2aXNod2FzLmlldGZAZ21h aWwuY29tPiANCreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNC0wNSAwNzo1 OQ0KDQrK1bz+yMsNCm1wbHNAaWV0Zi5vcmcNCrOty80NClNhbWkgQm91dHJvcyA8c2JvdXRyb3NA Y2lzY28uY29tPiwgbXNpdmFAY2lzY28uY29tDQrW98ziDQpSZTogW21wbHNdIGRyYWZ0LWJvdXRy b3MtbXBscy1sc3AtcGluZy10dGwtdGx2DQoNCg0KDQoNCg0KDQpIaSwNCg0KSSB0aGluayBJIGhh dmUgZm91bmQgc29tZSB2ZXJ5IGJhc2ljIGlzc3VlcyB3aXRoIHRoZSBkcmFmdCBhbmQgaGFkDQpt YWlsZWQgdGhlIHNhbWUgb24gdGhlIGxpc3QuDQoNCkkgaGF2ZSBub3QgaGVhcmQgYmFjayBmcm9t IHlvdS4gSSB3YXMgd29uZGVyaW5nIGlmIHlvdSBoYWQgYWJhbmRvbmVkDQp0aGUgZHJhZnQuIElm IHNvIEkgY2FuIHBpY2sgaXQgdXAgYW5kIHByb2JhYmx5IGNvcnJlY3QgaXQuIERvIGxldCB1cw0K a25vdz8NCg0KVGhhbmtzLA0KVmlzaHdhcw0KDQpPbiBTdW4sIE1hciAyOCwgMjAxMCBhdCA5OjEy IFBNLCBWaXNod2FzIE1hbnJhbCA8dmlzaHdhcy5pZXRmQGdtYWlsLmNvbT4gDQp3cm90ZToNCj4g SGksDQo+DQo+IEkgZmluZCB0aGUgZHJhZnQgdXNlZnVsIGFuZCBjb25jaXNlLiBJIHJlYWQgdGhl IGRyYWZ0IGFuZCBmb3VuZCBhDQo+IGJhc2ljIGlzc3VlIC0gaXQgY2Fubm90IGJlIHVzZWQgdGhl IHdheSBpdCBpcyBkZWZpbmVkLiBJIGhhZCBhIGZldw0KPiBzdWdnZXN0aW9ucyBhbmQgYW4gaXNz dWUgd2l0aCB0aGUgZHJhZnQocG9pbnQgMyk6DQo+DQo+IDEuIEkgdGhpbmsgdGhlIGRyYWZ0IGNh biBiZSBtYWRlIG1vcmUgZ2VuZXJpYyBhcyBpdCBjYW4gYmUgdXNlZCB0bw0KPiB0ZXN0IGhvcHMg aW4gaGVpcmFyY2hpY2FsIGJpZGlyZWN0aW9uYWwgTFNQJ3Mgb3IgZXZlbiBqdXN0IHBsYWluDQo+ IGJpZGlyZWN0aW9uYWwgTFNQIGZyb20gYW4gTFNSIHRvIGFub3RoZXIgTFNSLg0KPiAyLiBUaG91 Z2ggdGhlIFRMViB3ZSB0YWxrIGFib3V0IGlzIGFuIExTUCBQaW5nIFRMViwgSSBhdCBmaXJzdCB0 aG91Z2h0DQo+IGl0IGlzIHByb2JhYmx5IGEgVExWIGluIHRoZSBBQ0ggaGVhZGVyLiBNYXkgYmUg dGhhdCBzaG91bGQgYmUgbWFkZQ0KPiBjbGVhci4NCj4gMy4gSSBhbSBub3Qgc3VyZSBob3cgeW91 IGNhbiBhc3N1bWUgdGhhdCBhIG5vZGUgdGhhdCBkb2VzIG5vdA0KPiB1bmRlcnN0YW5kIHRoZSBU TFYgd2lsbCBqdXN0IGlnbm9yZSB0aGUgVExWIChUeXBlIHZhbHVlIDExKS4gUkZDIDQzNzkNCj4g d2hpY2ggbWVudGlvbnMgdGhhdA0KPg0KPiAgIFR5cGVzIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0 byAzMjc2OCAoaS5lLiwgd2l0aCB0aGUgaGlnaC1vcmRlciBiaXQNCj4gICBlcXVhbCB0byAxKSBh cmUgb3B0aW9uYWwgVExWcyB0aGF0IFNIT1VMRCBiZSBpZ25vcmVkIGlmIHRoZQ0KPiAgIGltcGxl bWVudGF0aW9uIGRvZXMgbm90IHVuZGVyc3RhbmQgb3Igc3VwcG9ydCB0aGVtLg0KPg0KPiBJbiB0 aGF0IGNvbnRleHQgdGhlIHN0YXRlbWVudCBpcyB2ZXJ5IGludGVyZXN0aW5nOg0KPg0KPiBJZiBh IHJlY2VpdmVyIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIFRUTCBUTFYsIGl0IGNhbiBzaW1wbHkg aWdub3JlIHRoZSANClRMVi4NCj4NCj4gSSBhbSBub3Qgc3VyZSBidXQgaXQgbWF5IGJlIG5pY2Ug dG8gcmVtb3ZlIHRoZSBzdGF0ZW1lbnQgYWJvdmUgaW5zdGVhZA0KPiBvZiBtYWtpbmcgYW4gZXhj ZXB0aW9uLiBXZSBjYW5ub3QgbWFrZSByZWNjb21lZGF0aW9ucyBvZiB3aGF0IHRvIGRvDQo+IHdp dGggYSBUTFYgaWYgc29tZW9uZSBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBUTFYgYXMgdGhlIGVx dWlwbWVudA0KPiB0aGF0IGRvZXMgbm90IHVuZGVyc3RhbmQgaXQgaXMgYWxyZWFkeSBkZXBsb3ll ZC4NCj4NCj4gVGhhbmtzLA0KPiBWaXNod2FzDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5v dCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlv biB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4N Cg== --=_alternative 002CFA1C482576FD_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Gb3IgdGhpcyBkcmFmdCwgSSBkb24ndCBrbm93IHdo YXQgbWVhbmluZw0KdG8gZG8gc28uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Y2FuIGl0IHZlcmlmeSB0aGUgY29ubmVjdGlvbiBmcm9tIGFueQ0Kbm9kZSB0byBh bnkgbm9kZSBpbiB0aGUgTVMtUFc/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5JZiBzbywgd2hlbiBpdCBkZXRlY3RzIHRoZSBmYWlsdXJlIGluDQp0aGUgc2VnbWVu dCBieSBMU1AgUGluZyBUVEwgVExWLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+d2lsbCB0aGUgc291cmNlIG5vZGUgdHJpZ2dlciBzZWdtZW50DQpwcm90ZWN0aW9u IHN3aXRjaGluZz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm9y IG90aGVyIGFwcGx5bWVudCBmb3IgTFNQIFBpbmcgVFRMDQpUTFY/PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGRvbid0IGtub3cuIHRoYW5rIHlvdSE8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJlc3QgcmVn YXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bGl1PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8dGFi bGU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPWNlbnRlcj48L2Rpdj4NCjx0ZD48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD0zNCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlZpc2h3 YXMgTWFucmFsICZsdDt2aXNod2FzLmlldGZAZ21haWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLWJvdW5j ZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAx MC0wNC0wNSAwNzo1OTwvZm9udD4NCjx0ZCB3aWR0aD02NSU+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5tcGxzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TYW1pIEJvdXRy b3MgJmx0O3Nib3V0cm9zQGNpc2NvLmNvbSZndDssDQptc2l2YUBjaXNjby5jb208L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbbXBsc10gZHJhZnQtYm91dHJvcy1tcGxzLWxzcC1waW5nLXR0bC10bHY8 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRk PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0 PkhpLDxicj4NCjxicj4NCkkgdGhpbmsgSSBoYXZlIGZvdW5kIHNvbWUgdmVyeSBiYXNpYyBpc3N1 ZXMgd2l0aCB0aGUgZHJhZnQgYW5kIGhhZDxicj4NCm1haWxlZCB0aGUgc2FtZSBvbiB0aGUgbGlz dC48YnI+DQo8YnI+DQpJIGhhdmUgbm90IGhlYXJkIGJhY2sgZnJvbSB5b3UuIEkgd2FzIHdvbmRl cmluZyBpZiB5b3UgaGFkIGFiYW5kb25lZDxicj4NCnRoZSBkcmFmdC4gSWYgc28gSSBjYW4gcGlj ayBpdCB1cCBhbmQgcHJvYmFibHkgY29ycmVjdCBpdC4gRG8gbGV0IHVzPGJyPg0Ka25vdz88YnI+ DQo8YnI+DQpUaGFua3MsPGJyPg0KVmlzaHdhczxicj4NCjxicj4NCk9uIFN1biwgTWFyIDI4LCAy MDEwIGF0IDk6MTIgUE0sIFZpc2h3YXMgTWFucmFsICZsdDt2aXNod2FzLmlldGZAZ21haWwuY29t Jmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGZpbmQgdGhl IGRyYWZ0IHVzZWZ1bCBhbmQgY29uY2lzZS4gSSByZWFkIHRoZSBkcmFmdCBhbmQgZm91bmQgYTxi cj4NCiZndDsgYmFzaWMgaXNzdWUgLSBpdCBjYW5ub3QgYmUgdXNlZCB0aGUgd2F5IGl0IGlzIGRl ZmluZWQuIEkgaGFkIGEgZmV3PGJyPg0KJmd0OyBzdWdnZXN0aW9ucyBhbmQgYW4gaXNzdWUgd2l0 aCB0aGUgZHJhZnQocG9pbnQgMyk6PGJyPg0KJmd0Ozxicj4NCiZndDsgMS4gSSB0aGluayB0aGUg ZHJhZnQgY2FuIGJlIG1hZGUgbW9yZSBnZW5lcmljIGFzIGl0IGNhbiBiZSB1c2VkIHRvPGJyPg0K Jmd0OyB0ZXN0IGhvcHMgaW4gaGVpcmFyY2hpY2FsIGJpZGlyZWN0aW9uYWwgTFNQJ3Mgb3IgZXZl biBqdXN0IHBsYWluPGJyPg0KJmd0OyBiaWRpcmVjdGlvbmFsIExTUCBmcm9tIGFuIExTUiB0byBh bm90aGVyIExTUi48YnI+DQomZ3Q7IDIuIFRob3VnaCB0aGUgVExWIHdlIHRhbGsgYWJvdXQgaXMg YW4gTFNQIFBpbmcgVExWLCBJIGF0IGZpcnN0IHRob3VnaHQ8YnI+DQomZ3Q7IGl0IGlzIHByb2Jh Ymx5IGEgVExWIGluIHRoZSBBQ0ggaGVhZGVyLiBNYXkgYmUgdGhhdCBzaG91bGQgYmUgbWFkZTxi cj4NCiZndDsgY2xlYXIuPGJyPg0KJmd0OyAzLiBJIGFtIG5vdCBzdXJlIGhvdyB5b3UgY2FuIGFz c3VtZSB0aGF0IGEgbm9kZSB0aGF0IGRvZXMgbm90PGJyPg0KJmd0OyB1bmRlcnN0YW5kIHRoZSBU TFYgd2lsbCBqdXN0IGlnbm9yZSB0aGUgVExWIChUeXBlIHZhbHVlIDExKS4gUkZDIDQzNzk8YnI+ DQomZ3Q7IHdoaWNoIG1lbnRpb25zIHRoYXQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgVHlw ZXMgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvIDMyNzY4IChpLmUuLCB3aXRoIHRoZSBoaWdoLW9y ZGVyDQpiaXQ8YnI+DQomZ3Q7ICZuYnNwOyBlcXVhbCB0byAxKSBhcmUgb3B0aW9uYWwgVExWcyB0 aGF0IFNIT1VMRCBiZSBpZ25vcmVkIGlmIHRoZTxicj4NCiZndDsgJm5ic3A7IGltcGxlbWVudGF0 aW9uIGRvZXMgbm90IHVuZGVyc3RhbmQgb3Igc3VwcG9ydCB0aGVtLjxicj4NCiZndDs8YnI+DQom Z3Q7IEluIHRoYXQgY29udGV4dCB0aGUgc3RhdGVtZW50IGlzIHZlcnkgaW50ZXJlc3Rpbmc6PGJy Pg0KJmd0Ozxicj4NCiZndDsgSWYgYSByZWNlaXZlciBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBU VEwgVExWLCBpdCBjYW4gc2ltcGx5IGlnbm9yZQ0KdGhlIFRMVi48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJIGFtIG5vdCBzdXJlIGJ1dCBpdCBtYXkgYmUgbmljZSB0byByZW1vdmUgdGhlIHN0YXRlbWVu dCBhYm92ZSBpbnN0ZWFkPGJyPg0KJmd0OyBvZiBtYWtpbmcgYW4gZXhjZXB0aW9uLiBXZSBjYW5u b3QgbWFrZSByZWNjb21lZGF0aW9ucyBvZiB3aGF0IHRvIGRvPGJyPg0KJmd0OyB3aXRoIGEgVExW IGlmIHNvbWVvbmUgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgVExWIGFzIHRoZSBlcXVpcG1lbnQ8 YnI+DQomZ3Q7IHRoYXQgZG9lcyBub3QgdW5kZXJzdGFuZCBpdCBpcyBhbHJlYWR5IGRlcGxveWVk Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IFZpc2h3YXM8YnI+DQomZ3Q7 PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxi cj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtO b3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZu YnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5i c3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0 ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJz cDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZu YnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVz Jm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRl bnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3Ro ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7 ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3Nl ZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJz cDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0Fu eSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nh bm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJz cDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 002CFA1C482576FD_=-- From liu.guoman@zte.com.cn Tue Apr 6 01:50:35 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293693A689A; Tue, 6 Apr 2010 01:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.035 X-Spam-Level: X-Spam-Status: No, score=-96.035 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD19Vw4BaaaN; Tue, 6 Apr 2010 01:50:34 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 996983A68FE; Tue, 6 Apr 2010 01:50:31 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711911657480; Tue, 6 Apr 2010 16:48:31 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 23186.2171832422; Tue, 6 Apr 2010 16:47:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o368mXh0031181; Tue, 6 Apr 2010 16:49:07 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: Du Zongpeng MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Tue, 6 Apr 2010 16:48:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-06 16:48:57, Serialize complete at 2010-04-06 16:48:57 Content-Type: multipart/alternative; boundary="=_alternative 00306E71482576FD_=" X-MAIL: mse2.zte.com.cn o368mXh0031181 Cc: mpls , mpls-tp-bounces@ietf.org, mpls-tp Subject: Re: [mpls] [mpls-tp] A new ID draft-ji-mpls-tp-bidirectional-label-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 08:50:35 -0000 This is a multipart message in MIME format. --=_alternative 00306E71482576FD_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkNCklmIGxhYmVsIGFzc2lnbm1lbnQgaXMgYmFzZWQgb24gcGVyIGludGVyZmFjZSBsYWJlbCBz cGFjZSwgd2lsbCBsYWJlbCANCmNyYXNoIG5vdCBoYXBwZW4/DQoNCm1heWJlIG15IHVuZGVyc3Rh bmRpbmcgYmUgd3JvbmcuDQoNCnRoYW5rIHlvdQ0KbGl1DQoNCg0KDQoNCg0KDQoNCkR1IFpvbmdw ZW5nIDxkdXpvbmdwZW5nQGdtYWlsLmNvbT4gDQq3orz+yMs6ICBtcGxzLXRwLWJvdW5jZXNAaWV0 Zi5vcmcNCjIwMTAtMDQtMDYgMTI6NTcNCg0KytW8/sjLDQptcGxzLXRwIDxtcGxzLXRwQGlldGYu b3JnPiwgbXBscyA8bXBsc0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW21wbHMtdHBdICBBIG5l dyBJRCBkcmFmdC1qaS1tcGxzLXRwLWJpZGlyZWN0aW9uYWwtbGFiZWwtMDANCg0KDQoNCg0KDQoN CkRlYXIgTVBMUyBXRzoNCg0KUGxlYXNlIGJlIGF3YXJlIHRoYXQgd2Ugc3VibWl0dGVkIGEgbmV3 IFdHIGRvY3VtZW50LA0KDQpCaWRpcmVjdGlvbmFsIExhYmVsIEFzc2lnbm1lbnQgaW4gTVBMUy1U UA0KZHJhZnQtamktbXBscy10cC1iaWRpcmVjdGlvbmFsLWxhYmVsLTAwDQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtamktbXBscy10cC1iaWRpcmVjdGlvbmFsLWxhYmVsLTAwLnR4dA0K DQpBYnN0cmFjdA0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBuZXcgbWVjaGFuaXNtIGZvciB0 aGUgbGFiZWwgYWxsb2NhdGlvbiBvZiANCmNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBvaW50LXRv LXBvaW50IHBhdGhzIGluIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgDQooTVBMUy1UUCkgbmV0d29y a3MsIHdoaWNoIGlzIGNhbGxlZCB0aGUgYmlkaXJlY3Rpb25hbCBsYWJlbCBhbGxvY2F0aW9uIA0K bWVjaGFuaXNtLiBUaGUgbm9kZXMgb24gY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgcG9pbnQtdG8t IHBvaW50IHBhdGhzIHdpbGwgDQpub3QgbmVlZCB0byByZWNvcmQgdGhlIGxhYmVsIHBhaXJpbmcg cmVsYXRpb25zaGlwIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgDQpiYWNrd2FyZCBkaXJlY3Rpb25z IGluIHRoaXMgbWVjaGFuaXNtIGJlY2F1c2UgdGhlIGxhYmVscyBhcmUgc3ltbWV0cmljYWwuIA0K SW4gYWRkaXRpb24sIHRoZSBjb21wcmVzc2lvbiBvZiB0aGUgTElCIGJlY29tZXMgcG9zc2libGUg YmVjYXVzZSBvZiB0aGUgDQpleGlzdGluZyBvZiBzeW1tZXRyaWNhbCBlbGVtZW50cy4NCg0KV2Ug d291bGQgYXBwcmVjaWF0ZSByZXZpZXdzIGFuZCBjb21tZW50cyBmb3Igb3VyIGRvY3VtZW50Lg0K DQpCZXN0IFJlZ2FyZHMNCg0KWm9uZ3BlbmcgRHUNCg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KWm9uZ3BlbmcgRHUNCkJVUFQNCkFkZHJlc3M6IFAuTy5C b3ggOTAsIEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25z DQpOby4xMCwgWGl0dWNoZW5nIFJvYWQsIEhhaWRpYW4gRGlzdHJpY3QsIEJlaWppbmcsIENoaW5h LCAxMDA4NzYNClRlbDogKzg2LTAxMC02MjI4MjkwNS04MDcNCkVNYWlsOiBkdXpvbmdwZW5nQGdt YWlsLmNvbQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMtdHAg bWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00306E71482576FD_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBsYWJlbCBhc3NpZ25tZW50IGlzIGJhc2VkIG9u IHBlcg0KaW50ZXJmYWNlIGxhYmVsIHNwYWNlLCB3aWxsIGxhYmVsIGNyYXNoIG5vdCBoYXBwZW4/ PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5tYXliZSBt eSB1bmRlcnN0YW5kaW5nIGJlIHdyb25nLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+dGhhbmsgeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5saXU8YnI+DQo8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+DQo8dGQ+DQo8ZGl2 IGFsaWduPWNlbnRlcj48L2Rpdj4NCjx0ZD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNCU+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkR1IFpvbmdwZW5nICZsdDtkdXpvbmdwZW5n QGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPreivP7IyzogJm5ic3A7bXBscy10cC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDQtMDYgMTI6NTc8L2ZvbnQ+DQo8 dGQgd2lkdGg9NjUlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+bXBscy10cCAm bHQ7bXBscy10cEBpZXRmLm9yZyZndDssIG1wbHMNCiZsdDttcGxzQGlldGYub3JnJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W21w bHMtdHBdICZuYnNwO0EgbmV3IElEIGRyYWZ0LWppLW1wbHMtdHAtYmlkaXJlY3Rpb25hbC1sYWJl bC0wMDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mz5EZWFyIE1QTFMgV0c6PGJyPg0KPGJyPg0KUGxlYXNlIGJlIGF3YXJlIHRoYXQgd2Ugc3VibWl0 dGVkIGEgbmV3IFdHIGRvY3VtZW50LDxicj4NCjxicj4NCkJpZGlyZWN0aW9uYWwgTGFiZWwgQXNz aWdubWVudCBpbiBNUExTLVRQPGJyPg0KZHJhZnQtamktbXBscy10cC1iaWRpcmVjdGlvbmFsLWxh YmVsLTAwPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWppLW1wbHMtdHAtYmlkaXJl Y3Rpb25hbC1sYWJlbC0wMC50eHQiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWU+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWppLW1wbHMtdHAtYmlkaXJlY3Rp b25hbC1sYWJlbC0wMC50eHQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0K QWJzdHJhY3Q8YnI+DQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG5ldyBtZWNoYW5pc20gZm9y IHRoZSBsYWJlbCBhbGxvY2F0aW9uIG9mIGNvLXJvdXRlZA0KYmlkaXJlY3Rpb25hbCBwb2ludC10 by1wb2ludCBwYXRocyBpbiBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKQ0KbmV0d29y a3MsIHdoaWNoIGlzIGNhbGxlZCB0aGUgYmlkaXJlY3Rpb25hbCBsYWJlbCBhbGxvY2F0aW9uIG1l Y2hhbmlzbS4NClRoZSBub2RlcyBvbiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwb2ludC10by0g cG9pbnQgcGF0aHMgd2lsbCBub3QgbmVlZA0KdG8gcmVjb3JkIHRoZSBsYWJlbCBwYWlyaW5nIHJl bGF0aW9uc2hpcCBvZiB0aGUgZm9yd2FyZCBhbmQgdGhlIGJhY2t3YXJkDQpkaXJlY3Rpb25zIGlu IHRoaXMgbWVjaGFuaXNtIGJlY2F1c2UgdGhlIGxhYmVscyBhcmUgc3ltbWV0cmljYWwuIEluIGFk ZGl0aW9uLA0KdGhlIGNvbXByZXNzaW9uIG9mIHRoZSBMSUIgYmVjb21lcyBwb3NzaWJsZSBiZWNh dXNlIG9mIHRoZSBleGlzdGluZyBvZg0Kc3ltbWV0cmljYWwgZWxlbWVudHMuPGJyPg0KPGJyPg0K V2Ugd291bGQgYXBwcmVjaWF0ZSByZXZpZXdzIGFuZCBjb21tZW50cyBmb3Igb3VyIGRvY3VtZW50 Ljxicj4NCjxicj4NCkJlc3QgUmVnYXJkczxicj4NCjxicj4NClpvbmdwZW5nIER1PGJyPg0KPGJy Pg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NClpv bmdwZW5nIER1PGJyPg0KQlVQVDxicj4NCkFkZHJlc3M6IFAuTy5Cb3ggOTAsIEJlaWppbmcgVW5p dmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zPGJyPg0KTm8uMTAsIFhpdHVj aGVuZyBSb2FkLCBIYWlkaWFuIERpc3RyaWN0LCBCZWlqaW5nLCBDaGluYSwgMTAwODc2PGJyPg0K VGVsOiArODYtMDEwLTYyMjgyOTA1LTgwNzxicj4NCkVNYWlsOiA8L2ZvbnQ+PGEgaHJlZj1tYWls dG86ZHV6b25ncGVuZ0BnbWFpbC5jb20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+ZHV6b25n cGVuZ0BnbWFpbC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjwvZm9udD48Zm9udCBz aXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzLXRwQGlldGYub3JnPGJyPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KPC90dD48L2Zv bnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5 Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVy dHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNw O1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50 aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7 b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJz cDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7 dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJz cDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7 Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3Im bmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtv ciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDth ZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0 aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5 Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4m bmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZu YnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNw O2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00306E71482576FD_=-- From Alexander.Vainshtein@ecitele.com Tue Apr 6 02:08:34 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3713A6A1B; Tue, 6 Apr 2010 02:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.605 X-Spam-Level: * X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BEaKx9tQTya; Tue, 6 Apr 2010 02:08:33 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 49F553A694F; Tue, 6 Apr 2010 02:08:27 -0700 (PDT) X-AuditID: 93eaf2e7-b7b6cae000005cc6-90-4bbaf7a1051a Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 65.5A.23750.1A7FABB4; Tue, 6 Apr 2010 11:58:10 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 6 Apr 2010 12:08:24 +0300 From: Alexander Vainshtein To: "liu.guoman@zte.com.cn" Date: Tue, 6 Apr 2010 12:08:23 +0300 Thread-Topic: [mpls-tp] A new ID draft-ji-mpls-tp-bidirectional-label-00 Thread-Index: AcrVZktfaelQ7YxqRJWUNuYqBM0OKQAAVqsw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76C1080A0089ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: mpls , Du Zongpeng , mpls-tp Subject: Re: [mpls] [mpls-tp] A new ID draft-ji-mpls-tp-bidirectional-label-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 09:08:34 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76C1080A0089ILPTMAIL02eci_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TGl1IGFuZCBhbGwsDQpVc2luZyBwZXItaW50ZXJmYWNlIGxhYmVsIHNwYWNlIG9uIFAyUCBpbnRl cmZhY2VzIHdvdWxkIGluZGVlZCBwcmV2ZW50IHRoZSBzaXR1YXRpb25zIHRvIHdoaWNoIGRyYWZ0 LWppLW1wbHMtdHAtYmlkaXJlY3Rpb25hbC1sYWJlbCByZWZlcnMgYXMgobBsYWJlbCBjcmFzaKGx IChJTU8gobBsYWJlbCBhbGxvY2F0aW9uIGNvbmZsaWN0obEgd291bGQgYmUgYSBtb3JlIHN1aXRh YmxlIG5hbWUpLiBCdXQgaXQgd291bGQgbm90IGhlbHAgbXVjaCBvbiBMQU4gKG9yIE1QMk1QKSBp bnRlcmZhY2VzIKhDIGFuZCB0aGVzZSBhcmUgYWxsb3dlZCAob3IsIGF0IGxlYXN0LCBub3QgcHJv aGliaXRlZCkgaW4gTVBMUy1UUCBhcyB3ZWxsLg0KDQpNeSAyYywNCiAgICAgU2FzaGENCg0KRnJv bTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgbGl1Lmd1b21hbkB6dGUuY29tLmNuDQpTZW50OiBUdWVzZGF5LCBB cHJpbCAwNiwgMjAxMCAxMTo0OSBBTQ0KVG86IER1IFpvbmdwZW5nDQpDYzogbXBsczsgbXBscy10 cC1ib3VuY2VzQGlldGYub3JnOyBtcGxzLXRwDQpTdWJqZWN0OiBSZTogW21wbHMtdHBdIEEgbmV3 IElEIGRyYWZ0LWppLW1wbHMtdHAtYmlkaXJlY3Rpb25hbC1sYWJlbC0wMA0KDQoNCmhpDQpJZiBs YWJlbCBhc3NpZ25tZW50IGlzIGJhc2VkIG9uIHBlciBpbnRlcmZhY2UgbGFiZWwgc3BhY2UsIHdp bGwgbGFiZWwgY3Jhc2ggbm90IGhhcHBlbj8NCg0KbWF5YmUgbXkgdW5kZXJzdGFuZGluZyBiZSB3 cm9uZy4NCg0KdGhhbmsgeW91DQpsaXUNCg0KDQoNCg0KRHUgWm9uZ3BlbmcgPGR1em9uZ3BlbmdA Z21haWwuY29tPg0Kt6K8/sjLOiAgbXBscy10cC1ib3VuY2VzQGlldGYub3JnDQoNCjIwMTAtMDQt MDYgMTI6NTcNCg0KytW8/sjLDQoNCm1wbHMtdHAgPG1wbHMtdHBAaWV0Zi5vcmc+LCBtcGxzIDxt cGxzQGlldGYub3JnPg0KDQqzrcvNDQoNCtb3zOINCg0KW21wbHMtdHBdICBBIG5ldyBJRCBkcmFm dC1qaS1tcGxzLXRwLWJpZGlyZWN0aW9uYWwtbGFiZWwtMDANCg0KDQoNCg0KDQoNCg0KRGVhciBN UExTIFdHOg0KDQpQbGVhc2UgYmUgYXdhcmUgdGhhdCB3ZSBzdWJtaXR0ZWQgYSBuZXcgV0cgZG9j dW1lbnQsDQoNCkJpZGlyZWN0aW9uYWwgTGFiZWwgQXNzaWdubWVudCBpbiBNUExTLVRQDQpkcmFm dC1qaS1tcGxzLXRwLWJpZGlyZWN0aW9uYWwtbGFiZWwtMDANCmh0dHA6Ly90b29scy5pZXRmLm9y Zy9pZC9kcmFmdC1qaS1tcGxzLXRwLWJpZGlyZWN0aW9uYWwtbGFiZWwtMDAudHh0DQoNCkFic3Ry YWN0DQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG5ldyBtZWNoYW5pc20gZm9yIHRoZSBsYWJl bCBhbGxvY2F0aW9uIG9mIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHBvaW50LXRvLXBvaW50IHBh dGhzIGluIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIG5ldHdvcmtzLCB3aGljaCBp cyBjYWxsZWQgdGhlIGJpZGlyZWN0aW9uYWwgbGFiZWwgYWxsb2NhdGlvbiBtZWNoYW5pc20uIFRo ZSBub2RlcyBvbiBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBwb2ludC10by0gcG9pbnQgcGF0aHMg d2lsbCBub3QgbmVlZCB0byByZWNvcmQgdGhlIGxhYmVsIHBhaXJpbmcgcmVsYXRpb25zaGlwIG9m IHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQgZGlyZWN0aW9ucyBpbiB0aGlzIG1lY2hhbmlz bSBiZWNhdXNlIHRoZSBsYWJlbHMgYXJlIHN5bW1ldHJpY2FsLiBJbiBhZGRpdGlvbiwgdGhlIGNv bXByZXNzaW9uIG9mIHRoZSBMSUIgYmVjb21lcyBwb3NzaWJsZSBiZWNhdXNlIG9mIHRoZSBleGlz dGluZyBvZiBzeW1tZXRyaWNhbCBlbGVtZW50cy4NCg0KV2Ugd291bGQgYXBwcmVjaWF0ZSByZXZp ZXdzIGFuZCBjb21tZW50cyBmb3Igb3VyIGRvY3VtZW50Lg0KDQpCZXN0IFJlZ2FyZHMNCg0KWm9u Z3BlbmcgRHUNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KWm9uZ3BlbmcgRHUNCkJVUFQNCkFkZHJlc3M6IFAuTy5Cb3ggOTAsIEJlaWppbmcgVW5pdmVy c2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQpOby4xMCwgWGl0dWNoZW5nIFJv YWQsIEhhaWRpYW4gRGlzdHJpY3QsIEJlaWppbmcsIENoaW5hLCAxMDA4NzYNClRlbDogKzg2LTAx MC02MjI4MjkwNS04MDcNCkVNYWlsOiBkdXpvbmdwZW5nQGdtYWlsLmNvbTxtYWlsdG86ZHV6b25n cGVuZ0BnbWFpbC5jb20+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscy10cCBtYWlsaW5nIGxpc3QNCm1wbHMtdHBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQoN ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --_000_A3C5DF08D38B6049839A6F553B331C76C1080A0089ILPTMAIL02eci_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Liu and all,

Using per-interface label space on P2P interfaces would inde= ed prevent the situations to which draft-ji-mpls-tp-bidirectional-label refers= as =A1=B0label crash=A1=B1 (IMO =A1=B0label allocation conflict=A1=B1 would be a more suit= able name). But it would not help much on LAN (or MP2MP) interfaces =A8C and these are allowed= (or, at least, not prohibited) in MPLS-TP as well.

 

My 2c,

     Sasha

 

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = liu.guoman@zte.com.cn
Sent: Tuesday, April 06, 2010 11:49 AM
To: Du Zongpeng
Cc: mpls; mpls-tp-bounces@ietf.org; mpls-tp
Subject: Re: [mpls-tp] A new ID draft-ji-mpls-tp-bidirectional-label= -00

 


hi=
If label assignment is based on per interface label space, will label crash not happ= en?

maybe my understanding be wrong.

thank you=
liu




Du Zongpeng <duzongpeng@gmail.com>
=B7=A2=BC=FE=C8=CB:  mpls-tp-bounces@ietf.org<= /span>

2010-= 04-06 12:57

=CA=D5=BC=FE=C8=CB

mpls-tp <mpls-tp@ietf.org>, mpls <mpls@ietf.org> =

=B3=AD=CB=CD

=D6=F7=CC=E2

[mpls-tp]  A new ID draft-ji-mpls-tp-bidirectional-label-00

 




Dear MPLS WG:

Please be aware that we submitted a new WG document,

Bidirectional Label Assignment in MPLS-TP
draft-ji-mpls-tp-bidirectional-label-00
http://tools.ietf.org/id/draft-ji-mpls-tp-bidirectional-l= abel-00.txt

Abstract
This document describes a new mechanism for the label allocation of co-rout= ed bidirectional point-to-point paths in MPLS Transport Profile (MPLS-TP) networks, which is called the bidirectional label allocation mechanism. The nodes on co-routed bidirectional point-to- point paths will not need to rec= ord the label pairing relationship of the forward and the backward directions i= n this mechanism because the labels are symmetrical. In addition, the compres= sion of the LIB becomes possible because of the existing of symmetrical elements= .

We would appreciate reviews and comments for our document.

Best Regards

Zongpeng Du

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zongpeng Du
BUPT
Address: P.O.Box 90, Beijing University of Posts and Telecommunications
No.10, Xitucheng Road, Haidian District, Beijing, China, 100876
Tel: +86-010-62282905-807
EMail: duzongpeng@gmail.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

 
------------------------------------------=
--------------
ZTE Information Security Notice: information contained in&nb=
sp;this mail is&nb=
sp;solely property of&nb=
sp;the sender's organization. This mail communication is confidential. Recipients named above=
 are obligated to&nb=
sp;maintain secrecy and&n=
bsp;are not permitted to disclose the&n=
bsp;contents of this communication to others.
This email and&n=
bsp;any files transmitted with it are confidential and intended for the&n=
bsp;use of the individual or entity to whom they are&n=
bsp;addressed. If you have received email in&nb=
sp;error please notify the originator of the message. Any&n=
bsp;views expressed in&nb=
sp;this message are&n=
bsp;those of the individual sender.
This message has&n= bsp;been scanned for&n= bsp;viruses and Spam&= nbsp;by ZTE Anti-Spam system.
--_000_A3C5DF08D38B6049839A6F553B331C76C1080A0089ILPTMAIL02eci_-- From hhelvoort@chello.nl Tue Apr 6 05:34:49 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721E13A68AA; Tue, 6 Apr 2010 05:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.686 X-Spam-Level: X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkxuEtzkN91o; Tue, 6 Apr 2010 05:34:48 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id A46F33A6837; Tue, 6 Apr 2010 05:34:44 -0700 (PDT) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406123441.GOA14855.viefep12-int.chello.at@edge05.upcmail.net>; Tue, 6 Apr 2010 14:34:41 +0200 Received: from McAsterix.local ([24.132.217.64]) by edge05.upcmail.net with edge id 2Cae1e04X1Px1NY05CafHz; Tue, 06 Apr 2010 14:34:40 +0200 X-SourceIP: 24.132.217.64 Message-ID: <4BBB2A5E.5080104@chello.nl> Date: Tue, 06 Apr 2010 14:34:38 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Malcolm.BETTS@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=SLkC287PFWo6d7eSEiSBB9255DBOWQ3bwOwHXJiyZoo= c=1 sm=0 a=KOr6Xb6AEl8A:10 a=8nJEP1OIZ-IA:10 a=hmzp-snQr4WrGwj77tIA:9 a=vR6E9FShC-6yknvOhE7vJMYAd-sA:4 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: loa.andersson@ericsson.com, mpls@ietf.org, ahmpls-tp@lists.itu.int, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, greg.jones@itu.int, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: Re: [mpls] [mpls-tp] New Liaison Statement, "MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:34:49 -0000 Hi Malcolm, You wrote: > Loa, > > The response liaison from the SG15 (ref # 15.02) on the -10 version > identified 4 major open issues, it also included numerous suggested > modifications and requested clarification on some issues that were not > explicitly included in the draft we also indicated our intention to > include these aspects in G.8110.1. > > We would appreciate a prompt response to that liaison indicating the > disposition of the comments and confirmation that our assumptions are > correct and that the IETF will support the documentation of the > scenarios mentioned in our liaison in G.8110.1. > > Depending on the timing of your response I may need to request > additional time to respond to your request - this is in parallel with 4 > other WG last calls and the second week overlaps with the experts > meeting on MPLS-TP. I support you on both issues. If these are not resolved properly I fear that the quality of our work will drop. Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From wwwrun@core3.amsl.com Tue Apr 6 07:07:10 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BFCE93A68C2; Tue, 6 Apr 2010 07:07:10 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100406140710.BFCE93A68C2@core3.amsl.com> Date: Tue, 6 Apr 2010 07:07:10 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS160 - MPLS-TP OAM Framework draft reviewed (ref # 018.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:07:10 -0000 Title: LS160 - MPLS-TP OAM Framework draft reviewed (ref # 018.02) Submission Date: 2010-04-06 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=864 Please reply by 2010-04-11 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: hhelvoort@huawei.com Purpose: For action Body: Attachment(s): LS160 - MPLS-TP OAM Framework draft reviewed (ref # 018.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file974.pdf) From wwwrun@core3.amsl.com Tue Apr 6 07:16:23 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 638323A6966; Tue, 6 Apr 2010 07:16:23 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100406141623.638323A6966@core3.amsl.com> Date: Tue, 6 Apr 2010 07:16:23 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "IETF response to ITU-T Comments on the MPLS-TP Framework (ref #015.03)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:16:23 -0000 Title: IETF response to ITU-T Comments on the MPLS-TP Framework (ref #015.03) Submission Date: 2010-04-06 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=865 From: Loa Andersson(IETF MPLS WG) To: SG15, Q9, Q10, Q12, Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For information Body: IETF response to ITU+T Comments on the MPLS-TP Framework (ref #015.03) SG15, Q9, Q10, Q12 and Q14 Please find our responses to the issues raised in your liaison �Comments on draft-ietf-mpls-tp-framework-10 [Ref #015.02]� of March 5, 2010. Loa Andersson George Swallow MPLS Working Group co-chairs Attachment(s): Response to comments on MPLS-TP Framework (https://datatracker.ietf.org/documents/LIAISON/file975.doc) From wwwrun@core3.amsl.com Tue Apr 6 09:07:29 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EA1373A68B7; Tue, 6 Apr 2010 09:07:29 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100406160729.EA1373A68B7@core3.amsl.com> Date: Tue, 6 Apr 2010 09:07:29 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, stbryant@cisco.com Subject: [mpls] Updated Liaison Statement, "LS160 - MPLS-TP OAM Framework draft reviewed (ref # 019.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:07:30 -0000 Title: LS160 - MPLS-TP OAM Framework draft reviewed (ref # 019.02) Submission Date: 2010-04-06 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=864 Please reply by 2010-04-11 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: hhelvoort@huawei.com Purpose: For action Body: Attachment(s): LS160 - MPLS-TP OAM Framework draft reviewed (ref # 019.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file976.pdf) From Italo.Busi@alcatel-lucent.com Tue Apr 6 10:10:55 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A364628C0EE; Tue, 6 Apr 2010 10:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et+N4HJrnysN; Tue, 6 Apr 2010 10:10:51 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 341C928C0F2; Tue, 6 Apr 2010 10:10:50 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o36HAXF2005502; Tue, 6 Apr 2010 19:10:34 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 19:10:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Apr 2010 19:14:09 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B1E18@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <4BBB2A5E.5080104@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [mpls-tp] New Liaison Statement, "MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01)" thread-index: AcrVhZEFDJ1RH6A4T7Ko95tAhrRD7QAAj0sA References: <4BBB2A5E.5080104@chello.nl> From: "BUSI ITALO" To: , X-OriginalArrivalTime: 06 Apr 2010 17:10:33.0450 (UTC) FILETIME=[1147F4A0:01CAD5AC] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: loa.andersson@ericsson.com, mpls@ietf.org, ahmpls-tp@lists.itu.int, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, greg.jones@itu.int, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: Re: [mpls] [mpls-tp] New Liaison Statement, "MPLS working group last call on "A Framework for MPLS in Transport Networks" (ref #026.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:10:56 -0000 Huub, Malcolm, I think the current schedule is seriously endangering the quality of the = work. Looking at the reference table, there are 10 RFCs that ITU-T needs to = normatively reference in the MPLS-TP Recommendations planned for consent = in June. Currently, only 4 of them are available. Of the remaining 6, one has just finished its first WG LC and received = substantial comments to be addressed. The other 5 are ALL in WG LC this week. It is my view that three of = these are not sufficiently mature. I cannot yet say anything about the = remaining two because I have not had time so far to review them. I have already proposed the development of a more realistic work plan to = resolve this issue, but so far this has not occurred. As a technical contributor to this work, trying to do a good job, I find = this approach very unprofessional and frustrating. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Huub van Helvoort > Sent: marted=EC 6 aprile 2010 14.35 > To: Malcolm.BETTS@zte.com.cn > Cc: loa.andersson@ericsson.com; mpls@ietf.org;=20 > ahmpls-tp@lists.itu.int; yoichi.maeda@ntt-at.co.jp;=20 > mpls-tp@ietf.org; greg.jones@itu.int; paf@cisco.com;=20 > adrian.farrel@huawei.com; tsbsg15@itu.int;=20 > hhelvoort@huawei.com; hklam@alcatel-lucent.com;=20 > ghani.abbas@ericsson.com > Subject: Re: [mpls] [mpls-tp] New Liaison Statement, "MPLS=20 > working group last call on "A Framework for MPLS in Transport=20 > Networks" (ref #026.01)" >=20 > Hi Malcolm, >=20 > You wrote: >=20 > > Loa, > > > > The response liaison from the SG15 (ref # 15.02) on the -10 version=20 > > identified 4 major open issues, it also included numerous suggested=20 > > modifications and requested clarification on some issues=20 > that were not=20 > > explicitly included in the draft we also indicated our intention to=20 > > include these aspects in G.8110.1. > > > > We would appreciate a prompt response to that liaison=20 > indicating the=20 > > disposition of the comments and confirmation that our=20 > assumptions are=20 > > correct and that the IETF will support the documentation of the=20 > > scenarios mentioned in our liaison in G.8110.1. > > > > Depending on the timing of your response I may need to request=20 > > additional time to respond to your request - this is in=20 > parallel with=20 > > 4 other WG last calls and the second week overlaps with the experts=20 > > meeting on MPLS-TP. >=20 > I support you on both issues. > If these are not resolved properly I fear that the quality of=20 > our work will drop. >=20 > Regards, Huub. >=20 >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From vishwas.ietf@gmail.com Tue Apr 6 12:26:09 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3BD3A6B0A for ; Tue, 6 Apr 2010 12:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=1.257, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnlrOhc+YG0X for ; Tue, 6 Apr 2010 12:26:08 -0700 (PDT) Received: from mail-yx0-f202.google.com (mail-yx0-f202.google.com [209.85.210.202]) by core3.amsl.com (Postfix) with ESMTP id B79E83A659A for ; Tue, 6 Apr 2010 12:23:28 -0700 (PDT) Received: by yxe40 with SMTP id 40so97630yxe.31 for ; Tue, 06 Apr 2010 12:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=q4GNyxyQTfliXcnBt9SaLxzO1YCuPqO6Qu5pFQsbs0s=; b=LsAJVm7C4rHZg7qDueaEDxhP+mMzfbSz1mpS37ycisoWFmO+UCjMIYX8qJAco0imtE /2Chidrzx4P70/G0ZR5xsqcSy6jLaRygoeMzveu/qFC7yfxuA7olhSPJj+OV3Gf5sx1m DhRx8ixDr00Ky/me0dKy4cvE4RN5HLhyUpjCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FAiYNNxIeTcfWxlh+NgVbEypbszeMcYtDHwiRsFvTsNJtExtdzQ0VHEpxziGSIv4G6 YfPoV7sr7WsI0YzpnmIsOwhpl+fcj/gN3qKV9mB6/ypvC72OPyvnAdYwrhGzbzM5Y9oK hIeucFb9GergKpkmUUrHT02op90y+MWL6O9Sg= MIME-Version: 1.0 Received: by 10.150.147.9 with HTTP; Tue, 6 Apr 2010 12:23:23 -0700 (PDT) Date: Tue, 6 Apr 2010 12:23:23 -0700 Received: by 10.150.159.7 with SMTP id h7mr4731203ybe.129.1270581803709; Tue, 06 Apr 2010 12:23:23 -0700 (PDT) Message-ID: From: Vishwas Manral To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:26:09 -0000 Hi folks, http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03 We have a new version of the LDP IPv6 draft. The draft has been around since 2008, however we are now seeing operators asking for it (and can be seen in some discussions in the RIPE mailing lists). We would want to hear comments on the same from the list. Thanks, Vishwas From vishwas.ietf@gmail.com Tue Apr 6 22:26:05 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C103A69EA for ; Tue, 6 Apr 2010 22:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=1.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXICtO-C+g+8 for ; Tue, 6 Apr 2010 22:26:03 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 9C7C43A6877 for ; Tue, 6 Apr 2010 22:24:26 -0700 (PDT) Received: by pwj2 with SMTP id 2so612737pwj.31 for ; Tue, 06 Apr 2010 22:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:cc:content-type; bh=BVDIKZVuWKyWH76ca27ZqLFpHBGLw5U+oZloswz0Kmc=; b=U61CoI3OExW9SDlwgq4ycrYjpMIIeYSs/PSrqpO937pFLewFqL7NM3v89La0YuhBAo mcsvcxJ9apNkbD39JIL3YF0iki+hNjwb/OKTZYXOof/6foR9Pwv/Yq2RT6LL6HwsLadW G88Tey8p264C0L1v18iMy38dG0V1IYjJ7rBAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=EmVpOFX4FzqDiNAQKi1DdO8P2HtJPQqs2vkehDrCvH8qAYgK4qttdsXs7A0C1DpFzC 8xMr51wjeM2+ylDyi3gNdFJ1DjTLpbwDk/Ea8VBqFTiW4iG1JtRmlcB8JHopO0Jpi/BY Xw/SHO0y1Rfb01MDvRiHRC4L+6HWASCk5Lm1I= MIME-Version: 1.0 Received: by 10.142.43.10 with HTTP; Tue, 6 Apr 2010 22:23:54 -0700 (PDT) Date: Tue, 6 Apr 2010 22:23:54 -0700 Received: by 10.142.9.10 with SMTP id 10mr2991771wfi.42.1270617834918; Tue, 06 Apr 2010 22:23:54 -0700 (PDT) Message-ID: From: Vishwas Manral To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] RSVP-TE for IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 05:26:05 -0000 Hi chairs, I was wondering what views the you/ WG had regarding about using Router-Alert for RSVP messages for IPv6. As RSVP-TE only works hop-by-hop and there is nearly no reason to support any backward compatibility, I see no reason why Router-Alert should be used for RSVP for IPv6. Other than adding security holes I noticed it is rearly implemented in any of the OS for IPv6 and only adds to confusion without adding any value. We already do the same for GMPLS. Thanks, Vishwas From wwwrun@core3.amsl.com Wed Apr 7 07:33:19 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 01B743A689B; Wed, 7 Apr 2010 07:33:18 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100407143319.01B743A689B@core3.amsl.com> Date: Wed, 7 Apr 2010 07:33:19 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-framework (A Framework for MPLS in Transport Networks) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:33:19 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Framework for MPLS in Transport Networks ' as an 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 2010-04-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18027&rfc_flag=0 From wwwrun@rfc-editor.org Wed Apr 7 10:11:46 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A653A6937 for ; Wed, 7 Apr 2010 10:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnsemwRDqy7x for ; Wed, 7 Apr 2010 10:11:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id BBAE03A6811 for ; Wed, 7 Apr 2010 10:11:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6C7B7130001; Wed, 7 Apr 2010 10:11:41 -0700 (PDT) To: loa@pi.se, ina@juniper.net, rhthomas@cisco.com, stbryant@cisco.com, adrian.farrel@huawei.com, swallow@cisco.com, loa@pi.nu From: RFC Errata System Message-Id: <20100407171141.6C7B7130001@rfc-editor.org> Date: Wed, 7 Apr 2010 10:11:41 -0700 (PDT) Cc: nmalykh@protocols.ru, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC5036 (2133) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:11:46 -0000 The following errata report has been submitted for RFC5036, "LDP Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5036&eid=2133 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 2.5.4 Original Text ------------- NON EXISTENT Session TCP connection established INITIALIZED established Corrected Text -------------- NON EXISTENT Session TCP connection established INITIALIZED 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. -------------------------------------- RFC5036 (draft-ietf-mpls-rfc3036bis-04) -------------------------------------- Title : LDP Specification Publication Date : October 2007 Author(s) : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed. Category : DRAFT STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From venkatflex@gmail.com Wed Apr 7 12:19:37 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1AE3A6940; Wed, 7 Apr 2010 12:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uie-7+rVTLqP; Wed, 7 Apr 2010 12:19:36 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 1B9183A67F5; Wed, 7 Apr 2010 12:19:36 -0700 (PDT) Received: by iwn27 with SMTP id 27so922701iwn.5 for ; Wed, 07 Apr 2010 12:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=pjsYEm5JDY3uKeRVDVueD9jDChs1FL29LCK3wkeoGpo=; b=krYgUmCHvJvH8rRHeB31YmUn6DAIW8rRxxXBFX0QX8OaAec+ii69+Z75ZkLUKSwrpP zrXEFUV7vdNcEHzwhQks+B32xCpiHOIzj547Yolg12enTK3XKwDmCd8e8esMGG4/2QEF ss2axgvZBLZO2Axm/PVSxStV9bAge9B2gEeAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xByccEeUmWuq3FoIjmzEiSjGs3m/ReAJaztbYvchGKqIK7A2GaLaA3HmkArH3D1X4x ZsiDDpnkR3QhHl+yHxlp7Bf9g60ZiQjVCW8Jx+lwYHmxnL5mOsklDLgCWSxzsZuLDWPn NC62HfIxpLTmU2McPsyReVtBX+k9kfGmyWn3M= MIME-Version: 1.0 Received: by 10.142.111.8 with HTTP; Wed, 7 Apr 2010 12:19:30 -0700 (PDT) Date: Thu, 8 Apr 2010 00:49:30 +0530 Received: by 10.142.120.4 with SMTP id s4mr3871454wfc.108.1270667970537; Wed, 07 Apr 2010 12:19:30 -0700 (PDT) Message-ID: From: venkatesan mahalingam To: mpls , mpls-tp@ietf.org, mpls@lists.ietf.org Content-Type: multipart/alternative; boundary=001636e0a51f02ebfc0483aa7169 Subject: [mpls] MPLS protection switching coordination X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:19:37 -0000 --001636e0a51f02ebfc0483aa7169 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please clarify my doubt on the draft-ietf-mpls-tp-linear-protection-01. Can't we pre-configure the egress node to take traffic on both the working path and protection path at a time though we send the traffic in one path (working or protection) at any point in time (1:1)? Instead of taking the action to move the traffic from working path to protection path and vice versa upon failure using PSC, can't we just run the signalling protocol to ensure that working/protection path is alive before any failure/degraded condition? If we do this we can easily switch the traffic immediately without any coordination from the peer node. It seems PSC may create over-head on the traffic switching from working path to protection path and vice versa. And it seems that IETF RFC-4090 (Fast Re-routing) talks about protected path and backup but in protection switching we use the term working path and protection path. Is this different convention really required? Please bear with me if the above is very basic. -- Best Regards, Venkatesan Mahalingam. --001636e0a51f02ebfc0483aa7169 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
Please clarify my doubt on the draft-ietf-mpls-tp-linear-protection-= 01.

Can't we pre-configure the egress node to take traffic on bo= th the working path and protection path at a time
though we send the tr= affic in one path (working or protection) at any point in time (1:1)?

Instead of taking the action to move the traffic from working path to p= rotection path and vice versa upon failure using PSC, can't we just run= the signalling protocol to ensure that working/protection path is alive be= fore any failure/degraded condition?
If we do this we can easily switch the traffic immediately without any coor= dination from the peer node.

It seems PSC may create over-head on th= e traffic switching from working path to protection path and vice versa.
And it seems that IETF RFC-4090 (Fast Re-routing) talks about protected= path and backup but in protection switching we use the term working path a= nd protection path.
Is this different convention really required?

Please bear with me if the above is very basic.

--
Best Rega= rds,
Venkatesan Mahalingam.
--001636e0a51f02ebfc0483aa7169-- From hhelvoort@chello.nl Wed Apr 7 12:52:33 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDB43A63EC; Wed, 7 Apr 2010 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RargLCS2yNRo; Wed, 7 Apr 2010 12:52:32 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 737703A6803; Wed, 7 Apr 2010 12:52:24 -0700 (PDT) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep17-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100407195220.MRH6431.viefep17-int.chello.at@edge05.upcmail.net>; Wed, 7 Apr 2010 21:52:20 +0200 Received: from McAsterix.local ([24.132.217.64]) by edge05.upcmail.net with edge id 2jsJ1e0481Px1NY05jsKRJ; Wed, 07 Apr 2010 21:52:20 +0200 X-SourceIP: 24.132.217.64 Message-ID: <4BBCE272.7050204@chello.nl> Date: Wed, 07 Apr 2010 21:52:18 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls-tp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=6UHAxsHwKCW0savQ7OVzrMBW5xvCzGO/qK2+m6qSwq4= c=1 sm=0 a=Ao8zajoe8KsA:10 a=8nJEP1OIZ-IA:10 a=I7sGuHaMBYMToTZ9lCYA:9 a=eOFbeEapVDgFCey_ouwA:7 a=ViLXI3tu9j8UY6O8bw8gI-9Ew34A:4 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: mpls Subject: Re: [mpls] [mpls-tp] MPLS protection switching coordination X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:52:33 -0000 Hi Venkatesan, You wrote: > Please clarify my doubt on the draft-ietf-mpls-tp-linear-protection-01. > > Can't we pre-configure the egress node to take traffic on both the > working path and protection path at a time > though we send the traffic in one path (working or protection) at any > point in time (1:1)? What you propose is to use a merging selector, this is not allowed in MPLS-TP. > Instead of taking the action to move the traffic from working path to > protection path and vice versa upon failure using PSC, can't we just run > the signalling protocol to ensure that working/protection path is alive > before any failure/degraded condition? How would the signalling be sent in the absence of a control plane? Just like APS: in-band with the data. The APS protocol "signals" that W and P are alive by sending NR (no request). > If we do this we can easily switch the traffic immediately without any > coordination from the peer node. This is possible only in case of uni-directional protection switching where both directions switch independently, this is possible only in 1+1. > It seems PSC may create over-head on the traffic switching from working > path to protection path and vice versa. Three messages at 3.3 ms if a change is signalled, and one message per second in stable state will not create a significant overhead. And it is also only sent on the protection entity, so there is no overhead on the working entity. > And it seems that IETF RFC-4090 (Fast Re-routing) talks about protected > path and backup but in protection switching we use the term working path > and protection path. > Is this different convention really required? In protection switching it is possible that only a section of the whole path is protected, this section has a working and a protection entity. This difference can be documented in the Rosetta draft if necessary. > Please bear with me if the above is very basic. I hope you have a better understanding now of these basics. Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From root@core3.amsl.com Wed Apr 7 15:30:02 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E96423A68A5; Wed, 7 Apr 2010 15:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100407223001.E96423A68A5@core3.amsl.com> Date: Wed, 7 Apr 2010 15:30:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-fastreroute-mib-14.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 22:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute Author(s) : R. Cetin, T. Nadeau, K. Koushik Filename : draft-ietf-mpls-fastreroute-mib-14.txt Pages : 47 Date : 2010-4-7 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-fastreroute-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-4-7152244.I-D@ietf.org> --NextPart-- From mtinka@globaltransit.net Thu Apr 8 09:24:51 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF1B3A695F for ; Thu, 8 Apr 2010 09:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6410sZE82rs for ; Thu, 8 Apr 2010 09:24:50 -0700 (PDT) Received: from the-host.globaltransit.net (unknown [203.223.132.212]) by core3.amsl.com (Postfix) with ESMTP id 118EF3A6838 for ; Thu, 8 Apr 2010 09:24:48 -0700 (PDT) Received: from [127.0.0.1] (helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.69) (envelope-from ) id 1NzjEv-0000cK-8A; Thu, 08 Apr 2010 12:21:13 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Thu, 8 Apr 2010 12:21:10 +0800 User-Agent: KMail/1.12.4 (Linux/2.6.31.12-0.2-desktop; KDE/4.3.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12713434.npasLWiqJk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201004081221.11915.mtinka@globaltransit.net> Subject: Re: [mpls] LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 16:24:51 -0000 --nextPart12713434.npasLWiqJk Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday 08 April 2010 12:16:01 pm Vishwas Manral wrote: > Hi folks, >=20 > http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03 >=20 > We have a new version of the LDP IPv6 draft. The draft > has been around since 2008, however we are now seeing > operators asking for it (and can be seen in some > discussions in the RIPE mailing lists). >=20 > We would want to hear comments on the same from the list. I've been tracking this draft since it first appeared, and=20 the latest iteration addresses some of the aspects I=20 previously thought about. I'm in support of this draft, and as an operator with a 100%=20 MPLS and BGP-free core (for IPv4, anyway), I'd be glad to=20 see vendors begin implementation plans. Cheers, Mark. --nextPart12713434.npasLWiqJk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iQIcBAABAgAGBQJLvVm3AAoJEGcZuYTeKm+GIIMP+QGkKk9lbP/UThw4CUggKWCd LntRJSr92cVbv9FJgrtISD89HrQBp1HRU2/n/G5VdNG/GYcbXXWl+sa/wYLnlRWk YgZiupwpvjIeYLjQJmJ8bbWjCl6XmaMXNeYX2DchoywuwESRv076udq1R0uktdFL 8Pf7bSdIGpi/RgVp8EZ9uBRdnkmeOoaT8OcSSz2YsKy9S+Q/pM/nPDwBZYu4T1hf lmXTcqV7ncp7hgxQSYwzv+kk7rUMNSb0B8abjnq4NS6WanC8G1kK8vMVME83NZbo dlNk5HJxImE0sy1uqKVCciu+pqlk1FBKCMG/aWELO22UcOrjlv5+THDZGumiHA+i 9/Bd5L//vsYDYLISzKm9G2W7t+GVP6JqoonxsjnHp1cKb6/tno7W7sxY0/UQ2QvQ FozjA1zslbzYbN3U6ITR1jh1gF2sB7RY0JW0j3giyX8dXl1WU7OE1GoocEoNVSnE aBFJYJvEJFe0/42cxncWkLbIPxbZPY0SFmQfLlWF1g9R6KUTS/WLo+Fy05LsGEfK 5R+ItykJQuxRTt8jzLYTmQpzs4+WxXWwxK0cCdXCXvoEww+A2KBoj62Xwv0ToMcr aLYNS1T9U0sh/iXH86MMw71dhyi8xv4tt1d8qSdV8GW5RBv/QUhrEtYC3YQiF4hk IpWKJSXdADEUOJNj9PJ5 =qg/R -----END PGP SIGNATURE----- --nextPart12713434.npasLWiqJk-- From davari@broadcom.com Thu Apr 8 12:00:03 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DCDB3A6ACE; Thu, 8 Apr 2010 12:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDnTjdtugPy3; Thu, 8 Apr 2010 12:00:02 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 32C6A3A69B2; Thu, 8 Apr 2010 12:00:02 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 08 Apr 2010 11:59:50 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 8 Apr 2010 11:59:49 -0700 From: "Shahram Davari" To: "Loa Andersson" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP Date: Thu, 8 Apr 2010 11:59:48 -0700 Thread-Topic: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> In-Reply-To: <4BB70AE7.1020605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A0F82C38O166931249-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:00:03 -0000 Hi Loa, The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As w= e know traditional transport layers only have one CoS. However E-LSP has mu= ltiple CoS, which can reorder packets (I know that the reorder packets belo= ng to different CoS). Additionally the definition of E-LSP OAM and performa= nce and protection and availability, etc will be questionable (because of c= arrying multiple CoS). Therefore I think E-LSP should not be supported in MPLS-TP or at least shou= ld be discouraged. Regards, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CC= AMP Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framewo= rk-11 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /Loa --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From jdrake@juniper.net Thu Apr 8 12:25:48 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977DF3A6A13; Thu, 8 Apr 2010 12:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P77snLQMQXAp; Thu, 8 Apr 2010 12:25:47 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id A2BB93A68DD; Thu, 8 Apr 2010 12:25:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS74trX4Qb95rMr2U68Dihk60FNUjzTfj@postini.com; Thu, 08 Apr 2010 12:25:44 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 8 Apr 2010 12:20:38 -0700 From: John E Drake To: Shahram Davari , Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team , "pwe3@ietf.org" , CCAMP Date: Thu, 8 Apr 2010 12:20:36 -0700 Thread-Topic: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAGqaWbA= Message-ID: <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:25:48 -0000 Sharam, We have been through this at least twice before. The best way to think E-L= SPs is that the former EXP bits in the header are part of an extended label= . So you effectively have eight parallel LSPs and there is no packet re-or= dering within each. Dave said he would mention something about OAM per parallel LSP in the fram= ework in response to a last call comment I made. Thanks, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: Thursday, April 08, 2010 12:00 PM > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > pwe3@ietf.org; CCAMP > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > mpls-tp-framework-11 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > we know traditional transport layers only have one CoS. However E-LSP has > multiple CoS, which can reorder packets (I know that the reorder packets > belong to different CoS). Additionally the definition of E-LSP OAM and > performance and protection and availability, etc will be questionable > (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or at least > should be discouraged. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > CCAMP > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A Framework > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that comments > raised during the orevious working group last call and reviews have > been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April 17th, the > latest. >=20 > /Loa > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Thu Apr 8 12:30:23 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76843A6ABD; Thu, 8 Apr 2010 12:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp0NTzrrphRA; Thu, 8 Apr 2010 12:30:22 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 703643A6AD3; Thu, 8 Apr 2010 12:30:22 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 08 Apr 2010 12:30:05 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 8 Apr 2010 12:30:05 -0700 From: "Shahram Davari" To: "John E Drake" , "Loa Andersson" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP Date: Thu, 8 Apr 2010 12:30:03 -0700 Thread-Topic: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAGqaWbAAAG/tQA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A0F13731G84960335-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:30:23 -0000 Hi John, Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of = them fail do protection switching for all of them? What will be the definit= ion of availability for such E-LSP?=20 Thanks SD -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, April 08, 2010 12:21 PM To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP= ad hoc team; pwe3@ietf.org; CCAMP Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf-mpls= -tp-framework-11 Sharam, We have been through this at least twice before. The best way to think E-L= SPs is that the former EXP bits in the header are part of an extended label= . So you effectively have eight parallel LSPs and there is no packet re-or= dering within each. Dave said he would mention something about OAM per parallel LSP in the fram= ework in response to a last call comment I made. Thanks, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: Thursday, April 08, 2010 12:00 PM > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > pwe3@ietf.org; CCAMP > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > mpls-tp-framework-11 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > we know traditional transport layers only have one CoS. However E-LSP has > multiple CoS, which can reorder packets (I know that the reorder packets > belong to different CoS). Additionally the definition of E-LSP OAM and > performance and protection and availability, etc will be questionable > (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or at least > should be discouraged. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > CCAMP > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A Framework > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that comments > raised during the orevious working group last call and reviews have > been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April 17th, the > latest. >=20 > /Loa > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Thu Apr 8 12:31:08 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84033A6ACA; Thu, 8 Apr 2010 12:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUNqmY3dn4Rs; Thu, 8 Apr 2010 12:31:07 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 1DDA73A6ABE; Thu, 8 Apr 2010 12:31:06 -0700 (PDT) Received: by ywh38 with SMTP id 38so1302611ywh.29 for ; Thu, 08 Apr 2010 12:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=DLP7A3H0WQ9m+/webozNCiWoYKjm+qRHeeoX1ZkYKUc=; b=CVwmQarLqOH8NZeui2xVUpHePU35mY3HfyNH+sk66/1aeuEwALlt4jVDLv/OHd6rGC 6ID/0xRlF1lu1CMjiyvrcuyDm5ISGP4GDff0D1+Su73li4P/ZAJGwWBypYZvOwS56oEV uKOXYKdy+2L8QyI8tVUQxGGWBG6xeCMMMW4aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cQkVqvOA3rOcNRjhXpDeUew6a3coqNcsQEp8gq/5d+GbDgR41Iaw7b6eeiyDu69SWu S4eidfx1bjYjA7LHfQtDvi8ru9jQBoXsS/gqTtTaftSn9FQpdpk6pVAxrC3r7NA3v50R ryhOZF+kKEN4QF3bct+oGUhc9+j6cJsq8B1bY= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Thu, 8 Apr 2010 12:30:59 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 8 Apr 2010 12:30:59 -0700 Received: by 10.90.14.37 with SMTP id 37mr155597agn.94.1270755059569; Thu, 08 Apr 2010 12:30:59 -0700 (PDT) Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=0016361e8936ec189d0483beb745 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:31:08 -0000 --0016361e8936ec189d0483beb745 Content-Type: text/plain; charset=ISO-8859-1 Dear Shahram, I share your concern regarding applicability of E-LSP in packet transport network. Though the document is about the Transport Profile, references to MPLS-TP as packet transport network technology been changed recently. Now MPLS-TP is referred as "packet network". It is my understanding that applicability of MPLS-TP functionality, features and capabilities to the packet transport network will be decided later, separately. Regarding classes of service in the transport. Neil Harrison pointed several times that a connection, transport path cannot have multiple classes, otherwise it leads to significant increased complexity of OAM, which has to be (SHOULD) per Class of Service per E-LSP. Regards, Greg On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrote: > Hi Loa, > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > we know traditional transport layers only have one CoS. However E-LSP has > multiple CoS, which can reorder packets (I know that the reorder packets > belong to different CoS). Additionally the definition of E-LSP OAM and > performance and protection and availability, etc will be questionable > (because of carrying multiple CoS). > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > should be discouraged. > > Regards, > Shahram > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > CCAMP > Subject: [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > All, > > this is to start a short working group last call on "A Framework > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > Please note that this wg last call is limited to verify that comments > raised during the orevious working group last call and reviews have > been correctly addressed. > > Please sen comments to the mpls-tp mailing list on April 17th, the > latest. > > /Loa > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --0016361e8936ec189d0483beb745 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Shahram,
I share your concern regarding applicability of E-LSP in p= acket transport network. Though the document is about the Transport Profile= , references to MPLS-TP as packet transport network technology been changed= recently. Now MPLS-TP is referred as "packet network". It is my = understanding that applicability of MPLS-TP functionality, features and cap= abilities to the packet transport network will be decided later, separately= .
Regarding classes of service in the transport. Neil Harrison pointed severa= l times that a connection, transport path cannot have multiple classes, oth= erwise it leads to significant increased complexity of OAM, which has to be= (SHOULD) per Class of Service per E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 = at 11:59 AM, Shahram Davari <davari@broadcom.com> wrote:
Hi Loa,

The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As w= e know traditional transport layers only have one CoS. However E-LSP has mu= ltiple CoS, which can reorder packets (I know that the reorder packets belo= ng to different CoS). Additionally the definition of E-LSP OAM and performa= nce and protection and availability, etc will be questionable (because of c= arrying multiple CoS).

Therefore I think E-LSP should not be supported in MPLS-TP or at least shou= ld be discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [m= ailto:pwe3-bounces@ietf.org] O= n Behalf Of Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP
Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framewo= rk-11

All,

this is to start a short working group last call on "A Framework
for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11).

Please note that this wg last call is limited to verify that comments
raised during the orevious working group last call and reviews have
been correctly addressed.

Please sen comments to the mpls-tp mailing list on April 17th, the
latest.

/Loa
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0+46 767 72 92 13
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3


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

--0016361e8936ec189d0483beb745-- From gregimirsky@gmail.com Thu Apr 8 12:33:34 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F043A68F3; Thu, 8 Apr 2010 12:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXZW9BMgOC0p; Thu, 8 Apr 2010 12:33:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8E7133A67E7; Thu, 8 Apr 2010 12:33:32 -0700 (PDT) Received: by gwaa20 with SMTP id a20so1355795gwa.31 for ; Thu, 08 Apr 2010 12:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=VfDPhpt/m4vUh00oI90YPxNi6ri7+ZeewjbwWqQabFA=; b=KT4VH8omm41QOUGLxh1uFq1DL0ciowk9RVUwUtUfJOKEALvqZJ5gwV+PEkxj7wVfAg gGwzfHD+YqeknkEsLlyYpQqsQZWzBb72kUIKZz1YEtovuXZagSPOwv93hLk4XCA1RmD9 j+OeFLFO+KEpI76BCTP2+BiXRu4TjDDY/BTUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ohq8i65JAT6eJauEOerBKIoNy5BKB6aozTWj7MDsW9tICNWqs7fgOdmVCtcIyVTftN E+Zm0qVugRN394234I9L1JRApLRq2ZL/keL7/SZTwDQkbco0DZYgGRItxpS/C35jENqI ou/XE9N2nZMr4JZmbs1ie+aj85cVEVNjQW5r0= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Thu, 8 Apr 2010 12:33:25 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 8 Apr 2010 12:33:25 -0700 Received: by 10.90.18.30 with SMTP id 30mr150478agr.77.1270755205913; Thu, 08 Apr 2010 12:33:25 -0700 (PDT) Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=0016361e82caa51dd00483bec02f Cc: MPLS-TP ad hoc team , "mpls@ietf.org" , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:33:34 -0000 --0016361e82caa51dd00483bec02f Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, as John mentioned, OAM per CoS for E-LSP was discussed on another thread. I believe that we agreed that OAM SHOULD be per CoS. Right? Regards, Greg On Thu, Apr 8, 2010 at 12:30 PM, Shahram Davari wrote: > Hi John, > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of > them fail do protection switching for all of them? What will be the > definition of availability for such E-LSP? > > Thanks > SD > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, April 08, 2010 12:21 PM > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; > MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP > Subject: RE: [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > Sharam, > > We have been through this at least twice before. The best way to think > E-LSPs is that the former EXP bits in the header are part of an extended > label. So you effectively have eight parallel LSPs and there is no packet > re-ordering within each. > > Dave said he would mention something about OAM per parallel LSP in the > framework in response to a last call comment I made. > > Thanks, > > John > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Shahram Davari > > Sent: Thursday, April 08, 2010 12:00 PM > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > > pwe3@ietf.org; CCAMP > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > > we know traditional transport layers only have one CoS. However E-LSP has > > multiple CoS, which can reorder packets (I know that the reorder packets > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > > CCAMP > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --0016361e82caa51dd00483bec02f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shahram,
as John mentioned, OAM per CoS for E-LSP was discussed on an= other thread. I believe that we agreed that OAM SHOULD be per CoS. Right?
Regards,
Greg

On Thu, Apr 8, 201= 0 at 12:30 PM, Shahram Davari <davari@broadcom.com> wrote:
Hi John,

Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of = them fail do protection switching for all of them? What will be the definit= ion of availability for such E-LSP?

Thanks
SD

-----Original Message-----
From: John E Drake [mailto:jdrake@jun= iper.net]
Sent: Thursday, April 08, 2010 12:21 PM
To: Shahram Davari; Loa Andersson; mpls= -tp@ietf.org; mpls@ietf.org; MPLS-= TP ad hoc team; pwe3@ietf.org; CCAMP Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf-mpls= -tp-framework-11

Sharam,

We have been through this at least twice before. =A0The best way to think E= -LSPs is that the former EXP bits in the header are part of an extended lab= el. =A0So you effectively have eight parallel LSPs and there is no packet r= e-ordering within each.

Dave said he would mention something about OAM per parallel LSP in the fram= ework in response to a last call comment I made.

Thanks,

John

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Shahram Davari
> Sent: Thursday, April 08, 2010 12:00 PM
> To: Loa Andersson; mpls-tp@ietf.or= g; mpls@ietf.org; MPLS-TP ad hoc t= eam;
> pwe3@ietf.org; CCAMP
> Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf= -
> mpls-tp-framework-11
>
> Hi Loa,
>
> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP.= As
> we know traditional transport layers only have one CoS. However E-LSP = has
> multiple CoS, which can reorder packets (I know that the reorder packe= ts
> belong to different CoS). Additionally the definition of E-LSP OAM and=
> performance and protection and availability, etc will be questionable<= br> > (because of carrying multiple CoS).
>
> Therefore I think E-LSP should not be supported in MPLS-TP or at least=
> should be discouraged.
>
> Regards,
> Shahram
>
> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Loa Andersson
> Sent: Saturday, April 03, 2010 2:31 AM
> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org;
> CCAMP
> Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11
>
> All,
>
> this is to start a short working group last call on "A Framework<= br> > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11)= .
>
> Please note that this wg last call is limited to verify that comments<= br> > raised during the orevious working group last call and reviews have > been correctly addressed.
>
> Please sen comments to the mpls-tp mailing list on April 17th, the
> latest.
>
> /Loa
> --
>
>
> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: <= a href=3D"mailto:loa.andersson@ericsson.com">loa.andersson@ericsson.com=
> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:= +46 10 717 52 13
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


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

--0016361e82caa51dd00483bec02f-- From david.i.allan@ericsson.com Thu Apr 8 12:45:34 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE113A6AE4; Thu, 8 Apr 2010 12:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QSibP6E41VQ; Thu, 8 Apr 2010 12:45:33 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A310E28C0DC; Thu, 8 Apr 2010 12:45:28 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o38JnO0T013985; Thu, 8 Apr 2010 14:49:24 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 8 Apr 2010 15:45:21 -0400 From: David Allan I To: Greg Mirsky , Shahram Davari Date: Thu, 8 Apr 2010 15:45:19 -0400 Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrXUhDmA913Y8gxSkSinQmgQfqgdAAACFZw Message-ID: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD4F9953DBF7EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , CCAMP , MPLS-TP ad hoc team , "pwe3@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:45:34 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD4F9953DBF7EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not quite following this argument.... If I have a number of co-routed paths with different PHBs, I can instantiat= e a number of L-LSPs, which is a significant amount of state at every hop, = or I can instantiate one E-LSP, which is an N:1 compression in the amount o= f state in transit nodes. The only wrinkle is all PHBs of an E-LSP fate share. But then if I was prot= ecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or anothe= r E-LSP, and if they were co-routed, the majority of failure cases (link cu= ts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched = (although there would be 'n' signal fail indications internally to contend = with). Overall, it sounds to me like an E-LSP may be a bit faster there.... The actual OAM load to instrument them equally is the same. If an E-LSP tak= es 'n' times the flows to be instumented like 'n' L-LSPs so what???? I app= reciate that the ability to generate per PHB flows may be undesirable for s= ome, but that does not make it a bad idea. IMO there is no penalty for supporting E-LSPs and there are measurable bene= fits. The analysis is flawed. my 2 cents D ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= reg Mirsky Sent: Thursday, April 08, 2010 3:31 PM To: Shahram Davari Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; pwe3@ietf.= org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-i= etf-mpls-tp-framework-11 Dear Shahram, I share your concern regarding applicability of E-LSP in packet transport n= etwork. Though the document is about the Transport Profile, references to M= PLS-TP as packet transport network technology been changed recently. Now MP= LS-TP is referred as "packet network". It is my understanding that applicab= ility of MPLS-TP functionality, features and capabilities to the packet tra= nsport network will be decided later, separately. Regarding classes of service in the transport. Neil Harrison pointed severa= l times that a connection, transport path cannot have multiple classes, oth= erwise it leads to significant increased complexity of OAM, which has to be= (SHOULD) per Class of Service per E-LSP. Regards, Greg On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari > wrote: Hi Loa, The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As w= e know traditional transport layers only have one CoS. However E-LSP has mu= ltiple CoS, which can reorder packets (I know that the reorder packets belo= ng to different CoS). Additionally the definition of E-LSP OAM and performa= nce and protection and availability, etc will be questionable (because of c= arrying multiple CoS). Therefore I think E-LSP should not be supported in MPLS-TP or at least shou= ld be discouraged. Regards, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framewo= rk-11 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_60C093A41B5E45409A19D42CF7786DFD4F9953DBF7EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm not quite following this=20 argument....
 
If I have a number of co-routed paths with differe= nt PHBs,=20 I can instantiate a number of L-LSPs, which is a significant amount of stat= e at=20 every hop, or I can instantiate one E-LSP, which is an N:1 compression= in=20 the amount of state in transit nodes.
 
The only wrinkle is all PHBs of an E-LSP fate shar= e. But=20 then if I was protecting the L-LSP or the E-LSP version I'd have= =20 another 'n' L-LSPs or another E-LSP, and if they were co-routed, the majori= ty of=20 failure cases (link cuts) would result in a loud clang as many L-LSPs = vs.=20 one E-LSP was switched (although there would be 'n' signal fail indications= =20 internally to contend with). Overall, it sounds to me like an E-LSP ma= y be=20 a bit faster there....
 
The actual OAM load to instrument them equally is = the same.=20 If an E-LSP takes 'n' times the flows to be instumented like 'n' L-LSPs=20 so what????  I appreciate that the ability to generate per P= HB=20 flows may be undesirable for some, but that does not make it a bad=20 idea.
 
IMO there is no penalty for supporting E-LSPs and = there are=20 measurable benefits. The analysis is flawed.
 
my 2 cents
D

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent:= =20 Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc:= =20 mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org;=20 pwe3@ietf.org
Subject: Re: [CCAMP] [mpls] [PWE3] short working gr= oup=20 last call on draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability of= =20 E-LSP in packet transport network. Though the document is about the Transpo= rt=20 Profile, references to MPLS-TP as packet transport network technology been= =20 changed recently. Now MPLS-TP is referred as "packet network". It is my=20 understanding that applicability of MPLS-TP functionality, features and=20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil Harrison= =20 pointed several times that a connection, transport path cannot have multipl= e=20 classes, otherwise it leads to significant increased complexity of OAM, whi= ch=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari <davari@broadcom.com> wrot= e:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are supported in= =20 MPLS-TP. As we know traditional transport layers only have one CoS. Howev= er=20 E-LSP has multiple CoS, which can reorder packets (I know that the reorde= r=20 packets belong to different CoS). Additionally the definition of E-LSP OA= M and=20 performance and protection and availability, etc will be questionable (be= cause=20 of carrying multiple CoS).

Therefore I think E-LSP should not be=20 supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:pwe3-bounces@ietf.org">pwe3-bounces@ietf.org] On Behal= f Of=20 Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP
Subject: [PWE3]= short=20 working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start a sho= rt=20 working group last call on "A Framework
for MPLS in Transport Networks= "=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg last c= all=20 is limited to verify that comments
raised during the orevious working = group=20 last call and reviews have
been correctly addressed.

Please sen= =20 comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson     &= nbsp;=20                   email: loa.andersson@ericsson.com=
Sr=20 Strategy and Standards Manager            <= A=20 href=3D"mailto:loa@pi.nu">loa@pi.nu
Ericsson Inc     &nb= sp;=20                    phon= e:=20 +46 10 717 52 13
              &nbs= p;=20                     &nb= sp;=20        +46 767 72 92=20 13
_______________________________________________
pwe3 mailing=20 list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

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

--_000_60C093A41B5E45409A19D42CF7786DFD4F9953DBF7EUSAACMS0703e_-- From jdrake@juniper.net Thu Apr 8 12:55:09 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B053A6868; Thu, 8 Apr 2010 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjpIOtQYrqhm; Thu, 8 Apr 2010 12:55:08 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id CD79E3A6945; Thu, 8 Apr 2010 12:55:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS740jjFUlHeQE0nuzDQDPPStBNta54+h@postini.com; Thu, 08 Apr 2010 12:55:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 8 Apr 2010 12:51:32 -0700 From: John E Drake To: David Allan I , Greg Mirsky , Shahram Davari Date: Thu, 8 Apr 2010 12:51:31 -0700 Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrXUhDmA913Y8gxSkSinQmgQfqgdAAACFZwAACHmoA= Message-ID: <5E893DB832F57341992548CDBB3331639806CF47E6@EMBX01-HQ.jnpr.net> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" , MPLS-TP Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:55:09 -0000 Dave, My only comment is with your last sentence: "The analysis is flawed." To = be clearer, it should be: "The analysis that concludes that E-LSPs are a b= ad idea is flawed." Your analysis seems completely correct. Thanks, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Thursday, April 08, 2010 12:45 PM > To: Greg Mirsky; Shahram Davari > Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; mpls- > tp@ietf.org > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft= - > ietf-mpls-tp-framework-11 >=20 > I'm not quite following this argument.... >=20 > If I have a number of co-routed paths with different PHBs, I can > instantiate a number of L-LSPs, which is a significant amount of state at > every hop, or I can instantiate one E-LSP, which is an N:1 compression in > the amount of state in transit nodes. >=20 > The only wrinkle is all PHBs of an E-LSP fate share. But then if I was > protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or > another E-LSP, and if they were co-routed, the majority of failure cases > (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was > switched (although there would be 'n' signal fail indications internally > to contend with). Overall, it sounds to me like an E-LSP may be a bit > faster there.... >=20 > The actual OAM load to instrument them equally is the same. If an E-LSP > takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? = I > appreciate that the ability to generate per PHB flows may be undesirable > for some, but that does not make it a bad idea. >=20 > IMO there is no penalty for supporting E-LSPs and there are measurable > benefits. The analysis is flawed. >=20 > my 2 cents > D >=20 > ________________________________ >=20 > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: Thursday, April 08, 2010 3:31 PM > To: Shahram Davari > Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; > pwe3@ietf.org > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft= - > ietf-mpls-tp-framework-11 >=20 >=20 > Dear Shahram, > I share your concern regarding applicability of E-LSP in packet transport > network. Though the document is about the Transport Profile, references t= o > MPLS-TP as packet transport network technology been changed recently. Now > MPLS-TP is referred as "packet network". It is my understanding that > applicability of MPLS-TP functionality, features and capabilities to the > packet transport network will be decided later, separately. > Regarding classes of service in the transport. Neil Harrison pointed > several times that a connection, transport path cannot have multiple > classes, otherwise it leads to significant increased complexity of OAM, > which has to be (SHOULD) per Class of Service per E-LSP. >=20 > Regards, > Greg >=20 >=20 > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari > wrote: >=20 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in MPLS- > TP. As we know traditional transport layers only have one CoS. However E- > LSP has multiple CoS, which can reorder packets (I know that the reorder > packets belong to different CoS). Additionally the definition of E-LSP OA= M > and performance and protection and availability, etc will be questionable > (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or at > least should be discouraged. >=20 > Regards, > Shahram >=20 >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > pwe3@ietf.org; CCAMP > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A Framework > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that > comments > raised during the orevious working group last call and reviews have > been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April 17th, the > latest. >=20 > /Loa > -- >=20 >=20 > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From gregimirsky@gmail.com Thu Apr 8 12:57:21 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BB928C153; Thu, 8 Apr 2010 12:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh1P2Lpz0Q6z; Thu, 8 Apr 2010 12:57:19 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 3CFAA3A6945; Thu, 8 Apr 2010 12:57:19 -0700 (PDT) Received: by ywh38 with SMTP id 38so1314362ywh.29 for ; Thu, 08 Apr 2010 12:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=OUQreu4iQPs7vBwfMT3Kw1Z7TY4zY+S3jB2812rhWNM=; b=UbFaBJFjI4VpR6IBQmP66RKkIBqpU7t69n5GqHrCEXivyUPzl4EB3PyGY6cF55ZM/w b/On9Q557cfj91TsCry2uO0ZY/4sZxMbYov/bhnpOoCdet+i6rl+hfGU4XUKvvA/fp9i JmVc0FQWKhqRy9kEqyvQylCeas0yFbamj9zmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cZ6Wn2UkBRxe5oF91y03hits00YnLD84f0aOh+ElJ67mAOoq3yI0jN00xfZDNAG3Uf T9sSDaDNm0ItdoM1EFTjW7GmI6FX72+qBN6hb4mBUahtr6Bdl7xnT047Mg97e3JqS/j8 R6Zth5Yk5vmD5J4Y8gPW1s7Tfz9dHhPsO9IQc= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Thu, 8 Apr 2010 12:57:12 -0700 (PDT) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> Date: Thu, 8 Apr 2010 12:57:12 -0700 Received: by 10.91.185.3 with SMTP id m3mr168065agp.79.1270756632816; Thu, 08 Apr 2010 12:57:12 -0700 (PDT) Message-ID: From: Greg Mirsky To: David Allan I Content-Type: multipart/alternative; boundary=0016e6460744b1ef110483bf158f Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:57:21 -0000 --0016e6460744b1ef110483bf158f Content-Type: text/plain; charset=ISO-8859-1 Dear David, my understanding of pro-active CV/CC when applied to E-LSP is that all supported CoS will be run at all time regardless whether a particular class ever used. Though that might be taken care of by a intelligent OAM implementation. The protection of N L-LSPs might be done through PST to reduce the bang level. In my view both methods to do DiffServ in MPLS have proven itself. Both have merits and drawbacks. Both are part of MPLS-TP. Will they be both part of packet transport? Regards, Greg On Thu, Apr 8, 2010 at 12:45 PM, David Allan I wrote: > I'm not quite following this argument.... > > If I have a number of co-routed paths with different PHBs, I can > instantiate a number of L-LSPs, which is a significant amount of state at > every hop, or I can instantiate one E-LSP, which is an N:1 compression in > the amount of state in transit nodes. > > The only wrinkle is all PHBs of an E-LSP fate share. But then if I was > protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or > another E-LSP, and if they were co-routed, the majority of failure cases > (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was > switched (although there would be 'n' signal fail indications internally to > contend with). Overall, it sounds to me like an E-LSP may be a bit faster > there.... > > The actual OAM load to instrument them equally is the same. If an E-LSP > takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? I > appreciate that the ability to generate per PHB flows may be undesirable for > some, but that does not make it a bad idea. > > IMO there is no penalty for supporting E-LSPs and there are measurable > benefits. The analysis is flawed. > > my 2 cents > D > > ------------------------------ > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Greg Mirsky > *Sent:* Thursday, April 08, 2010 3:31 PM > *To:* Shahram Davari > *Cc:* mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; > pwe3@ietf.org > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > Dear Shahram, > I share your concern regarding applicability of E-LSP in packet transport > network. Though the document is about the Transport Profile, references to > MPLS-TP as packet transport network technology been changed recently. Now > MPLS-TP is referred as "packet network". It is my understanding that > applicability of MPLS-TP functionality, features and capabilities to the > packet transport network will be decided later, separately. > Regarding classes of service in the transport. Neil Harrison pointed > several times that a connection, transport path cannot have multiple > classes, otherwise it leads to significant increased complexity of OAM, > which has to be (SHOULD) per Class of Service per E-LSP. > > Regards, > Greg > > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrote: > >> Hi Loa, >> >> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As >> we know traditional transport layers only have one CoS. However E-LSP has >> multiple CoS, which can reorder packets (I know that the reorder packets >> belong to different CoS). Additionally the definition of E-LSP OAM and >> performance and protection and availability, etc will be questionable >> (because of carrying multiple CoS). >> >> Therefore I think E-LSP should not be supported in MPLS-TP or at least >> should be discouraged. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Loa Andersson >> Sent: Saturday, April 03, 2010 2:31 AM >> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; >> CCAMP >> Subject: [PWE3] short working group last call on >> draft-ietf-mpls-tp-framework-11 >> >> All, >> >> this is to start a short working group last call on "A Framework >> for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >> >> Please note that this wg last call is limited to verify that comments >> raised during the orevious working group last call and reviews have >> been correctly addressed. >> >> Please sen comments to the mpls-tp mailing list on April 17th, the >> latest. >> >> /Loa >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > --0016e6460744b1ef110483bf158f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear David,
my understanding of pro-active CV/CC when applied to E-LSP i= s that all supported CoS will be run at all time regardless whether a parti= cular class ever used. Though that might be taken care of by a intelligent = OAM implementation. The protection of N L-LSPs might be done through PST to= reduce the bang level.
In my view both methods to do DiffServ in MPLS have proven itself. Both hav= e merits and drawbacks. Both are part of MPLS-TP. Will they be both part of= packet transport?

Regards,
Greg

On Thu, Apr 8, 2010 at 12:45 PM, David Allan I <david.i.allan@ericsson.com><= /span> wrote:
I'm not quite following this=20 argument....
=A0
If I have a number of co-routed paths with different PHBs,=20 I can instantiate a number of L-LSPs, which is a significant amount of stat= e at=20 every hop, or I can instantiate=A0one E-LSP, which is an N:1 compression in= =20 the amount of state in transit nodes.
=A0
The only wrinkle is all PHBs of an E-LSP fate share. But=20 then if I was protecting=A0the L-LSP or the E-LSP version=A0I'd have=20 another 'n' L-LSPs or another E-LSP, and if they were co-routed, th= e majority of=20 failure cases (link cuts) would result in a loud clang as many L-LSPs=A0vs.= =20 one E-LSP was switched (although there would be 'n' signal fail ind= ications=20 internally to contend with).=A0Overall, it sounds to me like an E-LSP may b= e=20 a bit faster there....
=A0
The actual OAM load to instrument them equally is the same.=20 If an E-LSP takes 'n' times the flows to be instumented like 'n= ' L-LSPs=20 so=A0what????=A0=A0I appreciate that the ability to generate per PHB=20 flows may be undesirable for some, but that does not make it a bad=20 idea.
=A0
IMO there is no penalty for supporting E-LSPs and there are=20 measurable benefits. The analysis is flawed.
=A0
my 2 cents
D

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky
Sent:=20 Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc:= =20 mpls@ietf.org; MPLS-= TP ad hoc team; CCAMP; mpls-tp@ietf.org;=20 pwe3@ietf.org
= Subject: Re: [CCAMP] [mpls] [PWE3] short working group=20 last call on draft-ietf-mpls-tp-framework-11

=
Dear Shahram,
I share your concern regarding applicability of= =20 E-LSP in packet transport network. Though the document is about the Transpo= rt=20 Profile, references to MPLS-TP as packet transport network technology been= =20 changed recently. Now MPLS-TP is referred as "packet network". It= is my=20 understanding that applicability of MPLS-TP functionality, features and=20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil Harrison= =20 pointed several times that a connection, transport path cannot have multipl= e=20 classes, otherwise it leads to significant increased complexity of OAM, whi= ch=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari = <davari@broadcom.com> wrote:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are supported in= =20 MPLS-TP. As we know traditional transport layers only have one CoS. Howev= er=20 E-LSP has multiple CoS, which can reorder packets (I know that the reorde= r=20 packets belong to different CoS). Additionally the definition of E-LSP OA= M and=20 performance and protection and availability, etc will be questionable (be= cause=20 of carrying multiple CoS).

Therefore I think E-LSP should not be= =20 supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]= On Behalf Of=20 Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad h= oc team; pwe3@ietf.org; CCAMP
Subject: [PWE3] short=20 working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start a sho= rt=20 working group last call on "A Framework
for MPLS in Transport Net= works"=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg last c= all=20 is limited to verify that comments
raised during the orevious working = group=20 last call and reviews have
been correctly addressed.

Please sen= =20 comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr=20 Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:=20 +46 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0+46 767 72 92=20 13
_______________________________________________
pwe3 mailing=20 list
pwe3@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/pwe3


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


--0016e6460744b1ef110483bf158f-- From jdrake@juniper.net Thu Apr 8 12:58:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BBA3A68F3; Thu, 8 Apr 2010 12:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9413GO8kmBU6; Thu, 8 Apr 2010 12:58:17 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id B5C613A698D; Thu, 8 Apr 2010 12:58:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKS741SeVHa53qaHr1ZEXKocUGdAEDmCG5@postini.com; Thu, 08 Apr 2010 12:58:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 8 Apr 2010 12:56:16 -0700 From: John E Drake To: Shahram Davari , Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team , "pwe3@ietf.org" , CCAMP Date: Thu, 8 Apr 2010 12:56:14 -0700 Thread-Topic: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAGqaWbAAAG/tQAAA2Kjg Message-ID: <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:58:18 -0000 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, April 08, 2010 12:30 PM > To: John E Drake; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP > ad hoc team; pwe3@ietf.org; CCAMP > Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf- > mpls-tp-framework-11 >=20 > Hi John, >=20 > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP [JD]=20 I think that might be gilding the lily. Since, except for the buffer, queu= ing, and scheduling, the eight are tightly coupled, one CV/CC is probably f= ine. Performance monitoring by PHB is probably a good thing. > and if any of > them fail do protection switching for all of them? What will be the > definition of availability for such E-LSP? >=20 > Thanks > SD >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, April 08, 2010 12:21 PM > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS- > TP ad hoc team; pwe3@ietf.org; CCAMP > Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf- > mpls-tp-framework-11 >=20 > Sharam, >=20 > We have been through this at least twice before. The best way to think E= - > LSPs is that the former EXP bits in the header are part of an extended > label. So you effectively have eight parallel LSPs and there is no packe= t > re-ordering within each. >=20 > Dave said he would mention something about OAM per parallel LSP in the > framework in response to a last call comment I made. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Shahram Davari > > Sent: Thursday, April 08, 2010 12:00 PM > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team= ; > > pwe3@ietf.org; CCAMP > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. > As > > we know traditional transport layers only have one CoS. However E-LSP > has > > multiple CoS, which can reorder packets (I know that the reorder packet= s > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org= ; > > CCAMP > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 From gregimirsky@gmail.com Thu Apr 8 13:09:53 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E743A6A7A; Thu, 8 Apr 2010 13:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUawCYmU+QEy; Thu, 8 Apr 2010 13:09:52 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9868E3A679C; Thu, 8 Apr 2010 13:09:51 -0700 (PDT) Received: by gyh4 with SMTP id 4so1376226gyh.31 for ; Thu, 08 Apr 2010 13:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=gNen0YeiOfXWMvok2hWTFyO71Ax2b1afONifWG2zA/E=; b=gCWYTUUB7zq0EgMaqpv3TXT4A4r65cjL2zd76BKe6PLWTdKBNhgBApavAOtgh608p5 cENN9w8DVorAMkqh3rNTnq2jI+U5fOEqgsMuS/fPgPU0r+GpZVYAbS6C0qpclf/ZMJRW u/T3bOoWr6Nw74epmaZvmpztI+f4AuG4NCg90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VmnIFCQdDzzYOS6x6qKnEgDsHP7J8pYUe0VQtukg346JHtNM0B1QL+AreYihLLudwP SpPuvvgHnkZXfvhWfXfx6blszTR/ckRnzHkagLb8/Gn1IleiN3IdC2sL6+y+Ku1ajM4j DLaV7sW7MHQyB91/xnIggtaSDYQojjLEmZJO0= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Thu, 8 Apr 2010 13:09:40 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> Date: Thu, 8 Apr 2010 13:09:40 -0700 Received: by 10.90.5.24 with SMTP id 24mr174060age.47.1270757380762; Thu, 08 Apr 2010 13:09:40 -0700 (PDT) Message-ID: From: Greg Mirsky To: John E Drake Content-Type: multipart/alternative; boundary=0016364d283f46ad530483bf4219 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:09:53 -0000 --0016364d283f46ad530483bf4219 Content-Type: text/plain; charset=ISO-8859-1 Dear John, I think that especially because of all things you've mentioned "... except for the buffer, queuing, and scheduling, ..." even CV/CC will have to be ran per CoS. Otherwise, CV/CC be ignoring PHB. It might be unlikely situation unless operator oversubscribes resources. I'd "be prepared". Regards, Greg On Thu, Apr 8, 2010 at 12:56 PM, John E Drake wrote: > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, April 08, 2010 12:30 PM > > To: John E Drake; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; > MPLS-TP > > ad hoc team; pwe3@ietf.org; CCAMP > > Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi John, > > > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP > [JD] > > I think that might be gilding the lily. Since, except for the buffer, > queuing, and scheduling, the eight are tightly coupled, one CV/CC is > probably fine. Performance monitoring by PHB is probably a good thing. > > > and if any of > > them fail do protection switching for all of them? What will be the > > definition of availability for such E-LSP? > > > > Thanks > > SD > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, April 08, 2010 12:21 PM > > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; > MPLS- > > TP ad hoc team; pwe3@ietf.org; CCAMP > > Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Sharam, > > > > We have been through this at least twice before. The best way to think > E- > > LSPs is that the former EXP bits in the header are part of an extended > > label. So you effectively have eight parallel LSPs and there is no > packet > > re-ordering within each. > > > > Dave said he would mention something about OAM per parallel LSP in the > > framework in response to a last call comment I made. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > > Shahram Davari > > > Sent: Thursday, April 08, 2010 12:00 PM > > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc > team; > > > pwe3@ietf.org; CCAMP > > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > > mpls-tp-framework-11 > > > > > > Hi Loa, > > > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. > > As > > > we know traditional transport layers only have one CoS. However E-LSP > > has > > > multiple CoS, which can reorder packets (I know that the reorder > packets > > > belong to different CoS). Additionally the definition of E-LSP OAM and > > > performance and protection and availability, etc will be questionable > > > (because of carrying multiple CoS). > > > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > > should be discouraged. > > > > > > Regards, > > > Shahram > > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > > > Loa Andersson > > > Sent: Saturday, April 03, 2010 2:31 AM > > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > pwe3@ietf.org; > > > CCAMP > > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > > framework-11 > > > > > > All, > > > > > > this is to start a short working group last call on "A Framework > > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > > > Please note that this wg last call is limited to verify that comments > > > raised during the orevious working group last call and reviews have > > > been correctly addressed. > > > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > > latest. > > > > > > /Loa > > > -- > > > > > > > > > Loa Andersson email: > loa.andersson@ericsson.com > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13 > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --0016364d283f46ad530483bf4219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear John,
I think that especially because of all things you've ment= ioned "... except for the buffer, queuing, and scheduling, ..." e= ven CV/CC will have to be ran per CoS. Otherwise, CV/CC be ignoring PHB. It= might be unlikely situation unless operator oversubscribes resources. I= 9;d "be prepared".

Regards,
Greg

On Thu, Apr 8, 2010 = at 12:56 PM, John E Drake <jdrake@juniper.net> wrote:


> -----Original Message-----
> From: Shahram Davari [mailto:da= vari@broadcom.com]
> Sent: Thursday, April 08, 2010 12:30 PM
> To: John E Drake; Loa Andersson; m= pls-tp@ietf.org; mpls@ietf.org; MP= LS-TP
> ad hoc team; pwe3@ietf.org; CCAMP=
> Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf= -
> mpls-tp-framework-11
>
> Hi John,
>
> Thanks. Does that mean one needs to run 8 BFDs on that E-LSP
[JD]

I think that might be gilding the lily. =A0Since, except for the buffer, qu= euing, and scheduling, the eight are tightly coupled, one CV/CC is probably= fine. =A0Performance monitoring by PHB is probably a good thing.

> and if any of
> them fail do protection switching for all of them? What will be the > definition of availability for such E-LSP?
>
> Thanks
> SD
>
> -----Original Message-----
> From: John E Drake [mailto:jdrak= e@juniper.net]
> Sent: Thursday, April 08, 2010 12:21 PM
> To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; = MPLS-
> TP ad hoc team; pwe3@ietf.org; CC= AMP
> Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf= -
> mpls-tp-framework-11
>
> Sharam,
>
> We have been through this at least twice before. =A0The best way to th= ink E-
> LSPs is that the former EXP bits in the header are part of an extended=
> label. =A0So you effectively have eight parallel LSPs and there is no = packet
> re-ordering within each.
>
> Dave said he would mention something about OAM per parallel LSP in the=
> framework in response to a last call comment I made.
>
> Thanks,
>
> John
>
> > -----Original Message-----
> > From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.= org] On Behalf Of
> > Shahram Davari
> > Sent: Thursday, April 08, 2010 12:00 PM
> > To: Loa Andersson; mpls-tp@ie= tf.org; mpls@ietf.org; MPLS-TP ad = hoc team;
> > pwe3@ietf.org; CCAMP
> > Subject: Re: [mpls] [PWE3] short working group last call on draft= -ietf-
> > mpls-tp-framework-11
> >
> > Hi Loa,
> >
> > The draft mentions that both L-LSP and E-LSP are supported in MPL= S-TP.
> As
> > we know traditional transport layers only have one CoS. However E= -LSP
> has
> > multiple CoS, which can reorder packets (I know that the reorder = packets
> > belong to different CoS). Additionally the definition of E-LSP OA= M and
> > performance and protection and availability, etc will be question= able
> > (because of carrying multiple CoS).
> >
> > Therefore I think E-LSP should not be supported in MPLS-TP or at = least
> > should be discouraged.
> >
> > Regards,
> > Shahram
> >
> > -----Original Message-----
> > From: pwe3-bounces@ietf.= org [mailto:pwe3-bounces@ietf.= org] On Behalf Of
> > Loa Andersson
> > Sent: Saturday, April 03, 2010 2:31 AM
> > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org;
> > CCAMP
> > Subject: [PWE3] short working group last call on draft-ietf-mpls-= tp-
> > framework-11
> >
> > All,
> >
> > this is to start a short working group last call on "A Frame= work
> > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framewor= k-11).
> >
> > Please note that this wg last call is limited to verify that comm= ents
> > raised during the orevious working group last call and reviews ha= ve
> > been correctly addressed.
> >
> > Please sen comments to the mpls-tp mailing list on April 17th, th= e
> > latest.
> >
> > /Loa
> > --
> >
> >
> > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ema= il: loa.andersson@ericsson.co= m
> > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
> > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p= hone: +46 10 717 52 13
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www.ietf.org/mailman/listinfo/pwe3
> >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
>

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

--0016364d283f46ad530483bf4219-- From david.i.allan@ericsson.com Thu Apr 8 13:11:31 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D9B3A6927; Thu, 8 Apr 2010 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ICH420bGoV2; Thu, 8 Apr 2010 13:11:28 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6206D3A697A; Thu, 8 Apr 2010 13:11:28 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o38KFRA4030623; Thu, 8 Apr 2010 15:15:28 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 8 Apr 2010 16:11:22 -0400 From: David Allan I To: Greg Mirsky Date: Thu, 8 Apr 2010 16:11:19 -0400 Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrXVb8ATDKsAoqoQFinAoaIJUcPQAAAM6hw Message-ID: <60C093A41B5E45409A19D42CF7786DFD4F9953DC3B@EUSAACMS0703.eamcs.ericsson.se> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD4F9953DC3BEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:11:31 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD4F9953DC3BEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg: yes there is a ying and yang to this. But "a" PST that could stunt double for many L-LSPs would have to be an E-L= SP itself. else an L-LSP matching the highest PHB of the set of L-LSPs carr= ied. The alternative being 'n' PSTs. So you end up with either undifferenti= ated treatment of the original set of L-LSPs or 2x'N' OAM flows no matter h= ow you cut it. .... I agree that for E-LSPs additional intelligence/configuration would be need= ed to only instrument the PHBs that were geninue bearers... Meanwhile, I believe this dialog started because both methods are already i= n packet transport, at least as being specified by this effort. That was be= ing questioned. cheers D ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Thursday, April 08, 2010 3:57 PM To: David Allan I Cc: Shahram Davari; mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf= .org; pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-i= etf-mpls-tp-framework-11 Dear David, my understanding of pro-active CV/CC when applied to E-LSP is that all supp= orted CoS will be run at all time regardless whether a particular class eve= r used. Though that might be taken care of by a intelligent OAM implementat= ion. The protection of N L-LSPs might be done through PST to reduce the ban= g level. In my view both methods to do DiffServ in MPLS have proven itself. Both hav= e merits and drawbacks. Both are part of MPLS-TP. Will they be both part of= packet transport? Regards, Greg On Thu, Apr 8, 2010 at 12:45 PM, David Allan I > wrote: I'm not quite following this argument.... If I have a number of co-routed paths with different PHBs, I can instantiat= e a number of L-LSPs, which is a significant amount of state at every hop, = or I can instantiate one E-LSP, which is an N:1 compression in the amount o= f state in transit nodes. The only wrinkle is all PHBs of an E-LSP fate share. But then if I was prot= ecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or anothe= r E-LSP, and if they were co-routed, the majority of failure cases (link cu= ts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched = (although there would be 'n' signal fail indications internally to contend = with). Overall, it sounds to me like an E-LSP may be a bit faster there.... The actual OAM load to instrument them equally is the same. If an E-LSP tak= es 'n' times the flows to be instumented like 'n' L-LSPs so what???? I app= reciate that the ability to generate per PHB flows may be undesirable for s= ome, but that does not make it a bad idea. IMO there is no penalty for supporting E-LSPs and there are measurable bene= fits. The analysis is flawed. my 2 cents D ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, April 08, 2010 3:31 PM To: Shahram Davari Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-t= p@ietf.org; pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-i= etf-mpls-tp-framework-11 Dear Shahram, I share your concern regarding applicability of E-LSP in packet transport n= etwork. Though the document is about the Transport Profile, references to M= PLS-TP as packet transport network technology been changed recently. Now MP= LS-TP is referred as "packet network". It is my understanding that applicab= ility of MPLS-TP functionality, features and capabilities to the packet tra= nsport network will be decided later, separately. Regarding classes of service in the transport. Neil Harrison pointed severa= l times that a connection, transport path cannot have multiple classes, oth= erwise it leads to significant increased complexity of OAM, which has to be= (SHOULD) per Class of Service per E-LSP. Regards, Greg On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari > wrote: Hi Loa, The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As w= e know traditional transport layers only have one CoS. However E-LSP has mu= ltiple CoS, which can reorder packets (I know that the reorder packets belo= ng to different CoS). Additionally the definition of E-LSP OAM and performa= nce and protection and availability, etc will be questionable (because of c= arrying multiple CoS). Therefore I think E-LSP should not be supported in MPLS-TP or at least shou= ld be discouraged. Regards, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framewo= rk-11 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_60C093A41B5E45409A19D42CF7786DFD4F9953DC3BEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Greg:
 
yes there is a ying and yang to this.
 
But "a" PST that could stunt double for many L-LSP= s would=20 have to be an E-LSP itself. else an L-LSP matching the highest PHB of the s= et of=20 L-LSPs carried. The alternative being 'n' PSTs. So you end up wit= h=20 either undifferentiated treatment of the original set of L-LSPs or 2x'N' OA= M=20 flows no matter how you cut it. ....
 
I agree that for E-LSPs additional=20 intelligence/configuration would be needed to only instrument the PHBs that= were=20 geninue bearers...
 
Meanwhile, I believe this dialog started because b= oth=20 methods are already in packet transport, at least as being specified by thi= s=20 effort. That was being questioned.
 
cheers
D

From: Greg Mirsky [mailto:gregimirsky@g= mail.com]=20
Sent: Thursday, April 08, 2010 3:57 PM
To: David Allan= =20 I
Cc: Shahram Davari; mpls@ietf.org; MPLS-TP ad hoc team; CCAMP;= =20 mpls-tp@ietf.org; pwe3@ietf.org
Subject: Re: [CCAMP] [mpls] [PWE3= ]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

Dear David,
my understanding of pro-active CV/CC when applied= to=20 E-LSP is that all supported CoS will be run at all time regardless whether = a=20 particular class ever used. Though that might be taken care of by a intelli= gent=20 OAM implementation. The protection of N L-LSPs might be done through PST to= =20 reduce the bang level.
In my view both methods to do DiffServ in MPLS ha= ve=20 proven itself. Both have merits and drawbacks. Both are part of MPLS-TP. Wi= ll=20 they be both part of packet transport?

Regards,
Greg

On Thu, Apr 8, 2010 at 12:45 PM, David Allan I <david.i.allan@ericsson.com&g= t;=20 wrote:
I'm not=20 quite following this argument....
 
If I have=20 a number of co-routed paths with different PHBs, I can instantiate a numb= er of=20 L-LSPs, which is a significant amount of state at every hop, or I can=20 instantiate one E-LSP, which is an N:1 compression in the amount of = state=20 in transit nodes.
 
The only=20 wrinkle is all PHBs of an E-LSP fate share. But then if I was=20 protecting the L-LSP or the E-LSP version I'd have another 'n'= =20 L-LSPs or another E-LSP, and if they were co-routed, the majority of fail= ure=20 cases (link cuts) would result in a loud clang as many L-LSPs vs. on= e=20 E-LSP was switched (although there would be 'n' signal fail indications=20 internally to contend with). Overall, it sounds to me like an E-LSP = may=20 be a bit faster there....
 
The actual=20 OAM load to instrument them equally is the same. If an E-LSP takes 'n' ti= mes=20 the flows to be instumented like 'n' L-LSPs so what????  I= =20 appreciate that the ability to generate per PHB flows may be undesirable = for=20 some, but that does not make it a bad idea.
 
IMO there=20 is no penalty for supporting E-LSPs and there are measurable benefits. Th= e=20 analysis is flawed.
 
my 2=20 cents
D

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf= .org]=20 On Behalf Of Greg Mirsky
Sent: Thursday, April 08, 2010 = 3:31=20 PM
To: Shahram Davari
Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; pwe3@ietf.org
Sub= ject:=20 Re: [CCAMP] [mpls] [PWE3] short working group last call on=20 draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability = of=20 E-LSP in packet transport network. Though the document is about the Trans= port=20 Profile, references to MPLS-TP as packet transport network technology bee= n=20 changed recently. Now MPLS-TP is referred as "packet network". It is my=20 understanding that applicability of MPLS-TP functionality, features and=20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil Harris= on=20 pointed several times that a connection, transport path cannot have multi= ple=20 classes, otherwise it leads to significant increased complexity of OAM, w= hich=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari = <davari@broadcom.com> wrote:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are supported = in=20 MPLS-TP. As we know traditional transport layers only have one CoS. How= ever=20 E-LSP has multiple CoS, which can reorder packets (I know that the reor= der=20 packets belong to different CoS). Additionally the definition of E-LSP = OAM=20 and performance and protection and availability, etc will be questionab= le=20 (because of carrying multiple CoS).

Therefore I think E-LSP shou= ld=20 not be supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf= .org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa AnderssonSent:=20 Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org;=20 CCAMP
Subject: [PWE3] short working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start a s= hort=20 working group last call on "A Framework
for MPLS in Transport Networ= ks"=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg last= call=20 is limited to verify that comments
raised during the orevious workin= g=20 group last call and reviews have
been correctly addressed.

Pl= ease=20 sen comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson    = =20                     e= mail:=20 loa.andersson@ericsson.com
Sr Strategy and Stand= ards=20 Manager            loa@pi.nu
Ericsson Inc       &nbs= p;=20                  phone: +4= 6 10=20 717 52 13
                &n= bsp;=20                     &= nbsp;=20      +46 767 72 92=20 13
_______________________________________________
pwe3 mailing=20 list
pwe3@ietf.org<= /A>
https://www.ietf.org/mailman/listinfo/pwe3

<= BR>
_______________________________________________
mpls=20 mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


--_000_60C093A41B5E45409A19D42CF7786DFD4F9953DC3BEUSAACMS0703e_-- From venkatflex@gmail.com Thu Apr 8 13:12:35 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93153A6AD3; Thu, 8 Apr 2010 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRzX7RSypsVb; Thu, 8 Apr 2010 13:12:32 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 336093A6AE6; Thu, 8 Apr 2010 13:12:25 -0700 (PDT) Received: by pwj2 with SMTP id 2so2309169pwj.31 for ; Thu, 08 Apr 2010 13:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=86Sy/z90FqHiMuAOIQdRRTFvdc84i15Jm6xszhZ8M9w=; b=mITtx9ZW68xDzBky99BrbGyM/u8wZcb2kbYdX3mDK/XPFHE5l3La/voPilMYxn4Qi3 Z0nPz8EiXoFsJCaXkw0g9WC4qSzRq2n151zJ88XL/n3sJfLVVJv29CVQOt/K+M3zvVC5 kiRKfSInqB/cG9aKBjGI8Mn4HWMZOmbNxBSvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WjxHcbhqUNWYLCFgcv5RszEUm/0j8O7e+2b7CNkonr9zGHMzhL9JTn8spgIHpLSpUS PrP0IKr0qH0bQhDk5MNIlMa5AikOPxPQTsuyt9di9P0mG6FEeK1GF6abWc2CiNOdHN7s WsJNWpT2b6dRZxk20lP73GIUTWf1Ol3Rv1ndk= MIME-Version: 1.0 Received: by 10.142.111.8 with HTTP; Thu, 8 Apr 2010 13:12:17 -0700 (PDT) Date: Fri, 9 Apr 2010 01:42:17 +0530 Received: by 10.142.196.21 with SMTP id t21mr459186wff.237.1270757537460; Thu, 08 Apr 2010 13:12:17 -0700 (PDT) Message-ID: From: venkatesan mahalingam To: mpls-tp@ietf.org, mpls Content-Type: multipart/alternative; boundary=000e0cd32f509db43b0483bf4be6 Subject: [mpls] MPLS-TP NON-IP Tunnel MIB changes X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:12:35 -0000 --000e0cd32f509db43b0483bf4be6 Content-Type: text/plain; charset=ISO-8859-1 Hi, Anybody started working on MPLS-TP tunnel MIB related changes for non IP based LSPs? I'm looking forward to work with you guys. -- Best Regards, Venkatesan Mahalingam. --000e0cd32f509db43b0483bf4be6 Content-Type: text/html; charset=ISO-8859-1 Hi,
Anybody started working on MPLS-TP tunnel MIB related changes for non IP based LSPs?

I'm looking forward to work with you guys.

--
Best Regards,
Venkatesan Mahalingam.
--000e0cd32f509db43b0483bf4be6-- From venkatflex@gmail.com Thu Apr 8 13:40:13 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460C228C10F; Thu, 8 Apr 2010 13:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkZZiOV--627; Thu, 8 Apr 2010 13:40:12 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id DFB2C28C0DE; Thu, 8 Apr 2010 13:40:10 -0700 (PDT) Received: by pzk29 with SMTP id 29so2327886pzk.29 for ; Thu, 08 Apr 2010 13:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=nXknSHUQlSpQL/XYKpr1AqfTnRNJk68+mRJ/+5SkQvY=; b=uo8FNKj8gsBnEiZnBbPaK1SmhOlXRUtkbvqCZdPFonra4LRf+EV2+JHkISVmtOjD1m 9nCokF9jvkjjAAv79gkx7EyUmGRPGMHqXtwUEkYCVAbeOx/K9ef6KxVlDKKAphYCvcCa +rMAT2IAOF7ywOiMd6Kn/6JIOZ1mL/ULTOKic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ThaauoQwJ/8xCTtXgHBDgkyl0EQL8cEDHfmL265YNHqgTuCmLbMxwQYY5tvbujtCnh 21+J05EuPyYdaojAhPO9jZ/deYok5uIcDhRHLpT9sdZ1JdYqi+o9nOx8UPJ7JBr1+vgm ihhoP68tyGtLKcPp570cpF5Spue3iqdmo66fE= MIME-Version: 1.0 Received: by 10.142.111.8 with HTTP; Thu, 8 Apr 2010 13:40:05 -0700 (PDT) Date: Fri, 9 Apr 2010 02:10:05 +0530 Received: by 10.142.201.11 with SMTP id y11mr497133wff.118.1270759205379; Thu, 08 Apr 2010 13:40:05 -0700 (PDT) Message-ID: From: venkatesan mahalingam To: mpls , mpls-tp@ietf.org Content-Type: multipart/alternative; boundary=000e0cd32a9a081da10483bfaff9 Subject: [mpls] Global_ID or ICC for operator identification - Why not just Global_ID? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:40:13 -0000 --000e0cd32a9a081da10483bfaff9 Content-Type: text/plain; charset=ISO-8859-1 HI, In the draft draft-ietf-mpls-tp-identifiers-01, Is there any dependency to use either Global Id or ICC for operator identification? Can't we just use Global_ID to uniquely identify an operator? Best Regards, Venkatesan Mahalingam. --000e0cd32a9a081da10483bfaff9 Content-Type: text/html; charset=ISO-8859-1 
HI,

In the draft draft-ietf-mpls-tp-identifiers-01, 
Is there any dependency to use either Global Id or ICC for operator identification? Can't we just use Global_ID to uniquely identify an operator?

Best Regards,
Venkatesan Mahalingam.
--000e0cd32a9a081da10483bfaff9-- From gregimirsky@gmail.com Thu Apr 8 18:38:27 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3B43A67C2; Thu, 8 Apr 2010 18:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hwcAhCtTnkW; Thu, 8 Apr 2010 18:38:26 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id D01043A659C; Thu, 8 Apr 2010 18:38:25 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so957084qwb.31 for ; Thu, 08 Apr 2010 18:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=J/swuOVojHLOLn5Pyzu/RSiwCjMaSXlN99ayrFLf7XM=; b=UaoHqsI7em5e76MPrVTxz4dp49SMDsIAJLhbm/QWKtlmwFaH8pxYlkf4Dg8jBDhcT1 2CdarROpSD5v8n0yRuWZqHrMIJlgySQ/HmGuH/4NVjuzoYdaJSJHYhDJ034fmGJCoo0p SKnAn4/DY6i7vCxSJPTlKbgGNqYInjHGbzzNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fS3lnnn9TfO8hzvj7DutbKgcDq4tQR/w+7wXOo7S8IBktieBjj0evnggHV84s1VD+8 QnrvkJo/9f1pmw/oWA7I3qNldMAMXyn468l/HpteVsCs6fb0V/Um8QP73akOEEQxYYBS N8Sq2T5bm/VHcUyy+yOzyvfFfE+VgHHavewaw= MIME-Version: 1.0 Received: by 10.224.28.129 with HTTP; Thu, 8 Apr 2010 18:38:19 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 8 Apr 2010 18:38:19 -0700 Received: by 10.224.49.77 with SMTP id u13mr372542qaf.363.1270777099528; Thu, 08 Apr 2010 18:38:19 -0700 (PDT) Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=001485e7c9469b2afe0483c3d9da Cc: MPLS-TP ad hoc team , "mpls@ietf.org" , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 01:38:27 -0000 --001485e7c9469b2afe0483c3d9da Content-Type: text/plain; charset=ISO-8859-1 Dear Shahram, I agree that defining criteria for E-LSP availability as function of per-CoS availability is not a trivial task. I would say that an operator should be given flexibility to weight differently availability of individual CoS of a particular E-LSP (or that could be per specified group, domain). That is implementation detail, but in a PM document we might say that it is a function of per-CoS measured availabilities. Regards, Greg On Thu, Apr 8, 2010 at 12:30 PM, Shahram Davari wrote: > Hi John, > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of > them fail do protection switching for all of them? What will be the > definition of availability for such E-LSP? > > Thanks > SD > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, April 08, 2010 12:21 PM > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; > MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP > Subject: RE: [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > Sharam, > > We have been through this at least twice before. The best way to think > E-LSPs is that the former EXP bits in the header are part of an extended > label. So you effectively have eight parallel LSPs and there is no packet > re-ordering within each. > > Dave said he would mention something about OAM per parallel LSP in the > framework in response to a last call comment I made. > > Thanks, > > John > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Shahram Davari > > Sent: Thursday, April 08, 2010 12:00 PM > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > > pwe3@ietf.org; CCAMP > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > > we know traditional transport layers only have one CoS. However E-LSP has > > multiple CoS, which can reorder packets (I know that the reorder packets > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > > CCAMP > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --001485e7c9469b2afe0483c3d9da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Shahram,
I agree that defining criteria for E-LSP availability as f= unction of per-CoS availability is not a trivial task. I would say that an = operator should be given flexibility to weight differently availability of = individual CoS of a particular E-LSP (or that could be per specified group,= domain). That is implementation detail, but in a PM document we might say = that it is a function of per-CoS measured availabilities.

Regards,
Greg

On Thu, Apr 8, 2010 = at 12:30 PM, Shahram Davari <davari@broadcom.com> wrote:
Hi John,

Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of = them fail do protection switching for all of them? What will be the definit= ion of availability for such E-LSP?

Thanks
SD

-----Original Message-----
From: John E Drake [mailto:jdrake@jun= iper.net]
Sent: Thursday, April 08, 2010 12:21 PM
To: Shahram Davari; Loa Andersson; mpls= -tp@ietf.org; mpls@ietf.org; MPLS-= TP ad hoc team; pwe3@ietf.org; CCAMP Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf-mpls= -tp-framework-11

Sharam,

We have been through this at least twice before. =A0The best way to think E= -LSPs is that the former EXP bits in the header are part of an extended lab= el. =A0So you effectively have eight parallel LSPs and there is no packet r= e-ordering within each.

Dave said he would mention something about OAM per parallel LSP in the fram= ework in response to a last call comment I made.

Thanks,

John

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Shahram Davari
> Sent: Thursday, April 08, 2010 12:00 PM
> To: Loa Andersson; mpls-tp@ietf.or= g; mpls@ietf.org; MPLS-TP ad hoc t= eam;
> pwe3@ietf.org; CCAMP
> Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf= -
> mpls-tp-framework-11
>
> Hi Loa,
>
> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP.= As
> we know traditional transport layers only have one CoS. However E-LSP = has
> multiple CoS, which can reorder packets (I know that the reorder packe= ts
> belong to different CoS). Additionally the definition of E-LSP OAM and=
> performance and protection and availability, etc will be questionable<= br> > (because of carrying multiple CoS).
>
> Therefore I think E-LSP should not be supported in MPLS-TP or at least=
> should be discouraged.
>
> Regards,
> Shahram
>
> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Loa Andersson
> Sent: Saturday, April 03, 2010 2:31 AM
> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org;
> CCAMP
> Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11
>
> All,
>
> this is to start a short working group last call on "A Framework<= br> > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11)= .
>
> Please note that this wg last call is limited to verify that comments<= br> > raised during the orevious working group last call and reviews have > been correctly addressed.
>
> Please sen comments to the mpls-tp mailing list on April 17th, the
> latest.
>
> /Loa
> --
>
>
> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: <= a href=3D"mailto:loa.andersson@ericsson.com">loa.andersson@ericsson.com=
> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:= +46 10 717 52 13
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


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

--001485e7c9469b2afe0483c3d9da-- From curtis@occnc.com Thu Apr 8 21:18:48 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964283A67C1; Thu, 8 Apr 2010 21:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3WeiCr+fHHj; Thu, 8 Apr 2010 21:18:46 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 4D18828C0FE; Thu, 8 Apr 2010 21:18:38 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o394ISEo090151; Fri, 9 Apr 2010 00:18:28 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004090418.o394ISEo090151@harbor.orleans.occnc.com> To: John E Drake From: Curtis Villamizar In-reply-to: Your message of "Thu, 08 Apr 2010 12:20:36 PDT." <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> Date: Fri, 09 Apr 2010 00:18:28 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 04:18:48 -0000 In message <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> John E Drake writes: > > Sharam, > > We have been through this at least twice before. The best way to think E-LSPs is that the former EXP bits in the header are part of an extended label. So you effectively have eight parallel LSPs and there is no packet re-ordering within each. > > Dave said he would mention something about OAM per parallel LSP in > the framework in response to a last call comment I made. > > Thanks, > > John John, Anyone using AF service would be very mad at you if you reordered based on TC bits aka EXP. Groups of TC values remain ordered. For AF it is a group of 3. For the old IPprec (CS service) it is 8 discrete PHB and each remains ordered but the higher priorities can get queued first. But otherwise I agree. QoS is important. Curtis > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Shahram Davari > > Sent: Thursday, April 08, 2010 12:00 PM > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > > pwe3@ietf.org; CCAMP > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > > we know traditional transport layers only have one CoS. However E-LSP has > > multiple CoS, which can reorder packets (I know that the reorder packets > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > > CCAMP > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From curtis@occnc.com Thu Apr 8 21:30:17 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B8728C10F; Thu, 8 Apr 2010 21:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJHobEDn0ddi; Thu, 8 Apr 2010 21:30:16 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 03BA028C0FD; Thu, 8 Apr 2010 21:30:15 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o394U91l090288; Fri, 9 Apr 2010 00:30:09 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004090430.o394U91l090288@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Thu, 08 Apr 2010 12:30:03 PDT." <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 09 Apr 2010 00:30:09 -0400 Sender: curtis@occnc.com Cc: MPLS-TP ad hoc team , "mpls@ietf.org" , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 04:30:17 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi John, > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if > any of them fail do protection switching for all of them? What will be > the definition of availability for such E-LSP? > > Thanks > SD If there were multiple priorities on an LSP the OAM should be at a high priority. For example for CS service (the old IP prec) CS6 is normally used for control traffic. If OAM failed for CS6 the link is down. If OAM fails for CS0 the link may just be oversubscribed and contested but CS0 is defined as the best effort (BE) service. A provider may choose to do this. For example, if VOIP ran at CS4 and worked fine and web and email was runnig on CS0, phone would work and web would be slow. If a natural disaster took out 3/4 of the network capacity, then having working phone and slow web and maybe unworkable web streaming video might be better than prohibiting oversubscription and having no service at all. Curtis From curtis@occnc.com Thu Apr 8 21:44:47 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B763A692C for ; Thu, 8 Apr 2010 21:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZlTpzYpS4R1 for ; Thu, 8 Apr 2010 21:44:47 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 91D8F3A67BD for ; Thu, 8 Apr 2010 21:44:47 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o394ifjd090514; Fri, 9 Apr 2010 00:44:41 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004090444.o394ifjd090514@harbor.orleans.occnc.com> To: Greg Mirsky From: Curtis Villamizar In-reply-to: Your message of "Thu, 08 Apr 2010 12:30:59 PDT." Date: Fri, 09 Apr 2010 00:44:41 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 04:44:48 -0000 In message Greg Mirsky writes: > > > Dear Shahram, > > I share your concern regarding applicability of E-LSP in packet > transport network. Though the document is about the Transport Profile, > references to MPLS-TP as packet transport network technology been > changed recently. Now MPLS-TP is referred as "packet network". It is > my understanding that applicability of MPLS-TP functionality, features > and capabilities to the packet transport network will be decided > later, separately. Regarding classes of service in the > transport. Neil Harrison pointed several times that a connection, > transport path cannot have multiple classes, otherwise it leads to > significant increased complexity of OAM, which has to be (SHOULD) per > Class of Service per E-LSP. > > Regards, > Greg Greg, Reality check! MPLS-TP needs to: Provide an ability to deliver a service that has the characteristis of a transport network should anyone decide to use it that way. Also provide a solution that has certain important characteristis of a transport network but eliminates the characteristis of a transport network that make it not cost effective. Among the things that need to go is a hard guarentee on bandwidth for every service, including the lowest priority services. Otherwise we might as well just use circuits or allocate time slots to fixed sized MPLS packets. Curtis > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrote: > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > > we know traditional transport layers only have one CoS. However E-LSP has > > multiple CoS, which can reorder packets (I know that the reorder packets > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > > CCAMP > > Subject: [PWE3] short working group last call on > > draft-ietf-mpls-tp-framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:01:57 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866B13A6877; Fri, 9 Apr 2010 00:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3ug0oZoE8s7; Fri, 9 Apr 2010 00:01:56 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 4B2473A67EB; Fri, 9 Apr 2010 00:01:54 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3971520028616; Fri, 9 Apr 2010 09:01:46 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:01:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7B2.77A8BB2D" Date: Fri, 9 Apr 2010 09:05:04 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B232F@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Global_ID or ICC for operator identification - Why notjust Global_ID? thread-index: AcrXW7NPDcVyx/MdSUuB+DUsxsB7OQAVuRiw References: From: "BUSI ITALO" To: "venkatesan mahalingam" X-OriginalArrivalTime: 09 Apr 2010 07:01:24.0810 (UTC) FILETIME=[77D552A0:01CAD7B2] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: mpls , mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Global_ID or ICC for operator identification - Why notjust Global_ID? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:01:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD7B2.77A8BB2D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Venkatesan, =20 in all the other ITU-T transport technologies the ICC is used for = operator identification. =20 When MPLS-TP is deployed with other ITU-T transport networks, the ICC = will be used for operator identification. =20 Italo=20 P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of venkatesan mahalingam Sent: gioved=EC 8 aprile 2010 22.40 To: mpls; mpls-tp@ietf.org Subject: [mpls-tp] Global_ID or ICC for operator identification - Why = notjust Global_ID? =09 =09 HI, =09 In the draft draft-ietf-mpls-tp-identifiers-01,=20 Is there any dependency to use either Global Id or ICC for operator = identification? Can't we just use Global_ID to uniquely identify an = operator? =09 =09 Best Regards, Venkatesan Mahalingam. =09 ------_=_NextPart_001_01CAD7B2.77A8BB2D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Venkatesan,
 
in all the = other ITU-T=20 transport technologies the ICC is used for operator = identification.
 
When = MPLS-TP is deployed=20 with other ITU-T transport networks, the ICC will be used for operator=20 identification.
 
Italo 

P.S. Please note my new email address,=20 Italo.Busi@alcatel-lucent.com, effective since 1 November = 2009.

 

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of venkatesan=20 mahalingam
Sent: gioved=EC 8 aprile 2010 22.40
To: = mpls;=20 mpls-tp@ietf.org
Subject: [mpls-tp] Global_ID or ICC for = operator=20 identification - Why notjust Global_ID?

HI,

In the draft =
draft-ietf-mpls-tp-identifiers-01, 
Is there =
any dependency to use either Global Id or ICC for operator =
identification? Can't we just use Global_ID to uniquely identify an =
operator?

Best Regards,
Venkatesan=20 Mahalingam.
------_=_NextPart_001_01CAD7B2.77A8BB2D-- From venkatflex@gmail.com Fri Apr 9 00:16:30 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F393A68F3; Fri, 9 Apr 2010 00:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs8nyWci1GTk; Fri, 9 Apr 2010 00:16:25 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id 991813A67EC; Fri, 9 Apr 2010 00:16:24 -0700 (PDT) Received: by pzk29 with SMTP id 29so2606033pzk.29 for ; Fri, 09 Apr 2010 00:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=d2vLvHW0VaesWe+NQ3uQ0AWxXOFRIMYKUxWArVwKVkc=; b=lXCixlybrHMTE56odr6wlwJ9OgTsjuz/mcw4g6t1ocMrQBWQyonj0myRDjnTdXafCJ TpjQ+PfPSfs3qecVFXVhVS6dKeoem/Y1sSLKABtiEhL7vgSN+0FgGcc1mrmqml0e1VSk IxVb2BEc8eLbwkY3sX1W5CR5H2P9PKLBFjBKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=af83oS/xgHX+kS2rKrRLMb7CS33lUYRvYutvYp6Pcjw9K0j99kIHuJkyBD5a12MQRW ZZM5+Y2Sk2uKqnIUVoCsYLG3rw3F/QZzRpujm12JPY3gmHZFVK/FfeBNqIykgKzCQ6xh d34eB61iEF0xDvymvselPsHkl0+ZSeoaEHROE= MIME-Version: 1.0 Received: by 10.142.111.8 with HTTP; Fri, 9 Apr 2010 00:16:17 -0700 (PDT) In-Reply-To: <6FD21B53861BF44AA90A288402036AB4030B232F@FRVELSMBS21.ad2.ad.alcatel.com> References: <6FD21B53861BF44AA90A288402036AB4030B232F@FRVELSMBS21.ad2.ad.alcatel.com> Date: Fri, 9 Apr 2010 12:46:17 +0530 Received: by 10.142.119.3 with SMTP id r3mr748678wfc.145.1270797378131; Fri, 09 Apr 2010 00:16:18 -0700 (PDT) Message-ID: From: venkatesan mahalingam To: BUSI ITALO Content-Type: multipart/alternative; boundary=001636e0b6b94e195d0483c892d9 Cc: mpls , mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Global_ID or ICC for operator identification - Why notjust Global_ID? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:16:30 -0000 --001636e0b6b94e195d0483c892d9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable BUSI ITALO, Thanks for your reply. >>When MPLS-TP is deployed with other ITU-T transport networks, the ICC wil= l be used for operator identification. You mean to say MPLS-TP enabled swich should be identified by Global_ID and ICC if the switch needs to be deployed with other ITU-T networks and MPLS-T= P networks. Is this understanding correct? BR, Venkatesan Mahalingam. On Fri, Apr 9, 2010 at 12:35 PM, BUSI ITALO wrote: > Venkatesan, > > in all the other ITU-T transport technologies the ICC is used for operato= r > identification. > > When MPLS-TP is deployed with other ITU-T transport networks, the ICC wil= l > be used for operator identification. > > Italo > > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, > effective since 1 November 2009. > > > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *venkatesan mahalingam > *Sent:* gioved=EC 8 aprile 2010 22.40 > > *To:* mpls; mpls-tp@ietf.org > *Subject:* [mpls-tp] Global_ID or ICC for operator identification - Why > notjust Global_ID? > > HI, > > In the draft draft-ietf-mpls-tp-identifiers-01, > Is there any dependency to use either Global Id or ICC for operator ident= ification? Can't we just use Global_ID to uniquely identify an operator? > > > Best Regards, > Venkatesan Mahalingam. > > --=20 Best Regards, Venkatesan Mahalingam. --001636e0b6b94e195d0483c892d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
BUSI ITALO,
=A0
Thanks for your reply.
=A0
>>When MPLS-TP is deployed with other ITU-T transport netw= orks, the ICC will be used for operator identification.
You mean to say MPLS-TP enabled=A0swich should be identified by = Global_ID and ICC if the switch needs to be deployed with other ITU-= T networks and MPLS-TP networks.
=A0
Is this understanding correct?

BR,
Venkatesan Mahalingam.
On Fri, Apr 9, 2010 at 12:35 PM, BUSI ITALO <Italo.Bu= si@alcatel-lucent.com> wrote:
Venkatesan,
=A0
in all the other ITU-T transport tech= nologies the ICC is used for operator identification.
=A0
When MPLS-TP is deployed with other I= TU-T transport networks, the ICC will be used for operator identification.<= /span>
=A0
Italo=A0

P.S. Please note my new email address, Italo.Busi@alcatel-lucen= t.com, effective since 1 November 2009.

=A0

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] = On Behalf Of venkatesan mahalingam
Sent: gioved=EC 8 aprile 2010 22.40=20

To: mpls; mpls-tp@ietf.org
Subject: [mpls-tp] G= lobal_ID or ICC for operator identification - Why notjust Global_ID?

HI,

In the draft draft-ietf-mpls-tp-identifiers-01, 
Is there any dependency to use either Global Id or ICC for=
 operator identification? Can't we just use Global_ID to uniquely ident=
ify an operator?

Best Regards,
Venkatesan Mahalingam.



--
Best Regar= ds,
Venkatesan Mahalingam.
--001636e0b6b94e195d0483c892d9-- From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:20:59 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67DB13A68F3; Fri, 9 Apr 2010 00:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.915 X-Spam-Level: X-Spam-Status: No, score=-4.915 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGAaZOUhUC1G; Fri, 9 Apr 2010 00:20:56 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 099213A687E; Fri, 9 Apr 2010 00:20:55 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397KUpD011011; Fri, 9 Apr 2010 09:20:45 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:20:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 09:24:25 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B233D@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 thread-index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAIPh/OA= References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> From: "BUSI ITALO" To: "Shahram Davari" , "Loa Andersson" , , , "MPLS-TP ad hoc team" , , "CCAMP" X-OriginalArrivalTime: 09 Apr 2010 07:20:44.0669 (UTC) FILETIME=[2B29C2D0:01CAD7B5] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:20:59 -0000 Shahram, > As we know traditional transport layers only have=20 > one CoS. This is no more the case after Ethernet transport layer has been = developed. > Additionally the definition of E-LSP OAM and=20 > performance and protection and availability, etc will be=20 > questionable (because of carrying multiple CoS). I agree that performance monitoring for multi-CoS connections (e.g., = E-LSP) is not trivial. We have exactly the same issue with Ethernet = performance monitoring. In principle I think that a solution can be defined but I am spending = too much time on mpls-tp standardization so I had not time to monitor = the status of this work within Q14/15. I do not see any issue with fault monitoring of multi-CoS connections as = faults are not per-CoS but per-connection. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Shahram Davari > Sent: gioved=EC 8 aprile 2010 21.00 > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP=20 > ad hoc team; pwe3@ietf.org; CCAMP > Subject: Re: [mpls] [PWE3] short working group last call on=20 > draft-ietf-mpls-tp-framework-11 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in=20 > MPLS-TP. As we know traditional transport layers only have=20 > one CoS. However E-LSP has multiple CoS, which can reorder=20 > packets (I know that the reorder packets belong to different=20 > CoS). Additionally the definition of E-LSP OAM and=20 > performance and protection and availability, etc will be=20 > questionable (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or=20 > at least should be discouraged. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team;=20 > pwe3@ietf.org; CCAMP > Subject: [PWE3] short working group last call on=20 > draft-ietf-mpls-tp-framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A=20 > Framework for MPLS in Transport Networks"=20 > (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that=20 > comments raised during the orevious working group last call=20 > and reviews have been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April=20 > 17th, the latest. >=20 > /Loa > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:24:44 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF12E3A68D4; Fri, 9 Apr 2010 00:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSs65yjvXRn8; Fri, 9 Apr 2010 00:24:42 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 732083A687E; Fri, 9 Apr 2010 00:24:41 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397OR1I013143; Fri, 9 Apr 2010 09:24:32 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:24:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7B5.B219F6C3" Date: Fri, 9 Apr 2010 09:28:11 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B2346@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 thread-index: AcrXUhDmA913Y8gxSkSinQmgQfqgdAAACFZwABjlfWA= References: <4BB70AE7.1020605@pi.nu><2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> From: "BUSI ITALO" To: "David Allan I" , "Greg Mirsky" , "Shahram Davari" X-OriginalArrivalTime: 09 Apr 2010 07:24:31.0542 (UTC) FILETIME=[B263D560:01CAD7B5] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: mpls@ietf.org, CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:24:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD7B5.B219F6C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that running OAM flows per-PHB, while very much appropriate for = PM tools (as already documented in the OAM frameworkd draft), is = actually an overdesign for FM tools. =20 Misconnections and failures are per-LSP and not per-PHB. =20 Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of David Allan I Sent: gioved=EC 8 aprile 2010 21.45 To: Greg Mirsky; Shahram Davari Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; = mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last callon = draft-ietf-mpls-tp-framework-11 =09 =09 I'm not quite following this argument.... =20 If I have a number of co-routed paths with different PHBs, I can = instantiate a number of L-LSPs, which is a significant amount of state = at every hop, or I can instantiate one E-LSP, which is an N:1 = compression in the amount of state in transit nodes. =20 The only wrinkle is all PHBs of an E-LSP fate share. But then if I was = protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or = another E-LSP, and if they were co-routed, the majority of failure cases = (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP = was switched (although there would be 'n' signal fail indications = internally to contend with). Overall, it sounds to me like an E-LSP may = be a bit faster there.... =20 The actual OAM load to instrument them equally is the same. If an E-LSP = takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? = I appreciate that the ability to generate per PHB flows may be = undesirable for some, but that does not make it a bad idea. =20 IMO there is no penalty for supporting E-LSPs and there are measurable = benefits. The analysis is flawed. =20 my 2 cents D ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Greg Mirsky Sent: Thursday, April 08, 2010 3:31 PM To: Shahram Davari Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; = pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on = draft-ietf-mpls-tp-framework-11 =09 =09 Dear Shahram, I share your concern regarding applicability of E-LSP in packet = transport network. Though the document is about the Transport Profile, = references to MPLS-TP as packet transport network technology been = changed recently. Now MPLS-TP is referred as "packet network". It is my = understanding that applicability of MPLS-TP functionality, features and = capabilities to the packet transport network will be decided later, = separately. Regarding classes of service in the transport. Neil Harrison pointed = several times that a connection, transport path cannot have multiple = classes, otherwise it leads to significant increased complexity of OAM, = which has to be (SHOULD) per Class of Service per E-LSP. =09 Regards, Greg =09 =09 On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari = wrote: =09 Hi Loa, =09 The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. = As we know traditional transport layers only have one CoS. However E-LSP = has multiple CoS, which can reorder packets (I know that the reorder = packets belong to different CoS). Additionally the definition of E-LSP = OAM and performance and protection and availability, etc will be = questionable (because of carrying multiple CoS). =09 Therefore I think E-LSP should not be supported in MPLS-TP or at least = should be discouraged. =09 Regards, Shahram =09 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Loa Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; = pwe3@ietf.org; CCAMP Subject: [PWE3] short working group last call on = draft-ietf-mpls-tp-framework-11 =09 All, =09 this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). =09 Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. =09 Please sen comments to the mpls-tp mailing list on April 17th, the latest. =09 /Loa -- =09 =09 Loa Andersson email: = loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 =09 =09 =09 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =09 ------_=_NextPart_001_01CAD7B5.B219F6C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think that running OAM flows per-PHB, while = very much=20 appropriate for PM tools (as already documented in the OAM frameworkd = draft), is=20 actually an overdesign for FM tools.
 
Misconnections and failures are per-LSP and not = per-PHB.
 
Italo

P.S. Please note my new email address,=20 Italo.Busi@alcatel-lucent.com, effective since 1 November = 2009.

 

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of David Allan=20 I
Sent: gioved=EC 8 aprile 2010 21.45
To: Greg = Mirsky;=20 Shahram Davari
Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc = team;=20 pwe3@ietf.org; mpls-tp@ietf.org
Subject: Re: [CCAMP] [mpls] = [PWE3]=20 short working group last callon=20 draft-ietf-mpls-tp-framework-11

I'm not quite following this=20 argument....
 
If I have a number of co-routed paths with = different=20 PHBs, I can instantiate a number of L-LSPs, which is a significant = amount of=20 state at every hop, or I can instantiate one E-LSP, which is an = N:1=20 compression in the amount of state in transit = nodes.
 
The only wrinkle is all PHBs of an E-LSP fate = share. But=20 then if I was protecting the L-LSP or the E-LSP version I'd = have=20 another 'n' L-LSPs or another E-LSP, and if they were co-routed, the = majority=20 of failure cases (link cuts) would result in a loud clang as many=20 L-LSPs vs. one E-LSP was switched (although there would be 'n' = signal=20 fail indications internally to contend with). Overall, it sounds = to me=20 like an E-LSP may be a bit faster there....
 
The actual OAM load to instrument them = equally is the=20 same. If an E-LSP takes 'n' times the flows to be instumented like 'n' = L-LSPs=20 so what????  I appreciate that the ability to generate = per PHB=20 flows may be undesirable for some, but that does not make it a bad=20 idea.
 
IMO there is no penalty for supporting E-LSPs = and there=20 are measurable benefits. The analysis is flawed.
 
my 2 cents
D

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: = Shahram=20 Davari
Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP;=20 mpls-tp@ietf.org; pwe3@ietf.org
Subject: Re: [CCAMP] [mpls] = [PWE3]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding = applicability of=20 E-LSP in packet transport network. Though the document is about the = Transport=20 Profile, references to MPLS-TP as packet transport network technology = been=20 changed recently. Now MPLS-TP is referred as "packet network". It is = my=20 understanding that applicability of MPLS-TP functionality, features = and=20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil = Harrison=20 pointed several times that a connection, transport path cannot have = multiple=20 classes, otherwise it leads to significant increased complexity of = OAM, which=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram = Davari <davari@broadcom.com> = wrote:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are = supported in=20 MPLS-TP. As we know traditional transport layers only have one CoS. = However=20 E-LSP has multiple CoS, which can reorder packets (I know that the = reorder=20 packets belong to different CoS). Additionally the definition of = E-LSP OAM=20 and performance and protection and availability, etc will be = questionable=20 (because of carrying multiple CoS).

Therefore I think E-LSP = should=20 not be supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org = [mailto:pwe3-bounces@ietf.org] On = Behalf Of=20 Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc = team; pwe3@ietf.org; CCAMP
Subject: = [PWE3]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start = a short=20 working group last call on "A Framework
for MPLS in Transport = Networks"=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg = last call=20 is limited to verify that comments
raised during the orevious = working=20 group last call and reviews have
been correctly = addressed.

Please=20 sen comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson   =  =20                   =   email:=20 loa.andersson@ericsson.com=
Sr=20 Strategy and Standards Manager           =  loa@pi.nu
Ericsson Inc   =    =20                   =  phone:=20 +46 10 717 52 13
              =  =20                   =    =20        +46 767 72 92=20 13
_______________________________________________
pwe3 = mailing=20 list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

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

------_=_NextPart_001_01CAD7B5.B219F6C3-- From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:31:08 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B693A696A; Fri, 9 Apr 2010 00:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkTel+NbKrSv; Fri, 9 Apr 2010 00:31:07 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 29A7C3A6944; Fri, 9 Apr 2010 00:31:06 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397Usms008983; Fri, 9 Apr 2010 09:30:56 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:30:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7B6.92E30A5B" Date: Fri, 9 Apr 2010 09:34:28 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B2351@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Global_ID or ICC for operator identification - Why notjust Global_ID? thread-index: AcrXtJCKZ+LVPBciTG+UQRXCeIc6dQAAfM3Q References: <6FD21B53861BF44AA90A288402036AB4030B232F@FRVELSMBS21.ad2.ad.alcatel.com> From: "BUSI ITALO" To: "venkatesan mahalingam" X-OriginalArrivalTime: 09 Apr 2010 07:30:48.0786 (UTC) FILETIME=[933EB320:01CAD7B6] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: mpls , mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Global_ID or ICC for operator identification - Why notjust Global_ID? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:31:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD7B6.92E30A5B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not sure I understand your question. =20 An MPLS-TP enabled switch may be deployed either by a transport = operator, who manages his network according to ITU-T operations, or by = an IP operator, who manages his network according to IP operations. =20 In the latter case, I understand that the Global_ID is likely to be used = to identify the operator while the ICC will be used in the former case. =20 If you are building an MPLS-TP switch addressing both types of operators = you need to support both types of operators' identification. =20 Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 ________________________________ From: venkatesan mahalingam [mailto:venkatflex@gmail.com]=20 Sent: venerd=EC 9 aprile 2010 9.16 To: BUSI ITALO Cc: mpls; mpls-tp@ietf.org Subject: Re: [mpls-tp] Global_ID or ICC for operator identification - = Why notjust Global_ID? =09 =09 BUSI ITALO, =20 Thanks for your reply. =20 >>When MPLS-TP is deployed with other ITU-T transport networks, the ICC = will be used for operator identification. You mean to say MPLS-TP enabled swich should be identified by Global_ID = and ICC if the switch needs to be deployed with other ITU-T networks and = MPLS-TP networks. =20 Is this understanding correct? =09 BR, Venkatesan Mahalingam. =09 On Fri, Apr 9, 2010 at 12:35 PM, BUSI ITALO = wrote: =09 Venkatesan, =20 in all the other ITU-T transport technologies the ICC is used for = operator identification. =20 When MPLS-TP is deployed with other ITU-T transport networks, the ICC = will be used for operator identification. =20 Italo=20 P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =09 =20 ________________________________ =09 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of venkatesan mahalingam =09 Sent: gioved=EC 8 aprile 2010 22.40=20 To: mpls; mpls-tp@ietf.org =09 Subject: [mpls-tp] Global_ID or ICC for operator identification - Why = notjust Global_ID? =09 =09 HI, =09 In the draft draft-ietf-mpls-tp-identifiers-01,=20 Is there any dependency to use either Global Id or ICC for operator = identification? Can't we just use Global_ID to uniquely identify an = operator? =09 =09 =09 Best Regards, Venkatesan Mahalingam. =09 --=20 Best Regards, Venkatesan Mahalingam. =09 ------_=_NextPart_001_01CAD7B6.92E30A5B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am not sure I understand your=20 question.
 
An MPLS-TP enabled switch may be deployed = either by a=20 transport operator, who manages his network according to ITU-T = operations, or by=20 an IP operator, who manages his network according to IP=20 operations.
 
In the latter case, I understand that the = Global_ID is=20 likely to be used to identify the operator while the ICC will be used in = the=20 former case.
 
If=20 you are building an MPLS-TP switch addressing both types of operators = you need=20 to support both types of operators'=20 identification.
 
Italo

P.S. Please note my new email address,=20 Italo.Busi@alcatel-lucent.com, effective since 1 November = 2009.

 

From: venkatesan mahalingam=20 [mailto:venkatflex@gmail.com]
Sent: venerd=EC 9 aprile 2010 = 9.16
To: BUSI ITALO
Cc: mpls;=20 mpls-tp@ietf.org
Subject: Re: [mpls-tp] Global_ID or ICC for = operator identification - Why notjust Global_ID?

BUSI ITALO,
 
Thanks for your reply.
 
>>When MPLS-TP is deployed with other ITU-T transport = networks, the ICC will be used for operator = identification.
You mean to say MPLS-TP enabled swich should be = identified by=20 Global_ID and ICC if the switch needs to be deployed with other = ITU-T=20 networks and MPLS-TP networks.
 
Is this understanding correct?

BR,
Venkatesan=20 Mahalingam.
On Fri, Apr 9, 2010 at 12:35 PM, BUSI ITALO = <Italo.Busi@alcatel-lucent.c= om>=20 wrote:
Venkatesan,
 
in all the other ITU-T transport = technologies=20 the ICC is used for operator identification.
 
When MPLS-TP is deployed with = other ITU-T=20 transport networks, the ICC will be used for operator=20 identification.
 
Italo 

P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effective since 1 = November=20 2009.

 

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = venkatesan=20 mahalingam
Sent: gioved=EC 8 aprile 2010 22.40=20

To: mpls; mpls-tp@ietf.org
Subject: = [mpls-tp]=20 Global_ID or ICC for operator identification - Why notjust=20 Global_ID?

HI,

In the draft =
draft-ietf-mpls-tp-identifiers-01, 
Is there any =
dependency to use either Global Id or ICC for operator identification? =
Can't we just use Global_ID to uniquely identify an operator?

Best Regards,
Venkatesan=20 = Mahalingam.



--
Best Regards,
Venkatesan=20 Mahalingam.
------_=_NextPart_001_01CAD7B6.92E30A5B-- From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:33:37 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5ED3A69BE; Fri, 9 Apr 2010 00:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb2faq3ps8be; Fri, 9 Apr 2010 00:33:36 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 87F9D3A696A; Fri, 9 Apr 2010 00:33:35 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397Wsgl016014; Fri, 9 Apr 2010 09:33:23 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:33:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 09:36:47 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B2353@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 thread-index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAGqaWbAAAG/tQAAA2KjgABiYjaA= References: <4BB70AE7.1020605@pi.nu><2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com><5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net><2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> From: "BUSI ITALO" To: "John E Drake" , "Shahram Davari" , "Loa Andersson" , , , "MPLS-TP ad hoc team" , , "CCAMP" X-OriginalArrivalTime: 09 Apr 2010 07:33:07.0589 (UTC) FILETIME=[E5FA5B50:01CAD7B6] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:33:38 -0000 > [JD]=20 >=20 > I think that might be gilding the lily. Since, except for=20 > the buffer, queuing, and scheduling, the eight are tightly=20 > coupled, one CV/CC is probably fine. Performance monitoring=20 > by PHB is probably a good thing. I cannot agree more. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of John E Drake > Sent: gioved=EC 8 aprile 2010 21.56 > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org;=20 > mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last=20 > call on draft-ietf-mpls-tp-framework-11 >=20 >=20 >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, April 08, 2010 12:30 PM > > To: John E Drake; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org;=20 > > MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP > > Subject: RE: [mpls] [PWE3] short working group last call on=20 > > draft-ietf- > > mpls-tp-framework-11 > >=20 > > Hi John, > >=20 > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP > [JD]=20 >=20 > I think that might be gilding the lily. Since, except for=20 > the buffer, queuing, and scheduling, the eight are tightly=20 > coupled, one CV/CC is probably fine. Performance monitoring=20 > by PHB is probably a good thing. >=20 > > and if any of > > them fail do protection switching for all of them? What will be the=20 > > definition of availability for such E-LSP? > >=20 > > Thanks > > SD > >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, April 08, 2010 12:21 PM > > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org;=20 > > MPLS- TP ad hoc team; pwe3@ietf.org; CCAMP > > Subject: RE: [mpls] [PWE3] short working group last call on=20 > > draft-ietf- > > mpls-tp-framework-11 > >=20 > > Sharam, > >=20 > > We have been through this at least twice before. The best way to=20 > > think E- LSPs is that the former EXP bits in the header are=20 > part of an=20 > > extended label. So you effectively have eight parallel=20 > LSPs and there=20 > > is no packet re-ordering within each. > >=20 > > Dave said he would mention something about OAM per parallel=20 > LSP in the=20 > > framework in response to a last call comment I made. > >=20 > > Thanks, > >=20 > > John > >=20 > > > -----Original Message----- > > > From: mpls-bounces@ietf.org=20 > [mailto:mpls-bounces@ietf.org] On Behalf=20 > > > Of Shahram Davari > > > Sent: Thursday, April 08, 2010 12:00 PM > > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org;=20 > MPLS-TP ad hoc=20 > > > team; pwe3@ietf.org; CCAMP > > > Subject: Re: [mpls] [PWE3] short working group last call on=20 > > > draft-ietf- > > > mpls-tp-framework-11 > > > > > > Hi Loa, > > > > > > The draft mentions that both L-LSP and E-LSP are=20 > supported in MPLS-TP. > > As > > > we know traditional transport layers only have one CoS. However=20 > > > E-LSP > > has > > > multiple CoS, which can reorder packets (I know that the reorder=20 > > > packets belong to different CoS). Additionally the definition of=20 > > > E-LSP OAM and performance and protection and=20 > availability, etc will=20 > > > be questionable (because of carrying multiple CoS). > > > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at=20 > > > least should be discouraged. > > > > > > Regards, > > > Shahram > > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org=20 > [mailto:pwe3-bounces@ietf.org] On Behalf=20 > > > Of Loa Andersson > > > Sent: Saturday, April 03, 2010 2:31 AM > > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team;=20 > > > pwe3@ietf.org; CCAMP > > > Subject: [PWE3] short working group last call on=20 > draft-ietf-mpls-tp- > > > framework-11 > > > > > > All, > > > > > > this is to start a short working group last call on "A=20 > Framework for=20 > > > MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > > > Please note that this wg last call is limited to verify that=20 > > > comments raised during the orevious working group last call and=20 > > > reviews have been correctly addressed. > > > > > > Please sen comments to the mpls-tp mailing list on April=20 > 17th, the=20 > > > latest. > > > > > > /Loa > > > -- > > > > > > > > > Loa Andersson email:=20 > loa.andersson@ericsson.com > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13=20 > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From gregimirsky@gmail.com Fri Apr 9 00:34:07 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677EA3A696A; Fri, 9 Apr 2010 00:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfshHehyLqmh; Fri, 9 Apr 2010 00:34:06 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id E6BD628B56A; Fri, 9 Apr 2010 00:34:03 -0700 (PDT) Received: by yxe9 with SMTP id 9so1669502yxe.29 for ; Fri, 09 Apr 2010 00:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=6R+xw0B9ZEuTGaNusYdM/0yiA2JLNqVfG6D6FBcMTUA=; b=XZsE+qDgCkO/wUgt57hQ5BxZJmFTqagjqXuFoCWxh621t3cyO3Mlpex5LMeyyh2Z2P cCw3FlGU861RK1jz5wAIC5YHevpP5QfE58/sL7XrqugRal/oIfuN2M7AAB416d490jac 4qp4xY/8tj4bRVPlusMRQC81pb8Rnkd+jxw4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MSxm5eft+U/kFl/XvH2ff66nnIBd59nbGUaKaC5QxmBGQw35gdsKt1gsT0JONiJ8TG KEW0UzcCyejm9Uz9fxp5Vtc+qI2OAF5kA2lNDzPf4PTgEstsBh8488+NMEGjonse+tnU cONvqUs+E4IxqXxI3Cc8aHdBfBQTPhb8OyGnU= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Fri, 9 Apr 2010 00:33:56 -0700 (PDT) In-Reply-To: <6FD21B53861BF44AA90A288402036AB4030B2346@FRVELSMBS21.ad2.ad.alcatel.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> <6FD21B53861BF44AA90A288402036AB4030B2346@FRVELSMBS21.ad2.ad.alcatel.com> Date: Fri, 9 Apr 2010 00:33:56 -0700 Received: by 10.91.20.23 with SMTP id x23mr507778agi.83.1270798436640; Fri, 09 Apr 2010 00:33:56 -0700 (PDT) Message-ID: From: Greg Mirsky To: BUSI ITALO Content-Type: multipart/alternative; boundary=0016e640918a65a9f00483c8d1cb Cc: mpls@ietf.org, MPLS-TP ad hoc team , CCAMP , mpls-tp@ietf.org, pwe3@ietf.org Subject: Re: [mpls] [CCAMP] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:34:07 -0000 --0016e640918a65a9f00483c8d1cb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Italo, if we consider Link Bundle (RFC 4201) then it is possible that some CoS flows are being mapped to a different component links. In this case per Co= S FM is quite necessary. Regards, Greg On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO wrote: > I think that running OAM flows per-PHB, while very much appropriate for > PM tools (as already documented in the OAM frameworkd draft), is actually= an > overdesign for FM tools. > > Misconnections and failures are per-LSP and not per-PHB. > > Italo > > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, > effective since 1 November 2009. > > > ------------------------------ > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *David Allan I > *Sent:* gioved=EC 8 aprile 2010 21.45 > *To:* Greg Mirsky; Shahram Davari > *Cc:* mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; > mpls-tp@ietf.org > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last callon > draft-ietf-mpls-tp-framework-11 > > I'm not quite following this argument.... > > If I have a number of co-routed paths with different PHBs, I can > instantiate a number of L-LSPs, which is a significant amount of state at > every hop, or I can instantiate one E-LSP, which is an N:1 compression in > the amount of state in transit nodes. > > The only wrinkle is all PHBs of an E-LSP fate share. But then if I was > protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or > another E-LSP, and if they were co-routed, the majority of failure cases > (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was > switched (although there would be 'n' signal fail indications internally = to > contend with). Overall, it sounds to me like an E-LSP may be a bit faster > there.... > > The actual OAM load to instrument them equally is the same. If an E-LSP > takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? = I > appreciate that the ability to generate per PHB flows may be undesirable = for > some, but that does not make it a bad idea. > > IMO there is no penalty for supporting E-LSPs and there are measurable > benefits. The analysis is flawed. > > my 2 cents > D > > ------------------------------ > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Greg Mirsky > *Sent:* Thursday, April 08, 2010 3:31 PM > *To:* Shahram Davari > *Cc:* mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; > pwe3@ietf.org > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > Dear Shahram, > I share your concern regarding applicability of E-LSP in packet transport > network. Though the document is about the Transport Profile, references t= o > MPLS-TP as packet transport network technology been changed recently. Now > MPLS-TP is referred as "packet network". It is my understanding that > applicability of MPLS-TP functionality, features and capabilities to the > packet transport network will be decided later, separately. > Regarding classes of service in the transport. Neil Harrison pointed > several times that a connection, transport path cannot have multiple > classes, otherwise it leads to significant increased complexity of OAM, > which has to be (SHOULD) per Class of Service per E-LSP. > > Regards, > Greg > > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrot= e: > >> Hi Loa, >> >> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. A= s >> we know traditional transport layers only have one CoS. However E-LSP ha= s >> multiple CoS, which can reorder packets (I know that the reorder packets >> belong to different CoS). Additionally the definition of E-LSP OAM and >> performance and protection and availability, etc will be questionable >> (because of carrying multiple CoS). >> >> Therefore I think E-LSP should not be supported in MPLS-TP or at least >> should be discouraged. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Loa Andersson >> Sent: Saturday, April 03, 2010 2:31 AM >> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; >> CCAMP >> Subject: [PWE3] short working group last call on >> draft-ietf-mpls-tp-framework-11 >> >> All, >> >> this is to start a short working group last call on "A Framework >> for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >> >> Please note that this wg last call is limited to verify that comments >> raised during the orevious working group last call and reviews have >> been correctly addressed. >> >> Please sen comments to the mpls-tp mailing list on April 17th, the >> latest. >> >> /Loa >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > --0016e640918a65a9f00483c8d1cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Italo,
if we consider Link Bundle (RFC 4201) then it is possible th= at some CoS flows are=A0 being mapped to a different component links. In th= is case per CoS FM is quite necessary.

Regards,
Greg

On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO <Italo.Busi@alcatel-lucent.com= > wrote:
I think that running OAM flows per-PHB, while very much=20 appropriate for PM tools (as already documented in the OAM frameworkd draft= ), is=20 actually an overdesign for FM tools.
=A0
Misconnections and failures are per-LSP and not=20 per-PHB.
=A0
Italo

P.S. Please note my new email address,=20 Italo.Bu= si@alcatel-lucent.com, effective since 1 November 2009.

=A0

From: ccamp-bounces@ietf.org=20 [mailto:ccamp= -bounces@ietf.org] On Behalf Of David Allan=20 I
Sent: gioved=EC 8 aprile 2010 21.45
To: Greg Mirsky= ;=20 Shahram Davari
Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team;=20 pwe3@ietf.org; mpls-tp@ietf.org
= Subject: Re: [CCAMP] [mpls] [PWE3]=20 short working group last callon=20 draft-ietf-mpls-tp-framework-11

I'm not quite following this=20 argument....
=A0
If I have a number of co-routed paths with different=20 PHBs, I can instantiate a number of L-LSPs, which is a significant amount= of=20 state at every hop, or I can instantiate=A0one E-LSP, which is an N:1=20 compression in the amount of state in transit nodes.
=A0
The only wrinkle is all PHBs of an E-LSP fate share. But=20 then if I was protecting=A0the L-LSP or the E-LSP version=A0I'd have= =20 another 'n' L-LSPs or another E-LSP, and if they were co-routed, = the majority=20 of failure cases (link cuts) would result in a loud clang as many=20 L-LSPs=A0vs. one E-LSP was switched (although there would be 'n' = signal=20 fail indications internally to contend with).=A0Overall, it sounds to me= =20 like an E-LSP may be a bit faster there....
=A0
The actual OAM load to instrument them equally is the=20 same. If an E-LSP takes 'n' times the flows to be instumented lik= e 'n' L-LSPs=20 so=A0what????=A0=A0I appreciate that the ability to generate per PHB=20 flows may be undesirable for some, but that does not make it a bad=20 idea.
=A0
IMO there is no penalty for supporting E-LSPs and there=20 are measurable benefits. The analysis is flawed.
=A0
my 2 cents
D

From: ccamp-bounces@ietf.org=20 [mailto:ccamp= -bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Sha= hram=20 Davari
Cc: m= pls@ietf.org; MPLS-TP ad hoc team; CCAMP;=20 mpls-tp@ietf.org; pwe3@ietf.org
= Subject: Re: [CCAMP] [mpls] [PWE3]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability = of=20 E-LSP in packet transport network. Though the document is about the Trans= port=20 Profile, references to MPLS-TP as packet transport network technology bee= n=20 changed recently. Now MPLS-TP is referred as "packet network". = It is my=20 understanding that applicability of MPLS-TP functionality, features and= =20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil Harris= on=20 pointed several times that a connection, transport path cannot have multi= ple=20 classes, otherwise it leads to significant increased complexity of OAM, w= hich=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davar= i <davari@broadcom.com>=20 wrote:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are supported = in=20 MPLS-TP. As we know traditional transport layers only have one CoS. How= ever=20 E-LSP has multiple CoS, which can reorder packets (I know that the reor= der=20 packets belong to different CoS). Additionally the definition of E-LSP = OAM=20 and performance and protection and availability, etc will be questionab= le=20 (because of carrying multiple CoS).

Therefore I think E-LSP shou= ld=20 not be supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of=20 Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad = hoc team; pwe3@ietf.org<= /a>; CCAMP
Subject: [PWE3]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start a s= hort=20 working group last call on "A Framework
for MPLS in Transport N= etworks"=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg last= call=20 is limited to verify that comments
raised during the orevious workin= g=20 group last call and reviews have
been correctly addressed.

Pl= ease=20 sen comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:=20 loa.and= ersson@ericsson.com
Sr=20 Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:=20 +46 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0+46 767 72 92=20 13
_______________________________________________
pwe3 mailing= =20 list
pwe3@ietf.or= g
https://www.ietf.org/mailman/listinfo/pwe3


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


--0016e640918a65a9f00483c8d1cb-- From maarten.vissers@huawei.com Fri Apr 9 00:35:45 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7501028C121; Fri, 9 Apr 2010 00:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.294 X-Spam-Level: X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dksEsXCAuISF; Fri, 9 Apr 2010 00:35:44 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CAD6228C0DC; Fri, 9 Apr 2010 00:35:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0L00224MF5LM@szxga03-in.huawei.com>; Fri, 09 Apr 2010 15:35:29 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0L00MJSMF524@szxga03-in.huawei.com>; Fri, 09 Apr 2010 15:35:29 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0L00JQFMEZA9@szxml04-in.huawei.com>; Fri, 09 Apr 2010 15:35:28 +0800 (CST) Date: Fri, 09 Apr 2010 09:35:27 +0200 From: Maarten Vissers In-reply-to: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> To: 'David Allan I' , 'Greg Mirsky' , 'Shahram Davari' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_YtqB4KMQtXNh8D+Uz/bdkw)" Thread-index: AcrXUhDmA913Y8gxSkSinQmgQfqgdAAACFZwABj+BOA= References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> Cc: mpls@ietf.org, 'CCAMP' , 'MPLS-TP ad hoc team' , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] [CCAMP] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:35:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YtqB4KMQtXNh8D+Uz/bdkw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT E-LSPs (and E-PWs) seem to be more appreciated by customers then L-LSPs (L-PWs) I am told by an operator. If an E-LSP/E-PW breaks, then there is no connectivity for any of the CoS levels. Partial failure of a multi-CoS service (i.e. for one of the CoS levels) is considered to be bad. Main service these days is Ethernet and Ethernet VLANs are by default supporting multiple CoS levels. Most of the OAM checks if the transport path is present. Only the packet loss measurement and packet delay measurement OAM checks treatment of client flows. So only those two OAM types may need per CoS measurements. This is not different from Ethernet OAM. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of David Allan I Sent: donderdag 8 april 2010 21:45 To: Greg Mirsky; Shahram Davari Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] [CCAMP] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 I'm not quite following this argument.... If I have a number of co-routed paths with different PHBs, I can instantiate a number of L-LSPs, which is a significant amount of state at every hop, or I can instantiate one E-LSP, which is an N:1 compression in the amount of state in transit nodes. The only wrinkle is all PHBs of an E-LSP fate share. But then if I was protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or another E-LSP, and if they were co-routed, the majority of failure cases (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched (although there would be 'n' signal fail indications internally to contend with). Overall, it sounds to me like an E-LSP may be a bit faster there.... The actual OAM load to instrument them equally is the same. If an E-LSP takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? I appreciate that the ability to generate per PHB flows may be undesirable for some, but that does not make it a bad idea. IMO there is no penalty for supporting E-LSPs and there are measurable benefits. The analysis is flawed. my 2 cents D _____ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, April 08, 2010 3:31 PM To: Shahram Davari Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Dear Shahram, I share your concern regarding applicability of E-LSP in packet transport network. Though the document is about the Transport Profile, references to MPLS-TP as packet transport network technology been changed recently. Now MPLS-TP is referred as "packet network". It is my understanding that applicability of MPLS-TP functionality, features and capabilities to the packet transport network will be decided later, separately. Regarding classes of service in the transport. Neil Harrison pointed several times that a connection, transport path cannot have multiple classes, otherwise it leads to significant increased complexity of OAM, which has to be (SHOULD) per Class of Service per E-LSP. Regards, Greg On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrote: Hi Loa, The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As we know traditional transport layers only have one CoS. However E-LSP has multiple CoS, which can reorder packets (I know that the reorder packets belong to different CoS). Additionally the definition of E-LSP OAM and performance and protection and availability, etc will be questionable (because of carrying multiple CoS). Therefore I think E-LSP should not be supported in MPLS-TP or at least should be discouraged. Regards, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --Boundary_(ID_YtqB4KMQtXNh8D+Uz/bdkw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
E-LSPs (and E-PWs) seem to be more appreciated by customers then L-LSPs (L-PWs) I am told by an operator. If an E-LSP/E-PW breaks, then there is no connectivity for any of the CoS levels. Partial failure of a multi-CoS service (i.e. for one of the CoS levels) is considered to be bad.
 
Main service these days is Ethernet and Ethernet VLANs are by default supporting multiple CoS levels.
 
Most of the OAM checks if the transport path is present. Only the packet loss measurement and packet delay measurement OAM checks treatment of client flows. So only those two OAM types may need per CoS measurements. This is not different from Ethernet OAM.
 
Regards,
Maarten

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of David Allan I
Sent: donderdag 8 april 2010 21:45
To: Greg Mirsky; Shahram Davari
Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] [CCAMP] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11

I'm not quite following this argument....
 
If I have a number of co-routed paths with different PHBs, I can instantiate a number of L-LSPs, which is a significant amount of state at every hop, or I can instantiate one E-LSP, which is an N:1 compression in the amount of state in transit nodes.
 
The only wrinkle is all PHBs of an E-LSP fate share. But then if I was protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or another E-LSP, and if they were co-routed, the majority of failure cases (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched (although there would be 'n' signal fail indications internally to contend with). Overall, it sounds to me like an E-LSP may be a bit faster there....
 
The actual OAM load to instrument them equally is the same. If an E-LSP takes 'n' times the flows to be instumented like 'n' L-LSPs so what????  I appreciate that the ability to generate per PHB flows may be undesirable for some, but that does not make it a bad idea.
 
IMO there is no penalty for supporting E-LSPs and there are measurable benefits. The analysis is flawed.
 
my 2 cents
D

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; pwe3@ietf.org
Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability of E-LSP in packet transport network. Though the document is about the Transport Profile, references to MPLS-TP as packet transport network technology been changed recently. Now MPLS-TP is referred as "packet network". It is my understanding that applicability of MPLS-TP functionality, features and capabilities to the packet transport network will be decided later, separately.
Regarding classes of service in the transport. Neil Harrison pointed several times that a connection, transport path cannot have multiple classes, otherwise it leads to significant increased complexity of OAM, which has to be (SHOULD) per Class of Service per E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari <davari@broadcom.com> wrote:
Hi Loa,

The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As we know traditional transport layers only have one CoS. However E-LSP has multiple CoS, which can reorder packets (I know that the reorder packets belong to different CoS). Additionally the definition of E-LSP OAM and performance and protection and availability, etc will be questionable (because of carrying multiple CoS).

Therefore I think E-LSP should not be supported in MPLS-TP or at least should be discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP
Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

All,

this is to start a short working group last call on "A Framework
for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11).

Please note that this wg last call is limited to verify that comments
raised during the orevious working group last call and reviews have
been correctly addressed.

Please sen comments to the mpls-tp mailing list on April 17th, the
latest.

/Loa
--


Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                             +46 767 72 92 13
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3


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

--Boundary_(ID_YtqB4KMQtXNh8D+Uz/bdkw)-- From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:36:38 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224EE3A67EB; Fri, 9 Apr 2010 00:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn+YGJLfrCQP; Fri, 9 Apr 2010 00:36:36 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3097B3A67D2; Fri, 9 Apr 2010 00:36:36 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397ZRS8017896; Fri, 9 Apr 2010 09:36:28 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:36:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 09:39:52 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B235B@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <201004090430.o394U91l090288@harbor.orleans.occnc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 thread-index: AcrXnV1pDPvZNYnUTk2MVRfh6P5CAgAGldhQ References: Your message of "Thu, 08 Apr 2010 12:30:03 PDT."<2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> <201004090430.o394U91l090288@harbor.orleans.occnc.com> From: "BUSI ITALO" To: , "Shahram Davari" X-OriginalArrivalTime: 09 Apr 2010 07:36:12.0110 (UTC) FILETIME=[53F606E0:01CAD7B7] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: mpls@ietf.org, CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:36:38 -0000 Curtis, I agree that FM OAM must run at the highest priority within an LSP. However, PM OAM must run at the priority it is measuring. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Curtis Villamizar > Sent: venerd=EC 9 aprile 2010 6.30 > To: Shahram Davari > Cc: MPLS-TP ad hoc team; mpls@ietf.org; CCAMP;=20 > mpls-tp@ietf.org; pwe3@ietf.org > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last=20 > call ondraft-ietf-mpls-tp-framework-11 >=20 >=20 > In message=20 > <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.a > d.broadcom.com> > "Shahram Davari" writes: > > =20 > > Hi John, > > =20 > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if=20 > > any of them fail do protection switching for all of them?=20 > What will be=20 > > the definition of availability for such E-LSP? > > =20 > > Thanks > > SD >=20 >=20 > If there were multiple priorities on an LSP the OAM should be=20 > at a high priority. For example for CS service (the old IP=20 > prec) CS6 is normally used for control traffic. If OAM=20 > failed for CS6 the link is down. If OAM fails for CS0 the=20 > link may just be oversubscribed and contested but CS0 is=20 > defined as the best effort (BE) service. >=20 > A provider may choose to do this. For example, if VOIP ran=20 > at CS4 and worked fine and web and email was runnig on CS0,=20 > phone would work and web would be slow. If a natural=20 > disaster took out 3/4 of the network capacity, then having=20 > working phone and slow web and maybe unworkable web streaming=20 > video might be better than prohibiting oversubscription and=20 > having no service at all. >=20 > Curtis > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From maarten.vissers@huawei.com Fri Apr 9 00:59:19 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF74A3A69CE; Fri, 9 Apr 2010 00:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o8w7ACn4knG; Fri, 9 Apr 2010 00:59:19 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D90A53A6876; Fri, 9 Apr 2010 00:59:18 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0L00LQWNIGWF@szxga03-in.huawei.com>; Fri, 09 Apr 2010 15:59:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0L0081FNIG24@szxga03-in.huawei.com>; Fri, 09 Apr 2010 15:59:04 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0L00JEDNICAC@szxml04-in.huawei.com>; Fri, 09 Apr 2010 15:59:04 +0800 (CST) Date: Fri, 09 Apr 2010 09:59:04 +0200 From: Maarten Vissers In-reply-to: <201004090430.o394U91l090288@harbor.orleans.occnc.com> To: curtis@occnc.com, 'Shahram Davari' Message-id: <4AA9A83DBDBF4EC2AFFCAA143B40681D@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrXngttOj8FJAlyR4ixCguypTcc0AAHGZhg References: "Your message of Thu, 08 Apr 2010 12:30:03 PDT." <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> <201004090430.o394U91l090288@harbor.orleans.occnc.com> Cc: mpls@ietf.org, 'CCAMP' , 'MPLS-TP ad hoc team' , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:59:19 -0000 Curtis, > If there were multiple priorities on an LSP the OAM should be at a high priority. This is the approach taken in Y.1731 for Ethernet OAM. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Curtis Villamizar Sent: vrijdag 9 april 2010 6:30 To: Shahram Davari Cc: MPLS-TP ad hoc team; mpls@ietf.org; CCAMP; mpls-tp@ietf.org; pwe3@ietf.org Subject: Re: [mpls-tp] [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 In message <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com > "Shahram Davari" writes: > > Hi John, > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if > any of them fail do protection switching for all of them? What will be > the definition of availability for such E-LSP? > > Thanks > SD If there were multiple priorities on an LSP the OAM should be at a high priority. For example for CS service (the old IP prec) CS6 is normally used for control traffic. If OAM failed for CS6 the link is down. If OAM fails for CS0 the link may just be oversubscribed and contested but CS0 is defined as the best effort (BE) service. A provider may choose to do this. For example, if VOIP ran at CS4 and worked fine and web and email was runnig on CS0, phone would work and web would be slow. If a natural disaster took out 3/4 of the network capacity, then having working phone and slow web and maybe unworkable web streaming video might be better than prohibiting oversubscription and having no service at all. Curtis _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From loa@pi.nu Fri Apr 9 01:46:16 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD0E3A69BD; Fri, 9 Apr 2010 01:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnSVRdhihk-d; Fri, 9 Apr 2010 01:46:13 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id AB15F3A69CA; Fri, 9 Apr 2010 01:46:07 -0700 (PDT) Received: from [79.138.184.1] (79.138.184.1.bredband.tre.se [79.138.184.1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 0006ED404F; Fri, 9 Apr 2010 10:46:00 +0200 (CEST) Message-ID: <4BBEE98B.3090805@pi.nu> Date: Fri, 09 Apr 2010 10:47:07 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org, "mpls-tp@ietf.org" , MPLS-TP ad hoc team Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] team to drive a BFD based solution for CC, CV and RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 08:46:16 -0000 All, For some time the mpls working group chairs have been very concerned about the lack of progress on a BFD based solution for CV, CC and RDI. To improve on this situation the working group chairs have decided to create a team modeled after how we worked with the LDP specification when we started up the MPLS work. The new team will work based on a mandate from the working group chairs, with clear instructions progress the draft in such a way that author contributions are recognized, that the IETF expertise on BFD is involved and to seek a quick rough consensus among the authors. Note that this means that the people currently involved in the draft-asm remain as authors. We will therefore have one team of editors consisting of Dave Allan George Swallow John Drake That is mainly responsible for driving the effort and make sure that we are making good progress. The full team of authors will also include the current authors of the document, i.e.: Sami Boutros Annamaria Fulignoli Martin Vigoureux Siva Sivabalan David Ward /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From maarten.vissers@huawei.com Fri Apr 9 01:51:03 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A68B3A69C1; Fri, 9 Apr 2010 01:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8c-qqoaYxJ+K; Fri, 9 Apr 2010 01:51:02 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CA46D3A69B7; Fri, 9 Apr 2010 01:50:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0L007JGPW8TD@szxga04-in.huawei.com>; Fri, 09 Apr 2010 16:50:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0L00HAAPW8K0@szxga04-in.huawei.com>; Fri, 09 Apr 2010 16:50:32 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0L00H2MPW4HW@szxml06-in.huawei.com>; Fri, 09 Apr 2010 16:50:32 +0800 (CST) Date: Fri, 09 Apr 2010 10:50:32 +0200 From: Maarten Vissers In-reply-to: <6FD21B53861BF44AA90A288402036AB4030B233D@FRVELSMBS21.ad2.ad.alcatel.com> To: 'BUSI ITALO' , mpls-tp@ietf.org, mpls@ietf.org, 'MPLS-TP ad hoc team' , pwe3@ietf.org, 'CCAMP' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAIPh/OAAAYBBEA== References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <6FD21B53861BF44AA90A288402036AB4030B233D@FRVELSMBS21.ad2.ad.alcatel.com> Subject: Re: [mpls] [mpls-tp] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 08:51:03 -0000 Performance monitoring for multiple CoS connections has been specified = in Y.1731 as follows: 1) pro-active PM (i.e. 15 minute/24 hour ES/SES/BBE and UAT) for=20 **one (default: highest)** CoS level in the connection [also Degraded (DEG) defect has been defined for this highest CoS = level] 2) on-demand frame loss monitoring and frame delay (delay variation) monitoring for any CoS level; this on-demand monitoring does not provide ES/SES/BBE/UAT results, it provides just an event result MEF has requested to extend the Y.1731 performance monitoring with: A) pro-active PM (i.e. 15 minute/24 hour ES/SES/BBE and UAT) for=20 **every** CoS level in the connection B) pro-active PM (i.e. 15 minute/24 hour reports) for frame delay (delay variation) monitoring for **every** CoS level in the = connection C) introduce pro-active and on-demand synthetic frame loss monitoring = for=20 mp2mp/rmp connections for every CoS level in the connection Q.9/15 and Q.10/15 are analysing the complexity of this extension at the moment. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of BUSI ITALO Sent: vrijdag 9 april 2010 9:24 To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; = MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP Subject: Re: [mpls-tp] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 Shahram, > As we know traditional transport layers only have one CoS. This is no more the case after Ethernet transport layer has been = developed. > Additionally the definition of E-LSP OAM and performance and=20 > protection and availability, etc will be questionable (because of=20 > carrying multiple CoS). I agree that performance monitoring for multi-CoS connections (e.g., = E-LSP) is not trivial. We have exactly the same issue with Ethernet performance monitoring. In principle I think that a solution can be defined but I am spending = too much time on mpls-tp standardization so I had not time to monitor the = status of this work within Q14/15. I do not see any issue with fault monitoring of multi-CoS connections as faults are not per-CoS but per-connection. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effective since 1 November 2009. =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Shahram Davari > Sent: gioved=EC 8 aprile 2010 21.00 > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc=20 > team; pwe3@ietf.org; CCAMP > Subject: Re: [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. = > As we know traditional transport layers only have one CoS. However=20 > E-LSP has multiple CoS, which can reorder packets (I know that the=20 > reorder packets belong to different CoS). Additionally the definition=20 > of E-LSP OAM and performance and protection and availability, etc will = > be questionable (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or at least = > should be discouraged. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf=20 > Of Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team;=20 > pwe3@ietf.org; CCAMP > Subject: [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A Framework for=20 > MPLS in Transport Networks" > (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that comments=20 > raised during the orevious working group last call and reviews have=20 > been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April 17th, the=20 > latest. >=20 > /Loa > -- >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 > 13 _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From tom.nadeau@bt.com Fri Apr 9 04:37:48 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDBC3A67EB; Fri, 9 Apr 2010 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.466 X-Spam-Level: X-Spam-Status: No, score=0.466 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kIhj6SZSxFN; Fri, 9 Apr 2010 04:37:47 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 4C2AD3A67D2; Fri, 9 Apr 2010 04:37:46 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 12:37:42 +0100 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Apr 2010 11:37:41 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 09 Apr 2010 07:37:40 -0400 From: "Thomas D. Nadeau" To: venkatesan mahalingam , , mpls Message-ID: Thread-Topic: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes Thread-Index: AcrX2Q9qx/MCEqwCmk6rBmSP1qdC/w== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3353643460_25195777" X-OriginalArrivalTime: 09 Apr 2010 11:37:42.0602 (UTC) FILETIME=[10F7A2A0:01CAD7D9] Subject: Re: [mpls] [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:37:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3353643460_25195777 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I think a good first step would be to first identify any gaps that exist between the G/MPLS MIBs that exist today. --Tom On 4/8/10 4:12 PM, "venkatesan mahalingam" wrote: > Hi, > Anybody started working on MPLS-TP tunnel MIB related changes for non IP based > LSPs? > > I'm looking forward to work with you guys. --B_3353643460_25195777 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes
    I think a good first step would be to first identif= y any gaps that exist between the G/MPLS MIBs that exist today.

    --Tom



On 4/8/10 4:12 PM, "venkatesan mahalingam" <venkatflex@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>Hi,
Anybody started working on MPLS-TP tunnel MIB related changes for non IP ba= sed LSPs?

I'm looking forward to work with you guys.
=

--B_3353643460_25195777-- From nurit.sprecher@nsn.com Fri Apr 9 05:03:13 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A4B3A689C; Fri, 9 Apr 2010 05:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky+M6DJxGiLG; Fri, 9 Apr 2010 05:03:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1DE863A6881; Fri, 9 Apr 2010 05:03:11 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o39C33pP026910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Apr 2010 14:03:03 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o39C30nT012400; Fri, 9 Apr 2010 14:03:03 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 14:03:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD7DC.9ABD1E54" Date: Fri, 9 Apr 2010 14:03:02 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640208F608@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes Thread-Index: AcrX2Q9qx/MCEqwCmk6rBmSP1qdC/wAAdsLQ References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Thomas D. Nadeau" , "venkatesan mahalingam" , , "mpls" X-OriginalArrivalTime: 09 Apr 2010 12:03:01.0946 (UTC) FILETIME=[9A9121A0:01CAD7DC] Subject: Re: [mpls] [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:03:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD7DC.9ABD1E54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Thomas D. Nadeau Sent: Friday, April 09, 2010 2:38 PM To: venkatesan mahalingam; mpls-tp@ietf.org; mpls Subject: Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes =20 I think a good first step would be to first identify any gaps that exist between the G/MPLS MIBs that exist today. --Tom On 4/8/10 4:12 PM, "venkatesan mahalingam" wrote: Hi, Anybody started working on MPLS-TP tunnel MIB related changes for non IP based LSPs? I'm looking forward to work with you guys. =20 ------_=_NextPart_001_01CAD7DC.9ABD1E54 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes

+1

 

From:= mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of ext Thomas D. Nadeau
Sent: Friday, April 09, 2010 2:38 PM
To: venkatesan mahalingam; mpls-tp@ietf.org; mpls
Subject: Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB = changes

 


    I think a good first step would be to first = identify any gaps that exist between the G/MPLS MIBs that exist today.

    --Tom



On 4/8/10 4:12 PM, "venkatesan mahalingam" <venkatflex@gmail.com> = wrote:

Hi,
Anybody started working on MPLS-TP tunnel MIB related changes for non IP = based LSPs?

I'm looking forward to work with you guys.

 

------_=_NextPart_001_01CAD7DC.9ABD1E54-- From scott.mansfield@ericsson.com Fri Apr 9 07:25:22 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61B73A67F9; Fri, 9 Apr 2010 07:25:22 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BB9ciekUt-4I; Fri, 9 Apr 2010 07:25:21 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 90AEE3A6358; Fri, 9 Apr 2010 07:25:21 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o39ESWPZ019368; Fri, 9 Apr 2010 09:29:17 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 9 Apr 2010 10:25:10 -0400 From: Scott Mansfield To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Thomas D. Nadeau" , venkatesan mahalingam , "mpls-tp@ietf.org" , mpls Date: Fri, 9 Apr 2010 10:24:54 -0400 Thread-Topic: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes Thread-Index: AcrX2Q9qx/MCEqwCmk6rBmSP1qdC/wAAdsLQAAUQ6HA= Message-ID: References: <077E41CFFD002C4CAB7DFA4386A532640208F608@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A532640208F608@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FDC72027C316A44F82F425284E1C4C3201E8B1EF79EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 14:25:22 -0000 --_000_FDC72027C316A44F82F425284E1C4C3201E8B1EF79EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in the process of gathering information in order to perform a gap anal= ysis for the MIBs needed by the transport profile of MPLS. Anyone interest= ed in providing input to the gap identification process, please let me know= . regards, -scott. ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Friday, April 09, 2010 8:03 AM To: ext Thomas D. Nadeau; venkatesan mahalingam; mpls-tp@ietf.org; mpls Subject: Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes +1 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of ext Thomas D. Nadeau Sent: Friday, April 09, 2010 2:38 PM To: venkatesan mahalingam; mpls-tp@ietf.org; mpls Subject: Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes I think a good first step would be to first identify any gaps that exis= t between the G/MPLS MIBs that exist today. --Tom On 4/8/10 4:12 PM, "venkatesan mahalingam" wrote: Hi, Anybody started working on MPLS-TP tunnel MIB related changes for non IP ba= sed LSPs? I'm looking forward to work with you guys. --_000_FDC72027C316A44F82F425284E1C4C3201E8B1EF79EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re= : [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes
I am=20 in the process of gathering information in order to perform a gap analysis = for=20 the MIBs needed by the transport profile of MPLS.  Anyone interested i= n=20 providing input to the gap identification process, please let me=20 know.
 
regards,
-scott.

From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NS= N -=20 IL/Hod HaSharon)
Sent: Friday, April 09, 2010 8:03 AM
To:= =20 ext Thomas D. Nadeau; venkatesan mahalingam; mpls-tp@ietf.org;=20 mpls
Subject: Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB=20 changes

+1

 

From:=20 mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf O= f=20 ext Thomas D. Nadeau
Sent: Friday, April 09, 2010 2:38=20 PM
To: venkatesan mahalingam; mpls-tp@ietf.org;=20 mpls
Subject: Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB=20 changes

 


 =    I=20 think a good first step would be to first identify any gaps that exist be= tween=20 the G/MPLS MIBs that exist=20 today.

    --Tom



On 4/8/10 4:12= PM,=20 "venkatesan mahalingam" <venkatflex@gmail.com>=20 wrote:

Hi,
Any= body=20 started working on MPLS-TP tunnel MIB related changes for non IP based=20 LSPs?

I'm looking forward to work with you guys.=

 

--_000_FDC72027C316A44F82F425284E1C4C3201E8B1EF79EUSAACMS0701e_-- From venkatflex@gmail.com Fri Apr 9 13:27:19 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168663A6837; Fri, 9 Apr 2010 13:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcpUfH8OPArF; Fri, 9 Apr 2010 13:27:18 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 2097D3A699F; Fri, 9 Apr 2010 13:27:18 -0700 (PDT) Received: by pwj2 with SMTP id 2so3227462pwj.31 for ; Fri, 09 Apr 2010 13:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=FmrRKZv0MqHAQc5/08mnIv6b6a1kC6ebkQUuEE9d6YI=; b=kalLglMfA5YTBFtwGx+9cCbWoBGlsp0Sv1tafFApxwbivBNNSWtjWcGaJanJR+Dc6S Y9vCLvNulCnXDk9M6y3u0xcPsuQ8WlX+r0D/0foIB15y4bBHpsR56ravZqqYMb2X6+eP X19yWlLHJFQlFlE4mXDD0QfRNqAmaco8aPf+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p4NFKFuaiHowggU82oXgP85vcOB9227/BTH9eQg7oYNUmspPqUeaymiN0Eqe24yEZB EIwpIkl/iHi4RE/+PohfbBbl1vRnMQW7d4DNjYg5J78dEEw4zW4RsKl9mCjsASdgrGGH j7zmOIhfNN20Hz0UK1lOcFtz6C1Df/XCnI6To= MIME-Version: 1.0 Received: by 10.143.168.20 with HTTP; Fri, 9 Apr 2010 13:27:11 -0700 (PDT) In-Reply-To: References: <077E41CFFD002C4CAB7DFA4386A532640208F608@DEMUEXC014.nsn-intra.net> Date: Sat, 10 Apr 2010 01:57:11 +0530 Received: by 10.142.209.4 with SMTP id h4mr567461wfg.245.1270844831922; Fri, 09 Apr 2010 13:27:11 -0700 (PDT) Message-ID: From: venkatesan mahalingam To: Scott Mansfield Content-Type: multipart/alternative; boundary=000e0cd23ea4c579e10483d39eb7 Cc: mpls , mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 20:27:19 -0000 --000e0cd23ea4c579e10483d39eb7 Content-Type: text/plain; charset=ISO-8859-1 Scott, I am interested, please let me know what inputs you need from me to help you in the gap identification process? Best Regards, Venkatesan Mahalingam. On Fri, Apr 9, 2010 at 7:54 PM, Scott Mansfield < scott.mansfield@ericsson.com> wrote: > I am in the process of gathering information in order to perform a gap > analysis for the MIBs needed by the transport profile of MPLS. Anyone > interested in providing input to the gap identification process, please let > me know. > > regards, > -scott. > > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *Sprecher, Nurit (NSN - IL/Hod HaSharon) > *Sent:* Friday, April 09, 2010 8:03 AM > *To:* ext Thomas D. Nadeau; venkatesan mahalingam; mpls-tp@ietf.org; mpls > > *Subject:* Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes > > +1 > > > > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *ext Thomas D. Nadeau > *Sent:* Friday, April 09, 2010 2:38 PM > *To:* venkatesan mahalingam; mpls-tp@ietf.org; mpls > *Subject:* Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB changes > > > > > I think a good first step would be to first identify any gaps that > exist between the G/MPLS MIBs that exist today. > > --Tom > > > > On 4/8/10 4:12 PM, "venkatesan mahalingam" wrote: > > Hi, > Anybody started working on MPLS-TP tunnel MIB related changes for non IP > based LSPs? > > I'm looking forward to work with you guys. > > > > -- Best Regards, Venkatesan Mahalingam. --000e0cd23ea4c579e10483d39eb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Scott,

I am interested, please let me know what inputs you need from= me to help you in the gap identification process?

Best Regards,
= Venkatesan Mahalingam.

On Fri, Apr 9, 201= 0 at 7:54 PM, Scott Mansfield <scott.mansfield@ericsson.com> wrote:=
I am=20 in the process of gathering information in order to perform a gap analysis = for=20 the MIBs needed by the transport profile of MPLS.=A0 Anyone interested in= =20 providing input to the gap identification process, please let me=20 know.
= =A0
regards,
-scott.=

From: mpls-tp-bounces@ietf= .org=20 [mailto:mpl= s-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -=20 IL/Hod HaSharon)
Sent: Friday, April 09, 2010 8:03 AM
= To:=20 ext Thomas D. Nadeau; venkatesan mahalingam; mpls-tp@ietf.org;=20 mpls

Subject: Re: [mpls-tp] MPLS-TP NON-IP Tu= nnel MIB=20 changes

+1

=A0

From:=20 mpls-tp-bou= nces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of=20 ext Thomas D. Nadeau
Sent: Friday, April 09, 2010 2:38=20 PM
To: venkatesan mahalingam; mpls-tp@ietf.org;=20 mpls
Subject: Re: [mpls-tp] MPLS-TP NON-IP Tunnel MIB=20 changes

=A0


=A0=A0=A0=A0I=20 think a good first step would be to first identify any gaps that exist be= tween=20 the G/MPLS MIBs that exist=20 today.

=A0=A0=A0=A0--Tom



On 4/8/10 4:12 PM,=20 "venkatesan mahalingam" <venkatflex@gmail.com>=20 wrote:

Hi,
Anybody=20 started working on MPLS-TP tunnel MIB related changes for non IP based=20 LSPs?

I'm looking forward to work with you guys.

=A0

=



--
Best Regards,
Venkat= esan Mahalingam.
--000e0cd23ea4c579e10483d39eb7-- From sob@harvard.edu Tue Mar 30 09:32:43 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547023A6AA0; Tue, 30 Mar 2010 09:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.575 X-Spam-Level: X-Spam-Status: No, score=0.575 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCID1-sHvpt1; Tue, 30 Mar 2010 09:32:42 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id D91C83A6AA4; Tue, 30 Mar 2010 09:32:30 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 43E2C5C488A; Tue, 30 Mar 2010 12:33:00 -0400 (EDT) To: greg.jones@itu.int, opsawg@ietf.org Message-Id: <20100330163300.43E2C5C488A@newdev.eecs.harvard.edu> Date: Tue, 30 Mar 2010 12:33:00 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-Mailman-Approved-At: Fri, 09 Apr 2010 17:02:54 -0700 Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int, malcolm.betts@zte.com.cn, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] opaswg last call for "The OAM Acronym Soup" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:32:43 -0000 This message starts an IETF opsawg working group last call for "The OAM Acronym Soup." (http://datatracker.ietf.org/doc/draft-ietf-opsawg-mpls-tp-oam-def/) for publication as an Informational RFC This message is also being sent to a number of other IETF working groups and to non-IETF groups to ensure wide review. Please direct any comments to the opsawg list (opsawg@ietf.org) The comment period for this working group last call extends until April 20th. Thanks Scott & Chris From cdl@asgaard.org Wed Mar 31 16:08:52 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844E23A6827; Wed, 31 Mar 2010 16:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB1UAogJe6XN; Wed, 31 Mar 2010 16:08:51 -0700 (PDT) Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id E156D3A6A31; Wed, 31 Mar 2010 16:08:49 -0700 (PDT) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.152.154]) by asgaard.org (Postfix) with ESMTP id 21ADB8AC0B1; Wed, 31 Mar 2010 23:09:14 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <20100330163300.43E2C5C488A@newdev.eecs.harvard.edu> Date: Thu, 1 Apr 2010 10:09:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <093F33AF-4F57-42B1-B097-382FFDBF745D@asgaard.org> References: <20100330163300.43E2C5C488A@newdev.eecs.harvard.edu> To: Scott O. Bradner X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Fri, 09 Apr 2010 17:02:54 -0700 Cc: mpls@ietf.org, greg.jones@itu.int, ghani.abbas@ericsson.com, malcolm.betts@zte.com.cn, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, opsawg@ietf.org, hhelvoort@huawei.com, hklam@alcatel-lucent.com, stbryant@cisco.com Subject: Re: [mpls] [OPSAWG] opaswg last call for "The OAM Acronym Soup" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 23:08:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 support. Chris On 31 Mar 2010, at 03.33 , Scott O. Bradner wrote: > This message starts an IETF opsawg working group last call for "The = OAM > Acronym Soup." > (http://datatracker.ietf.org/doc/draft-ietf-opsawg-mpls-tp-oam-def/) > for publication as an Informational RFC >=20 > This message is also being sent to a number of other IETF working = groups > and to non-IETF groups to ensure wide review. Please direct any > comments to the opsawg list (opsawg@ietf.org) >=20 > The comment period for this working group last call extends until = April > 20th. >=20 > Thanks >=20 > Scott & Chris >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 - --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJLs9YaAAoJEGmx2Mt/+Iw/rSYH/1LAp6GsatmS7fCXgI92m+AO JkJ0hNv4wsUzaxFMkRwO3zNXGR/Jhe9L7um8Uy9XuWI3UGV8qSJdyfydqDT0L7FQ yw+jiqEDXhouMWmsKAyrHhmRMgQL5adtlw/urvrJWIVUW8RvHr13xgapmMs8J6vT Gu0wUQT7c2jm8pHKhtvT0RUhk+84ZNPL3ROLS0EblgoPnUazpZYm+/43/QlZhKmv +lBaXDWnDs3WWa+q+zXgutn7l8cKQEqjgyJcFv8BvGTBAKu7KpBMOf60LheiQAwC PgFwxPD/FSurydvPv9msyVn2VmAxqfPWyaA4JHpxhxLxt/FzloEFLr2fmj+YsRE=3D =3DW5UA -----END PGP SIGNATURE----- From duzongpeng@gmail.com Mon Apr 5 20:37:32 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E5F3A67CC; Mon, 5 Apr 2010 20:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9T1L2RksALC; Mon, 5 Apr 2010 20:37:31 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 0EE513A65A6; Mon, 5 Apr 2010 20:37:31 -0700 (PDT) Received: by iwn29 with SMTP id 29so1488170iwn.17 for ; Mon, 05 Apr 2010 20:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=H+tZohiNBBQ8zuVjjs1qAXbrEF4swEoCxbPhTZuSaGs=; b=Id8ugJ6X3fR+cBkOQPQeUXxl7Luwfva0tkZ/vyk5YNPs8qzFneajT1L3Bf473DoXKr VfnLh/r2ihN3ocqCD3NmARWQkiojnvfJNEXe4GAp87Jo/AHVboISDEUKcDXLuMn7WOBs v2chpJdNpe+EhUHggeChEocvdL4h0wsD/OuEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tT+Ygs3SE9ZpFvnBCMf+yThH3EuEhywrr3OPSlGoYDFPZ0WgZ0PZv6OVSM2NsqrOvE WfB0IlzcUxZXiD7qcbiqHjTbKVTjkgYewnMRchNGDzTiCOFKzwbHhxI053WeOkJ+yXk8 02DDNlwd1Nuz5zKRj3pf9qIJ76Osdo971PeEM= MIME-Version: 1.0 Received: by 10.231.117.218 with HTTP; Mon, 5 Apr 2010 20:37:24 -0700 (PDT) Date: Tue, 6 Apr 2010 11:37:24 +0800 Received: by 10.231.167.4 with SMTP id o4mr696228iby.66.1270525044457; Mon, 05 Apr 2010 20:37:24 -0700 (PDT) Message-ID: From: Du Zongpeng To: mpls-tp@ietf.org, mpls@ietf.org Content-Type: multipart/alternative; boundary=005045015ea7f3ff8c0483892935 X-Mailman-Approved-At: Fri, 09 Apr 2010 17:02:54 -0700 Subject: [mpls] [mpls-tp] A new ID draft-ji-mpls-tp-bidirectional-label-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 03:37:32 -0000 --005045015ea7f3ff8c0483892935 Content-Type: text/plain; charset=ISO-8859-1 Dear MPLS WG: Please be aware that we submitted a new WG document, Bidirectional Label Assignment in MPLS-TP draft-ji-mpls-tp-bidirectional-label-00 http://tools.ietf.org/id/draft-ji-mpls-tp-bidirectional-label-00.txt Abstract This document describes a new mechanism for the label allocation of co-routed bidirectional point-to-point paths in MPLS Transport Profile (MPLS-TP) networks, which is called the bidirectional label allocation mechanism. The nodes on co-routed bidirectional point-to- point paths will not need to record the label pairing relationship of the forward and the backward directions in this mechanism because the labels are symmetrical. In addition, the compression of the LIB becomes possible because of the existing of symmetrical elements. We would appreciate reviews and comments for our document. Best Regards Zongpeng Du ============================================== Zongpeng Du BUPT Address: P.O.Box 90, Beijing University of Posts and Telecommunications No.10, Xitucheng Road, Haidian District, Beijing, China, 100876 Tel: +86-010-62282905-807 ============================================== --005045015ea7f3ff8c0483892935 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear MPLS WG:

Please be aware that we submitted a new WG document,
Bidirectional Label Assignment in MPLS-TP
draft-ji-mpls-tp-bidirec= tional-label-00
http://tools.ietf.org/id/draft-ji-mpls-tp-bidirect= ional-label-00.txt

Abstract
This document describes a new mechanism for the label allocation of co-routed bidirectional point-to-point paths in MPLS Transport Profile (MPLS-TP) networks, which is called the bidirectional label allocation mechanism. The nodes on co-routed bidirectional point-to- point paths will not need to record the label pairing relationship of the forward and the backward directions in this mechanism because the labels are symmetrical. In addition, the compression of the LIB becomes possible because of the existing of symmetrical elements.

We would appreciate reviews and comments for our document.

B= est Regards

Zongpeng Du

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Zongpeng Du
BUPT
Address: P.O.Box 90, = Beijing University of Posts and Telecommunications
No.10, Xitucheng Road, Haidian District,=20 Beijing, China, 100876
Tel: +86-010-62282905-807
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--005045015ea7f3ff8c0483892935-- From duzongpeng@gmail.com Mon Apr 5 21:57:06 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B253A681D; Mon, 5 Apr 2010 21:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUxr2G92x+u0; Mon, 5 Apr 2010 21:57:05 -0700 (PDT) Received: from mail-iw0-f203.google.com (mail-iw0-f203.google.com [209.85.223.203]) by core3.amsl.com (Postfix) with ESMTP id 3B0A43A67A6; Mon, 5 Apr 2010 21:57:05 -0700 (PDT) Received: by iwn41 with SMTP id 41so726262iwn.20 for ; Mon, 05 Apr 2010 21:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=TREvHbBbay8oGpU0B4Eg0QNzUIZ0SSEQpGnDPvtUtK4=; b=LdgSDO/Ik2XYK8//5n15ssY8M8xOTCpYNRq9gMDUl0lJcyMqgHqDohvkMTwLQXU95v 3LnPIMU9JENHRxv0HJsZKVez9aCMPUBwRBTU1CUs8mDTCAiVojmB6IOOf9MVBJBRC+p3 VqVE5muLLAIamQoLW//Bv9bcSaEVKtgQ+KOR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GB7j72VoEZ7FTFdR61EMWLWc8Tv/ib/5CEIcZvuH+r3cpPZOf3wKFCE3nhk2NOmFGM fUkNHJoSQx7y16U/qeYEAwcM+HKKkluZ2Y/mCWCiEBQQO9ZF6vWdgewKTfPC7W2iN3M5 6ib1ksZbB1+77aVpidUlVj9bA/dCAelPMU4qg= MIME-Version: 1.0 Received: by 10.231.117.218 with HTTP; Mon, 5 Apr 2010 21:57:00 -0700 (PDT) Date: Tue, 6 Apr 2010 12:57:00 +0800 Received: by 10.231.147.2 with SMTP id j2mr414084ibv.65.1270529820458; Mon, 05 Apr 2010 21:57:00 -0700 (PDT) Message-ID: From: Du Zongpeng To: mpls-tp , mpls Content-Type: multipart/alternative; boundary=0016e64354569ffe2204838a46f8 X-Mailman-Approved-At: Fri, 09 Apr 2010 17:02:54 -0700 Subject: [mpls] [mpls-tp] A new ID draft-ji-mpls-tp-bidirectional-label-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 04:57:06 -0000 --0016e64354569ffe2204838a46f8 Content-Type: text/plain; charset=ISO-8859-1 Dear MPLS WG: Please be aware that we submitted a new WG document, Bidirectional Label Assignment in MPLS-TP draft-ji-mpls-tp-bidirectional-label-00 http://tools.ietf.org/id/draft-ji-mpls-tp-bidirectional-label-00.txt Abstract This document describes a new mechanism for the label allocation of co-routed bidirectional point-to-point paths in MPLS Transport Profile (MPLS-TP) networks, which is called the bidirectional label allocation mechanism. The nodes on co-routed bidirectional point-to- point paths will not need to record the label pairing relationship of the forward and the backward directions in this mechanism because the labels are symmetrical. In addition, the compression of the LIB becomes possible because of the existing of symmetrical elements. We would appreciate reviews and comments for our document. Best Regards Zongpeng Du ============================================== Zongpeng Du BUPT Address: P.O.Box 90, Beijing University of Posts and Telecommunications No.10, Xitucheng Road, Haidian District, Beijing, China, 100876 Tel: +86-010-62282905-807 EMail: duzongpeng@gmail.com ============================================== --0016e64354569ffe2204838a46f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear MPLS WG:

Please be aware that we submitted a new WG document,
Bidirectional Label Assignment in MPLS-TP
draft-ji-mpls-tp-bidirec= tional-label-00
http://tools.ietf.org/id/draft-j= i-mpls-tp-bidirectional-label-00.txt

Abstract
This document describes a new mechanism for the label alloc= ation of co-routed bidirectional point-to-point paths in MPLS Transport Pro= file (MPLS-TP) networks, which is called the bidirectional label allocation= mechanism. The nodes on co-routed bidirectional point-to- point paths will= not need to record the label pairing relationship of the forward and the b= ackward directions in this mechanism because the labels are symmetrical. In= addition, the compression of the LIB becomes possible because of the exist= ing of symmetrical elements.

We would appreciate reviews and comments for our document.

Best = Regards

Zongpeng Du

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Zongpeng Du
BUPT
Address: P.O.Box 90, Bei= jing University of Posts and Telecommunications
No.10, Xitucheng Road, Haidian District, Beijing, China, 100876
Tel: +86= -010-62282905-807
EMail: duzongp= eng@gmail.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

--0016e64354569ffe2204838a46f8-- From curtis@occnc.com Sat Apr 10 20:43:26 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59E23A6816; Sat, 10 Apr 2010 20:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wed+fsjwIQi; Sat, 10 Apr 2010 20:43:25 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 36A113A6781; Sat, 10 Apr 2010 20:43:25 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o3B3hEAv095631; Sat, 10 Apr 2010 23:43:14 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004110343.o3B3hEAv095631@harbor.orleans.occnc.com> To: "BUSI ITALO" From: Curtis Villamizar In-reply-to: Your message of "Fri, 09 Apr 2010 09:39:52 +0200." <6FD21B53861BF44AA90A288402036AB4030B235B@FRVELSMBS21.ad2.ad.alcatel.com> Date: Sat, 10 Apr 2010 23:43:14 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org, MPLS-TP ad hoc team , CCAMP , mpls-tp@ietf.org, pwe3@ietf.org, curtis@occnc.com Subject: Re: [mpls] [CCAMP] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 03:43:26 -0000 In message <6FD21B53861BF44AA90A288402036AB4030B235B@FRVELSMBS21.ad2.ad.alcatel.com> "BUSI ITALO" writes: > > Curtis, > > I agree that FM OAM must run at the highest priority within an LSP. > > However, PM OAM must run at the priority it is measuring. > > Italo Italo, It would be best if the documents allowed FM to be run at one priority. This should be constrained (at least with a SHOULD) to be the lowest priority for which congestion cannot occur by virtue of the SLA, the resource reservations, and policing, or a priority higher than traffic if all traffic is not policed. PM should be allowed to be run at any priority, including run at multiple priorities. Curtis > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effective since 1 November 2009. > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > > On Behalf Of Curtis Villamizar > > Sent: venerdì 9 aprile 2010 6.30 > > To: Shahram Davari > > Cc: MPLS-TP ad hoc team; mpls@ietf.org; CCAMP; > > mpls-tp@ietf.org; pwe3@ietf.org > > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last > > call ondraft-ietf-mpls-tp-framework-11 > > > > > > In message > > <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.a > > d.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi John, > > > > > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if > > > any of them fail do protection switching for all of them? > > What will be > > > the definition of availability for such E-LSP? > > > > > > Thanks > > > SD > > > > > > If there were multiple priorities on an LSP the OAM should be > > at a high priority. For example for CS service (the old IP > > prec) CS6 is normally used for control traffic. If OAM > > failed for CS6 the link is down. If OAM fails for CS0 the > > link may just be oversubscribed and contested but CS0 is > > defined as the best effort (BE) service. > > > > A provider may choose to do this. For example, if VOIP ran > > at CS4 and worked fine and web and email was runnig on CS0, > > phone would work and web would be slow. If a natural > > disaster took out 3/4 of the network capacity, then having > > working phone and slow web and maybe unworkable web streaming > > video might be better than prohibiting oversubscription and > > having no service at all. > > > > Curtis From curtis@occnc.com Sat Apr 10 21:50:10 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9603A3A67F7 for ; Sat, 10 Apr 2010 21:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.296 X-Spam-Level: * X-Spam-Status: No, score=1.296 tagged_above=-999 required=5 tests=[AWL=-2.971, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, MANGLED_PLEASE=2.3, MANGLED_WORKNG=2.3, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfjOFxSiV273 for ; Sat, 10 Apr 2010 21:50:10 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 0EAE93A6928 for ; Sat, 10 Apr 2010 21:50:09 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o3B4o1Ou096475; Sun, 11 Apr 2010 00:50:01 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004110450.o3B4o1Ou096475@harbor.orleans.occnc.com> To: Greg Mirsky From: Curtis Villamizar In-reply-to: Your message of "Fri, 09 Apr 2010 00:33:56 PDT." Date: Sun, 11 Apr 2010 00:50:01 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org, MPLS-TP ad hoc team , BUSI ITALO , CCAMP , mpls-tp@ietf.org, pwe3@ietf.org Subject: Re: [mpls] [mpls-tp] [CCAMP] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 04:50:10 -0000 In message Greg Mirsky writes: > > > Dear Italo, if we consider Link Bundle (RFC 4201) then it is possible > that some CoS flows are being mapped to a different component > links. In this case per CoS FM is quite necessary. > > Regards, > Greg Greg, That would be a broken implementation. The AF service occupies 3 TC values and is supposed to remain in order. There is no document that suggests this behaviour. Curtis > On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO > wrote: > > > I think that running OAM flows per-PHB, while very much appropriate for > > PM tools (as already documented in the OAM frameworkd draft), is actually= > an > > overdesign for FM tools. > > > > Misconnections and failures are per-LSP and not per-PHB. > > > > Italo > > > > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, > > effective since 1 November 2009. > > > > > > ------------------------------ > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > > Of *David Allan I > > *Sent:* gioved=EC 8 aprile 2010 21.45 > > *To:* Greg Mirsky; Shahram Davari > > *Cc:* mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; > > mpls-tp@ietf.org > > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last callon > > draft-ietf-mpls-tp-framework-11 > > > > I'm not quite following this argument.... > > > > If I have a number of co-routed paths with different PHBs, I can > > instantiate a number of L-LSPs, which is a significant amount of state at > > every hop, or I can instantiate one E-LSP, which is an N:1 compression in > > the amount of state in transit nodes. > > > > The only wrinkle is all PHBs of an E-LSP fate share. But then if I was > > protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or > > another E-LSP, and if they were co-routed, the majority of failure cases > > (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was > > switched (although there would be 'n' signal fail indications internally = > to > > contend with). Overall, it sounds to me like an E-LSP may be a bit faster > > there.... > > > > The actual OAM load to instrument them equally is the same. If an E-LSP > > takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? = > I > > appreciate that the ability to generate per PHB flows may be undesirable = > for > > some, but that does not make it a bad idea. > > > > IMO there is no penalty for supporting E-LSPs and there are measurable > > benefits. The analysis is flawed. > > > > my 2 cents > > D > > > > ------------------------------ > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > > Of *Greg Mirsky > > *Sent:* Thursday, April 08, 2010 3:31 PM > > *To:* Shahram Davari > > *Cc:* mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; > > pwe3@ietf.org > > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last call on > > draft-ietf-mpls-tp-framework-11 > > > > Dear Shahram, > > I share your concern regarding applicability of E-LSP in packet transport > > network. Though the document is about the Transport Profile, references t= > o > > MPLS-TP as packet transport network technology been changed recently. Now > > MPLS-TP is referred as "packet network". It is my understanding that > > applicability of MPLS-TP functionality, features and capabilities to the > > packet transport network will be decided later, separately. > > Regarding classes of service in the transport. Neil Harrison pointed > > several times that a connection, transport path cannot have multiple > > classes, otherwise it leads to significant increased complexity of OAM, > > which has to be (SHOULD) per Class of Service per E-LSP. > > > > Regards, > > Greg > > > > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrot= > e: > > > >> Hi Loa, > >> > >> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. A= > s > >> we know traditional transport layers only have one CoS. However E-LSP ha= > s > >> multiple CoS, which can reorder packets (I know that the reorder packets > >> belong to different CoS). Additionally the definition of E-LSP OAM and > >> performance and protection and availability, etc will be questionable > >> (because of carrying multiple CoS). > >> > >> Therefore I think E-LSP should not be supported in MPLS-TP or at least > >> should be discouraged. > >> > >> Regards, > >> Shahram > >> > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > >> Loa Andersson > >> Sent: Saturday, April 03, 2010 2:31 AM > >> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > >> CCAMP > >> Subject: [PWE3] short working group last call on > >> draft-ietf-mpls-tp-framework-11 > >> > >> All, > >> > >> this is to start a short working group last call on "A Framework > >> for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > >> > >> Please note that this wg last call is limited to verify that comments > >> raised during the orevious working group last call and reviews have > >> been correctly addressed. > >> > >> Please sen comments to the mpls-tp mailing list on April 17th, the > >> latest. > >> > >> /Loa > >> -- > >> > >> > >> Loa Andersson email: loa.andersson@ericsson.com > >> Sr Strategy and Standards Manager loa@pi.nu > >> Ericsson Inc phone: +46 10 717 52 13 > >> +46 767 72 92 13 > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > > > > > > --0016e640918a65a9f00483c8d1cb > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Dear Italo,
if we consider Link Bundle (RFC 4201) then it is possible th= > at some CoS flows are=A0 being mapped to a different component links. In th= > is case per CoS FM is quite necessary.

Regards,
Greg

class=3D"gmail_quote"> > On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO < =3D"mailto:Italo.Busi@alcatel-lucent.com">Italo.Busi@alcatel-lucent.com= > > wrote:
t 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1= > ex;"> > > > > >
>
ce=3D"Arial">I think that running OAM flows per-PHB, while very much=20 > appropriate for PM tools (as already documented in the OAM frameworkd draft= > ), is=20 > actually an overdesign for FM tools.
>
ce=3D"Arial">=A0
>
ce=3D"Arial">Misconnections and failures are per-LSP and not=20 > per-PHB.
>
ce=3D"Arial">=A0
>
ce=3D"Arial">Italo

>

P.S. Please note my new email address,=20 > Italo.Bu= > si@alcatel-lucent.com, effective since 1 November 2009.

>
=A0

>
: 2px solid rgb(0, 0, 255); margin-right: 0px;"> >
>
> From: nces@ietf.org" target=3D"_blank">ccamp-bounces@ietf.org=20 > [mailto:ccamp= > -bounces@ietf.org] On Behalf Of David Allan=20 > I
Sent: gioved=EC 8 aprile 2010 21.45
To: Greg Mirsky= > ;=20 > Shahram Davari
Cc: blank">mpls@ietf.org; CCAMP; MPLS-TP ad hoc team;=20 > pwe3@ietf.org; href=3D"mailto:mpls-tp@ietf.org" target=3D"_blank">mpls-tp@ietf.org
= > Subject: Re: [CCAMP] [mpls] [PWE3]=20 > short working group last callon=20 > draft-ietf-mpls-tp-framework-11

class=3D"h5"> >
>
face=3D"Arial">I'm not quite following this=20 > argument....
>
face=3D"Arial">=A0
>
face=3D"Arial">If I have a number of co-routed paths with different=20 > PHBs, I can instantiate a number of L-LSPs, which is a significant amount= > of=20 > state at every hop, or I can instantiate=A0one E-LSP, which is an N:1=20 > compression in the amount of state in transit nodes.
>
face=3D"Arial">=A0
>
face=3D"Arial">The only wrinkle is all PHBs of an E-LSP fate share. But=20 > then if I was protecting=A0the L-LSP or the E-LSP version=A0I'd have= > =20 > another 'n' L-LSPs or another E-LSP, and if they were co-routed, = > the majority=20 > of failure cases (link cuts) would result in a loud clang as many=20 > L-LSPs=A0vs. one E-LSP was switched (although there would be 'n' = > signal=20 > fail indications internally to contend with).=A0Overall, it sounds to me= > =20 > like an E-LSP may be a bit faster there....
>
face=3D"Arial">=A0
>
face=3D"Arial">The actual OAM load to instrument them equally is the=20 > same. If an E-LSP takes 'n' times the flows to be instumented lik= > e 'n' L-LSPs=20 > so=A0what????=A0=A0I appreciate that the ability to generate per PHB=20 > flows may be undesirable for some, but that does not make it a bad=20 > idea.
>
face=3D"Arial">=A0
>
face=3D"Arial">IMO there is no penalty for supporting E-LSPs and there=20 > are measurable benefits. The analysis is flawed.
>
face=3D"Arial">=A0
>
face=3D"Arial">my 2 cents
>
face=3D"Arial">D

>
>
> From: nces@ietf.org" target=3D"_blank">ccamp-bounces@ietf.org=20 > [mailto:ccamp= > -bounces@ietf.org] On Behalf Of Greg=20 > Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Sha= > hram=20 > Davari
Cc: m= > pls@ietf.org; MPLS-TP ad hoc team; CCAMP;=20 > mpls-tp@ietf.org >; pwe3@ietf.org
= > Subject: Re: [CCAMP] [mpls] [PWE3]=20 > short working group last call on=20 > draft-ietf-mpls-tp-framework-11

>
Dear Shahram,
I share your concern regarding applicability = > of=20 > E-LSP in packet transport network. Though the document is about the Trans= > port=20 > Profile, references to MPLS-TP as packet transport network technology bee= > n=20 > changed recently. Now MPLS-TP is referred as "packet network". = > It is my=20 > understanding that applicability of MPLS-TP functionality, features and= > =20 > capabilities to the packet transport network will be decided later,=20 > separately.
Regarding classes of service in the transport. Neil Harris= > on=20 > pointed several times that a connection, transport path cannot have multi= > ple=20 > classes, otherwise it leads to significant increased complexity of OAM, w= > hich=20 > has to be (SHOULD) per Class of Service per=20 > E-LSP.

Regards,
Greg

>
On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davar= > i < lank">davari@broadcom.com>=20 > wrote:
>
0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);">Hi=20 > Loa,

The draft mentions that both L-LSP and E-LSP are supported = > in=20 > MPLS-TP. As we know traditional transport layers only have one CoS. How= > ever=20 > E-LSP has multiple CoS, which can reorder packets (I know that the reor= > der=20 > packets belong to different CoS). Additionally the definition of E-LSP = > OAM=20 > and performance and protection and availability, etc will be questionab= > le=20 > (because of carrying multiple CoS).

Therefore I think E-LSP shou= > ld=20 > not be supported in MPLS-TP or at least should be=20 > discouraged.

Regards,
Shahram
>
>
>

-----Original Message-----
From: nces@ietf.org" target=3D"_blank">pwe3-bounces@ietf.org [mailto: =3D"mailto:pwe3-bounces@ietf.org" target=3D"_blank">pwe3-bounces@ietf.org a>] On Behalf Of=20 > Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: =3D"mailto:mpls-tp@ietf.org" target=3D"_blank">mpls-tp@ietf.org; f=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; MPLS-TP ad = > hoc team; pwe3@ietf.org<= > /a>; CCAMP
> Subject: [PWE3]=20 > short working group last call on=20 > draft-ietf-mpls-tp-framework-11

All,

this is to start a s= > hort=20 > working group last call on "A Framework
for MPLS in Transport N= > etworks"=20 > (draft-ietf-mpls-tp-framework-11).

Please note that this wg last= > call=20 > is limited to verify that comments
raised during the orevious workin= > g=20 > group last call and reviews have
been correctly addressed.

Pl= > ease=20 > sen comments to the mpls-tp mailing list on April 17th,=20 > the
latest.

/Loa
--


Loa Andersson =A0 =A0=20 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:=20 > loa.and= > ersson@ericsson.com
Sr=20 > Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0 :loa@pi.nu" target=3D"_blank">loa@pi.nu
Ericsson Inc =A0 =A0 =A0=20 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:=20 > +46 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 > =A0 =A0 =A0 =A0+46 767 72 92=20 > 13
_______________________________________________
pwe3 mailing= > =20 > list
pwe3@ietf.or= > g
blank">https://www.ietf.org/mailman/listinfo/pwe3


v>_______________________________________________
> mpls=20 > mailing list
mpls= > @ietf.org
get=3D"_blank">https://www.ietf.org/mailman/listinfo/mpls
te> >

>

> > --0016e640918a65a9f00483c8d1cb-- > > --===============1523831359== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > --===============1523831359==-- From stbryant@cisco.com Sun Apr 11 01:04:00 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFC53A68DF; Sun, 11 Apr 2010 01:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.767 X-Spam-Level: X-Spam-Status: No, score=-9.767 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpFaXmBIijqH; Sun, 11 Apr 2010 01:03:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6D0073A6767; Sun, 11 Apr 2010 01:03:59 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0LABQfwUtAaMHG/2dsb2JhbACPOYtDSHGdPIFRCgGWQYUMBA X-IronPort-AV: E=Sophos;i="4.52,184,1270425600"; d="scan'208";a="113525099" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 11 Apr 2010 08:03:52 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3B83lNd028379; Sun, 11 Apr 2010 08:03:48 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o3B83jX29504; Sun, 11 Apr 2010 09:03:45 +0100 (BST) Message-ID: <4BC18261.1010800@cisco.com> Date: Sun, 11 Apr 2010 09:03:45 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 References: <201004110450.o3B4o1Ou096475@harbor.orleans.occnc.com> In-Reply-To: <201004110450.o3B4o1Ou096475@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] [mpls-tp] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 11 Apr 2010 08:04:00 -0000 In Loa's original mail he says "Please send comments to the mpls-tp mailing list..." Please can we continue this discussion on ONLY that list (mpls-tp@ietf.org). Thanks Stewart From vishwas.ietf@gmail.com Sun Apr 11 17:18:10 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734323A677E; Sun, 11 Apr 2010 17:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUu2Wz-HPIQi; Sun, 11 Apr 2010 17:18:09 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id B20023A63EC; Sun, 11 Apr 2010 17:18:08 -0700 (PDT) Received: by yxe9 with SMTP id 9so2611656yxe.29 for ; Sun, 11 Apr 2010 17:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=C7S4QHCwwjzmk29AKuqUoC91LbbcWyo3ziRpE3QKxG0=; b=DPRBmha3sDQiA0yssGZFMquLdFhy6LJ0Hsi8u2gHI51tPE9BPBf7+yRu1TA5gU+ebu 8FxtK0ElG1WU928/Z5tusifaA9Ytrn6iY6PMfbjfv8PbHx22uRJbhAPxOXsiy2+JhBMw WmLvK0mPoOlRWo7CfFGA1JGE5Xy9thhGthAz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gWWgNsiWJUEZFAFmbNd+yz7bXhqxcb3hKtGYrWdt/blRadEw5bHmUdw1sHvv4GezEH duLTh1Or8Zdshl2VvD4yeIjHEZym8K2EYF641GQCh4daj1wtT3PPSReoW9fEtqLo9xC6 P9uob+rKy1E+odi06O0wSQ5pAdsx3hyBIb1tQ= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Sun, 11 Apr 2010 17:17:58 -0700 (PDT) In-Reply-To: <4BBEE98B.3090805@pi.nu> References: <4BBEE98B.3090805@pi.nu> Date: Sun, 11 Apr 2010 17:17:58 -0700 Received: by 10.151.28.16 with SMTP id f16mr2764799ybj.124.1271031478456; Sun, 11 Apr 2010 17:17:58 -0700 (PDT) Message-ID: From: Vishwas Manral To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, MPLS-TP ad hoc team , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] team to drive a BFD based solution for CC, CV and RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 00:18:10 -0000 Hi Loa, Thanks for bringing this UP. I see a lot of basic gaps in the spec. On a first read this is what I found: 1. I did not understand why we have a seperate CC and CC/CV mode. In other words when would CV not be required? Some justification on why some decisions have been taken would be helful, rather than just the packet formats. 2. If we have CV it is good to be able to allow different packet sizes te test a packet. So the packet should be like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Flags |0xHH MPLS-TP CV/CC Code Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Unique MEP-ID of source of the BFD packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. For BFD profile for MPLS-TP we should probably clarify that echo function in the asynch mode is not supported. 4. I think an error BFD packet should not bring the BFD session to down. The draft states that: On a Sink MEP, a BFD session is declared Down if one of the following defects identified by the proactive CC-CV functions occurs: - an unexpected globally unique Source MEP identifier is received An error BFD packet in my view should be discraded and the respective conutners need to be updated. 5. The Admin Down state section unnecessarily confuses/ breaks the BFD specification (for bidirectional sessions). It states that: When the MEP source function is disabled, BFD Control packets SHOULD be sent in AdminDown state for a period equal to (bfd.DesiredMinTxInterval * bfd.DetectMult) in order to ensure that the remote system is aware of the state change. However a packet is never sent at but also is based on the peers RxInterval and we should not voilate the same. So BFD packets should be sent "at least" till bfdSessNegotiatedInterval * bfdDetectMult and can be sent for more. Note this interval can be bigger than the interval you have specified in your document. 6. Section 3.4.2 should be clarified with respect to the slow timer and fast timer, as that is how BFD sessions are currently controlled. Also this section seems to change the BFD behavior but does not clarify the same. Should the "Required Min RX Interval" be a big value greater than the peer "esired Min TX Interval field"? If so an explicit statement for the same needs to be added. 7. Section 3.4.2 should come before 3.4.1. Thanks again, Vishwas On Fri, Apr 9, 2010 at 1:47 AM, Loa Andersson wrote: > All, > > For some time the mpls working group chairs have been very > concerned about the lack of progress on a BFD based solution > for CV, CC and RDI. > > To improve on this situation the working group chairs have decided > to create a team modeled after how we worked with the LDP specification > when we started up the MPLS work. > > The new team will work based on a mandate from the working group > chairs, with clear instructions progress the draft in such a way > that author contributions are recognized, that the IETF expertise > on BFD is involved and to seek a quick rough consensus among the > authors. > > Note that this means that the people currently involved in the > draft-asm remain as authors. > > We will therefore have one team of editors consisting of > > Dave Allan > George Swallow > John Drake > > That is mainly responsible for driving the effort and make > sure that we are making good progress. > > The full team of authors will also include the > current authors of the document, i.e.: > > Sami Boutros > Annamaria Fulignoli > Martin Vigoureux > Siva Sivabalan > David Ward > > > /Loa > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From wwwrun@core3.amsl.com Mon Apr 12 01:12:34 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E5DE93A6972; Mon, 12 Apr 2010 01:12:34 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100412081234.E5DE93A6972@core3.amsl.com> Date: Mon, 12 Apr 2010 01:12:34 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, malcolm.betts@zte.com.cn, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS-162 - Comments on draft-ietf-mpls-tp-data-plane-01 [Ref # 023.02]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 08:12:35 -0000 Title: LS-162 - Comments on draft-ietf-mpls-tp-data-plane-01 [Ref # 023.02] Submission Date: 2010-04-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=867 Please reply by 2010-04-27 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@zte.com.cn Purpose: For action Body: Thank you for your liaison statement (Ref # 023.01) requesting a review by the ITU-T of the MPLS-TP data plane draft. The experts of Q.12/15 have reviewed draft-ietf-mpls-tp-data-plane-01 by correspondence. The comments and proposed changes shown in the attached marked up draft were provided by a number of experts and do not necessarily represent a consensus view of all of the experts of Q.12. Considering the magnitude of these changes we request that we have another opportunity to review the resolution of these and any other comments, before this draft is forwarded for approval. See attachment Attachment(s): LS-162 - Comments on draft-ietf-mpls-tp-data-plane-01 [Ref # 023.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file978.pdf) LS-162 - Comments on draft-ietf-mpls-tp-data-plane-01 [Ref # 023.02] - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file979.pdf) From wwwrun@core3.amsl.com Mon Apr 12 01:18:52 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B73C528C0ED; Mon, 12 Apr 2010 01:18:51 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100412081851.B73C528C0ED@core3.amsl.com> Date: Mon, 12 Apr 2010 01:18:51 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, malcolm.betts@zte.com.cn, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS163 - Comments on draft-ietf-mpls-tp-identifiers-01 [Ref # 022.02]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 08:18:52 -0000 Title: LS163 - Comments on draft-ietf-mpls-tp-identifiers-01 [Ref # 022.02] Submission Date: 2010-04-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=868 Please reply by 2010-04-25 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@zte.com.cn Purpose: For action Body: Thank you for your liaison statement (Ref # 022.01) requesting a review by the ITU-T of the MPLS-TP identifiers draft. The experts of Q.12/15 have reviewed draft-ietf-mpls-tp-identifiers-01 by correspondence. We were surprised to find that a draft in Working Group last call included section 8 Open Issues. The issues identified in this section must be resolved before approval. The comments and proposed changes shown in the attached marked up draft were provided by a number of experts and do not necessarily represent a consensus view of all of the experts of Q.12. Considering the magnitude of these changes we request that we have another opportunity to review the resolution of these and any other comments, before this draft is forwarded for approval. See attachment Attachment(s): LS163 - Comments on draft-ietf-mpls-tp-identifiers-01 [Ref # 022.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file980.pdf) LS163 - Comments on draft-ietf-mpls-tp-identifiers-01 [Ref # 022.02] - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file981.pdf) From wwwrun@core3.amsl.com Mon Apr 12 01:34:29 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4849C3A6A09; Mon, 12 Apr 2010 01:34:29 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100412083429.4849C3A6A09@core3.amsl.com> Date: Mon, 12 Apr 2010 01:34:29 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS164 - Response to MPLS-TP ACH TLV Structure -02 WG Last Call (ref # 020.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 08:34:29 -0000 Title: LS164 - Response to MPLS-TP ACH TLV Structure -02 WG Last Call (ref # 020.02) Submission Date: 2010-04-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=869 Please reply by 2010-04-26 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Kam.Lam@alcatel-lucent.com Purpose: For action Body: Attachment(s): LS164 - Response to MPLS-TP ACH TLV Structure -02 WG Last Call (ref # 020.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file982.pdf) From loa@pi.nu Mon Apr 12 02:50:58 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3193A6964; Mon, 12 Apr 2010 02:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUP+4jF14sIV; Mon, 12 Apr 2010 02:50:57 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id DF7873A68DF; Mon, 12 Apr 2010 02:50:55 -0700 (PDT) Received: from [172.16.4.76] (static-213-115-148-132.sme.bredbandsbolaget.se [213.115.148.132]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 7542CD404F; Mon, 12 Apr 2010 11:50:48 +0200 (CEST) Message-ID: <4BC2ECF8.5090309@pi.nu> Date: Mon, 12 Apr 2010 11:50:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "mpls-tp@ietf.org" , MPLS-TP ad hoc team , mpls@ietf.org References: <4BAD5B78.5000808@pi.nu> In-Reply-To: <4BAD5B78.5000808@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] mpls working group last calls on mpls-tp documents - has ended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 09:50:58 -0000 All, the mpls working group last call on as referenced in the mail on mpls wg group last call schedule in the mail for 2010-03-27: MPLS-TP Survivability Framework draft-ietf-mpls-tp-survive-fwk The ongoing MPLS working group last call will end on April 11 MPLS-TP Data plane draft-ietf-mpls-tp-data-plane The ongoing MPLS working group last call will end on April 11 MPLS-TP Identifiers draft-ietf-mpls-tp-identifiers-00 The ongoing MPLS wg last call will end on April 11 has ended. Could the authors please address the comments and publish new versions of the documents. /Loa On 2010-03-27 02:12, Loa Andersson wrote: > Working Group(s), Ad Hoc Team > > Offline the mpls-tp working group chairs, ADs and for part of the > time the ITU-T SG15 Rapporteurs attending the meeting in Anaheim > have spent time during the IETF week on the issue how to get a > high-quality standard out of the joint mpls-tp project. The > IETF leadership still see great value in keeping to the schedule > we've been working on for the last 9 months and is quite optimistic > about getting a high-quality work done on time. > > The working group chairs have agreed to extend the working group > last call schedule. > > We have made the following extensions/changes for the mpls-tp > project drafts that is currently in (or soon will be) in mpls > wg last call: > > > OAM Acronyms draft-ietf-opsawg-mpls-tp-oam-def > The OPSAWG wg last call will start on March 29 and end on April 18 > > > MPLS-TP Framework draft-ietf-mpls-tp-framework > The MPLS wg last call will start on April 5 and end on April 18 > > > MPLS-TP OAM Framework draft-ietf-mpls-tp-oam-framework > The ongoing MPLS wg last call will end on April 1 > > MPLS-TP Survivability Framework draft-ietf-mpls-tp-survive-fwk > The ongoing MPLS working group last call will end on April 11 > > > MPLS-TP Data plane draft-ietf-mpls-tp-data-plane > The ongoing MPLS working group last call will end on April 11 > > > ACH-TLV structure draft-ietf-mpls-tp-ach-tlv > The ongoing MPLS wg last call will end on April 12 > > > MPLS-TP Identifiers draft-ietf-mpls-tp-identifiers-00 > The ongoing MPLS wg last call will end on April 11 > > The latest version of a excel schedule that has been discussed > is included in this mail. I'd lake to poll for working group(s) > for comments on the schedule. As usual send these comments to > the mpls-tp mailing list only. > > /Loa > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wwwrun@core3.amsl.com Mon Apr 12 03:16:28 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3C1E23A68EB; Mon, 12 Apr 2010 03:16:28 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100412101628.3C1E23A68EB@core3.amsl.com> Date: Mon, 12 Apr 2010 03:16:28 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS161 - MPLS-TP Survivability Framework draft reviewed (ref # 021.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 10:16:28 -0000 Title: LS161 - MPLS-TP Survivability Framework draft reviewed (ref # 021.02) Submission Date: 2010-04-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=870 Please reply by 2010-04-25 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: hhelvoort@huawei.com Purpose: For action Body: Attachment(s): LS161 - MPLS-TP Survivability Framework draft reviewed (ref # 021.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file983.pdf) LS161 - MPLS-TP Survivability Framework draft reviewed (ref # 021.02) - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file984.pdf) From N.Leymann@telekom.de Mon Apr 12 04:44:12 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BAAC3A67E2 for ; Mon, 12 Apr 2010 04:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlTt0IPuzFya for ; Mon, 12 Apr 2010 04:44:11 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 315683A682D for ; Mon, 12 Apr 2010 04:44:11 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 12 Apr 2010 13:42:58 +0200 Received: from S4DE9JSAAIB.ost.t-com.de ([10.125.177.167]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Apr 2010 13:42:58 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Apr 2010 13:43:02 +0200 Message-ID: <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] LDP IPv6 Thread-Index: AcrVvwtDL4N6oFirRlKbXiuQz9xwswEbzrzw References: From: To: X-OriginalArrivalTime: 12 Apr 2010 11:42:58.0314 (UTC) FILETIME=[4C62B6A0:01CADA35] Subject: Re: [mpls] LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 11:44:12 -0000 Hi,=20 I think that IPv6 for LDP is getting more and more important. Even with = private IPv4 addresses - depending on network size and addressing scheme = - for mid and long term it is definitely a good idea to take IPv6 into = account! I've also a short comment regarding the draft. It states: "This document preserves the usage of 32-bit LSR Id on an IPv6 only LSR and allows the usage of a common LDP identifier i.e. same LSR-Id and same Label space id for IPv4 and IPv6 on a dual-stack LSR. This rightly enables the per-platform label space to be shared between IPv4 and IPv6." At the moment providers tend to use an IPv4 address as LSR ID and I = wonder about the operational impact if this is going to be moved towards = a more abstract ID. Regards Nic -----Urspr=FCngliche Nachricht----- Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von = Vishwas Manral Gesendet: Dienstag, 6. April 2010 21:23 An: mpls@ietf.org Betreff: [mpls] LDP IPv6 Hi folks, http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03 We have a new version of the LDP IPv6 draft. The draft has been around since 2008, however we are now seeing operators asking for it (and can be seen in some discussions in the RIPE mailing lists). We would want to hear comments on the same from the list. Thanks, Vishwas _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From vishwas.ietf@gmail.com Mon Apr 12 07:55:35 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F913A6853 for ; Mon, 12 Apr 2010 07:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBMd9+54bcRB for ; Mon, 12 Apr 2010 07:55:34 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 5E6993A67D9 for ; Mon, 12 Apr 2010 07:55:34 -0700 (PDT) Received: by ywh38 with SMTP id 38so2866846ywh.29 for ; Mon, 12 Apr 2010 07:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QP1rPKXmO7JhqRtRXmVEQDl2+h+iRbVHCtsp2x0Rclw=; b=jF+covw6ZV4RArQD61FMaw+RCTbOp6P3ahfbNgVkxI5ENH9z9xZkqob/rlL4w4Jkhr /HdoQHpXQcWZvSXFHjPNLSbQlGdUrYS9lLDr6H0hOV2qqeAbnakqThnS4aZ5r5KYtgPy +OqHQUut5yaXsHqANQTIJlvTcrOLwpqoF4Cn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ffc/Gv62pkXhadHrvWG1GLNUyWz+kUBDcDgcdLZSS9xqvEBNwlq0j0xmSm9Htu7gu5 w2qmmMkmyg6ZQrrQrIO0P6ytmaZoa3nhkBtRiFsqPaWJn3wtwFNtnLR0T76xRQOEC7hy rKVhXpEV1ZVubq3ou0CmeVkAXH9rqitzEOnKw= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Mon, 12 Apr 2010 07:55:26 -0700 (PDT) In-Reply-To: <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> References: <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> Date: Mon, 12 Apr 2010 07:55:26 -0700 Received: by 10.151.92.9 with SMTP id u9mr2605747ybl.336.1271084126320; Mon, 12 Apr 2010 07:55:26 -0700 (PDT) Message-ID: From: Vishwas Manral To: N.Leymann@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:55:35 -0000 Hi Nic, We now see the requirement from a few carriers like Trentino Network and a few others for IPv6 in the core, which they want to deploy now. They have actually made these requirements on the field. I agree its probably not the same with the bigger carriers yet. For the TE extensions for IPv6 in Routing protocols we still assume the Router ID is 32 bits, so that remains the same with LDP. Though I think LSR-ID 32 bit should not make a difference in the LDP context, if however we need a routable IPv6 address loopback address was required, we could advertize that as a seperate TLV which could map on a one-to-one basis to an IPv6 address. Let me look further into this and get back to you. Thanks, Vishwas On Mon, Apr 12, 2010 at 4:43 AM, wrote: > Hi, > > I think that IPv6 for LDP is getting more and more important. Even with p= rivate IPv4 addresses - depending on network size and addressing scheme - f= or mid and long term it is definitely a good idea to take IPv6 into account= ! > > I've also a short comment regarding the draft. It states: > > =A0"This document preserves the usage of 32-bit LSR Id on an IPv6 only > =A0 LSR and allows the usage of a common LDP identifier i.e. same LSR-Id > =A0 and same Label space id for IPv4 and IPv6 on a dual-stack LSR. This > =A0 rightly enables the per-platform label space to be shared between > =A0 IPv4 and IPv6." > > At the moment providers tend to use an IPv4 address as LSR ID and I wonde= r about the operational impact if this is going to be moved towards a more = abstract ID. > > =A0Regards > > =A0 =A0Nic > > -----Urspr=FCngliche Nachricht----- > Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von = Vishwas Manral > Gesendet: Dienstag, 6. April 2010 21:23 > An: mpls@ietf.org > Betreff: [mpls] LDP IPv6 > > Hi folks, > > http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03 > > We have a new version of the LDP IPv6 draft. The draft has been around > since 2008, however we are now seeing operators asking for it (and can > be seen in some discussions in the RIPE mailing lists). > > We would want to hear comments on the same from the list. > > Thanks, > Vishwas > _______________________________________________ > 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 wwwrun@core3.amsl.com Mon Apr 12 08:53:22 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CC11F3A67EB; Mon, 12 Apr 2010 08:53:22 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100412155322.CC11F3A67EB@core3.amsl.com> Date: Mon, 12 Apr 2010 08:53:22 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, " Liaison in response to COM15-LS151-E ref:18.02 (ref #018.03)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 15:53:22 -0000 Title: Liaison in response to COM15-LS151-E ref:18.02 (ref #018.03) Submission Date: 2010-04-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=871 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For information Body: Attachment(s): Liaison in response to COM15-LS151-E ref:18.02 (ref #018.03) (https://datatracker.ietf.org/documents/LIAISON/file985.doc) From vishwas.ietf@gmail.com Mon Apr 12 09:45:34 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D66B3A6AC5 for ; Mon, 12 Apr 2010 09:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mgCm8xSxEtX for ; Mon, 12 Apr 2010 09:45:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 7DB503A6A1F for ; Mon, 12 Apr 2010 09:40:56 -0700 (PDT) Received: by gwb1 with SMTP id 1so1263679gwb.31 for ; Mon, 12 Apr 2010 09:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lHIzmkFrfIZ1ExvnE7GdRjXyK2Mea+U1Bun3Ggi9cD0=; b=PJaQ0grO3psUr+hWB3+0ZhVgOH/0ZhNI8lA54Kbzji5BE6lD8+NmxMxs7EHzNps1HA AitKxS1ESs4xvv8KUeBOwKwUiHY2ePfoz9OO6jRa4pmL7fsT30zFgRjfGIk/H2p856At wBO1tZLc1ArQq2ib/398hvRlfMTQm+kM8M+9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DD5Q5yitleQKJohEmlORNORl/EvEd3KZK7h54DwJidGXFaUmALth2YYK8p0wWftLm7 Zr1jf6xF6n+V31f5V1l7//E7ejxXrvF5lpP0m2IcWVKBFHn65OiFjf2xQ0UvUtkJA1Ip 3U/Jfqd3C1yiFVO/brESFONxlv6t8mJ5Oie/A= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Mon, 12 Apr 2010 09:40:47 -0700 (PDT) In-Reply-To: References: <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> Date: Mon, 12 Apr 2010 09:40:47 -0700 Received: by 10.150.165.20 with SMTP id n20mr4020230ybe.316.1271090447797; Mon, 12 Apr 2010 09:40:47 -0700 (PDT) Message-ID: From: Vishwas Manral To: N.Leymann@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 16:45:34 -0000 Hi Nic, I noticed that RFC 5329 has the Router IPv6 Address TLV. Does this serve your purpose or not? BTW, thanks a lot for supporting this effort. Like I said I know a lot of operators (maily Europe and Asia) want the specs for this to be finalized and I am just hoping they can speak up in the mailing list too. Thanks, Vishwas On Mon, Apr 12, 2010 at 7:55 AM, Vishwas Manral wr= ote: > Hi Nic, > > We now see the requirement from a few carriers like Trentino Network > and a few others for IPv6 in the core, which they want to deploy now. > They have actually made these requirements on the field. I agree its > probably not the same with the bigger carriers yet. > > For the TE extensions for IPv6 in Routing protocols we still assume > the Router ID is 32 bits, so that remains the same with LDP. > > Though I think LSR-ID 32 bit should not make a difference in the LDP > context, if however we need a routable IPv6 address loopback address > was required, we could advertize that as a seperate TLV which could > map on a one-to-one basis to an IPv6 address. > > Let me look further into this and get back to you. > > Thanks, > Vishwas > > On Mon, Apr 12, 2010 at 4:43 AM, =A0 wrote: >> Hi, >> >> I think that IPv6 for LDP is getting more and more important. Even with = private IPv4 addresses - depending on network size and addressing scheme - = for mid and long term it is definitely a good idea to take IPv6 into accoun= t! >> >> I've also a short comment regarding the draft. It states: >> >> =A0"This document preserves the usage of 32-bit LSR Id on an IPv6 only >> =A0 LSR and allows the usage of a common LDP identifier i.e. same LSR-Id >> =A0 and same Label space id for IPv4 and IPv6 on a dual-stack LSR. This >> =A0 rightly enables the per-platform label space to be shared between >> =A0 IPv4 and IPv6." >> >> At the moment providers tend to use an IPv4 address as LSR ID and I wond= er about the operational impact if this is going to be moved towards a more= abstract ID. >> >> =A0Regards >> >> =A0 =A0Nic >> >> -----Urspr=FCngliche Nachricht----- >> Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von= Vishwas Manral >> Gesendet: Dienstag, 6. April 2010 21:23 >> An: mpls@ietf.org >> Betreff: [mpls] LDP IPv6 >> >> Hi folks, >> >> http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03 >> >> We have a new version of the LDP IPv6 draft. The draft has been around >> since 2008, however we are now seeing operators asking for it (and can >> be seen in some discussions in the RIPE mailing lists). >> >> We would want to hear comments on the same from the list. >> >> Thanks, >> Vishwas >> _______________________________________________ >> 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 lesnix@gmail.com Tue Apr 13 01:59:04 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E09E28C0E4 for ; Tue, 13 Apr 2010 01:59:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCRX06mS4dDM for ; Tue, 13 Apr 2010 01:59:03 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 5A48728B56A for ; Tue, 13 Apr 2010 01:59:02 -0700 (PDT) Received: by bwz9 with SMTP id 9so5469466bwz.29 for ; Tue, 13 Apr 2010 01:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=HFyuY8DHJy5GdMgzrfdX505V8b4jGg0b9tA8CF10H7w=; b=lAivFmALd3AkEF7o9AT9m5UC7is5ONDFYVq+55DyOnpGYKs3FyCsb6NrVwgLK2CO/w 72N17Ewxwtgj06Ru2+sYW+TXPDVXekFcchA242FIqt7K2EYVhmepKcN74dmbY5b/6C3F CREZ56ZLKT0xnx4GYeuTImZjfCuw06VUpxqWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MEic/0X0KXgqauH1aq4wtxws7j9y9kfpnGPG2KeAg1F/3wRGMEMFmUKbW5WExluSh9 O0Nu6nvYZC3ktmKFHsKXgAoDWygyE5A7AUMLAVa7eNTQWc8OOQwqosPd+LUWcl7DUf7k CYFNisNQdeC6Vhb/sZS3kbTN5tEFxkcWOwUV4= MIME-Version: 1.0 Received: by 10.204.52.72 with HTTP; Tue, 13 Apr 2010 01:58:52 -0700 (PDT) In-Reply-To: <063301cacc91$79382f90$231c8182@china.huawei.com> References: <063301cacc91$79382f90$231c8182@china.huawei.com> Date: Tue, 13 Apr 2010 12:58:52 +0400 Received: by 10.204.46.153 with SMTP id j25mr6104308bkf.191.1271149133001; Tue, 13 Apr 2010 01:58:53 -0700 (PDT) Message-ID: From: Egor Zimin To: Yong Lucy Content-Type: multipart/alternative; boundary=0016e6d77f7487730a04841a78aa Cc: mpls@ietf.org Subject: Re: [mpls] TC bit on Flow Label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 08:59:04 -0000 --0016e6d77f7487730a04841a78aa Content-Type: text/plain; charset=ISO-8859-1 Similar question is Is there semantics in 3 bits field between "label value" and "S-bit" in VPNv4 NLRI (1/128) ? 2010/3/26 Yong Lucy > Question to WG: > > > > Is there semantics in TC field of PW flow label? > > > > Lucy > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- Best regards, Egor Zimin --0016e6d77f7487730a04841a78aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Similar question is
Is there semantics in 3 bits field between "lab= el value" and "S-bit" in VPNv4 NLRI (1/128) ?

2010/3/26 Yong Lucy <lucyyong@huawei.com>

Question to WG:

=A0

Is there semantics in TC field of PW flow = label?

=A0

Lucy


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




--
Best regards,
E= gor Zimin
--0016e6d77f7487730a04841a78aa-- From loa@pi.nu Tue Apr 13 03:14:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575663A692E; Tue, 13 Apr 2010 03:14:14 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhBM-BsDoEEq; Tue, 13 Apr 2010 03:14:13 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 746F03A681D; Tue, 13 Apr 2010 03:14:13 -0700 (PDT) Received: from [109.58.29.26] (109.58.29.26.bredband.tre.se [109.58.29.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 85728D404F; Tue, 13 Apr 2010 12:14:04 +0200 (CEST) Message-ID: <4BC443E9.2060407@pi.nu> Date: Tue, 13 Apr 2010 12:14:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "mpls-tp@ietf.org" , MPLS-TP ad hoc team , mpls@ietf.org References: <4BAD5B78.5000808@pi.nu> In-Reply-To: <4BAD5B78.5000808@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] the mpls working group klast calls on draft-ietf-mpls-tp-ach-tlv has ended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 10:14:14 -0000 All, the mpls working group last call on the ACH-TLV structure (draft-ietf-mpls-tp-ach-tlv) has ended. > ACH-TLV structure draft-ietf-mpls-tp-ach-tlv > The ongoing MPLS wg last call will end on April 12 Could the authors please address the comments and publish a new version of the draft. Loa and George -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wwwrun@core3.amsl.com Tue Apr 13 05:15:27 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7233F3A6B2A; Tue, 13 Apr 2010 05:15:27 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100413121527.7233F3A6B2A@core3.amsl.com> Date: Tue, 13 Apr 2010 05:15:27 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "Response to LS161 - MPLS-TP Survivability Framework draft reviewed (ref # 021.02), LS162 - Comments on draft-ietf-mpls-tp-data-plane-01 [Ref # 023.02], LS163 - Comments on draft-ietf-mpls-tp-identifiers-01 [Ref # 022.02], LS164 - Response to MPLS-TP ACH T" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 12:15:27 -0000 Title: Response to LS161 - MPLS-TP Survivability Framework draft reviewed (ref # 021.02), LS162 - Comments on draft-ietf-mpls-tp-data-plane-01 [Ref # 023.02], LS163 - Comments on draft-ietf-mpls-tp-identifiers-01 [Ref # 022.02], LS164 - Response to MPLS-TP ACH T Submission Date: 2010-04-13 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=872 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For information Body: See attachment. Attachment(s): Response to 4 Liaisons (https://datatracker.ietf.org/documents/LIAISON/file986.doc) From vishwas.ietf@gmail.com Tue Apr 13 07:00:37 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53BB83A6A2C for ; Tue, 13 Apr 2010 07:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZYHyZd6QESY for ; Tue, 13 Apr 2010 07:00:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8F6873A6A39 for ; Tue, 13 Apr 2010 07:00:25 -0700 (PDT) Received: by gwb1 with SMTP id 1so1831603gwb.31 for ; Tue, 13 Apr 2010 07:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=YLO2vVavM8hMNds7bwt6cFVbWxdjSUm28LvElTVfoP0=; b=RgiLyJTcRXWpHw9dteAKVDnfURDkMaarfzKTSjOTszZfi5XGT94lVZG+TwSqE1G1DO KHC9+zi/KyiSlZcOxGnQzZVAfV4NGYZ88ByMPOsAojAqfRVUC0lrNqPi0MUC45z/CC5V i5eXp5IVjpxirH1CWeTAOrGd/pz7V86SRFgL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DaEH4btzKqK19si59f2v0xKwxxP3iKIUsNvW3Pse5zHN0msJQv1VVgWHX9ueaO3mWZ bOHy2tzX6esnDFBxH5G8RyPNHV9nkGDsRfykCSQI+JKERDs+FBnLWNzy4JzAL3xjpNdZ sbdy5MEoYKK7T514AKdccrQkBEBSLhk/Wf6Go= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Tue, 13 Apr 2010 07:00:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 07:00:17 -0700 Received: by 10.150.141.12 with SMTP id o12mr5629268ybd.189.1271167217275; Tue, 13 Apr 2010 07:00:17 -0700 (PDT) Message-ID: From: Vishwas Manral To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] Fwd: LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:00:37 -0000 Egor, Thanks for your support. -Vishwas ---------- Forwarded message ---------- From: Egor Zimin Date: Tue, Apr 13, 2010 at 1:05 AM Subject: Re: [mpls] LDP IPv6 To: Vishwas Manral I'm in support of this draft. LDPv6 can be used, for example in complex VPNv6 CsC scenarios as a label distribution protocol between CsC-PE and CsC-CE. Btw, some leading vendors still say "We have no LDP over IPv6 implementation, because LDPv6 specification still have "draft" status. 2010/4/6 Vishwas Manral > > Hi folks, > > http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03 > > We have a new version of the LDP IPv6 draft. The draft has been around > since 2008, however we are now seeing operators asking for it (and can > be seen in some discussions in the RIPE mailing lists). > > We would want to hear comments on the same from the list. > > Thanks, > Vishwas > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Best regards, Egor Zimin From lucyyong@huawei.com Tue Apr 13 08:26:41 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD633A6B1C for ; Tue, 13 Apr 2010 08:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.012 X-Spam-Level: * X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAXniRCgkscZ for ; Tue, 13 Apr 2010 08:26:37 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 84FDA3A683B for ; Tue, 13 Apr 2010 08:26:30 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0T000SNMVQ0I@szxga01-in.huawei.com> for mpls@ietf.org; Tue, 13 Apr 2010 23:26:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0T008FJMVQDN@szxga01-in.huawei.com> for mpls@ietf.org; Tue, 13 Apr 2010 23:26:14 +0800 (CST) Received: from y736742 ([10.124.12.148]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0T001W8MVNX2@szxml04-in.huawei.com> for mpls@ietf.org; Tue, 13 Apr 2010 23:26:14 +0800 (CST) Date: Tue, 13 Apr 2010 10:26:11 -0500 From: Yong Lucy In-reply-to: To: 'Egor Zimin' Message-id: <005201cadb1d$a6e1c970$940c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_UmiqaTUoK3K0lLtfC6wqpw)" Thread-index: Acra5+4SgWPhYxYyQseYmhYWlhMlVAAMu1lQ References: <063301cacc91$79382f90$231c8182@china.huawei.com> Cc: mpls@ietf.org Subject: Re: [mpls] TC bit on Flow Label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 15:26:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_UmiqaTUoK3K0lLtfC6wqpw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Egor, I am not sure if two questions are exactly same or not because I am not expert on L3VPN. Let's see if I can describe them clearly. If the backbone network carries client L3VPN by using LDP, then PW is not used. Thus PW flow label is not used too. The 3 bits between label value and S-bit on the LSP label are used for DiffServ purpose. However, there was proposal about entropy label for LDP LSP. Draft-kpmpella-mpls-entropy-label-01 if the entropy label is used at the bottom of the label stack, IMO: 3 bits field on entropy label has not semantics. This is the same question as I propose. PW flow label has its special usage in the network, which is very different from LSP label and PW label, although they all inherit from MPLS label. Thank you for bringing the question. Regards, Lucy _____ From: Egor Zimin [mailto:lesnix@gmail.com] Sent: Tuesday, April 13, 2010 3:59 AM To: Yong Lucy Cc: mpls@ietf.org Subject: Re: [mpls] TC bit on Flow Label Similar question is Is there semantics in 3 bits field between "label value" and "S-bit" in VPNv4 NLRI (1/128) ? 2010/3/26 Yong Lucy Question to WG: Is there semantics in TC field of PW flow label? Lucy _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Best regards, Egor Zimin --Boundary_(ID_UmiqaTUoK3K0lLtfC6wqpw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Egor,

 

I am not sure if two questions are exactly same or not because I am not expert on L3VPN. Let’s see if I can describe them clearly.

 

If the backbone network carries client L3VPN by using LDP, then PW is not used. Thus PW flow label is not used too.

The 3 bits between label value and S-bit on the LSP label are used for DiffServ purpose.

 

However, there was proposal about entropy label for LDP LSP. Draft-kpmpella-mpls-entropy-label-01 if the entropy label is used at the bottom of the label stack, IMO: 3 bits field on entropy label has not semantics. This is the same question as I propose.

 

PW flow label has its special usage in the network, which is very different from LSP label and PW label, although they all inherit from MPLS label.

 

Thank you for bringing the question.

 

Regards,

Lucy

 

From: Egor Zimin [mailto:lesnix@gmail.com]
Sent: Tuesday, April 13, 2010 3:59 AM
To: Yong Lucy
Cc: mpls@ietf.org
Subject: Re: [mpls] TC bit on Flow Label

 

Similar question is
Is there semantics in 3 bits field between "label value" and "S-bit" in VPNv4 NLRI (1/128) ?

2010/3/26 Yong Lucy <lucyyong@huawei.com>

Question to WG:

 

Is there semantics in TC field of PW flow label?

 

Lucy


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




--
Best regards,
Egor Zimin

--Boundary_(ID_UmiqaTUoK3K0lLtfC6wqpw)-- From davari@broadcom.com Tue Apr 13 10:35:20 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA1A3A6A1C; Tue, 13 Apr 2010 10:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHxZe324Qhi8; Tue, 13 Apr 2010 10:35:19 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 790B83A67FB; Tue, 13 Apr 2010 10:35:19 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 13 Apr 2010 10:35:01 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 13 Apr 2010 10:34:59 -0700 From: "Shahram Davari" To: "Loa Andersson" , "mpls-tp@ietf.org" , "MPLS-TP ad hoc team" , "mpls@ietf.org" Date: Tue, 13 Apr 2010 10:34:58 -0700 Thread-Topic: [mpls] the mpls working group klast calls on draft-ietf-mpls-tp-ach-tlv has ended Thread-Index: Acra8hU+HCUacB1NRKWLeNzbCJU/iwAPMILQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F0189C2D@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BAD5B78.5000808@pi.nu> <4BC443E9.2060407@pi.nu> In-Reply-To: <4BC443E9.2060407@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67DA74C838O171403253-02-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] the mpls working group klast calls on draft-ietf-mpls-tp-ach-tlv has ended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:35:20 -0000 Hi Loa, This draft seems to define TLV formats for some of the identifiers defined = in mpls-tp-identifiers draft. Is the intent to have another draft to define= the remaining identifiers? Why not combine this draft with the identifiers= draft? Thanks, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Tuesday, April 13, 2010 3:14 AM To: mpls-tp@ietf.org; MPLS-TP ad hoc team; mpls@ietf.org Subject: Re: [mpls] the mpls working group klast calls on draft-ietf-mpls-t= p-ach-tlv has ended All, the mpls working group last call on the ACH-TLV structure (draft-ietf-mpls-tp-ach-tlv) has ended. > ACH-TLV structure draft-ietf-mpls-tp-ach-tlv > The ongoing MPLS wg last call will end on April 12 Could the authors please address the comments and publish a new version of the draft. Loa and George --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Tue Apr 13 11:30:16 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D713A6A7A; Tue, 13 Apr 2010 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xPQ38nt2Pjo; Tue, 13 Apr 2010 11:30:15 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id CEC923A67DA; Tue, 13 Apr 2010 11:30:14 -0700 (PDT) Received: by gxk9 with SMTP id 9so4265757gxk.8 for ; Tue, 13 Apr 2010 11:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=tFwK9TTG8PDkL2eaNT/EDxcnAO/oXNLY/cpFWQ1Zt1I=; b=HRR2dw5avnTMOe5rbCKtZ60OP1KDyjnnepvY762JIsa5uGB6FFfmBUOMViEvqJZfww IQmI7TEnomTl2DgyG81n57I/mBpnR7HWn0WJgenm6B79yHWUk5jKD2xyPJ0Up1ta8/VM jn2s0UpN5hs/lrkWcAQSOQ9ESMUBANXjbdjfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vqaAPx/gNkRl5UXnAcDxzIscmA4N/nwTAYXGwlxcCB1xwvz23SFn9m0Wda57duJ9lZ 0N+lbzZhC2Zzg2RRttDNg1hhDkG93MdH/mpzEMDSIgscRSTvIjvcwEj5dm+9qll7EA7V INIi95NgVVx++HXVJsx89jgCzfBIIIzX9ghjk= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Tue, 13 Apr 2010 11:30:06 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F0189C2D@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BAD5B78.5000808@pi.nu> <4BC443E9.2060407@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F0189C2D@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 13 Apr 2010 11:30:06 -0700 Received: by 10.90.131.20 with SMTP id e20mr2882829agd.13.1271183406406; Tue, 13 Apr 2010 11:30:06 -0700 (PDT) Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=0016e64f90d6621edb04842273ab Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] the mpls working group klast calls on draft-ietf-mpls-tp-ach-tlv has ended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:30:16 -0000 --0016e64f90d6621edb04842273ab Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, I would not speak for Loa or authors of two documents you've asked. I think that ACH TLV document will include, perhaps not right from the start, more then MPLS-TP Identifiers. For example, in Anaheim was discussed to add Timestamp TLV as ACH TLV rather than as extension of LSP-Ping. Regards, Greg On Tue, Apr 13, 2010 at 10:34 AM, Shahram Davari wrote: > Hi Loa, > > This draft seems to define TLV formats for some of the identifiers defined > in mpls-tp-identifiers draft. Is the intent to have another draft to define > the remaining identifiers? Why not combine this draft with the identifiers > draft? > > Thanks, > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Tuesday, April 13, 2010 3:14 AM > To: mpls-tp@ietf.org; MPLS-TP ad hoc team; mpls@ietf.org > Subject: Re: [mpls] the mpls working group klast calls on > draft-ietf-mpls-tp-ach-tlv has ended > > All, > > the mpls working group last call on the ACH-TLV structure > (draft-ietf-mpls-tp-ach-tlv) has ended. > > > > ACH-TLV structure draft-ietf-mpls-tp-ach-tlv > > The ongoing MPLS wg last call will end on April 12 > > Could the authors please address the comments and publish > a new version of the draft. > > Loa and George > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --0016e64f90d6621edb04842273ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shahram,
I would not speak for Loa or authors of two documents you= 9;ve asked. I think that ACH TLV document will include, perhaps not right f= rom the start, more then MPLS-TP Identifiers. For example, in Anaheim was d= iscussed to add Timestamp TLV as ACH TLV rather than as extension of LSP-Pi= ng.

Regards,
Greg

On Tue, Apr 13, 2010= at 10:34 AM, Shahram Davari <davari@broadcom.com> wrote:
Hi Loa,

This draft seems to define TLV formats for some of the identifiers defined = in mpls-tp-identifiers draft. Is the intent to have another draft to define= the remaining identifiers? Why not combine this draft with the identifiers= draft?

Thanks,
Shahram

-----Original Message-----
From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of Loa Andersson
Sent: Tuesday, April 13, 2010 3:14 AM
To: mpls-tp@ietf.org; MPLS-TP ad ho= c team; mpls@ietf.org
Subject: Re: [mpls] the mpls working group klast calls on draft-ietf-mpls-t= p-ach-tlv has ended

All,

the mpls working group last call on the ACH-TLV structure
(draft-ietf-mpls-tp-ach-tlv) has ended.


> ACH-TLV structure draft-ietf-mpls-tp-ach-tlv
> The ongoing MPLS wg last call will end on April 12

Could the authors please address the comments and publish
a new version of the draft.

Loa and George

--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0+46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


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

--0016e64f90d6621edb04842273ab-- From davarish@yahoo.com Tue Apr 13 13:51:40 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7132628C179 for ; Tue, 13 Apr 2010 13:51:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcB8Yh7EmDXm for ; Tue, 13 Apr 2010 13:51:40 -0700 (PDT) Received: from n22a.bullet.mail.mud.yahoo.com (n22a.bullet.mail.mud.yahoo.com [68.142.207.188]) by core3.amsl.com (Postfix) with SMTP id 5103A28C183 for ; Tue, 13 Apr 2010 13:51:38 -0700 (PDT) Received: from [68.142.200.227] by n22.bullet.mail.mud.yahoo.com with NNFMP; 13 Apr 2010 20:51:29 -0000 Received: from [66.196.97.143] by t8.bullet.mud.yahoo.com with NNFMP; 13 Apr 2010 20:51:29 -0000 Received: from [127.0.0.1] by omp201.mail.re3.yahoo.com with NNFMP; 13 Apr 2010 20:51:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 424421.88980.bm@omp201.mail.re3.yahoo.com Received: (qmail 42649 invoked by uid 60001); 13 Apr 2010 20:51:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271191889; bh=kBjiayLxtAbcACgasnk9fAijfWBOSIqP/MW27stFXlw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ptZtqoheeDhN124SqR8pFA+HUBBC+2JapDccasorhQHI7rrNXe8aEYsY9Yfk3kP03nJEdonYg1qtR5rBBwo0gM8JFdKlOstaDEnQVE9M/LgkiXv7lVJG8xEzNHXO+wC746CLgtFcXkV3UWj/y9potf2Uy9P14a2yfJMQS5/bEGw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=V7QNIDUDMJWnVT86E1LJ+BswTK1upFdURe4d7Tgs1xLygXh67q6FyO5eq/KcAQ2dLrtNvFqMxQAfUlZe9+ynx+aHGtt6pyjig+Rq1N4jzdPdpJ8QVx0J13VqGBIS5mEWQdgNeI5sa4wlNVDPdc8dbroZ1gsTpUnJygOx6wL8toI=; Message-ID: <169746.38158.qm@web88414.mail.re1.yahoo.com> X-YMail-OSG: eHvjdecVM1mkwRT3N_WjymKuyPnXPmi7aW2TQMnnuijcoJK P57cYA.iHJ6yx2Y9SfuGI._i6l5tafiQJGgRnl8tGrZb8dZ6lPdpA54XyQoJ PDrSf96BphVzmMJlpCgF1ggM_FYpZwdwQfgeFJJB4n6kIP5fCl1AfIW80Aea 0bURm1rK22PlwLtiTeoIpASHN__3FEHQQoqtV5Q0Oijjbc2QcG7UVUfYBHGW Px9h_G8_Tv1sQOhBs91FslrPQGwtF5SMin0iCUkefOoJqjVW_0oTF9hWqdZx r887e24tneIELigvZjqyN3nc8OorRHKMS7uH_ghq4zi3V_55h Received: from [216.31.219.19] by web88414.mail.re1.yahoo.com via HTTP; Tue, 13 Apr 2010 13:51:28 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Tue, 13 Apr 2010 13:51:28 -0700 (PDT) From: false To: Shahram Davari , Greg Mirsky In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1834923298-1271191888=:38158" Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] the mpls working group klast calls on draft-ietf-mpls-tp-ach-tlv has ended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: davarish@yahoo.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 20:51:40 -0000 --0-1834923298-1271191888=:38158 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Greg, What do you mean by "not right=A0 from the start"? This is the last call, i= sn't it? Thx SD --- On Tue, 4/13/10, Greg Mirsky wrote: From: Greg Mirsky Subject: Re: [mpls] [mpls-tp] the mpls working group klast calls on draft-i= etf-mpls-tp-ach-tlv has ended To: "Shahram Davari" Cc: "mpls@ietf.org" , "MPLS-TP ad hoc team" , "mpls-tp@ietf.org" Received: Tuesday, April 13, 2010, 2:30 PM Hi Shahram, I would not speak for Loa or authors of two documents you've asked. I think= that ACH TLV document will include, perhaps not right from the start, more= then MPLS-TP Identifiers. For example, in Anaheim was discussed to add Tim= estamp TLV as ACH TLV rather than as extension of LSP-Ping. =0A Regards, Greg On Tue, Apr 13, 2010 at 10:34 AM, Shahram Davari wrot= e: =0AHi Loa, =0A =0AThis draft seems to define TLV formats for some of the identifiers defin= ed in mpls-tp-identifiers draft. Is the intent to have another draft to def= ine the remaining identifiers? Why not combine this draft with the identifi= ers draft? =0A=0A =0AThanks, =0AShahram =0A =0A-----Original Message----- =0AFrom: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Loa Andersson =0ASent: Tuesday, April 13, 2010 3:14 AM =0ATo: mpls-tp@ietf.org; MPLS-TP ad hoc team; mpls@ietf.org =0ASubject: Re: [mpls] the mpls working group klast calls on draft-ietf-mpl= s-tp-ach-tlv has ended =0A =0AAll, =0A =0Athe mpls working group last call on the ACH-TLV structure =0A(draft-ietf-mpls-tp-ach-tlv) has ended. =0A =0A =0A> ACH-TLV structure draft-ietf-mpls-tp-ach-tlv =0A> The ongoing MPLS wg last call will end on April 12 =0A =0ACould the authors please address the comments and publish =0Aa new version of the draft. =0A =0ALoa and George =0A =0A-- =0A =0A =0ALoa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa= .andersson@ericsson.com =0ASr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu =0AEricsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: += 46 10 717 52 13 =0A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0+46 767 72 92 13 =0A_______________________________________________ =0Ampls mailing list =0Ampls@ietf.org =0Ahttps://www.ietf.org/mailman/listinfo/mpls =0A =0A =0A_______________________________________________ =0Ampls-tp mailing list =0Ampls-tp@ietf.org =0Ahttps://www.ietf.org/mailman/listinfo/mpls-tp =0A =0A -----Inline Attachment Follows----- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =0A=0A__________________________________________________=0ADo You Yahoo!?= =0ATired of spam? Yahoo! Mail has the best spam protection around =0Ahttp:= //mail.yahoo.com --0-1834923298-1271191888=:38158 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Greg,

What do you mean by "not righ= t  from the start"? This is the last call, isn't it?

Thx
SD<= br>
--- On Tue, 4/13/10, Greg Mirsky <gregimirsky@gmail.com>= wrote:

From: Greg Mirsky <gregi= mirsky@gmail.com>
Subject: Re: [mpls] [mpls-tp] the mpls working grou= p klast calls on draft-ietf-mpls-tp-ach-tlv has ended
To: "Shahram Davar= i" <davari@broadcom.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>= , "MPLS-TP ad hoc team" <ahmpls-tp@lists.itu.int>, "mpls-tp@ietf.org"= <mpls-tp@ietf.org>
Received: Tuesday, April 13, 2010, 2:30 PM
=
Hi Shahram,
I would not speak for Loa or a= uthors of two documents you've asked. I think that ACH TLV document will in= clude, perhaps not right from the start, more then MPLS-TP Identifiers. For examp= le, in Anaheim was discussed to add Timestamp TLV as ACH TLV rather than as= extension of LSP-Ping.
=0A
Regards,
Greg

On Tue, Apr 13, 2010 at 10:34 AM, Shahram Davari <davari@broadcom.com> wrote:
=0AHi Loa,
=0A
=0AThis draft seems to define TLV formats for s= ome of the identifiers defined in mpls-tp-identifiers draft. Is the intent = to have another draft to define the remaining identifiers? Why not combine = this draft with the identifiers draft?
=0A=0A
=0AThanks,
=0AShahra= m
=0A

=0A-----Original Message-----=
=0AFrom: mpls-bounc= es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
=0ASent: Tuesday,= April 13, 2010 3:14 AM
=0ATo: mpls-tp@ietf.org; MPLS-TP ad hoc team; mpls@ietf.org
=0ASubject: Re: [mpls] the mpls working group kla= st calls on draft-ietf-mpls-tp-ach-tlv has ended
=0A
=0AAll,
=0A=0Athe mpls working group last call on the ACH-TLV structure
=0A(draft= -ietf-mpls-tp-ach-tlv) has ended.
=0A
=0A
=0A> ACH-TLV structur= e draft-ietf-mpls-tp-ach-tlv
=0A> The ongoing MPLS wg last call will = end on April 12
=0A
=0ACould the authors please address the comments = and publish
=0Aa new version of the draft.
=0A
=0ALoa and George=0A
=0A--
=0A
=0A
=0ALoa Andersson        = ;                 email: loa.andersson@ericsson.= com
=0ASr Strategy and Standards Manager        =    loa@pi.nu
=0AEricsson Inc =                      = ;    phone: +46 10 717 52 13
=0A         &= nbsp;                    =                +46 767 72 92 13=0A_______________________________________________
=0Ampls mailing list=
=0Ampls@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/mpls
=0A
=0A
= =0A
_______________________________________________
=0Ampls-t= p mailing list
=0Ampls-tp@ietf= .org
=0Ahttps://www.ietf.org/mailman/listinfo/mpls= -tp
=0A

=0A

-----Inline Attachment Fo= llows-----

________________________________= _______________
mpls mailing list
mpls@ietf.org
https://www.iet= f.org/mailman/listinfo/mpls
__________________________________________________
Do You Yahoo!?
Ti= red of spam? Yahoo! Mail has the best spam protection around
http://ma= il.yahoo.com --0-1834923298-1271191888=:38158-- From rjs@eng.gxn.net Wed Apr 14 07:05:17 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506103A683E for ; Wed, 14 Apr 2010 07:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmdhRK0xNExR for ; Wed, 14 Apr 2010 07:05:16 -0700 (PDT) Received: from mocha.rob.sh (mocha.rob.sh [193.239.32.250]) by core3.amsl.com (Postfix) with ESMTP id DA7903A69E2 for ; Wed, 14 Apr 2010 07:05:09 -0700 (PDT) Received: from [195.224.160.13] (helo=stm-emason.internal.gxn.net) by mocha.rob.sh with esmtpa (Exim 4.66) (envelope-from ) id L0VDS8-0009HJ-QR; Wed, 14 Apr 2010 15:04:57 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: Date: Wed, 14 Apr 2010 15:04:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E2FA684-E5E0-45FA-9885-0BA7C288AC08@eng.gxn.net> References: <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> To: Vishwas Manral X-Mailer: Apple Mail (2.1077) Cc: mpls@ietf.org Subject: Re: [mpls] LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 14:05:17 -0000 Hi Vishwas, On 12 Apr 2010, at 17:40, Vishwas Manral wrote: > BTW, thanks a lot for supporting this effort. Like I said I know a lot > of operators (maily Europe and Asia) want the specs for this to be > finalized and I am just hoping they can speak up in the mailing list > too. I'd just like to speak up in support of this draft also. As an operator = that is progressing an IPv6 rollout, we are finding that in a number of = places, the only need to utilise 6PE is in order to address the lack of = support for IPv6 in LDP. Whilst I think it's unlikely that many operators are currently putting = this down as a mandatory requirement, it's definitely something that I = believe is required. Kind regards, Rob --=20 Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http://www.vialtus.com/disclaimer.html From Ilya.Varlashkin@de.easynet.net Wed Apr 14 07:44:07 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D243A69E2 for ; Wed, 14 Apr 2010 07:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-1.345, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw7v5ZjoCmou for ; Wed, 14 Apr 2010 07:44:06 -0700 (PDT) Received: from softy.de.easynet.net (softy.de.easynet.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id B87EC3A69D9 for ; Wed, 14 Apr 2010 07:44:05 -0700 (PDT) Received: from fe01kgham.de.easynet.net ([194.163.250.17] helo=fe01kgham.adoffice.local.de.easynet.net) by softy.de.easynet.net with esmtp (Exim 4.63) (envelope-from ) id 1O23or-0006pj-HS for mpls@ietf.org; Wed, 14 Apr 2010 16:43:57 +0200 Received: from ex01kgham.adoffice.local.de.easynet.net ([10.43.3.3]) by fe01kgham.adoffice.local.de.easynet.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 16:43:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 16:43:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LSP traceroute failure with Inter-AS MPLS Thread-Index: Acrb4OmcH4dXUMi5ScmPdF5tQmgXPQ== From: "Ilya Varlashkin" To: "IETF MPLS" X-OriginalArrivalTime: 14 Apr 2010 14:43:57.0171 (UTC) FILETIME=[E9984C30:01CADBE0] Subject: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 14:44:07 -0000 Hi, I was doing some LSP traceroutes across AS boundaries (on real-world network) and missed replies from some intermediate routers in the target AS. Digging a bit deeper I've found following: if some AS has BGP-free core and its internal (core) routers don't have routing information for foreign prefixes, then these internal routers won't be able to send LSP Echo Replies to originator of the traceroute. Normal end-to-end traffic is delivered without problems both ways because PE routers in such AS put two labels on the stack (using labelled-unicast) when sending packets towards foreign routers, so core routers don't have to know how to reach foreign PE. Before going to our routers' vendor I've looked through RFC4379 once more to check whether it's an implementation or specification issue. It looks like there is nothing in RFC to address above mentioned scenario, so looks like specification issue.=20 Similar problem with normal traceroute within MPLS L3VPN environment is addressed by ICMP-tunnelling trick - forwarding ICMP message along the same path as original packet that caused generation of that ICMP message. Wouldn't the same approach work with LSP ping? All what's needed, from protocol PoV, is to say that if an intermediate router (not final destination!) needs to send a reply (because TTL expired) doesn't have route back to originator of LSP ECHO then it should send reply along the same path as original LSP ECHO. I.e. if PE1 sends LSP ECHO request to PE2 over intermediate router P, and P would use label L1 and interface INTF1 to send packets towards PE2, then P should also use label L1 and interface INTF1 when it needs to send replies back to PE1. Would doing so cause any problems? If not, should we ammend specification of LSP ping/traceroute? Cheers, iLya From vishwas.ietf@gmail.com Wed Apr 14 09:59:57 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85EBC3A6940 for ; Wed, 14 Apr 2010 09:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8XZzdAszALI for ; Wed, 14 Apr 2010 09:59:56 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B42533A688B for ; Wed, 14 Apr 2010 09:59:56 -0700 (PDT) Received: by gwb1 with SMTP id 1so151493gwb.31 for ; Wed, 14 Apr 2010 09:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=ibKVqQIN9Sl0MQ8A2eVZDkrF2oU1pHtRDiGgvstCcpA=; b=kHVmUQ9Zf9cGgq2YCM15iDfxWg8x1CvWBiCCaXbuWVISy1gTuh9BssPsC5YLLY7np2 qRKUM+htJWnkH0nRiWPHsk4r7bCURxya3fUEPZropah0PDwsPcZ0tBen3WoSAfcN0Zto DXej7tKIcxxi5LBiPgUBK7XmQYSjqjS4UxESo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oWXhd9w6DmrVHRibe1b65Si5GB9DfZiuAqBVA7iDDjpNrEoAfmUZc29UFMU2rtNNic 3ZidCnkiaU3Dtd4f4R95w/tS7ZTgF0Ga4C1mzLCYLEnml4vFdMgOzun8ycupSBxgdjfd NVplCYtwzRuAdUyR5JNj9GODrHWDBgzDkvTW4= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Wed, 14 Apr 2010 09:59:46 -0700 (PDT) Date: Wed, 14 Apr 2010 09:59:46 -0700 Received: by 10.150.119.20 with SMTP id r20mr7443613ybc.55.1271264386224; Wed, 14 Apr 2010 09:59:46 -0700 (PDT) Message-ID: From: Vishwas Manral To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] MPLS-TC MIB for IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 16:59:57 -0000 Hi folks, There are some basic issues in the TC-MIB RFC 3811 for IPv6. We had made the changes to the MIB and updated the document below. As we seem to have support for the IPv6 MPLS effort, I think we should take the updates for the MIB along too. Here is the link to the MIB draft: http://tools.ietf.org/id/draft-manral-mpls-rfc3811bis-00.txt Thanks, Vishwas From tnadeau@lucidvision.com Wed Apr 14 10:44:02 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A6C28C17B for ; Wed, 14 Apr 2010 10:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mff9-gENtVTl for ; Wed, 14 Apr 2010 10:44:01 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 65CAD28C111 for ; Wed, 14 Apr 2010 10:44:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 01C433ED88C; Wed, 14 Apr 2010 13:43:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frhL+q41upCh; Wed, 14 Apr 2010 13:43:54 -0400 (EDT) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 34F0D3ED881; Wed, 14 Apr 2010 13:43:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: Date: Wed, 14 Apr 2010 13:43:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F2E4C55-6498-45E4-85FF-A28F85A731CD@lucidvision.com> References: To: Vishwas Manral X-Mailer: Apple Mail (2.1078) Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-TC MIB for IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 17:44:02 -0000 Before we get carried away with this let us first be clear that = the "base" MPLS MIBs do indeed support IPv6 in a manner that does work. = I've implemented them and know of dozens of implementations that did as = well. There are also 100s of deployments where these MIBs are now in = use.=20 When the draft you reference first came out, many reviewed the = changes it contains (including myself). The consensus at the time was = that the changes proposed therein did not seem to outweigh the = disadvantages of uprooting and updating EVERY MIB that imports the TC = (or the many implementations thereof). For reference, people need to = understand that ANY changes to the TEXTUAL-CONVENTIONs contained in = rfc3811 will require changes to EVERY MIB module that imports and uses = those TCs, as per MIB module deprecation and object update rules. In the = analysis of the changes proposed in your draft, it was determined that = they would result in not only all of the "base" MPLS MIBs needing = updating, but then the GMPLS and PWE3 MIBs which rely on parts of those = modules, would also result in similar module deprecation/updates needed. = I don't believe that the situation has changed since then, but I can = only speak on behalf of myself in this regard. --Tom > Hi folks, >=20 > There are some basic issues in the TC-MIB RFC 3811 for IPv6. We had > made the changes to the MIB and updated the document below. As we seem > to have support for the IPv6 MPLS effort, I think we should take the > updates for the MIB along too. >=20 > Here is the link to the MIB draft: >=20 > http://tools.ietf.org/id/draft-manral-mpls-rfc3811bis-00.txt >=20 > Thanks, > Vishwas > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From nitinb@juniper.net Wed Apr 14 13:34:30 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04A03A6894 for ; Wed, 14 Apr 2010 13:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-ZeI1kCZlFR for ; Wed, 14 Apr 2010 13:34:30 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id AB87C3A6A8E for ; Wed, 14 Apr 2010 13:32:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKS8YmS1HhoaFJyOBXxZnWDK+bhjWbBtJc@postini.com; Wed, 14 Apr 2010 13:32:14 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 14 Apr 2010 13:27:26 -0700 From: Nitin Bahadur To: 'Ilya Varlashkin' , IETF MPLS Date: Wed, 14 Apr 2010 13:27:25 -0700 Thread-Topic: LSP traceroute failure with Inter-AS MPLS Thread-Index: Acrb4OmcH4dXUMi5ScmPdF5tQmgXPQAL4gkg Message-ID: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 20:34:31 -0000 Hi Ilya, There is an expired draft by George Swallow & Tom Nadeau that tries to address the problem you are encountering. mpls-tunneling will not help. Mainly because lsp-traceroute is used as a diagnostic tool to detect where a failure is in the network. If there is a = failure in the network, then the echo request/response will unlikely make it to the= =20 egress PE. So for fault isolation, you need the transit nodes to respond back. How t= hey respond back is theorized in the above mentioned draft. Thanks Nitin =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Ilya Varlashkin > Sent: Wednesday, April 14, 2010 7:44 AM > To: IETF MPLS > Subject: [mpls] LSP traceroute failure with Inter-AS MPLS >=20 > Hi, >=20 > I was doing some LSP traceroutes across AS boundaries (on real-world > network) and missed replies from some intermediate routers in=20 > the target AS. Digging a bit deeper I've found following: if=20 > some AS has BGP-free core and its internal (core) routers=20 > don't have routing information for foreign prefixes, then=20 > these internal routers won't be able to send LSP Echo Replies=20 > to originator of the traceroute. Normal end-to-end traffic is=20 > delivered without problems both ways because PE routers in=20 > such AS put two labels on the stack (using labelled-unicast)=20 > when sending packets towards foreign routers, so core routers=20 > don't have to know how to reach foreign PE. >=20 > Before going to our routers' vendor I've looked through=20 > RFC4379 once more to check whether it's an implementation or=20 > specification issue. It looks like there is nothing in RFC to=20 > address above mentioned scenario, so looks like specification issue.=20 >=20 > Similar problem with normal traceroute within MPLS L3VPN=20 > environment is addressed by ICMP-tunnelling trick -=20 > forwarding ICMP message along the same path as original=20 > packet that caused generation of that ICMP message. Wouldn't=20 > the same approach work with LSP ping? All what's needed, from=20 > protocol PoV, is to say that if an intermediate router (not=20 > final destination!) needs to send a reply (because TTL=20 > expired) doesn't have route back to originator of LSP ECHO=20 > then it should send reply along the same path as original LSP=20 > ECHO. I.e. if PE1 sends LSP ECHO request to PE2 over=20 > intermediate router P, and P would use label L1 and interface=20 > INTF1 to send packets towards PE2, then P should also use=20 > label L1 and interface INTF1 when it needs to send replies=20 > back to PE1. > Would doing so cause any problems? If not, should we ammend=20 > specification of LSP ping/traceroute? >=20 > Cheers, > iLya > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From Ilya.Varlashkin@de.easynet.net Wed Apr 14 14:16:20 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C759228C27C for ; Wed, 14 Apr 2010 14:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl+IgobqDQlZ for ; Wed, 14 Apr 2010 14:16:20 -0700 (PDT) Received: from softy.de.easynet.net (softy.de.easynet.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id 4AC0528C175 for ; Wed, 14 Apr 2010 14:13:54 -0700 (PDT) Received: from fe01kgham.de.easynet.net ([194.163.250.17] helo=fe01kgham.adoffice.local.de.easynet.net) by softy.de.easynet.net with esmtp (Exim 4.63) (envelope-from ) id 1O29u6-0003e1-5l; Wed, 14 Apr 2010 23:13:46 +0200 Received: from ex01kgham.adoffice.local.de.easynet.net ([10.43.3.3]) by fe01kgham.adoffice.local.de.easynet.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 23:13:45 +0200 Received: from [172.30.255.212] ([172.30.255.212]) by ex01kgham.adoffice.local.de.easynet.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 23:13:45 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net> Date: Wed, 14 Apr 2010 23:13:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06043151-779D-4ABC-BFA5-E4A35FA12362@de.easynet.net> References: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net> To: Nitin Bahadur X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 14 Apr 2010 21:13:45.0804 (UTC) FILETIME=[5E4E78C0:01CADC17] Cc: IETF MPLS Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 21:16:20 -0000 Hi Nitin, On Apr 14, 2010, at 22:27 , Nitin Bahadur wrote: >=20 > Hi Ilya, >=20 > There is an expired draft by George Swallow & Tom Nadeau that tries = to > address the problem you are encountering. >=20 > mpls-tunneling will not help. Mainly because lsp-traceroute is used = as a ... I thought about that, but then better something than nothing at all. = After all traceroute in VPN environment is used for the same purpose and = it's quite useful because problem is not necessarily complete loss of = connectivity but e.g. packet loss. Do you have pointer to the draft? /iLya From nitinb@juniper.net Wed Apr 14 17:08:11 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56983A6452 for ; Wed, 14 Apr 2010 17:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBMvM1VtWX77 for ; Wed, 14 Apr 2010 17:08:11 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 7E8C63A6900 for ; Wed, 14 Apr 2010 17:08:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKS8ZY4qXGQ+CfhTYB7QXZW8YNTv3TZiNP@postini.com; Wed, 14 Apr 2010 17:08:04 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Wed, 14 Apr 2010 17:05:04 -0700 From: Nitin Bahadur To: 'Ilya Varlashkin' Date: Wed, 14 Apr 2010 17:05:03 -0700 Thread-Topic: LSP traceroute failure with Inter-AS MPLS Thread-Index: AcrcF2C+pWSuIUBDSF+2w7RQ2JmMjAAF9csA Message-ID: <05542EC42316164383B5180707A489EE1D0AC2F9F4@EMBX02-HQ.jnpr.net> References: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net> <06043151-779D-4ABC-BFA5-E4A35FA12362@de.easynet.net> In-Reply-To: <06043151-779D-4ABC-BFA5-E4A35FA12362@de.easynet.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF MPLS Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 00:08:11 -0000 http://tools.ietf.org/html/draft-ietf-mpls-interas-lspping-00 Thanks Nitin =20 > -----Original Message----- > From: Ilya Varlashkin [mailto:Ilya.Varlashkin@de.easynet.net]=20 > Sent: Wednesday, April 14, 2010 2:14 PM > To: Nitin Bahadur > Cc: IETF MPLS > Subject: Re: LSP traceroute failure with Inter-AS MPLS >=20 > Hi Nitin, >=20 > On Apr 14, 2010, at 22:27 , Nitin Bahadur wrote: >=20 > >=20 > > Hi Ilya, > >=20 > > There is an expired draft by George Swallow & Tom Nadeau=20 > that tries=20 > > to address the problem you are encountering. > >=20 > > mpls-tunneling will not help. Mainly because=20 > lsp-traceroute is used=20 > > as a > ... >=20 > I thought about that, but then better something than nothing=20 > at all. After all traceroute in VPN environment is used for=20 > the same purpose and it's quite useful because problem is not=20 > necessarily complete loss of connectivity but e.g. packet loss. >=20 > Do you have pointer to the draft? >=20 > /iLya >=20 >=20 > = From vishwas.ietf@gmail.com Wed Apr 14 21:24:48 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A5C28C189 for ; Wed, 14 Apr 2010 21:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lHd6QQZG+U3 for ; Wed, 14 Apr 2010 21:24:47 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C0CE128C1CD for ; Wed, 14 Apr 2010 21:24:00 -0700 (PDT) Received: by gyh4 with SMTP id 4so520439gyh.31 for ; Wed, 14 Apr 2010 21:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oTQFVqbFeHV4guq14gb+bkcYjGFVlrVzGOF2qG5eEyU=; b=UpDwxkGQbOocYT0b2gFH7j23n8DsjweEhH96FRvVJbn+nS4q/mxnxNbegLQ+qpJYEI XfQY23EydnJBr6wQCxoRVhcBsC3pGNvqgSgC1YwQdHtCytooXNe90gI2tyPpRHEc31Wo 1Nb8riI4S5P5hQSwt6OUmb8KRewOdSxuNfOFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i2Epib9dk8lzTAkVrA53cy0ksr1SZgA4SNMdCc0uT1/3yWyOm169h/zfTftpCN0K2S ZzzwGsA/4fLrpdZirujNkIcGmwcNKBgjVf6QO54Sk/KJGILOZXPSf9nSArLlU+rQMTtD PBtpAey2trpJ+qiqs7JhNFT+Vov8xOgUDGZ0s= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Wed, 14 Apr 2010 21:23:49 -0700 (PDT) In-Reply-To: <7F2E4C55-6498-45E4-85FF-A28F85A731CD@lucidvision.com> References: <7F2E4C55-6498-45E4-85FF-A28F85A731CD@lucidvision.com> Date: Wed, 14 Apr 2010 21:23:49 -0700 Received: by 10.150.165.11 with SMTP id n11mr7968454ybe.185.1271305429822; Wed, 14 Apr 2010 21:23:49 -0700 (PDT) Message-ID: From: Vishwas Manral To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-TC MIB for IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 04:24:48 -0000 Hi Thomas, Great to hear from you. MPLS-TC's for IPv6 are broken. We have a solution to incrementally update the MIB without having to break any existing MIB's. I do not see your concern? It would be better if the "dozens" of vendors talk for themselves about the support they have for MPLS IPv6 MIB's, if they have concerns with having IPv6 support for the MIB's. I am sure if they had implemented the MIB for IPv6 they would have figured the issues basic issues in it. The consensus was that we would meet and discuss it during IETF meetings, but I guess because you have been busy we have been unable to do that earlier. Thanks, Vishwas On Wed, Apr 14, 2010 at 10:43 AM, Thomas Nadeau w= rote: > > =A0 =A0 =A0 =A0Before we get carried away with this let us first be clear= that the "base" MPLS MIBs do indeed support IPv6 in a manner that does wor= k. I've implemented them and know of dozens of implementations that did as = well. There are also 100s of deployments where these MIBs are now in use. > > =A0 =A0 =A0 =A0When the draft you reference first came out, many reviewed= the changes it contains (including myself). The consensus at the time was = that the changes proposed therein did not seem to outweigh the disadvantage= s of uprooting and updating EVERY MIB that imports the TC (or the many impl= ementations thereof). =A0For reference, people need to understand that ANY = changes to the TEXTUAL-CONVENTIONs contained in rfc3811 will require change= s to EVERY MIB module that imports and uses those TCs, as per MIB module de= precation and object update rules. In the analysis of the changes proposed = in your draft, it was determined that they would result in not only all of = the "base" MPLS MIBs needing updating, but then the GMPLS and PWE3 MIBs whi= ch rely on parts of those modules, would also result in similar module depr= ecation/updates needed. I don't believe that the situation has changed sinc= e then, but I can only speak on behalf of myself in this regard. > > =A0 =A0 =A0 =A0--Tom > > > >> Hi folks, >> >> There are some basic issues in the TC-MIB RFC 3811 for IPv6. We had >> made the changes to the MIB and updated the document below. As we seem >> to have support for the IPv6 MPLS effort, I think we should take the >> updates for the MIB along too. >> >> Here is the link to the MIB draft: >> >> http://tools.ietf.org/id/draft-manral-mpls-rfc3811bis-00.txt >> >> Thanks, >> Vishwas >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > From swmike@swm.pp.se Wed Apr 14 23:01:44 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9F93A6765 for ; Wed, 14 Apr 2010 23:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.204 X-Spam-Level: X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NwBaoBF84b5 for ; Wed, 14 Apr 2010 23:01:43 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 45F0D3A67B2 for ; Wed, 14 Apr 2010 23:01:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3FBE29C; Thu, 15 Apr 2010 08:01:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3F14A9A; Thu, 15 Apr 2010 08:01:29 +0200 (CEST) Date: Thu, 15 Apr 2010 08:01:29 +0200 (CEST) From: Mikael Abrahamsson To: Rob Shakir In-Reply-To: <1E2FA684-E5E0-45FA-9885-0BA7C288AC08@eng.gxn.net> Message-ID: References: <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> <1E2FA684-E5E0-45FA-9885-0BA7C288AC08@eng.gxn.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mpls@ietf.org Subject: Re: [mpls] LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 06:01:44 -0000 On Wed, 14 Apr 2010, Rob Shakir wrote: > I'd just like to speak up in support of this draft also. As an operator > that is progressing an IPv6 rollout, we are finding that in a number of > places, the only need to utilise 6PE is in order to address the lack of > support for IPv6 in LDP. +1 from me as well, I'm actually surprised that there hasn't been more work in establishing feature parity between IPv4 and IPv6 in the control plane. I'd imagine that by now it would be possible to implement standards-based IPv6 only control plane with equal functionality as is today possible with IPv4. > Whilst I think it's unlikely that many operators are currently putting > this down as a mandatory requirement, it's definitely something that I > believe is required. Considering IPv4 runout I definitely see greenfield rollout in 1-2 years wanting to do this IPv6 only, and considering code usually takes time to be finished the standards should definitely be done by now. What else is missing? -- Mikael Abrahamsson email: swmike@swm.pp.se From wwwrun@rfc-editor.org Thu Apr 15 03:00:57 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310793A69EE for ; Thu, 15 Apr 2010 03:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_40=-0.185, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi3lzIdnfEqS for ; Thu, 15 Apr 2010 03:00:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id CEBC33A67CF for ; Thu, 15 Apr 2010 03:00:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D05A3E07CA; Thu, 15 Apr 2010 03:00:42 -0700 (PDT) To: erosen@cisco.com, tappan@cisco.com, yakov@juniper.net, fedorkow@cisco.com, dino@procket.com, tli@procket.com, aconta@txc.com, stbryant@cisco.com, adrian.farrel@huawei.com, swallow@cisco.com, loa@pi.nu From: RFC Errata System Message-Id: <20100415100042.D05A3E07CA@rfc-editor.org> Date: Thu, 15 Apr 2010 03:00:42 -0700 (PDT) Cc: nmalykh@protocols.ru, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3032 (2162) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 10:00:57 -0000 The following errata report has been submitted for RFC3032, "MPLS Label Stack Encoding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3032&eid=2162 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3.1 Original Text ------------- Suppose that an unlabeled IP datagram is received at a particular LSR, and that the the LSR pushes on a label before forwarding the datagram. Such a datagram will be called an Initially Labeled IP Datagram at that LSR. Corrected Text -------------- Suppose that an unlabeled IP datagram is received at a particular LSR, and that the LSR pushes on a label before forwarding the datagram. Such a datagram will be called an Initially Labeled IP Datagram at that LSR. Notes ----- Doubled "the" 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. -------------------------------------- RFC3032 (draft-ietf-mpls-label-encaps-07) -------------------------------------- Title : MPLS Label Stack Encoding Publication Date : January 2001 Author(s) : E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From tnadeau@lucidvision.com Thu Apr 15 04:35:10 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7183A68C1 for ; Thu, 15 Apr 2010 04:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVcS9na-cty4 for ; Thu, 15 Apr 2010 04:35:09 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id AED4D28C0E0 for ; Thu, 15 Apr 2010 04:34:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id E4FEA3F01F8; Thu, 15 Apr 2010 07:34:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV8riST5f4w6; Thu, 15 Apr 2010 07:34:49 -0400 (EDT) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 01F333F01ED; Thu, 15 Apr 2010 07:34:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net> Date: Thu, 15 Apr 2010 07:34:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F0555B1-1CA3-43F9-A832-2B0FBF2477C5@lucidvision.com> References: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net> To: Nitin Bahadur X-Mailer: Apple Mail (2.1078) Cc: IETF MPLS , 'Ilya Varlashkin' Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 11:35:10 -0000 Yes, for reference, the draft is called = draft-nadeau-mpls-interas-lspping-03.txt On Apr 14, 2010, at 4:27 PM, Nitin Bahadur wrote: >=20 > Hi Ilya, >=20 > There is an expired draft by George Swallow & Tom Nadeau that tries = to > address the problem you are encountering. >=20 > mpls-tunneling will not help. Mainly because lsp-traceroute is used = as a > diagnostic tool to detect where a failure is in the network. If there = is a failure > in the network, then the echo request/response will unlikely make it = to the=20 > egress PE. >=20 > So for fault isolation, you need the transit nodes to respond back. = How they > respond back is theorized in the above mentioned draft. >=20 > Thanks > Nitin =20 >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 >> Behalf Of Ilya Varlashkin >> Sent: Wednesday, April 14, 2010 7:44 AM >> To: IETF MPLS >> Subject: [mpls] LSP traceroute failure with Inter-AS MPLS >>=20 >> Hi, >>=20 >> I was doing some LSP traceroutes across AS boundaries (on real-world >> network) and missed replies from some intermediate routers in=20 >> the target AS. Digging a bit deeper I've found following: if=20 >> some AS has BGP-free core and its internal (core) routers=20 >> don't have routing information for foreign prefixes, then=20 >> these internal routers won't be able to send LSP Echo Replies=20 >> to originator of the traceroute. Normal end-to-end traffic is=20 >> delivered without problems both ways because PE routers in=20 >> such AS put two labels on the stack (using labelled-unicast)=20 >> when sending packets towards foreign routers, so core routers=20 >> don't have to know how to reach foreign PE. >>=20 >> Before going to our routers' vendor I've looked through=20 >> RFC4379 once more to check whether it's an implementation or=20 >> specification issue. It looks like there is nothing in RFC to=20 >> address above mentioned scenario, so looks like specification issue.=20= >>=20 >> Similar problem with normal traceroute within MPLS L3VPN=20 >> environment is addressed by ICMP-tunnelling trick -=20 >> forwarding ICMP message along the same path as original=20 >> packet that caused generation of that ICMP message. Wouldn't=20 >> the same approach work with LSP ping? All what's needed, from=20 >> protocol PoV, is to say that if an intermediate router (not=20 >> final destination!) needs to send a reply (because TTL=20 >> expired) doesn't have route back to originator of LSP ECHO=20 >> then it should send reply along the same path as original LSP=20 >> ECHO. I.e. if PE1 sends LSP ECHO request to PE2 over=20 >> intermediate router P, and P would use label L1 and interface=20 >> INTF1 to send packets towards PE2, then P should also use=20 >> label L1 and interface INTF1 when it needs to send replies=20 >> back to PE1. >> Would doing so cause any problems? If not, should we ammend=20 >> specification of LSP ping/traceroute? >>=20 >> Cheers, >> iLya >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From tnadeau@lucidvision.com Thu Apr 15 04:36:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F0B3A69FB for ; Thu, 15 Apr 2010 04:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF5dKZyIAGpj for ; Thu, 15 Apr 2010 04:36:16 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 35BF13A68ED for ; Thu, 15 Apr 2010 04:36:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id CFC2D3F0210; Thu, 15 Apr 2010 07:35:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gRmvbRrXsGV; Thu, 15 Apr 2010 07:35:54 -0400 (EDT) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 535793F0205; Thu, 15 Apr 2010 07:35:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <05542EC42316164383B5180707A489EE1D0AC2F9F4@EMBX02-HQ.jnpr.net> Date: Thu, 15 Apr 2010 07:35:54 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net> <06043151-779D-4ABC-BFA5-E4A35FA12362@de.easynet.net> <05542EC42316164383B5180707A489EE1D0AC2F9F4@EMBX02-HQ.jnpr.net> To: Nitin Bahadur X-Mailer: Apple Mail (2.1078) Cc: IETF MPLS , 'Ilya Varlashkin' Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 11:36:18 -0000 Yes, this one is correct. Sorry, disregard my last pointer. --Tom On Apr 14, 2010, at 8:05 PM, Nitin Bahadur wrote: > > http://tools.ietf.org/html/draft-ietf-mpls-interas-lspping-00 > > Thanks > Nitin > >> -----Original Message----- >> From: Ilya Varlashkin [mailto:Ilya.Varlashkin@de.easynet.net] >> Sent: Wednesday, April 14, 2010 2:14 PM >> To: Nitin Bahadur >> Cc: IETF MPLS >> Subject: Re: LSP traceroute failure with Inter-AS MPLS >> >> Hi Nitin, >> >> On Apr 14, 2010, at 22:27 , Nitin Bahadur wrote: >> >>> >>> Hi Ilya, >>> >>> There is an expired draft by George Swallow & Tom Nadeau >> that tries >>> to address the problem you are encountering. >>> >>> mpls-tunneling will not help. Mainly because >> lsp-traceroute is used >>> as a >> ... >> >> I thought about that, but then better something than nothing >> at all. After all traceroute in VPN environment is used for >> the same purpose and it's quite useful because problem is not >> necessarily complete loss of connectivity but e.g. packet loss. >> >> Do you have pointer to the draft? >> >> /iLya >> >> >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From Ilya.Varlashkin@de.easynet.net Thu Apr 15 04:56:30 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544293A69FB for ; Thu, 15 Apr 2010 04:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-65IGSoReBq for ; Thu, 15 Apr 2010 04:56:29 -0700 (PDT) Received: from softy.de.easynet.net (softy.de.easynet.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id 201293A6A13 for ; Thu, 15 Apr 2010 04:55:56 -0700 (PDT) Received: from fe01kgham.de.easynet.net ([194.163.250.17] helo=fe01kgham.adoffice.local.de.easynet.net) by softy.de.easynet.net with esmtp (Exim 4.63) (envelope-from ) id 1O2Nff-0005Cr-2T; Thu, 15 Apr 2010 13:55:47 +0200 Received: from ex01kgham.adoffice.local.de.easynet.net ([10.43.3.3]) by fe01kgham.adoffice.local.de.easynet.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Apr 2010 13:55:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Apr 2010 13:55:46 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] LSP traceroute failure with Inter-AS MPLS Thread-Index: Acrcj9wAz7cmwCI8QOqJ0Ppgc9GbDgAAotQA References: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net><06043151-779D-4ABC-BFA5-E4A35FA12362@de.easynet.net><05542EC42316164383B5180707A489EE1D0AC2F9F4@EMBX02-HQ.jnpr.net> From: "Ilya Varlashkin" To: "Thomas Nadeau" X-OriginalArrivalTime: 15 Apr 2010 11:55:46.0747 (UTC) FILETIME=[95A588B0:01CADC92] Cc: IETF MPLS Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 11:56:30 -0000 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Thomas Nadeau > Sent: Thursday, April 15, 2010 1:36 PM > To: Nitin Bahadur > Cc: IETF MPLS; Ilya Varlashkin > Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS >=20 >=20 > Yes, this one is correct. Sorry, disregard my last pointer. >=20 Thomas, why have you abandoned that draft? Would it be possible to revive it? /iLya From tnadeau@lucidvision.com Thu Apr 15 05:36:16 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23BA728C20F for ; Thu, 15 Apr 2010 05:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaoBwq2DKtrD for ; Thu, 15 Apr 2010 05:36:15 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id A44C328C21D for ; Thu, 15 Apr 2010 05:31:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id F2DBA3F061B; Thu, 15 Apr 2010 08:30:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOs7ghNgZtVB; Thu, 15 Apr 2010 08:30:59 -0400 (EDT) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 662A13F0610; Thu, 15 Apr 2010 08:30:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: Date: Thu, 15 Apr 2010 08:30:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6BCDA4A3-4111-4A16-9CF9-FF2DED514BAE@lucidvision.com> References: <05542EC42316164383B5180707A489EE1D0AC2F9DF@EMBX02-HQ.jnpr.net><06043151-779D-4ABC-BFA5-E4A35FA12362@de.easynet.net><05542EC42316164383B5180707A489EE1D0AC2F9F4@EMBX02-HQ.jnpr.net> To: "Ilya Varlashkin" X-Mailer: Apple Mail (2.1078) Cc: IETF MPLS Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 12:36:16 -0000 =46rom my end, I think it got lost in the shuffle when I changed = employers,=20 so there was no loss in interest per se. In any event, it is a WG draft, = so its up=20 to the WG on the status. =20 --Tom >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 >> Behalf Of Thomas Nadeau >> Sent: Thursday, April 15, 2010 1:36 PM >> To: Nitin Bahadur >> Cc: IETF MPLS; Ilya Varlashkin >> Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS >>=20 >>=20 >> Yes, this one is correct. Sorry, disregard my last pointer. >>=20 > Thomas, >=20 > why have you abandoned that draft? Would it be possible to revive it? >=20 > /iLya >=20 From mtinka@globaltransit.net Thu Apr 15 09:36:20 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDAB33A6B66 for ; Thu, 15 Apr 2010 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.857 X-Spam-Level: * X-Spam-Status: No, score=1.857 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx+yUxAhg4Wi for ; Thu, 15 Apr 2010 09:36:20 -0700 (PDT) Received: from the-host.globaltransit.net (unknown [203.223.132.219]) by core3.amsl.com (Postfix) with ESMTP id 5740C3A6B8A for ; Thu, 15 Apr 2010 09:36:18 -0700 (PDT) Received: from [127.0.0.1] (helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.69) (envelope-from ) id 1O2S2r-000312-Oz; Fri, 16 Apr 2010 00:36:01 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Fri, 16 Apr 2010 00:35:54 +0800 User-Agent: KMail/1.12.4 (Linux/2.6.31.12-0.2-desktop; KDE/4.3.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1668324.Lggf4Ho8aP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201004160035.59171.mtinka@globaltransit.net> Cc: Ilya Varlashkin Subject: Re: [mpls] LSP traceroute failure with Inter-AS MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 16:36:21 -0000 --nextPart1668324.Lggf4Ho8aP Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday 14 April 2010 10:43:57 pm Ilya Varlashkin=20 wrote: > Digging a bit > deeper I've found following: if some AS has BGP-free > core and its internal (core) routers don't have routing > information for foreign prefixes, then these internal > routers won't be able to send LSP Echo Replies to > originator of the traceroute. Operationally, we run a BGP-free core (free of IPv4 BGP, but=20 full IPv6 routing table, of course) where IPv4 traffic is=20 switched purely on MPLS labels. We have a mix of Cisco and Juniper routers that support=20 traceroute feedback from the core to sources that are=20 external to our AS. This has worked with us in Cisco IOS since Day One, but we=20 had a few challenges with the JUNOS code for this, which was=20 later fixed + explicit enabling of ICMP-Tunneling required.=20 All is well in our land, now. Obviously, we currently can't ping core routers from an=20 external AS and expect a response, but traceroute works. I haven't had a chance to read Thomas and George's draft=20 until now, although our BGP-free core was erected around the=20 same time this draft was initially written/published, so I'm=20 not sure if my feedback is even useful. But I'll study it=20 and see if there's anything I can add, if necessary, based=20 on what we've seen in the wild. Cheers, Mark. --nextPart1668324.Lggf4Ho8aP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iQIcBAABAgAGBQJLx0BuAAoJEGcZuYTeKm+G1kQP/jhZGFcFf0pqG7p1buDKNUAn mJ1CN4j3YokubaZ7FpG4C+wBWp4V0irXThOD/LXTjChlZfa4yMuS3o1uAyVJYG1O hMTnXvmfrWqfULNANQVB/dVdRSLgoMMsGmhn8Dj/TtobiFUR9/eC2nl6+GtIs/Ti ibisQA/MIN3TWYC/jVAB3HJnUGTgaYGSthehKpZBVnD5Jc8uQdDKKfd3omLe45ji IRKFa89AG1BeimhhI3Z7vXm7eitEHzXcyfEJsZyojm3iqqU/22NklxdEQU9s5OsI CINknyQVXeF0NtRwfX0USvIm/5W7kO8X25NZ7ooWldFA6xYac4bqN9oGT0kOiEns nQiZgtfCU4NSjJPBFkci/RHv2Aquom9DX1wfmneKRcYLahDcCigJu0hrV7d74lmp LSyn0R2aA6KZW8Vhuhy7II0mcmxa/U/rw9/CPYKQgV7/VelJwkdFGl4h2rvbUUgL 6s3dKUMPKNtYm09GUupUmLauy5KXdDAuhT/4TpNJV+8RPp8c/fUwp3fjpAOZlS1S 0qODaSNaGfumR/GkHYgMcWBL1t1JoMbN0fNosM/1yTwLwnIKNJC7jRf84RppsA/v uIlwuCRrt/n259ly3iK69CY7aeSbhRHRILabH4Xb8Z9lkJSWoQPin7Bg/hPSwR1W Qe7AMEBH32LTwlYrnHJd =vdcj -----END PGP SIGNATURE----- --nextPart1668324.Lggf4Ho8aP-- From vishwas.ietf@gmail.com Fri Apr 16 09:39:43 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACC23A6963 for ; Fri, 16 Apr 2010 09:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzcDezxApVVA for ; Fri, 16 Apr 2010 09:39:42 -0700 (PDT) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by core3.amsl.com (Postfix) with ESMTP id 7F73D3A6956 for ; Fri, 16 Apr 2010 09:39:42 -0700 (PDT) Received: by yxe14 with SMTP id 14so1500901yxe.5 for ; Fri, 16 Apr 2010 09:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JIiwTo3gN7x1tB2g5sis7C1htqtme8hugSFwmexJj0c=; b=Ipdd+HUY8kWahQfspi6ZovGXRhoUbH12JZf7KOnRN5OvmdLqqx1xx4OvvuWvO0SC4J pypSew5G3Jvsc8QHKCi29F/4VVZ2T8UGi/+iflTQt9T5gIqpWs76lVtO4QRUat2AFOzq ziDBTXYrUD6DP0EGx1K5/GBuVLgVIKQxZyGYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=cS91wnslyZJQnD7hwB+HYfUFjFq6J4zMD2dQZFl3Mji6fAuIOOEzENMuRMhIXvhiaM qgP2ZxRyzChMHNdYQ8r21mG/WhgxD/cwOFq6YXUYsnOR7UuvfkoohEdk+kPwS754NfG7 2U46tUglI/fW05uLwj0lHyQ0VAZDVMcyqfi1Y= MIME-Version: 1.0 Received: by 10.151.46.14 with HTTP; Fri, 16 Apr 2010 09:39:32 -0700 (PDT) In-Reply-To: References: <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> <1E2FA684-E5E0-45FA-9885-0BA7C288AC08@eng.gxn.net> Date: Fri, 16 Apr 2010 09:39:32 -0700 Received: by 10.150.194.12 with SMTP id r12mr1939344ybf.272.1271435972651; Fri, 16 Apr 2010 09:39:32 -0700 (PDT) Message-ID: From: Vishwas Manral To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [mpls] Fwd: LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 16:39:43 -0000 Hi Egor, We were using the wrong alias it is mpls@ietf.org and not mpls@ietf.com. Thanks, Vishwas ---------- Forwarded message ---------- From: Vishwas Manral Date: Fri, Apr 16, 2010 at 6:59 AM Subject: Re: [mpls] LDP IPv6 To: Egor Zimin Cc: Mikael Abrahamsson , Rob Shakir , mpls@ietf.com, faz@netfm.co.uk Hi Egor, 1. As Mikael brought out the question of what else is missing I brought up the MIB and RSVP-TE issues. I will bring the details out in another mail with the correct subject line. 2. I guess now that we have more knowledge of the draft we can actually try to push it further. Thanks, Vishwas On Fri, Apr 16, 2010 at 1:03 AM, Egor Zimin wrote: > Hi, Vishwas, > > 1. About RSVP-TE and IPv6 Router Alert option. > I do not quite understand your opinion. > Do you propose to remove Router Alert option for IPv6 ? Why ? Because of > lack of RSVP-TE IPv6 implementations alone ? Because of only RSVP TE uses > this option ? Also, what security issues do you mean ? > And... what does that have to LDPv6 draft discussion? > > 2. About draft-manral-mpls-ldp-ipv6-03: > I think, the changes and clarifications proposed in the draft are very > obvious and not so significant. In fact, the draft only clarifies peer > discovery and transport session establishment procedures for IPv6. I don'= t > understand why this draft has not yet become RFC. > > 2010/4/15 Vishwas Manral >> >> Hi Mikael/ Rob/ Farhan/ Egor, >> >> > Considering IPv4 runout I definitely see greenfield rollout in 1-2 >> > years wanting to do this IPv6 only, and considering code usually >> > takes time to be finished the standards should definitely be done >> > by now. >> > >> > What else is missing? >> Let me begin by saying that most drafts/ RFC's have some IPv6 >> component to them. This however is appended as an add-on in some >> cases. As most of these have not been looked at in detail there are >> some holes in the RFC for IPv6. >> >> I found similar holes a couple of years back and wrote this and the >> MPLS-TC IPv6 MIB draft. I also noticed that for RSVP-TE for IPv6 we do >> not have support for Router Alert in a lot of platforms. It also has >> all the security issues aside from that. >> >> As RSVP-TE seems to be carrying Router Alert as a legacy thing and as >> RSVP-TE IPv6 is not implemented on the field I think it would be good >> to do away, remove the use of Router Alert in RSVP for IPv6. >> >> What do folks on the list think? >> >> BTW, I had mails from a couple of more operators in private and have >> forwarded them to the chairs. >> >> Thanks, >> Vishwas >> >> On Wed, Apr 14, 2010 at 11:01 PM, Mikael Abrahamsson >> wrote: >> > On Wed, 14 Apr 2010, Rob Shakir wrote: >> > >> >> I'd just like to speak up in support of this draft also. As an operat= or >> >> that is progressing an IPv6 rollout, we are finding that in a number = of >> >> places, the only need to utilise 6PE is in order to address the lack = of >> >> support for IPv6 in LDP. >> > >> > +1 from me as well, I'm actually surprised that there hasn't been more >> > work >> > in establishing feature parity between IPv4 and IPv6 in the control >> > plane. >> > I'd imagine that by now it would be possible to implement >> > standards-based >> > IPv6 only control plane with equal functionality as is today possible >> > with >> > IPv4. >> > >> >> Whilst I think it's unlikely that many operators are currently puttin= g >> >> this down as a mandatory requirement, it's definitely something that = I >> >> believe is required. >> > >> > Considering IPv4 runout I definitely see greenfield rollout in 1-2 yea= rs >> > wanting to do this IPv6 only, and considering code usually takes time = to >> > be >> > finished the standards should definitely be done by now. >> > >> > What else is missing? >> > >> > -- >> > Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se >> > > > > > -- > Best regards, > Egor Zimin > From swallow@cisco.com Fri Apr 16 09:45:40 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DDB028C108; Fri, 16 Apr 2010 09:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVxLE3fUYBD6; Fri, 16 Apr 2010 09:45:39 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6C1C528C11F; Fri, 16 Apr 2010 09:45:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOowyEutJV2Y/2dsb2JhbACbc3GlQJodAoJXgjUE X-IronPort-AV: E=Sophos;i="4.52,220,1270425600"; d="scan'208";a="102431787" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2010 16:45:27 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o3GGjRsc007266; Fri, 16 Apr 2010 16:45:27 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Apr 2010 11:45:27 -0500 Received: from 10.98.32.165 ([10.98.32.165]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Apr 2010 16:45:27 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 16 Apr 2010 12:45:25 -0400 From: George Swallow To: Attila Takacs , Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Message-ID: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtc= In-Reply-To: <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Apr 2010 16:45:27.0723 (UTC) FILETIME=[37EDBFB0:01CADD84] Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 16:45:40 -0000 On 4/2/10 2:53 AM, "Attila Takacs" wrote: > Hi Matthew and George, > > Please find some comments/questions below. > > -In Section 5.1 you have: > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num? Existing implementations of RSVP-TE have used the tunnel space as global to the node. It is difficult if not impossible to coordinate such spaces between nodes. In RSVP-TE the coordination does not matter, since the tail end of the tunnel doesn't have a real interface - it only receives and usually with a PHP of the tunnel label, so the packets only belong to the physical interface. In a bidirectional world, separate tunnel spaces at the two ends becomes useful. If this independence is not need is some environments then one can configure just one value and use it in both fields. > Is it there to support associated unidirectional Tunnels/LSPs? If so it should > be called out in the text. That was not my original intent, but you are quite correct that this would be very useful. Particularly if the associated tunnels pass through a share mid-point somewhere along the path. > Same applies to the globally unique case. Of course. > -In Section 5.2 you simply append one LSP_Num to the above. This is a bit > confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums would be > needed too, wouldn't it? Once, you have independent tunnel-ids, coordination of the LSP numbers becomes easy. It also could be used to allow the two ends to readily identify which is working and which is protection. > -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tunnel_Num. So > this means that we may have two different tunnels identified with > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this intentional, > e.g., the associated unidirectional case? For the associated unidirectional, this works perfectly. For bidirectional, I was thinking of two options. 1) Strict binding - both ends are configure with the full identifier and will only accept the connection if everything matches. 2) Dynamic binding - Source signals with just its Tunnel_Num. RESV message would carry back the destination's tunnel_num. Note that both ends need both pieces for some of the OAM to work. > This should be clarified. I'll see what I can do. But this is not supposed to the MPLS-TP signaling draft. > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. I'm planning to keep it. > -Section 7 has a note saying to be aligned with the OAM fwk, is this still to > be done? Yes. That draft is also being updated. We appear to be converging. > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel level > and not at the LSP level? > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? I had been told early on that MEGs were needed for tunnels. Now getting comments that they are not (same comment is in the ITU liaison). So I planning to remove it, unless I hear other opinions. > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. See above. > -Section 8 talks about open issues? When will these be addressed? Before it is re-issued. Goal is end of next week. ...George > Thanks, > Attila > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Loa Andersson >> Sent: Friday, March 12, 2010 12:33 AM >> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >> >> All, >> >> this is to start an MPLS working group last call on >> draft-ietf-mpls-tp-identifiers-01 >> >> There is a discussion on the OAM model for MS-PWs where we >> haven't been able to come to conclusion. Once we reach >> agreement the document will be updated. Comments in this area >> are welcome during the working group last call. >> >> >> Please send your comments to the mpls-tp@ietf.org mailing list. >> >> The working group last ends eob April 2nd. >> >> /Loa >> >> -- >> >> Loa Andersson >> >> Sr Strategy and Standards Manager >> Ericsson /// >> phone: +46 10 717 52 13 >> +46 767 72 92 13 >> >> email: loa.andersson@ericsson.com >> loa@pi.nu >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From venkatflex@gmail.com Sun Apr 18 22:11:17 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64AC3A69DE; Sun, 18 Apr 2010 22:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEgppCNy0-Ec; Sun, 18 Apr 2010 22:11:14 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 9E1263A6907; Sun, 18 Apr 2010 22:11:10 -0700 (PDT) Received: by pvf33 with SMTP id 33so2806933pvf.31 for ; Sun, 18 Apr 2010 22:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=TnLRKrupxgHKYvO8BDc2efuFhZAMIMohkC9+wAENCe4=; b=Yv4B2s3yDiK3HoBnfBKVb6CUiI+ugwD20be5G+w2Rs89tMH1hEJSuKuMXOBaoWZHIu m9D68eqQfixyTS2RUL2FMbhK1hywQA3azGxHkBWStue+KKDhvqcDo3UUDsSEAbDo6Roi mtluxdtL9jtu28T6VOCzlS89foUsEagqbZb10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KTaGEzrJuJJEkFZbQhMjfzXMBxhcA+lPO62bm4bTTc7LYlMbg+C8Hak/yzlCXPt20F eSF/QqwS3gUdLXD2S2B5EDDNONyei77ZhRYRepg3tmumDnG53g8Tw7ytmI9eo3tMLa8G WBsSvDN5lrFq7sLrcD4lfFg0g/eMYLYmn90RY= MIME-Version: 1.0 Received: by 10.143.35.1 with HTTP; Sun, 18 Apr 2010 22:11:00 -0700 (PDT) Date: Mon, 19 Apr 2010 10:41:00 +0530 Received: by 10.142.75.21 with SMTP id x21mr1736439wfa.195.1271653860127; Sun, 18 Apr 2010 22:11:00 -0700 (PDT) Message-ID: From: venkatesan mahalingam To: mpls , mpls-tp@ietf.org Content-Type: multipart/alternative; boundary=001636e1fc1c9c363004848ffc9a Subject: [mpls] Regarding LDP host Address Fec type removal from RFC-3815 LDP MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 05:11:18 -0000 --001636e1fc1c9c363004848ffc9a Content-Type: text/plain; charset=ISO-8859-1 Hi All, As per RFC 5036 section 7 [Changes from RFC 3036 ] "Removed the Host Address FEC and references to it, since it is not used by any implementation" but in RFC-3815 [Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)] is not updated to remove the hostAddress Fec Type. Is there any work in progress to remove the hostAddress Fec type from this LDP MIB? mplsFecTable object: -------------------------------- mplsFecType OBJECT-TYPE SYNTAX INTEGER { prefix(1), *hostAddress(2)* } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the FEC. If the value of this object is 'prefix(1)' then the FEC type described by this row is an address prefix. If the value of this object is 'hostAddress(2)' then the FEC type described by this row is a host address." REFERENCE "RFC3036, Section 3.4.1. FEC TLV." ::= { mplsFecEntry 2 } -- Best Regards, Venkatesan Mahalingam. --001636e1fc1c9c363004848ffc9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
As per RFC 5036 section 7 [Changes from RFC 3036]
"Removed the Host Address FEC and re= ferences to it, since it is=A0not used by any implementation" but in R= FC-3815=A0[Definitions of Managed Objects for the=A0Multiprotocol Label Switching (MPLS),=A0Label Distribution Protocol (LDP)] is not updated=A0to = remove the hostAddress Fec Type.
=A0
Is there any work in progress to remove the hostAddress Fec type from = this LDP MIB?
mplsFecTable object:
--------------------------------

=A0=A0=A0=A0 mplsFecType=A0 OBJECT-TYPE
=A0=A0=A0= =A0=A0=A0=A0=A0 SYNTAX=A0=A0=A0=A0=A0 INTEGER {
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prefix(1),
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 hostAddress(= 2)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= }
=A0=A0=A0=A0=A0=A0=A0=A0 MAX-ACCESS=A0 read-create
=A0=A0=A0=A0=A0=A0=A0=A0 STATUS=A0=A0=A0=A0=A0 current
=A0=A0=A0=A0=A0= =A0=A0=A0 DESCRIPTION
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "The typ= e of the FEC.=A0 If the value of this object
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 is 'prefix(1)' then the FEC type described by this
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 row is an address prefix.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If the value of this object is = 9;hostAddress(2)' then
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the FEC = type described by this row is a host address."
=A0=A0=A0=A0=A0=A0= =A0=A0 REFERENCE
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "RFC3036, Section=A03.4.1. FEC TLV."
=A0=A0=A0=A0=A0=A0=A0=A0 ::=3D { mplsFecEntry 2 }

--
Best Regard= s,
Venkatesan Mahalingam.
--001636e1fc1c9c363004848ffc9a-- From wwwrun@core3.amsl.com Mon Apr 19 04:35:27 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C3B3B3A69D9; Mon, 19 Apr 2010 04:35:27 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100419113527.C3B3B3A69D9@core3.amsl.com> Date: Mon, 19 Apr 2010 04:35:27 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "Disposition of #012.02 Comments (ref #021.03)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 11:35:27 -0000 Title: Disposition of #012.02 Comments (ref #021.03) Submission Date: 2010-04-19 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=873 From: Loa Andersson(IETF MPLS WG) To: SG15, Q9, Q10, Q12, Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For information Body: see attachments Attachment(s): Liaison on Disposition of #012.02 Comments (ref #021.03) (https://datatracker.ietf.org/documents/LIAISON/file987.doc) Disposition of ITU-T Review Comments on draft-ietf-mpls-tp-survive-framework-04.txt (https://datatracker.ietf.org/documents/LIAISON/file988.doc) From tom.nadeau@bt.com Mon Apr 19 04:37:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77F63A6A35; Mon, 19 Apr 2010 04:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7C59UQR8CrZ; Mon, 19 Apr 2010 04:37:18 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 8E9F33A6A39; Mon, 19 Apr 2010 04:37:17 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 12:37:06 +0100 Received: from 217.32.164.180 ([217.32.164.180]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.149]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Apr 2010 11:37:06 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 19 Apr 2010 07:37:03 -0400 From: "Thomas D. Nadeau" To: venkatesan mahalingam , mpls , Message-ID: Thread-Topic: [mpls-tp] Regarding LDP host Address Fec type removal from RFC-3815 LDP MIB Thread-Index: AcrftKF+72Oi48S44Uu51RjvepnP2A== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3354507423_20465717" X-OriginalArrivalTime: 19 Apr 2010 11:37:06.0967 (UTC) FILETIME=[A3DBAA70:01CADFB4] Subject: Re: [mpls] [mpls-tp] Regarding LDP host Address Fec type removal from RFC-3815 LDP MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 11:37:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3354507423_20465717 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable If/when the LDP MIB (and other MPLS MIBs) are progressed to the next stage in standardization, we would definitely have to go through the implementation reports and mimic their changes. At present, there is no such work in progress. In the meantime, what I think implementations would just set the variable to the default value, while NM entities would ignore it (assuming they understood the device was ignoring it too). --Tom On 4/19/10 1:11 AM, "venkatesan mahalingam" wrote: > Hi All, > As per RFC 5036 section 7 [Changes from RFC 3036 > ] > "Removed the Host Address FEC and references to it, since it is=A0not used = by > any implementation" but in RFC-3815=A0[Definitions of Managed Objects for > the=A0Multiprotocol Label Switching (MPLS),=A0Label Distribution Protocol (LD= P)] > is not updated=A0to remove the hostAddress Fec Type. > =A0 > Is there any work in progress to remove the hostAddress Fec type from thi= s LDP > MIB? > mplsFecTable object: > -------------------------------- >=20 > =A0=A0=A0=A0 mplsFecType=A0 OBJECT-TYPE > =A0=A0=A0=A0=A0=A0=A0=A0 SYNTAX=A0=A0=A0=A0=A0 INTEGER { > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prefix(1), > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 hostAddress(2) > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 } > =A0=A0=A0=A0=A0=A0=A0=A0 MAX-ACCESS=A0 read-create > =A0=A0=A0=A0=A0=A0=A0=A0 STATUS=A0=A0=A0=A0=A0 current > =A0=A0=A0=A0=A0=A0=A0=A0 DESCRIPTION > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "The type of the FEC.=A0 If the value of this object > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is 'prefix(1)' then the FEC type described by this > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 row is an address prefix. >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If the value of this object is 'hostAddress(2)' then > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the FEC type described by this row is a host address." > =A0=A0=A0=A0=A0=A0=A0=A0 REFERENCE > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "RFC3036, Section=A03.4.1 > . FEC TLV." > =A0=A0=A0=A0=A0=A0=A0=A0 ::=3D { mplsFecEntry 2 } --B_3354507423_20465717 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls-tp] Regarding LDP host Address Fec type removal from RFC-3= 815 LDP MIB
    If/when the LDP MIB (and other MPLS MIBs) are progr= essed to the next stage in standardization, we would definitely have to go t= hrough the implementation reports and mimic their changes.  At present,= there is no such work in progress. In the meantime, what I think implementa= tions would just set the variable to the default value, while NM entities wo= uld ignore it (assuming they understood the device was ignoring it too).
    --Tom


On 4/19/10 1:11 AM, "venkatesan mahalingam" <venkatflex@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>Hi All,
As per RFC 5036 section 7 [Changes from RFC 3036 <http://tools.ietf.org/html/rfc3036> ]
"Removed the Host Address FEC and references to it, since it is=A0not us= ed by any implementation" but in RFC-3815=A0[Definitions of Managed Objec= ts for the=A0Multiprotocol Label Switching (MPLS),=A0Label Distribution Protocol= (LDP)] is not updated=A0to remove the hostAddress Fec Type.
=A0
Is there any work in progress to remove the hostAddress Fec type from this = LDP MIB?
mplsFecTable object:
--------------------------------

=A0=A0=A0=A0 mplsFecType=A0 OBJECT-TYPE
=A0=A0=A0=A0=A0=A0=A0=A0 SYNTAX=A0=A0=A0=A0=A0 INTEGER {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prefix(1),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 hostAddress(2)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0=A0=A0=A0 MAX-ACCESS=A0 read-create
=A0=A0=A0=A0=A0=A0=A0=A0 STATUS=A0=A0=A0=A0=A0 current
=A0=A0=A0=A0=A0=A0=A0=A0 DESCRIPTION
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "The type of the FEC.=A0 If the value of this object
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is 'prefix(1)' then the FEC type described by this
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 row is an address prefix.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If the value of this object is 'hostAddress(2)' then
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the FEC type described by this row is a host address." =A0=A0=A0=A0=A0=A0=A0=A0 REFERENCE
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "RFC3036, Section=A03.4.1 <http://tools.ietf.org/html/rfc3036#section-3.4= .1> . FEC TLV."
=A0=A0=A0=A0=A0=A0=A0=A0 ::=3D { mplsFecEntry 2 }
=

--B_3354507423_20465717-- From wwwrun@core3.amsl.com Mon Apr 19 08:32:16 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 90D9428C361; Mon, 19 Apr 2010 08:32:16 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100419153216.90D9428C361@core3.amsl.com> Date: Mon, 19 Apr 2010 08:32:16 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS166 - Decision on progressing G.8112 Interfaces for the MPLS-TP Hierarchy" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 15:32:16 -0000 Title: LS166 - Decision on progressing G.8112 Interfaces for the MPLS-TP Hierarchy Submission Date: 2010-04-19 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=874 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: hhelvoort@huawei.com Purpose: For information Body: The experts of Q10/15 would like to inform you that it was agreed that consenting G.8112 �Interfaces for the MPLS-TP Hierarchy� is based on the availability of both recommendations G.8110.1 and G.tpoam. This means it will not be consented in the June plenary meeting of SG15. The RFC � Recommendation dependency has been updated to reflect this agreement. Attachment(s): LS166 - Decision on progressing G.8112 Interfaces for the MPLS-TP Hierarchy - pdf (https://datatracker.ietf.org/documents/LIAISON/file989.pdf) From wwwrun@core3.amsl.com Mon Apr 19 08:36:38 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C541628C3BB; Mon, 19 Apr 2010 08:36:38 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100419153638.C541628C3BB@core3.amsl.com> Date: Mon, 19 Apr 2010 08:36:38 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, malcolm.betts@zte.com.cn, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS167 - Comments on draft-ietf-mpls-tp-framework-11 [Ref # 026.02]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 15:36:38 -0000 Title: LS167 - Comments on draft-ietf-mpls-tp-framework-11 [Ref # 026.02] Submission Date: 2010-04-19 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=875 Please reply by 2010-05-27 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@zte.com.cn Purpose: For action Body: Attachment(s): LS167 - Comments on draft-ietf-mpls-tp-framework-11 [Ref # 026.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file990.pdf) From wwwrun@core3.amsl.com Mon Apr 19 08:51:30 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A8CD528C202; Mon, 19 Apr 2010 08:51:30 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com, loa@pi.nu, martin.vigoureux@alcatel-lucent.com, sob@harvard.edu, chris@cw.net Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100419155130.A8CD528C202@core3.amsl.com> Date: Mon, 19 Apr 2010 08:51:30 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, dromasca@avaya.com, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, opsawg@ietf.org, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS168 - Response to The OAM Acronym Soup -03 WG Last Call (ref # 025.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 15:51:30 -0000 Title: LS168 - Response to The OAM Acronym Soup -03 WG Last Call (ref # 025.02) Submission Date: 2010-04-19 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=876 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG and OPSA WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com,sob@harvard.edu,chris@cw.net) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org dromasca@avaya.com opsawg@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Kam.Lam@alcatel-lucent.com Purpose: For information Body: Thank you for your liaison statement (ref # 025.01) soliciting last call comments by ITU-T on the OAM Acronym Soup draft. The experts of Q14/15 have reviewed draft-ietf-opsawg-mpls-tp-oam-def-03.txt by correspondence. While we have no concerns with the IETF proceeding with the publication of this -03 draft, we have some comments for your consideration for improvement. Our comments are shown with revision marks in the attached document. Attachment: 1 Attachment(s): LS168 - Response to The OAM Acronym Soup -03 WG Last Call (ref # 025.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file993.pdf) LS168 - Response to The OAM Acronym Soup -03 WG Last Call (ref # 025.02) - Attach1 (https://datatracker.ietf.org/documents/LIAISON/file994.pdf) From root@core3.amsl.com Mon Apr 19 10:15:01 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DEEC23A686C; Mon, 19 Apr 2010 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100419171501.DEEC23A686C@core3.amsl.com> Date: Mon, 19 Apr 2010 10:15:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-survive-fwk-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 17:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching Transport Profile Survivability Framework Author(s) : N. Sprecher, A. Farrel Filename : draft-ietf-mpls-tp-survive-fwk-05.txt Pages : 56 Date : 2010-04-19 Network survivability is the ability of a network to recover traffic delivery following failure, or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) which place maximum bounds on the length of time that services may be degraded or be unavailable. The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane which re-uses many aspects of the MPLS management and control planes. This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet-based transport network, as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-survive-fwk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-19100030.I-D@ietf.org> --NextPart-- From Martin.Vigoureux@alcatel-lucent.com Tue Apr 20 07:28:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C015128C1CF; Tue, 20 Apr 2010 07:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l80X4Kfckam4; Tue, 20 Apr 2010 07:28:14 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id E7FDD3A6C91; Tue, 20 Apr 2010 07:20:25 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3KEJH8B029831; Tue, 20 Apr 2010 16:20:13 +0200 Received: from [172.27.205.116] ([172.27.205.116]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 16:19:40 +0200 Message-ID: <4BCDB7FE.4020608@alcatel-lucent.com> Date: Tue, 20 Apr 2010 16:19:42 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2010 14:19:40.0099 (UTC) FILETIME=[83974130:01CAE094] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: mpls-tp@ietf.org Subject: [mpls] IETF 77 - minutes of MPLS WG sessions posted X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 14:28:14 -0000 all, please find a link to the sessions' minutes http://www.ietf.org/proceedings/10mar/minutes/mpls.txt If you have any comment, please let me know. regards, martin From erosen@cisco.com Tue Apr 20 10:06:53 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D993A6B36 for ; Tue, 20 Apr 2010 10:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.239 X-Spam-Level: X-Spam-Status: No, score=-7.239 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_50=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4qa0412JjTW for ; Tue, 20 Apr 2010 10:06:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 69AC13A6B7B for ; Tue, 20 Apr 2010 10:06:26 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,243,1270425600"; d="scan'208";a="103335240" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2010 17:06:17 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3KH6Gxm018605; Tue, 20 Apr 2010 17:06:16 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 o3KH6G9P002644; Tue, 20 Apr 2010 13:06:16 -0400 To: mpls@ietf.org X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Tue, 20 Apr 2010 13:06:16 -0400 Message-ID: <2643.1271783176@erosen-linux> From: Eric Rosen Subject: [mpls] draft-wijnands-mpls-mldp-recurs-fec X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 20 Apr 2010 17:06:53 -0000 At IETF 76, I believe Ice presented the draft "Using mLDP through a Backbone where there is no Route to the Root" to the MPLS WG. The latest version of this draft is draft-wijnands-mpls-mldp-recurs-fec-01.txt. The draft specifies two new mLDP "recursive" FEC elements, one for use in a VPN context and one for use in a non-VPN context. During a discussion on the mailing list, it was agreed that before the MPLS WG is asked to adopt the draft as a WG draft, the draft should be presented to the L3VPN WG, to see if that WG had any objections to the VPN part of the draft. At IETF 77, I presented this draft to the L3VPN WG. The VPN recursive FEC element was presented, along with two use cases for it: (a) support of unsegmented inter-AS P-tunnels, and (b) limited applicability carrier's carrier support. At the L3VPN WG, there was no objection to the VPN recursive FEC element itself or to use case (a). Rahul objected to use case (b), recommending that this use case be omitted. I argued that if the mechanism is accepted, there isn't much point to suppressing discussion of a possible use, and that the applicability limitations of use case (b) were clearly acknowledged in the document. When the room was asked whether there were any objections to the adoption of this document by the MPLS WG, only one hand was raised. Having now done the "due diligence" of consulting the L3VPN WG, I think we can ask the MPLS WG to accept this draft as a WG draft. From rajiva@cisco.com Tue Apr 20 21:52:10 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4253A6C2C for ; Tue, 20 Apr 2010 21:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEf69w3MIzho for ; Tue, 20 Apr 2010 21:52:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DBA053A6C2A for ; Tue, 20 Apr 2010 21:52:08 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANcgzktAZnwN/2dsb2JhbACcEXGkappHglgVCIIaBIM0 X-IronPort-AV: E=Sophos;i="4.52,247,1270425600"; d="scan'208";a="103637504" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2010 04:51:59 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3L4pxPP029728; Wed, 21 Apr 2010 04:51:59 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 23:51:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2010 23:51:56 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0195368A@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] LDP IPv6 Thread-Index: AcraX6sIbvxrUAshQIeCgpssVjNa5gGrMZWQ References: <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> From: "Rajiv Asati (rajiva)" To: "Vishwas Manral" , X-OriginalArrivalTime: 21 Apr 2010 04:51:58.0871 (UTC) FILETIME=[5FEE1270:01CAE10E] Cc: mpls@ietf.org Subject: Re: [mpls] LDP IPv6 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 04:52:10 -0000 Hi Nic, While the de facto practice is to assign the IPv4 address to the LSR-ID, = strictly speaking (per RFC5036), it just needs to be a globally unique = value (and doesn't need to be an IPv4 address) to identify the LSR. Note that the LDP session is formed using the IP address encoded in the = optional 'Transport Address TLV', not using what's encoded in the LSR-Id = field. Pls see section 6.1 for more details on this - http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03#section-6.1 Hence, its usage should be sufficient for LDP IPv6.=20 Cheers, Rajiv PS: It might be a good idea to add the above clarification in section 4 = to avoid any confusion. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > Vishwas Manral > Sent: Monday, April 12, 2010 12:41 PM > To: N.Leymann@telekom.de > Cc: mpls@ietf.org > Subject: Re: [mpls] LDP IPv6 >=20 > Hi Nic, >=20 > I noticed that RFC 5329 has the Router IPv6 Address TLV. Does this > serve your purpose or not? >=20 > BTW, thanks a lot for supporting this effort. Like I said I know a lot > of operators (maily Europe and Asia) want the specs for this to be > finalized and I am just hoping they can speak up in the mailing list > too. >=20 > Thanks, > Vishwas >=20 > On Mon, Apr 12, 2010 at 7:55 AM, Vishwas Manral > wrote: > > Hi Nic, > > > > We now see the requirement from a few carriers like Trentino Network > > and a few others for IPv6 in the core, which they want to deploy = now. > > They have actually made these requirements on the field. I agree its > > probably not the same with the bigger carriers yet. > > > > For the TE extensions for IPv6 in Routing protocols we still assume > > the Router ID is 32 bits, so that remains the same with LDP. > > > > Though I think LSR-ID 32 bit should not make a difference in the LDP > > context, if however we need a routable IPv6 address loopback address > > was required, we could advertize that as a seperate TLV which could > > map on a one-to-one basis to an IPv6 address. > > > > Let me look further into this and get back to you. > > > > Thanks, > > Vishwas > > > > On Mon, Apr 12, 2010 at 4:43 AM, =A0 wrote: > >> Hi, > >> > >> I think that IPv6 for LDP is getting more and more important. Even > with private IPv4 addresses - depending on network size and addressing > scheme - for mid and long term it is definitely a good idea to take > IPv6 into account! > >> > >> I've also a short comment regarding the draft. It states: > >> > >> =A0"This document preserves the usage of 32-bit LSR Id on an IPv6 = only > >> =A0 LSR and allows the usage of a common LDP identifier i.e. same = LSR- > Id > >> =A0 and same Label space id for IPv4 and IPv6 on a dual-stack LSR. > This > >> =A0 rightly enables the per-platform label space to be shared = between > >> =A0 IPv4 and IPv6." > >> > >> At the moment providers tend to use an IPv4 address as LSR ID and I > wonder about the operational impact if this is going to be moved > towards a more abstract ID. > >> > >> =A0Regards > >> > >> =A0 =A0Nic > >> > >> -----Urspr=FCngliche Nachricht----- > >> Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im = Auftrag > von Vishwas Manral > >> Gesendet: Dienstag, 6. April 2010 21:23 > >> An: mpls@ietf.org > >> Betreff: [mpls] LDP IPv6 > >> > >> Hi folks, > >> > >> http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03 > >> > >> We have a new version of the LDP IPv6 draft. The draft has been > around > >> since 2008, however we are now seeing operators asking for it (and > can > >> be seen in some discussions in the RIPE mailing lists). > >> > >> We would want to hear comments on the same from the list. > >> > >> Thanks, > >> Vishwas > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From maarten.vissers@huawei.com Wed Apr 21 00:12:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FFF3A6A40; Wed, 21 Apr 2010 00:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw12F2QPETi8; Wed, 21 Apr 2010 00:12:16 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0C3F03A6A3C; Wed, 21 Apr 2010 00:12:16 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700C1LTACA9@szxga04-in.huawei.com>; Wed, 21 Apr 2010 15:11:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700L0OTACIZ@szxga04-in.huawei.com>; Wed, 21 Apr 2010 15:11:00 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L17000G9TA8ZQ@szxml04-in.huawei.com>; Wed, 21 Apr 2010 15:11:00 +0800 (CST) Date: Wed, 21 Apr 2010 09:11:02 +0200 From: Maarten Vissers In-reply-to: To: 'George Swallow' , mpls@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org, ccamp@ietf.org Message-id: <69994A6066394E90B25BB721C3CA3BFF@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtcA5wPYwA== References: <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:12:18 -0000 George, It is a bad practice to identify a connection (e.g. LSP) within the scope of their server layer trail (e.g. tunnel LSP). Reason is that a connection (e.g. LSP) is typically carried by multiple server layer trails (e.g. tunnel LSPs). Example: a service-LSP X is carried over three transport-LSPs A,B,C: |<----------------service-LSP_X------------------->| |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->| It is possible to reroute this service-LSP and change it as follows: |<----------------service-LSP_X------------------->| |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->| or as follows: |<----------------service-LSP_X------------------->| |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->| The service-LSP X is still the same service-LSP with the same service-LSP MEP functions, only the path through the MPLS-TP network has been changed. Identification with respect to the server layer trail (e.g. tunnel LSP) is appropriate for a link connection (e.g. LSP segment). The service-LSP X has three service-LSP segments. Those segments are identified with respect to their tunnel; i.e. with respect to the transport-LSP in this example. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of George Swallow Sent: vrijdag 16 april 2010 18:45 To: Attila Takacs; Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: Re: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 On 4/2/10 2:53 AM, "Attila Takacs" wrote: > Hi Matthew and George, > > Please find some comments/questions below. > > -In Section 5.1 you have: > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num? Existing implementations of RSVP-TE have used the tunnel space as global to the node. It is difficult if not impossible to coordinate such spaces between nodes. In RSVP-TE the coordination does not matter, since the tail end of the tunnel doesn't have a real interface - it only receives and usually with a PHP of the tunnel label, so the packets only belong to the physical interface. In a bidirectional world, separate tunnel spaces at the two ends becomes useful. If this independence is not need is some environments then one can configure just one value and use it in both fields. > Is it there to support associated unidirectional Tunnels/LSPs? If so > it should be called out in the text. That was not my original intent, but you are quite correct that this would be very useful. Particularly if the associated tunnels pass through a share mid-point somewhere along the path. > Same applies to the globally unique case. Of course. > -In Section 5.2 you simply append one LSP_Num to the above. This is a > bit confusing to me, if there are Src/Dst Tunnel_Nums then two > LSP_Nums would be needed too, wouldn't it? Once, you have independent tunnel-ids, coordination of the LSP numbers becomes easy. It also could be used to allow the two ends to readily identify which is working and which is protection. > -In Section 5.3 Mapping to GMPLS signaling does not use the > Dst-Tunnel_Num. So this means that we may have two different tunnels > identified with > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this intentional, e.g., the associated unidirectional case? For the associated unidirectional, this works perfectly. For bidirectional, I was thinking of two options. 1) Strict binding - both ends are configure with the full identifier and will only accept the connection if everything matches. 2) Dynamic binding - Source signals with just its Tunnel_Num. RESV message would carry back the destination's tunnel_num. Note that both ends need both pieces for some of the OAM to work. > This should be clarified. I'll see what I can do. But this is not supposed to the MPLS-TP signaling draft. > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. I'm planning to keep it. > -Section 7 has a note saying to be aligned with the OAM fwk, is this > still to be done? Yes. That draft is also being updated. We appear to be converging. > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > How would Tunnel and LSP MEGs be used? What OAM would run at the > Tunnel level and not at the LSP level? > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? I had been told early on that MEGs were needed for tunnels. Now getting comments that they are not (same comment is in the ITU liaison). So I planning to remove it, unless I hear other opinions. > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. See above. > -Section 8 talks about open issues? When will these be addressed? Before it is re-issued. Goal is end of next week. ...George > Thanks, > Attila From neil.2.harrison@bt.com Wed Apr 21 00:37:58 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8219B3A688D; Wed, 21 Apr 2010 00:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0gCVyMW0XGR; Wed, 21 Apr 2010 00:37:57 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B6FCC3A6A0F; Wed, 21 Apr 2010 00:37:56 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 08:37:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 08:37:43 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05D5072C@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <69994A6066394E90B25BB721C3CA3BFF@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtcA5wPYwAAAfU5Q From: To: , , , , , X-OriginalArrivalTime: 21 Apr 2010 07:37:46.0771 (UTC) FILETIME=[89572630:01CAE125] Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:37:58 -0000 Maarten...agreed...but there is also a worrying addressing problem in all this IMO that does not seem to be recognised/understood. In summary, a layer network (any mode/technology, not just co-ps/MPLS-TP say) is most essentially characterised by its access point addressing scheme...screw this up on day 1 and it is very hard to change later. MPLS originally never had proper addressing allocated to it...largely due to is binding with the cl-ps mode IP layer network it could never be seen as a layer network in its own right (part of the common control-plane flaw - I come back on this later). Further, each LSP here was a *sublayer* and part of the same hybrid/MPLS/IP layer network. Moreover, each LSP (label distribution) signalling type created its own form of addressing for how it wanted to identify its type of access points. PWs made the situation significantly worse when they became multi-hop. These suddenly jumped from an adaptation role to a full blown layer network in their own right. So they needed their own addressing scheme (and OAM, LDP signalling, etc),...which is what all the AII stuff is. Not a great addressing structure I should add, we should have used v4 or v6 but the problem dogging this stuff was that we were still claiming this was all part of the same IP/MPLS layer network =3D> can also read = as same instance of routing.....something we should know now is a flawed notion for MPLS-T based on lessons learnt from GMPLS (I originally pointed this 'common CP nonsense' out at 2000 San Diego IETF mtg). Now MPLS-TP is supposed to be a transport network. So each LSP in a nested case should be in its own layer network....this is essentially what you shown below. MPLS-TP therefore does not need sublayering as per the old type of MPLS...and it for sure should not be generating a PW layer network, that simply indicates a failure to deliver a transport network and just propagates the error made in MPLS. However, because some folks want to retain the S bit notion and the old type of sublayering in MPLS-TP, we have no way of knowing whether a set of nested LSPs belong to different layer networks or are sublayers in some arbitary layer network grouping. The DP looks the same in all cases. I can see all sorts of problems brewing here in correctly identify which layer network a given LSP belongs to...esp if there are multiple parties involved in both client/server and peer-partition sense.=20 regards, Neil =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 21 April 2010 08:11 > To: 'George Swallow'; mpls@ietf.org; mpls-tp@ietf.org;=20 > pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [mpls-tp] [mpls] mpls wg last call on=20 > draft-ietf-mpls-tp-identifiers-01 >=20 > George, >=20 > It is a bad practice to identify a connection (e.g. LSP)=20 > within the scope of their server layer trail (e.g. tunnel=20 > LSP). Reason is that a connection (e.g. LSP) is typically=20 > carried by multiple server layer trails (e.g. tunnel LSPs).=20 > Example: a service-LSP X is carried over three transport-LSPs A,B,C: >=20 > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->| >=20 > It is possible to reroute this service-LSP and change it as follows: >=20 > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->| >=20 > or as follows: >=20 > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->| >=20 > The service-LSP X is still the same service-LSP with the same=20 > service-LSP MEP functions, only the path through the MPLS-TP=20 > network has been changed. >=20 > Identification with respect to the server layer trail (e.g.=20 > tunnel LSP) is appropriate for a link connection (e.g. LSP=20 > segment). The service-LSP X has three service-LSP segments.=20 > Those segments are identified with respect to their tunnel;=20 > i.e. with respect to the transport-LSP in this example. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of George Swallow > Sent: vrijdag 16 april 2010 18:45 > To: Attila Takacs; Loa Andersson; mpls@ietf.org;=20 > mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > draft-ietf-mpls-tp-identifiers-01 >=20 >=20 >=20 >=20 > On 4/2/10 2:53 AM, "Attila Takacs" wrote: >=20 > > Hi Matthew and George, > >=20 > > Please find some comments/questions below. > >=20 > > -In Section 5.1 you have: > >=20 > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > >=20 > > What is the reason of having a Dst-Tunnel_Num besides the=20 > Src-Tunnel_Num? >=20 > Existing implementations of RSVP-TE have used the tunnel=20 > space as global to the node. It is difficult if not=20 > impossible to coordinate such spaces between nodes. In=20 > RSVP-TE the coordination does not matter, since the tail end=20 > of the tunnel doesn't have a real interface - it only=20 > receives and usually with a PHP of the tunnel label, so the=20 > packets only belong to the physical interface. >=20 > In a bidirectional world, separate tunnel spaces at the two=20 > ends becomes useful. =20 >=20 > If this independence is not need is some environments then=20 > one can configure just one value and use it in both fields. >=20 > > Is it there to support associated unidirectional=20 > Tunnels/LSPs? If so=20 > > it should be called out in the text. >=20 > That was not my original intent, but you are quite correct=20 > that this would be very useful. Particularly if the=20 > associated tunnels pass through a share mid-point somewhere=20 > along the path. >=20 > > Same applies to the globally unique case. >=20 > Of course. >=20 > > -In Section 5.2 you simply append one LSP_Num to the above.=20 > This is a=20 > > bit confusing to me, if there are Src/Dst Tunnel_Nums then two=20 > > LSP_Nums would be needed too, wouldn't it? >=20 > Once, you have independent tunnel-ids, coordination of the=20 > LSP numbers becomes easy. It also could be used to allow the=20 > two ends to readily identify which is working and which is protection. >=20 > > -In Section 5.3 Mapping to GMPLS signaling does not use the=20 > > Dst-Tunnel_Num. So this means that we may have two=20 > different tunnels=20 > > identified with=20 > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this > intentional, e.g., the associated unidirectional case? >=20 > For the associated unidirectional, this works perfectly. For=20 > bidirectional, I was thinking of two options. >=20 > 1) Strict binding - both ends are configure with the full=20 > identifier and will only accept the connection if everything matches. >=20 > 2) Dynamic binding - Source signals with just its=20 > Tunnel_Num. RESV message would carry back the destination's=20 > tunnel_num. Note that both ends need both pieces for some of=20 > the OAM to work. >=20 > > This should be clarified. >=20 > I'll see what I can do. But this is not supposed to the=20 > MPLS-TP signaling draft. > =20 > > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. >=20 > I'm planning to keep it. > =20 > > -Section 7 has a note saying to be aligned with the OAM=20 > fwk, is this=20 > > still to be done? >=20 > Yes. That draft is also being updated. We appear to be converging. >=20 > > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > > How would Tunnel and LSP MEGs be used? What OAM would run at the=20 > > Tunnel level and not at the LSP level? > > > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? >=20 > I had been told early on that MEGs were needed for tunnels. =20 > Now getting comments that they are not (same comment is in=20 > the ITU liaison). So I planning to remove it, unless I hear=20 > other opinions. >=20 > > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. >=20 > See above. >=20 > > -Section 8 talks about open issues? When will these be addressed? >=20 > Before it is re-issued. Goal is end of next week. >=20 > ...George >=20 > > Thanks, > > Attila >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From maarten.vissers@huawei.com Wed Apr 21 02:06:33 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B2F3A677D; Wed, 21 Apr 2010 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.129 X-Spam-Level: X-Spam-Status: No, score=0.129 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsidvSCI9VWH; Wed, 21 Apr 2010 02:06:32 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C543A3A684A; Wed, 21 Apr 2010 02:06:30 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700FTXYM7LC@szxga02-in.huawei.com>; Wed, 21 Apr 2010 17:06:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700DF7YM69G@szxga02-in.huawei.com>; Wed, 21 Apr 2010 17:06:06 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L17000X3YM2ZN@szxml04-in.huawei.com>; Wed, 21 Apr 2010 17:06:06 +0800 (CST) Date: Wed, 21 Apr 2010 11:06:07 +0200 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C05D5072C@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, swallow@cisco.com, mpls@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org, ccamp@ietf.org Message-id: <98ED265C742D4598AAAD6B8CC7C2DB81@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtcA5wPYwAAAfU5QAAJ4WtA= References: <69994A6066394E90B25BB721C3CA3BFF@china.huawei.com> <2ECAA42C79676B42AEBAC11229CA7D0C05D5072C@E03MVB2-UKBR.domain1.systemhost.net> Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:06:34 -0000 Neil, There are three MPLS-TP layer netowrks defined: 1) Transport Service layer network (including MS-PWs, Service-LSPs, PST-LSPs) 2) Transport Path layer network (including Transport-LSPs, PST-LSPs) 3) Section layer network (including Section-LSPs, PST-LSPs). Each of those three MPLS-TP layer networks has two types of sub-layers defined: A) TCM sub-layer with a 1:1 relation (for admin domain monitoring and SNC/S protection switching applications) B) TCM sub-layer with a n:1 relation (for some protection switching applciations) which are supported by PST-LSPs. The three layer networks have Access Points, and those APs are identified by means of an Access Point Identifier. The sub-layers have sub-layer Access Points, and those sub-layer APs are identified by means of a sub-layer Access Point Identifier. [Note - We need to understand what the IETF equivalent of the ITU-T Access Point is... See below the '-----' for my view on this based on a question I received on what the equivalent ITU-T construct would be for an IETF 'interface'.] The MPLS-TP data plane does not demarc the boundary between those layer networks or between a layer and its sublayers. This is a clear difference with similar layer/sublayer structures in OTN ODU and Ethernet ETH layers; in those two technologies there is a clear demarcation between layer networks and between the layer network signal and its sublayers. But we have to ask ourselves the question if this would be an issue... Most likely not because of the following: Transport Service, Transport Path and Section layer names represent roles in a domain. A Transport-LSP in domain A can be passed through a domain B in which it is considered to be a Service-LSP. Similarly, a Section-LSP in domain A can be passed through a domain B in which it is considered to be a Service-LSP. And it is even possible to have a Section-LSP in domain A which is passed through a domain B as Service-LSP and is then handed of to domain C as a Transport-LSP. This role variability is also present in the OTN ODU and Ethernet ETH layers, so there is commonality between those three technologies at this point. The implication is that the Access Point in e.g. a MPLS-TP Section layer or Ethernet Virtual Section layer could be connected with an Access Point in a MPLS-TP Transport Path or Ethernet Virtual Path layer. This capability is of course a feature and not a bug, and the implication is that the access point identification scheme should be agnostic to the operational role names of the layer networks in each domain. ----------- I was asked the question what the ITU-T equivalent of the IETF 'interface' would be. It could be that this equivalent is the 'access point'. The access points demark a trail in a layer network and access points are identified by means of their 'access point identifier (APId)'. If you look at clause 8.6.1 in G.7710 http://www.itu.int/rec/T-REC-G.7710-200707-I/en then you find in figure 23 a description of how the APId is used to identify the other reference points (termination connection point, connection point). In G.831 http://www.itu.int/rec/T-REC-G.831-200003-I/en you find the following features of the access points: ---------- The features of Access Point Identifiers (APIs) are: - each access point identifier must be globally unique in its layer network; - where it may be expected that the access point may be required for path set-up across an inter-operator boundary, the access point identifier must be available to other network operators; - the access point identifier should not change while the access point remains in existence; - the access point identifier should be able to identify the country and network operator which is responsible for routing to and from the access point; - the set of all access point identifiers belonging to a single administrative layer network should form a single access point identification scheme; - the scheme of access point identifiers for each administrative layer network can be independent from the scheme in any other administrative layer network. The API shall begin with either the country code as defined in ITU-T E.164 (one, two or three numeric characters) or, the three alphabetic character country code as defined in ISO 3166. The remainder of the API characters that follow the country code shall be a matter for the organization to whom the country code has been assigned, provided that uniqueness is guaranteed. These characters may be any alphanumeric characters as defined in ITU-T T.50 (International Reference Version - 7-bit coded character set for information interchange). The alphanumeric character set consists of the characters "a" to "z", "A" to "Z", and "0" to "9". In the case where the API uses less than fifteen characters, the API will be padded (extended) with the T.50 "NUL" character to get a fifteen byte character string. ------------ Applying this AP, CP and TCP identification in MPLS-TP you would get the following: - PW access points demark the PW trail - PW termination connection points demark the PW network connection - LSP access points demark the LSP trail - LSP termination connection points demark the LSP network connection A PW trail and network connection are identified (PW_TID, PW_NCID) by means of their PW APId set for a p2p PW and for a p2mp PW. A LSP trail and network connection are identified (LSP_TID, LSP_NCID) by means of their LSP APId set for a p2p LSP and for a p2mp LSP. - a LSP carries one or more client LSPs and/or PWs and/or VPLSs. The client LSP connection points are identified by means of the LSP APId plus the client_LSP label value. The client PW connection points are identified by means of the LSP APId plus the client_PW label value. The client VPLS (i.e. ETH) flow points are identified by means of the LSP APId plus the client_VPLS (i.e. PW) label value. - a PW may carry one or more client LSPs. The client LSP connection points are identified by means of the PW APId plus the client_LSP label value. - a PW may carry one or more client VLANs. The client VLAN (i.e. ETH) flow points are identified by means of the PW APId plus the client_VLAN VLAN ID (VID) or Service instance ID (SID) value. The client connection/flow points demark a client link connection. A client_LSP or _VLAN link connection supported by a PW trail is then identified by the PW trail identifier (i.e. plus the client label or VID/SID value. A client_LSP/PW/VPLS link connection supported by a LSP trail is then identified by the LSP trail identifier (i.e. plus the client LSP or PW label value (LSP__LCID, PW_LCID, VPLS_LCID). A PW (or LSP) trail contains of one or more PW (or LSP) link connections with unique identifiers. This implies that one PW (or LSP) trail/network connection identifier is related to a set of PW (or LSP) link connection identifiers; e.g. PW_TID/PW_NCID <=> {PW_LCID_a,PW_LCID_b, ...} ------------ PWs and LSPs represent layer network trails and sublayer network trails in the MPLS-TP Transport Service, Transport Path and Section layer networks. An overview: Transport Service layer network: - MPLS-TP PW trail - MPLS-TP service-LSP trail [- ETH VPLS connectionless trail] - MPLS-TP PST-LSP sublayer trail Transport Path layer network: - MPLS-TP transport-LSP trail - MPLS-TP PST-LSP sublayer trail Section layer network: - MPLS-TP section-LSP trail - MPLS-TP PST-LSP sublayer trail Note that the PST-LSP sublayer trails performing a TCM function are dependent on the layer trails. If a layer trail is deleted all associated PST-LSP sublayer trails have to be deleted as well. In MPLS-TP these sublayer trails perform a complete encapsulation of the layer trail and/or client-sublayer trail. This is different from sublayer trails in SDH, OTN, ATM and Ethernet networks. In those latter network technologies a sublayer trail just adds an additional level of OAM without further encapsulating the incoming signal. As a consequence in those latter networks the addition or removal of a sublayer does not change the set of link connections in the trail/network connection. In MPLS-TP we have to decide if we follow the same model, or if we consider that the addition of a sublayer (i.e. a PST-LSP) changes the number of link connections in the layer trail/network connection. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: woensdag 21 april 2010 9:38 To: maarten.vissers@huawei.com; swallow@cisco.com; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: RE: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Maarten...agreed...but there is also a worrying addressing problem in all this IMO that does not seem to be recognised/understood. In summary, a layer network (any mode/technology, not just co-ps/MPLS-TP say) is most essentially characterised by its access point addressing scheme...screw this up on day 1 and it is very hard to change later. MPLS originally never had proper addressing allocated to it...largely due to is binding with the cl-ps mode IP layer network it could never be seen as a layer network in its own right (part of the common control-plane flaw - I come back on this later). Further, each LSP here was a *sublayer* and part of the same hybrid/MPLS/IP layer network. Moreover, each LSP (label distribution) signalling type created its own form of addressing for how it wanted to identify its type of access points. PWs made the situation significantly worse when they became multi-hop. These suddenly jumped from an adaptation role to a full blown layer network in their own right. So they needed their own addressing scheme (and OAM, LDP signalling, etc),...which is what all the AII stuff is. Not a great addressing structure I should add, we should have used v4 or v6 but the problem dogging this stuff was that we were still claiming this was all part of the same IP/MPLS layer network => can also read as same instance of routing.....something we should know now is a flawed notion for MPLS-T based on lessons learnt from GMPLS (I originally pointed this 'common CP nonsense' out at 2000 San Diego IETF mtg). Now MPLS-TP is supposed to be a transport network. So each LSP in a nested case should be in its own layer network....this is essentially what you shown below. MPLS-TP therefore does not need sublayering as per the old type of MPLS...and it for sure should not be generating a PW layer network, that simply indicates a failure to deliver a transport network and just propagates the error made in MPLS. However, because some folks want to retain the S bit notion and the old type of sublayering in MPLS-TP, we have no way of knowing whether a set of nested LSPs belong to different layer networks or are sublayers in some arbitary layer network grouping. The DP looks the same in all cases. I can see all sorts of problems brewing here in correctly identify which layer network a given LSP belongs to...esp if there are multiple parties involved in both client/server and peer-partition sense. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 21 April 2010 08:11 > To: 'George Swallow'; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; > ccamp@ietf.org > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > draft-ietf-mpls-tp-identifiers-01 > > George, > > It is a bad practice to identify a connection (e.g. LSP) within the > scope of their server layer trail (e.g. tunnel LSP). Reason is that a > connection (e.g. LSP) is typically carried by multiple server layer > trails (e.g. tunnel LSPs). > Example: a service-LSP X is carried over three transport-LSPs A,B,C: > > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->| > > It is possible to reroute this service-LSP and change it as follows: > > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->| > > or as follows: > > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->| > > The service-LSP X is still the same service-LSP with the same > service-LSP MEP functions, only the path through the MPLS-TP network > has been changed. > > Identification with respect to the server layer trail (e.g. > tunnel LSP) is appropriate for a link connection (e.g. LSP segment). > The service-LSP X has three service-LSP segments. > Those segments are identified with respect to their tunnel; i.e. with > respect to the transport-LSP in this example. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of George Swallow > Sent: vrijdag 16 april 2010 18:45 > To: Attila Takacs; Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; > pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > draft-ietf-mpls-tp-identifiers-01 > > > > > On 4/2/10 2:53 AM, "Attila Takacs" wrote: > > > Hi Matthew and George, > > > > Please find some comments/questions below. > > > > -In Section 5.1 you have: > > > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > > > What is the reason of having a Dst-Tunnel_Num besides the > Src-Tunnel_Num? > > Existing implementations of RSVP-TE have used the tunnel space as > global to the node. It is difficult if not impossible to coordinate > such spaces between nodes. In RSVP-TE the coordination does not > matter, since the tail end of the tunnel doesn't have a real interface > - it only receives and usually with a PHP of the tunnel label, so the > packets only belong to the physical interface. > > In a bidirectional world, separate tunnel spaces at the two ends > becomes useful. > > If this independence is not need is some environments then one can > configure just one value and use it in both fields. > > > Is it there to support associated unidirectional > Tunnels/LSPs? If so > > it should be called out in the text. > > That was not my original intent, but you are quite correct that this > would be very useful. Particularly if the associated tunnels pass > through a share mid-point somewhere along the path. > > > Same applies to the globally unique case. > > Of course. > > > -In Section 5.2 you simply append one LSP_Num to the above. > This is a > > bit confusing to me, if there are Src/Dst Tunnel_Nums then two > > LSP_Nums would be needed too, wouldn't it? > > Once, you have independent tunnel-ids, coordination of the LSP numbers > becomes easy. It also could be used to allow the two ends to readily > identify which is working and which is protection. > > > -In Section 5.3 Mapping to GMPLS signaling does not use the > > Dst-Tunnel_Num. So this means that we may have two > different tunnels > > identified with > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this > intentional, e.g., the associated unidirectional case? > > For the associated unidirectional, this works perfectly. For > bidirectional, I was thinking of two options. > > 1) Strict binding - both ends are configure with the full > identifier and will only accept the connection if everything matches. > > 2) Dynamic binding - Source signals with just its Tunnel_Num. RESV > message would carry back the destination's tunnel_num. Note that both > ends need both pieces for some of the OAM to work. > > > This should be clarified. > > I'll see what I can do. But this is not supposed to the MPLS-TP > signaling draft. > > > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. > > I'm planning to keep it. > > > -Section 7 has a note saying to be aligned with the OAM > fwk, is this > > still to be done? > > Yes. That draft is also being updated. We appear to be converging. > > > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > > How would Tunnel and LSP MEGs be used? What OAM would run at the > > Tunnel level and not at the LSP level? > > > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? > > I had been told early on that MEGs were needed for tunnels. > Now getting comments that they are not (same comment is in the ITU > liaison). So I planning to remove it, unless I hear other opinions. > > > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. > > See above. > > > -Section 8 talks about open issues? When will these be addressed? > > Before it is re-issued. Goal is end of next week. > > ...George > > > Thanks, > > Attila > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From wwwrun@rfc-editor.org Wed Apr 21 03:10:39 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C6928C0F2 for ; Wed, 21 Apr 2010 03:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5+-9grNLVWC for ; Wed, 21 Apr 2010 03:10:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 896B628C0E4 for ; Wed, 21 Apr 2010 03:10:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A9E26E07AC; Wed, 21 Apr 2010 03:10:28 -0700 (PDT) To: erosen@cisco.com, tappan@cisco.com, yakov@juniper.net, fedorkow@cisco.com, dino@procket.com, tli@procket.com, aconta@txc.com, stbryant@cisco.com, adrian.farrel@huawei.com, swallow@cisco.com, loa@pi.nu From: RFC Errata System Message-Id: <20100421101028.A9E26E07AC@rfc-editor.org> Date: Wed, 21 Apr 2010 03:10:28 -0700 (PDT) Cc: nmalykh@protocols.ru, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC3032 (2166) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 10:10:39 -0000 The following errata report has been submitted for RFC3032, "MPLS Label Stack Encoding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3032&eid=2166 -------------------------------------- Type: Technical Reported by: Nikolai Malykh Section: 4.2 Original Text ------------- 2. Data Link Layer Protocol Field Exactly one MPLSCP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 8281 (MPLS). Corrected Text -------------- 2. Data Link Layer Protocol Field Exactly one MPLSCP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 8281 (MPLSCP). 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. -------------------------------------- RFC3032 (draft-ietf-mpls-label-encaps-07) -------------------------------------- Title : MPLS Label Stack Encoding Publication Date : January 2001 Author(s) : E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From neil.2.harrison@bt.com Wed Apr 21 03:49:47 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767EB3A6B4F; Wed, 21 Apr 2010 03:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO9h2EW66y5h; Wed, 21 Apr 2010 03:49:45 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A9D6F3A694C; Wed, 21 Apr 2010 03:49:44 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 11:49:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 11:49:32 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05D5080B@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <98ED265C742D4598AAAD6B8CC7C2DB81@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtcA5wPYwAAAfU5QAAJ4WtAABQTnwA== From: To: , , , , , X-OriginalArrivalTime: 21 Apr 2010 10:49:34.0743 (UTC) FILETIME=[54A05270:01CAE140] Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 10:49:47 -0000 Thanks Maarten.....have IETF agreed to all this? regards, neil=20 > -----Original Message----- > From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 > Sent: 21 April 2010 10:06 > To: Harrison,N,Neil,DKQ7 R; swallow@cisco.com; mpls@ietf.org;=20 > mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: RE: [mpls-tp] [mpls] mpls wg last call on=20 > draft-ietf-mpls-tp-identifiers-01 >=20 > Neil, >=20 > There are three MPLS-TP layer netowrks defined: > 1) Transport Service layer network > (including MS-PWs, Service-LSPs, PST-LSPs) > 2) Transport Path layer network > (including Transport-LSPs, PST-LSPs) > 3) Section layer network > (including Section-LSPs, PST-LSPs). >=20 > Each of those three MPLS-TP layer networks has two types of sub-layers > defined: > A) TCM sub-layer with a 1:1 relation (for admin domain monitoring > and SNC/S protection switching applications) > B) TCM sub-layer with a n:1 relation (for some protection switching > applciations) > which are supported by PST-LSPs. >=20 > The three layer networks have Access Points, and those APs=20 > are identified by means of an Access Point Identifier.=20 >=20 > The sub-layers have sub-layer Access Points, and those=20 > sub-layer APs are identified by means of a sub-layer Access=20 > Point Identifier. >=20 > [Note - We need to understand what the IETF equivalent=20 > of the ITU-T Access Point > is... See below the '-----' for my view on this based=20 > on a question I received > on what the equivalent ITU-T construct would be for an=20 > IETF 'interface'.] >=20 > The MPLS-TP data plane does not demarc the boundary between=20 > those layer networks or between a layer and its sublayers.=20 > This is a clear difference with similar layer/sublayer=20 > structures in OTN ODU and Ethernet ETH layers; in those two=20 > technologies there is a clear demarcation between layer=20 > networks and between the layer network signal and its=20 > sublayers. But we have to ask ourselves the question if this=20 > would be an issue... Most likely not because of the following: >=20 > Transport Service, Transport Path and Section layer names=20 > represent roles in a domain. A Transport-LSP in domain A can=20 > be passed through a domain B in which it is considered to be=20 > a Service-LSP. Similarly, a Section-LSP in domain A can be=20 > passed through a domain B in which it is considered to be a=20 > Service-LSP. And it is even possible to have a Section-LSP in=20 > domain A which is passed through a domain B as Service-LSP=20 > and is then handed of to domain C as a Transport-LSP. >=20 > This role variability is also present in the OTN ODU and=20 > Ethernet ETH layers, so there is commonality between those=20 > three technologies at this point. >=20 > The implication is that the Access Point in e.g. a MPLS-TP=20 > Section layer or Ethernet Virtual Section layer could be=20 > connected with an Access Point in a MPLS-TP Transport Path or=20 > Ethernet Virtual Path layer. This capability is of course a=20 > feature and not a bug, and the implication is that the access=20 > point identification scheme should be agnostic to the=20 > operational role names of the layer networks in each domain. >=20 > ----------- >=20 > I was asked the question what the ITU-T equivalent of the=20 > IETF 'interface' > would be. > It could be that this equivalent is the 'access point'. The=20 > access points demark a trail in a layer network and access=20 > points are identified by means of their 'access point=20 > identifier (APId)'. If you look at clause 8.6.1 in G.7710=20 > http://www.itu.int/rec/T-REC-G.7710-200707-I/en then you find=20 > in figure 23 a description of how the APId is used to=20 > identify the other reference points (termination connection=20 > point, connection point). >=20 > In G.831 http://www.itu.int/rec/T-REC-G.831-200003-I/en you=20 > find the following features of the access points: > ---------- > The features of Access Point Identifiers (APIs) are: > - each access point identifier must be globally unique in its=20 > layer network; > - where it may be expected that the access point may be=20 > required for path set-up across an inter-operator boundary,=20 > the access point identifier must be available to other=20 > network operators; - the access point identifier should not=20 > change while the access point remains in existence; - the=20 > access point identifier should be able to identify the=20 > country and network operator which is responsible for routing=20 > to and from the access point; - the set of all access point=20 > identifiers belonging to a single administrative layer=20 > network should form a single access point identification=20 > scheme; - the scheme of access point identifiers for each=20 > administrative layer network can be independent from the=20 > scheme in any other administrative layer network. >=20 > The API shall begin with either the country code as defined=20 > in ITU-T E.164 (one, two or three numeric characters) or, the=20 > three alphabetic character country code as defined in ISO 3166. > The remainder of the API characters that follow the country=20 > code shall be a matter for the organization to whom the=20 > country code has been assigned, provided that uniqueness is=20 > guaranteed. > These characters may be any alphanumeric characters as=20 > defined in ITU-T T.50 (International Reference Version -=20 > 7-bit coded character set for information interchange). > The alphanumeric character set consists of the characters "a"=20 > to "z", "A" to "Z", and "0" to "9". > In the case where the API uses less than fifteen characters,=20 > the API will be padded (extended) with the T.50 "NUL"=20 > character to get a fifteen byte character string. > ------------ >=20 >=20 > Applying this AP, CP and TCP identification in MPLS-TP you=20 > would get the > following: >=20 > - PW access points demark the PW trail > - PW termination connection points demark the PW network connection >=20 > - LSP access points demark the LSP trail > - LSP termination connection points demark the LSP network connection >=20 > A PW trail and network connection are identified (PW_TID,=20 > PW_NCID) by means of their PW APId set =20 > for a p2p PW and for a p2mp PW. >=20 > A LSP trail and network connection are identified (LSP_TID,=20 > LSP_NCID) by means of their LSP APId set LSP_APId_2> for a p2p LSP and LSP_APId_n> for a p2mp LSP. >=20 >=20 > - a LSP carries one or more client LSPs and/or PWs and/or VPLSs.=20 > The client LSP connection points are identified by means of=20 > the LSP APId plus the client_LSP label value.=20 > The client PW connection points are identified by means of=20 > the LSP APId plus the client_PW label value.=20 > The client VPLS (i.e. ETH) flow points are identified by=20 > means of the LSP APId plus the client_VPLS (i.e. PW) label value. >=20 > - a PW may carry one or more client LSPs.=20 > The client LSP connection points are identified by means of=20 > the PW APId plus the client_LSP label value.=20 >=20 > - a PW may carry one or more client VLANs.=20 > The client VLAN (i.e. ETH) flow points are identified by=20 > means of the PW APId plus the client_VLAN VLAN ID (VID) or=20 > Service instance ID (SID) value.=20 >=20 > The client connection/flow points demark a client link connection. > A client_LSP or _VLAN link connection supported by a PW trail=20 > is then identified by the PW trail identifier (i.e. > plus the client label=20 > or VID/SID value. > A client_LSP/PW/VPLS link connection supported by a LSP trail=20 > is then identified by the LSP trail identifier (i.e. > plus the client LSP=20 > or PW label value (LSP__LCID, PW_LCID, VPLS_LCID). >=20 > A PW (or LSP) trail contains of one or more PW (or LSP) link=20 > connections with unique identifiers. This implies that one PW=20 > (or LSP) trail/network connection identifier is related to a=20 > set of PW (or LSP) link connection identifiers; e.g.=20 > PW_TID/PW_NCID <=3D> {PW_LCID_a,PW_LCID_b, ...} >=20 > ------------ >=20 > PWs and LSPs represent layer network trails and sublayer=20 > network trails in the MPLS-TP Transport Service, Transport=20 > Path and Section layer networks. An > overview: >=20 > Transport Service layer network: > - MPLS-TP PW trail > - MPLS-TP service-LSP trail > [- ETH VPLS connectionless trail] > - MPLS-TP PST-LSP sublayer trail >=20 > Transport Path layer network: > - MPLS-TP transport-LSP trail > - MPLS-TP PST-LSP sublayer trail >=20 > Section layer network: > - MPLS-TP section-LSP trail > - MPLS-TP PST-LSP sublayer trail >=20 > Note that the PST-LSP sublayer trails performing a TCM=20 > function are dependent on the layer trails. If a layer trail=20 > is deleted all associated PST-LSP sublayer trails have to be=20 > deleted as well. >=20 > In MPLS-TP these sublayer trails perform a complete=20 > encapsulation of the layer trail and/or client-sublayer=20 > trail. This is different from sublayer trails in SDH, OTN,=20 > ATM and Ethernet networks. In those latter network=20 > technologies a sublayer trail just adds an additional level=20 > of OAM without further encapsulating the incoming signal. As=20 > a consequence in those latter networks the addition or=20 > removal of a sublayer does not change the set of link=20 > connections in the trail/network connection. In MPLS-TP we=20 > have to decide if we follow the same model, or if we consider=20 > that the addition of a sublayer (i.e. a PST-LSP) changes the=20 > number of link connections in the layer trail/network connection.=20 >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: woensdag 21 april 2010 9:38 > To: maarten.vissers@huawei.com; swallow@cisco.com;=20 > mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: RE: [mpls-tp] [mpls] mpls wg last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > Maarten...agreed...but there is also a worrying addressing=20 > problem in all this IMO that does not seem to be=20 > recognised/understood. In summary, a layer network (any=20 > mode/technology, not just co-ps/MPLS-TP > say) is most essentially characterised by its access point=20 > addressing scheme...screw this up on day 1 and it is very=20 > hard to change later. >=20 > MPLS originally never had proper addressing allocated to=20 > it...largely due to is binding with the cl-ps mode IP layer=20 > network it could never be seen as a layer network in its own=20 > right (part of the common control-plane flaw - I come back on=20 > this later). Further, each LSP here was a *sublayer* and=20 > part of the same hybrid/MPLS/IP layer network. > Moreover, each LSP (label distribution) signalling type=20 > created its own form of addressing for how it wanted to=20 > identify its type of access points. >=20 > PWs made the situation significantly worse when they became multi-hop. > These suddenly jumped from an adaptation role to a full blown=20 > layer network in their own right. So they needed their own=20 > addressing scheme (and OAM, LDP signalling, etc),...which is=20 > what all the AII stuff is. > Not a great addressing structure I should add, we should have=20 > used v4 or > v6 but the problem dogging this stuff was that we were still=20 > claiming this was all part of the same IP/MPLS layer network=20 > =3D> can also read as same instance of routing.....something we=20 > should know now is a flawed notion for MPLS-T based on=20 > lessons learnt from GMPLS (I originally pointed this 'common=20 > CP nonsense' out at 2000 San Diego IETF mtg). >=20 > Now MPLS-TP is supposed to be a transport network. So each=20 > LSP in a nested case should be in its own layer=20 > network....this is essentially what you shown below. MPLS-TP=20 > therefore does not need sublayering as per the old type of=20 > MPLS...and it for sure should not be generating a PW layer=20 > network, that simply indicates a failure to deliver a=20 > transport network and just propagates the error made in MPLS. >=20 > However, because some folks want to retain the S bit notion=20 > and the old type of sublayering in MPLS-TP, we have no way of=20 > knowing whether a set of nested LSPs belong to different=20 > layer networks or are sublayers in some arbitary layer=20 > network grouping. The DP looks the same in all cases. >=20 > I can see all sorts of problems brewing here in correctly=20 > identify which layer network a given LSP belongs to...esp if=20 > there are multiple parties involved in both client/server and=20 > peer-partition sense.=20 >=20 > regards, Neil =20 >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > Sent: 21 April 2010 08:11 > > To: 'George Swallow'; mpls@ietf.org; mpls-tp@ietf.org;=20 > pwe3@ietf.org;=20 > > ccamp@ietf.org > > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > > draft-ietf-mpls-tp-identifiers-01 > >=20 > > George, > >=20 > > It is a bad practice to identify a connection (e.g. LSP) within the=20 > > scope of their server layer trail (e.g. tunnel LSP). Reason=20 > is that a=20 > > connection (e.g. LSP) is typically carried by multiple server layer=20 > > trails (e.g. tunnel LSPs). > > Example: a service-LSP X is carried over three transport-LSPs A,B,C: > >=20 > > |<----------------service-LSP_X------------------->| > > |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->| > >=20 > > It is possible to reroute this service-LSP and change it as follows: > >=20 > > |<----------------service-LSP_X------------------->| > > |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->| > >=20 > > or as follows: > >=20 > > |<----------------service-LSP_X------------------->| > > |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->| > >=20 > > The service-LSP X is still the same service-LSP with the same=20 > > service-LSP MEP functions, only the path through the=20 > MPLS-TP network=20 > > has been changed. > >=20 > > Identification with respect to the server layer trail (e.g.=20 > > tunnel LSP) is appropriate for a link connection (e.g. LSP=20 > segment).=20 > > The service-LSP X has three service-LSP segments. > > Those segments are identified with respect to their tunnel;=20 > i.e. with=20 > > respect to the transport-LSP in this example. > >=20 > > Regards, > > Maarten > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of George Swallow > > Sent: vrijdag 16 april 2010 18:45 > > To: Attila Takacs; Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org;=20 > > pwe3@ietf.org; ccamp@ietf.org > > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > > draft-ietf-mpls-tp-identifiers-01 > >=20 > >=20 > >=20 > >=20 > > On 4/2/10 2:53 AM, "Attila Takacs"=20 > wrote: > >=20 > > > Hi Matthew and George, > > >=20 > > > Please find some comments/questions below. > > >=20 > > > -In Section 5.1 you have: > > >=20 > > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > >=20 > > > What is the reason of having a Dst-Tunnel_Num besides the > > Src-Tunnel_Num? > >=20 > > Existing implementations of RSVP-TE have used the tunnel space as=20 > > global to the node. It is difficult if not impossible to=20 > coordinate=20 > > such spaces between nodes. In RSVP-TE the coordination does not=20 > > matter, since the tail end of the tunnel doesn't have a=20 > real interface > > - it only receives and usually with a PHP of the tunnel=20 > label, so the=20 > > packets only belong to the physical interface. > >=20 > > In a bidirectional world, separate tunnel spaces at the two ends=20 > > becomes useful. > >=20 > > If this independence is not need is some environments then one can=20 > > configure just one value and use it in both fields. > >=20 > > > Is it there to support associated unidirectional > > Tunnels/LSPs? If so > > > it should be called out in the text. > >=20 > > That was not my original intent, but you are quite correct=20 > that this=20 > > would be very useful. Particularly if the associated tunnels pass=20 > > through a share mid-point somewhere along the path. > >=20 > > > Same applies to the globally unique case. > >=20 > > Of course. > >=20 > > > -In Section 5.2 you simply append one LSP_Num to the above.=20 > > This is a > > > bit confusing to me, if there are Src/Dst Tunnel_Nums then two=20 > > > LSP_Nums would be needed too, wouldn't it? > >=20 > > Once, you have independent tunnel-ids, coordination of the=20 > LSP numbers=20 > > becomes easy. It also could be used to allow the two ends=20 > to readily=20 > > identify which is working and which is protection. > >=20 > > > -In Section 5.3 Mapping to GMPLS signaling does not use the=20 > > > Dst-Tunnel_Num. So this means that we may have two > > different tunnels > > > identified with > > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this > > intentional, e.g., the associated unidirectional case? > >=20 > > For the associated unidirectional, this works perfectly. For=20 > > bidirectional, I was thinking of two options. > >=20 > > 1) Strict binding - both ends are configure with the full=20 > > identifier and will only accept the connection if=20 > everything matches. > >=20 > > 2) Dynamic binding - Source signals with just its=20 > Tunnel_Num. RESV=20 > > message would carry back the destination's tunnel_num. =20 > Note that both=20 > > ends need both pieces for some of the OAM to work. > >=20 > > > This should be clarified. > >=20 > > I'll see what I can do. But this is not supposed to the MPLS-TP=20 > > signaling draft. > > =20 > > > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. > >=20 > > I'm planning to keep it. > > =20 > > > -Section 7 has a note saying to be aligned with the OAM > > fwk, is this > > > still to be done? > >=20 > > Yes. That draft is also being updated. We appear to be converging. > >=20 > > > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > > > How would Tunnel and LSP MEGs be used? What OAM would run at the=20 > > > Tunnel level and not at the LSP level? > > > > > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? > >=20 > > I had been told early on that MEGs were needed for tunnels. =20 > > Now getting comments that they are not (same comment is in the ITU=20 > > liaison). So I planning to remove it, unless I hear other opinions. > >=20 > > > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. > >=20 > > See above. > >=20 > > > -Section 8 talks about open issues? When will these be addressed? > >=20 > > Before it is re-issued. Goal is end of next week. > >=20 > > ...George > >=20 > > > Thanks, > > > Attila > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 >=20 From wwwrun@core3.amsl.com Wed Apr 21 08:01:49 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3120328C566; Wed, 21 Apr 2010 08:01:48 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100421150149.3120328C566@core3.amsl.com> Date: Wed, 21 Apr 2010 08:01:49 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "MPLS working group last call on "Multiprotocol Label Switching Transport Profile Survivability Framework" (ref #028.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 15:01:49 -0000 Title: MPLS working group last call on "Multiprotocol Label Switching Transport Profile Survivability Framework" (ref #028.01) Submission Date: 2010-04-21 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=878 Please reply by 2010-05-05 From: Loa Andersson(IETF MPLS WG) To: SG15, Q9, Q10, Q12, Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For action Body: MPLS working group last call on "Multiprotocol Label Switching Transport Profile Survivability Framework" (ref #028.01) draft-ietf-mpls-tp-survive-fwk-05 SG15, Q9, Q10, Q12 and Q14 We like to to inform you that the MPLS working group just started a short working group last call on "Multiprotocol Label Switching Transport Profile Survivability Framework" (draft-ietf-mpls-tp-survive-fwk-05). Please note that this wg last call is limited to verify that comments raised during the previous working group last call and reviews have been correctly addressed. We would like to receive comments from the ITU-T by May 5th 2010. Loa Andersson George Swallow MPLS Working Group co-chairs Attachment(s): No document has been attached From root@core3.amsl.com Wed Apr 21 11:45:01 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C5E5B3A6C5A; Wed, 21 Apr 2010 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100421184501.C5E5B3A6C5A@core3.amsl.com> Date: Wed, 21 Apr 2010 11:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-oam-framework-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 18:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP OAM Framework Author(s) : D. Allan, et al. Filename : draft-ietf-mpls-tp-oam-framework-06.txt Pages : 51 Date : 2010-04-21 Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS- TP) is based on a profile of the MPLS and pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS- TE), PW and multi-segment PW (MS-PW) architectures complemented with additional Operations, Administration and Maintenance (OAM) procedures for fault, performance and protection-switching management for packet transport applications that do not rely on the presence of a control plane. This document describes a framework to support a comprehensive set of OAM procedures that fulfill the MPLS-TP OAM requirements. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-oam-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-21113641.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Thu Apr 22 03:10:19 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B93683A69B2; Thu, 22 Apr 2010 03:10:19 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100422101019.B93683A69B2@core3.amsl.com> Date: Thu, 22 Apr 2010 03:10:19 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, elisa.bellagamba@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, loa.andersson@ericsson.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "Final MPLS working group last call on "MPLS-TP OAM Framework" (ref #029.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 10:10:19 -0000 Title: Final MPLS working group last call on "MPLS-TP OAM Framework" (ref #029.01) Submission Date: 2010-04-22 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=879 Please reply by 2010-05-06 From: Loa Andersson(IETF MPLS WG) To: SG15, Q9, Q10, Q12, Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com elisa.bellagamba@ericsson.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For action Body: Final MPLS working group last call on "MPLS-TP OAM Framework" (ref #029.01) draft-ietf-mpls-tp-oam-framework-06.txt SG15, Q9, Q10, Q12 and Q14 We like to to inform you that the MPLS working group just started a short working group last call on "MPLS-TP OAM Framework" (draft-ietf-mpls-tp-oam-framework-06.txt). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. We would like to receive comments from the ITU-T by May 6th 2010. Loa Andersson George Swallow MPLS Working Group co-chairs Attachment(s): No document has been attached From michelg@upperside.fr Thu Apr 22 03:43:45 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58B83A6A18 for ; Thu, 22 Apr 2010 03:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLk0kBsEeEdG for ; Thu, 22 Apr 2010 03:43:44 -0700 (PDT) Received: from smtp01.msg.oleane.net (smtp01.msg.oleane.net [62.161.4.1]) by core3.amsl.com (Postfix) with ESMTP id 650653A689D for ; Thu, 22 Apr 2010 03:43:43 -0700 (PDT) Received: from nbMichelvst (AClermont-Ferrand-751-1-7-100.w90-4.abo.wanadoo.fr [90.4.210.100]) (authenticated) by smtp01.msg.oleane.net (MSA) with ESMTP id o3MAhWsH009086 for ; Thu, 22 Apr 2010 12:43:32 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Thu, 22 Apr 2010 12:38:33 +0200 Message-ID: <23515D6E4DED46E2BB4EB3BA7CCCE699@UPPERSIDECONFERENCES.COM> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01CAE218.B8970D40" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Thread-Index: AcriB/SwF2r95QQDR3KNRMW4riW42Q== X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.4.22.103019 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] Call for Proposals - MPLS & Ethernet World 2011 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 10:43:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01CAE218.B8970D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 13th edition of the MPLS & Ethernet World Congress will take place from 8/11 February 2011 in Paris. A call for proposals is now online at: http://www.upperside.fr/mplsworld2011/mpls2011intro.htm ------=_NextPart_000_0034_01CAE218.B8970D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 13th = edition of the MPLS & Ethernet World Congress will take place from 8/11 February = 2011 in = Paris.

 

A call for proposals is now online at:

http://www.upperside.fr/mplsworld2011/mpls2011intro.htm

 

 

------=_NextPart_000_0034_01CAE218.B8970D40-- From root@core3.amsl.com Thu Apr 22 08:45:01 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9312E3A6B8A; Thu, 22 Apr 2010 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100422154501.9312E3A6B8A@core3.amsl.com> Date: Thu, 22 Apr 2010 08:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-data-plane-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Transport Profile Data Plane Architecture Author(s) : D. Frost, et al. Filename : draft-ietf-mpls-tp-data-plane-02.txt Pages : 14 Date : 2010-04-22 The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-data-plane-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-data-plane-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-22083018.I-D@ietf.org> --NextPart-- From loa@pi.nu Thu Apr 22 08:53:58 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABA83A6B70; Thu, 22 Apr 2010 08:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf-2OtQmw1Ai; Thu, 22 Apr 2010 08:53:58 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 11B213A6BB1; Thu, 22 Apr 2010 08:53:58 -0700 (PDT) Received: from [95.209.68.102] (95.209.68.102.bredband.tre.se [95.209.68.102]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 074C9D404F; Thu, 22 Apr 2010 17:53:44 +0200 (CEST) Message-ID: <4BD07159.2040209@pi.nu> Date: Thu, 22 Apr 2010 17:55:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: MPLS-TP ad hoc team , mpls@ietf.org, "mpls-tp@ietf.org" , CCAMP WG , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Finalk wg lst call on MPLS Transport Profile Data Plane Architecture X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:53:59 -0000 All, this is to start a two week final working group last call on draft-ietf-mpls-tp-data-plane-02.txt Please note that the final working group last call is started only to verify that comments from the previous working group last call has been correctly addressed. Please send your comments to the mpls-tp@ietf.org mailing list. This working group last call ends May 6th. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wwwrun@core3.amsl.com Thu Apr 22 09:02:46 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7E79428C0EE; Thu, 22 Apr 2010 09:02:46 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100422160246.7E79428C0EE@core3.amsl.com> Date: Thu, 22 Apr 2010 09:02:46 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, elisa.bellagamba@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, loa.andersson@ericsson.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "MPLS working group last call on "MPLS Transport Profile Data Plane Architecture" (ref #030.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 16:02:46 -0000 Title: MPLS working group last call on "MPLS Transport Profile Data Plane Architecture" (ref #030.01) Submission Date: 2010-04-22 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=880 Please reply by 2010-05-06 From: Loa Andersson(IETF MPLS WG) To: SG15, Q9, Q10, Q12, Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com elisa.bellagamba@ericsson.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For action Body: MPLS working group last call on "MPLS Transport Profile Data Plane Architecture" (ref #030.01) draft-ietf-mpls-tp-data-plane-02 SG15, Q9, Q10, Q12 and Q14 We like to to inform you that the MPLS working group just started a short working group last call on "MPLS Transport Profile Data Plane Architecture" (draft-ietf-mpls-tp-data-plane-02). Please note that this wg last call is limited to verify that comments raised during the previous working group last call and reviews have been correctly addressed. We would like to receive comments from the ITU-T by May 6th 2010. Loa Andersson George Swallow MPLS Working Group co-chairs Attachment(s): No document has been attached From wwwrun@core3.amsl.com Thu Apr 22 12:03:29 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9C3343A6BAB; Thu, 22 Apr 2010 12:03:29 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100422190329.9C3343A6BAB@core3.amsl.com> Date: Thu, 22 Apr 2010 12:03:29 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:03:29 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Multiprotocol Label Switching Transport Profile Survivability Framework ' as an 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 2010-05-06. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18472&rfc_flag=0 From venkatflex@gmail.com Thu Apr 22 12:59:51 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937FF3A685B; Thu, 22 Apr 2010 12:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1QH09HorPBq; Thu, 22 Apr 2010 12:59:50 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id CDC063A67D9; Thu, 22 Apr 2010 12:59:40 -0700 (PDT) Received: by pwj2 with SMTP id 2so6356233pwj.31 for ; Thu, 22 Apr 2010 12:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=QSz6BAfFqu688Dy+xMT4F53A8SrSd4+JDX6O2YkcN/I=; b=QxxdLZz5YRL9GRc7OWzFODYycT/ndDHBj8tgGR+NK1W55dpRcf4bY7YE6RGyTgAEcD nDvCQZWPdBAOgY8P4bAQ5K2XvwSkm/O/RMrux2zz8N+EeD+1wpn5N12zr/BvWgUh5688 J9xAwdfEDprbrB8Fp9MGIqrqbjnzBsc+1EkkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TtlPB48dz9K9tQ1JhtxZVe3qolT0+cOB3A+bw3vtwYKgNdxGX4Ji1J7ifkJnHVrC3D Q4xBEjtsv3ahQCwcWkYsPTrRvPcLxcjSNkjIbJsQZseCun45njjQVDLXGUZzb45Lj2E2 6LFfMSAeqX0ygIrl6Q2VEN3qQkXCbBaMSIyFM= MIME-Version: 1.0 Received: by 10.142.104.2 with HTTP; Thu, 22 Apr 2010 12:59:27 -0700 (PDT) Date: Fri, 23 Apr 2010 01:29:27 +0530 Received: by 10.142.249.16 with SMTP id w16mr4788649wfh.134.1271966367584; Thu, 22 Apr 2010 12:59:27 -0700 (PDT) Message-ID: From: venkatesan mahalingam To: mpls , mpls-tp@ietf.org Content-Type: multipart/alternative; boundary=00504502ca548192c40484d8bf13 Subject: [mpls] MPLS-TP GAL doubt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:59:51 -0000 --00504502ca548192c40484d8bf13 Content-Type: text/plain; charset=ISO-8859-1 Hi, Why are we using reserved Generic Associated Channel Label (GAL) for MPLS-TP instead of NON-IP transport networks -> control word, TTL expiry and router alert label and IP transport networks -> loopback address range, TTL expiry and rotuer alert label to send the MPLS-TP control packet to control plane from data plane? Is there any specific dependency to choose GAL label for MPLS-TP networks? When are we using OAM alert label in the MPLS networks, what is the special need to reserve this label and use? -- Best Regards, Venkatesan Mahalingam. --00504502ca548192c40484d8bf13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Why are we using reserved Generic Associated Channel Label (GAL)= for MPLS-TP instead of
NON-IP transport networks -> control word, T= TL expiry and router alert label and
IP transport networks -> loopbac= k address range, TTL expiry and rotuer alert label
to send the MPLS-TP control packet to control plane from data plane?
Is there any specific dependency to choose GAL label for MPLS-TP networks= ?

When are we using OAM alert label in the MPLS networ= ks, what is the special need to reserve this label and use?
--
Best Regards,
Venkatesan Mahalingam.
--00504502ca548192c40484d8bf13-- From liu.guoman@zte.com.cn Fri Apr 23 01:49:09 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95053A6992; Fri, 23 Apr 2010 01:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.221 X-Spam-Level: X-Spam-Status: No, score=-95.221 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLXybnNlgFVI; Fri, 23 Apr 2010 01:49:08 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id CE7953A693D; Fri, 23 Apr 2010 01:49:07 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871570495873; Fri, 23 Apr 2010 16:45:19 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 88040.1570495873; Fri, 23 Apr 2010 16:45:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3N8mSre015205; Fri, 23 Apr 2010 16:48:34 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <20100422190329.9C3343A6BAB@core3.amsl.com> To: mpls@ietf.org, mpls-tp@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 23 Apr 2010 16:48:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-23 16:48:23, Serialize complete at 2010-04-23 16:48:23 Content-Type: multipart/alternative; boundary="=_alternative 0030678A4825770E_=" X-MAIL: mse2.zte.com.cn o3N8mSre015205 Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 08:49:10 -0000 This is a multipart message in MIME format. --=_alternative 0030678A4825770E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksYWxsDQpJIHJldmlldyB0aGlzIGRyYWZ0LCBJIG1heWJlIGhhdmUgYSBmZXcgY29uZnVzaW9u cyAgYWJvdXQgdGhlIGRyYWZ0LiBtYXliZSANCnRoZXJlIGlzIGEgbGl0dGxlIGVycm9yIGVkaXRv cnMgaW4gIHRoaXMgZHJhZnQuDQoxIGluIHNlY3Rpb24gMS4zLCB0aGVyZSBpcyBhIGEgZGVzY3Jp YmxlcyBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbiBMU1AgDQpyZWNvdmVyeQ0KICIgVGhpcyBt YXkgYWxzbyBiZSB0aGUgY2FzZSBmb3IgYXNzb2NpYXRlZA0KICAgYmlkaXJlY3Rpb25hbCBMU1Bz IHdoZXJlIHRoZSB0d28gZGlyZWN0aW9ucyBvZiB0aGUgTFNQIGZvbGxvdw0KICAgZGlmZmVyZW50 IHBhdGhzIHRocm91Z2ggdGhlIG5ldHdvcmsuICBUaGlzIGNhdXNlcyBkaXJlY3QgaW50ZXJhY3Rp b24NCiAgIGJldHdlZW4gdGhlIHJlY292ZXJ5IHByb2Nlc3NlcyBhZmZlY3RpbmcgdGhlIHR3byBk aXJlY3Rpb25zIG9mIGFuDQogICBMU1AsIHNvIHRoYXQgYm90aCBkaXJlY3Rpb25zIG9mIHRoZSBM U1AgYXJlIHJlY292ZXJlZCBhdCB0aGUgc2FtZQ0KICAgdGltZSAoaS5lLiwgYmlkaXJlY3Rpb25h bCByZWNvdmVyeSBpcyBhIGNvbnNlcXVlbmNlIG9mIGZhdGUtc2hhcmluZykuIg0KSU1PLCB0aGlz IG1lYW4gaXQgc2hvdWxkIG5lZWQgdG8gaGF2ZSBmYXRlLXNoYXJpbmcgZm9yIGFzc29jaWF0ZWQg DQpiaWRpcmVjdGlvbiBsc3A/DQppZiBvbmUgZGlyZWN0aW9uIHdvcmtpbmcgcGF0aCBoYXZlIGZh aWx1cmUsIGFub3RoZXIgZGlyZWN0aW9uIHdvcmtpbmcgcGF0aCANCm11c3QNCnN3aXRjaCBpbnRv IHByb3RlY3Rpb24gcGF0aD8NCg0KMiBpbiBzZWN0aW9uIDIgVGVybWlub2xvZ3kgYW5kIFJlZmVy ZW5jZQ0KICB0aGVyZSBhcmUgdHdvIHRoZSBzYW1lIGRlZmluaXRpb25zIGZvciBSZXN0b3JhdGlv biANCiAgbWF5YmUgZGVsZXRlIG9uZSBkZWZpbml0aW9ucyBmb3IgUmVzdG9ydGlvbjsNCg0KMyB0 aGVyZSBhcmUgTVBMUy1UUCBTZWN0aW9uIGxldmVsIGFuZCBMaW5rIGxheWVyIGNvbmNlcHQuIEkg d2FudCB0byANCiAga25vdyB3aGF0IGRpZmZlcmVuY2UgYmV0d2VlbiBNUExTLVRQIFNlY3Rpb24g TGV2ZWwgYW5kIE1QTFMtVFAgTGluayANCmxheWVyPw0KDQo0IFNlY3Rpb24gNC43LjMgUDJNUCBM aW5lYXIgUHJvdGVjdGlvbg0KICBBcyB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IG9mIFAyTVAgc3Vw cG9ydCAxOm4gcHJvdGVjdGlvbiBpbiBSRkMgNTY1NCwNCiAgc28gSSBzdWdnZXN0IHRvIGFkZCAx Om4gcHJvdGVjdGlvbiBzb2x1dGlvbiBpbiB0aGlzIHNlY3Rpb24gb3IgZnVydGhlcg0KICBzdHVk eSBmb3IgMTpuIHByb3RlY3Rpb24gb2YgcDJtcCA7DQoNCmJlc3QgcmVnYXJkcw0KbGl1DQoNCg0K DQoNCg0KDQoNCg0KDQoNClRoZSBJRVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4gDQq3orz+ yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDQtMjMgMDM6MDMNCsfrtPC4tCC4+A0K aWV0ZkBpZXRmLm9yZw0KDQoNCsrVvP7Iyw0KSUVURi1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBp ZXRmLm9yZz4NCrOty80NCm1wbHNAaWV0Zi5vcmcNCtb3zOINClttcGxzXSBMYXN0IENhbGw6IGRy YWZ0LWlldGYtbXBscy10cC1zdXJ2aXZlLWZ3ayAoTXVsdGlwcm90b2NvbCBMYWJlbCANClN3aXRj aGluZyBUcmFuc3BvcnQgUHJvZmlsZSBTdXJ2aXZhYmlsaXR5IEZyYW1ld29yaykgdG8gSW5mb3Jt YXRpb25hbCBSRkMNCg0KDQoNCg0KDQoNClRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3Qg ZnJvbSB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgV0cgDQoobXBscykgdG8gY29u c2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCg0KLSAnTXVsdGlwcm90b2NvbCBMYWJlbCBT d2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUgU3Vydml2YWJpbGl0eSANCiAgIEZyYW1ld29yayAn DQogICA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXN1cnZpdmUtZndrLTA1LnR4dD4gYXMgYW4gSW5mb3Jt YXRpb25hbCBSRkMNCg0KVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBu ZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzDQpmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlv bi4gIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KaWV0ZkBpZXRmLm9y ZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTAtMDUtMDYuIEV4Y2VwdGlvbmFsbHksIA0KY29tbWVudHMg bWF5IGJlIHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxl YXNlIA0KcmV0YWluIHRoZSBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBh dXRvbWF0ZWQgc29ydGluZy4NCg0KVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLXRwLXN1cnZpdmUt ZndrLTA1LnR4dA0KDQoNCklFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvcHVibGljL3BpZHRyYWNrZXIuY2dpP2NvbW1hbmQ9dmll d19pZCZkVGFnPTE4NDcyJnJmY19mbGFnPTANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5v dCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlv biB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4N Cg== --=_alternative 0030678A4825770E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLGFsbDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSByZXZpZXcgdGhpcyBkcmFmdCwgSSBtYXli ZSBoYXZlIGENCmZldyBjb25mdXNpb25zICZuYnNwO2Fib3V0IHRoZSBkcmFmdC4gbWF5YmUgdGhl cmUgaXMgYSBsaXR0bGUgZXJyb3IgZWRpdG9ycw0KaW4gJm5ic3A7dGhpcyBkcmFmdC48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEgaW4gc2VjdGlvbiAxLjMsIHRo ZXJlIGlzIGEgYSBkZXNjcmlibGVzDQpmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbiBMU1AgcmVj b3Zlcnk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyZx dW90OyA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPXJlZD48dHQ+VGhpcw0KbWF5IGFsc28gYmUg dGhlIGNhc2UgZm9yIGFzc29jaWF0ZWQ8YnI+DQogJm5ic3A7IGJpZGlyZWN0aW9uYWwgTFNQcyB3 aGVyZSB0aGUgdHdvIGRpcmVjdGlvbnMgb2YgdGhlIExTUCBmb2xsb3c8YnI+DQogJm5ic3A7IGRp ZmZlcmVudCBwYXRocyB0aHJvdWdoIHRoZSBuZXR3b3JrLiAmbmJzcDtUaGlzIGNhdXNlcyBkaXJl Y3QgaW50ZXJhY3Rpb248YnI+DQogJm5ic3A7IGJldHdlZW4gdGhlIHJlY292ZXJ5IHByb2Nlc3Nl cyBhZmZlY3RpbmcgdGhlIHR3byBkaXJlY3Rpb25zIG9mDQphbjxicj4NCiAmbmJzcDsgTFNQLCBz byB0aGF0IGJvdGggZGlyZWN0aW9ucyBvZiB0aGUgTFNQIGFyZSByZWNvdmVyZWQgYXQgdGhlIHNh bWU8YnI+DQogJm5ic3A7IHRpbWUgKGkuZS4sIGJpZGlyZWN0aW9uYWwgcmVjb3ZlcnkgaXMgYSBj b25zZXF1ZW5jZSBvZiBmYXRlLXNoYXJpbmcpPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0dD4u JnF1b3Q7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5JTU8sIHRoaXMgbWVhbiBp dCBzaG91bGQgbmVlZCB0byBoYXZlIGZhdGUtc2hhcmluZw0KZm9yIGFzc29jaWF0ZWQgYmlkaXJl Y3Rpb24gbHNwPzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+aWYgb25lIGRpcmVj dGlvbiB3b3JraW5nIHBhdGggaGF2ZSBmYWlsdXJlLCBhbm90aGVyDQpkaXJlY3Rpb24gd29ya2lu ZyBwYXRoIG11c3Q8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0PnN3aXRjaCBpbnRv IHByb3RlY3Rpb24gcGF0aD88L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+PHR0 PjIgaW4gc2VjdGlvbiAyIFRlcm1pbm9sb2d5IGFuZCBSZWZlcmVuY2U8L3R0PjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTM+PHR0PiZuYnNwOyB0aGVyZSBhcmUgdHdvIHRoZSBzYW1lIGRlZmluaXRp b25zIGZvciBSZXN0b3JhdGlvbg0KPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4m bmJzcDsgbWF5YmUgZGVsZXRlIG9uZSBkZWZpbml0aW9ucyBmb3IgUmVzdG9ydGlvbjs8L3R0Pjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+PHR0PjMgdGhlcmUgYXJlIE1QTFMtVFAgU2Vj dGlvbiBsZXZlbCBhbmQgTGluayBsYXllciBjb25jZXB0Lg0KSSB3YW50IHRvIDwvdHQ+PC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+Jm5ic3A7IGtub3cgd2hhdCBkaWZmZXJlbmNlIGJldHdl ZW4gTVBMUy1UUCBTZWN0aW9uDQpMZXZlbCBhbmQgTVBMUy1UUCBMaW5rIGxheWVyPzwvdHQ+PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz48dHQ+NCBTZWN0aW9uIDQuNy4zIFAyTVAgTGlu ZWFyIFByb3RlY3Rpb248L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0PiZuYnNwOyBB cyB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IG9mIFAyTVAgc3VwcG9ydCAxOm4NCnByb3RlY3Rpb24g aW4gUkZDIDU2NTQsPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4mbmJzcDsgc28g SSBzdWdnZXN0IHRvIGFkZCAxOm4gcHJvdGVjdGlvbiBzb2x1dGlvbg0KaW4gdGhpcyBzZWN0aW9u IG9yIGZ1cnRoZXI8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0PiZuYnNwOyBzdHVk eSBmb3IgMTpuIHByb3RlY3Rpb24gb2YgcDJtcCA7PC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zPjx0dD5iZXN0IHJlZ2FyZHM8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+ PHR0PmxpdTwvdHQ+PC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50 ZXI+PC9kaXY+DQo8dGQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+ PC9kaXY+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzQlPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj48Yj5UaGUgSUVTRyAmbHQ7aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmcmZ3Q7 PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6 ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDEwLTA0LTIzIDAzOjAzPC9mb250Pg0KPHRhYmxlIGJvcmRlcj4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+x+u08Li0ILj4PGJyPg0KaWV0ZkBpZXRmLm9yZzwv Zm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTY1JT4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPklFVEYtQW5ub3VuY2UgJmx0O2lldGYtYW5ub3VuY2VAaWV0Zi5v cmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5tcGxzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5bbXBsc10gTGFzdCBDYWxsOiBkcmFmdC1pZXRmLW1wbHMtdHAtc3Vydml2ZS1md2sNCihNdWx0 aXByb3RvY29sICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0xhYmVsIFN3aXRjaGluZyBUcmFu c3BvcnQNClByb2ZpbGUgU3Vydml2YWJpbGl0eSBGcmFtZXdvcmspIHRvICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0luZm9ybWF0aW9uYWwNClJGQzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+VGhlIElFU0cgaGFzIHJlY2VpdmVkIGEg cmVxdWVzdCBmcm9tIHRoZSBNdWx0aXByb3RvY29sDQpMYWJlbCBTd2l0Y2hpbmcgV0cgPGJyPg0K KG1wbHMpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6PGJyPg0KPGJyPg0KLSAn TXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUgU3Vydml2YWJp bGl0eSA8YnI+DQogJm5ic3A7IEZyYW1ld29yayAnPGJyPg0KICZuYnNwOyAmbHQ7ZHJhZnQtaWV0 Zi1tcGxzLXRwLXN1cnZpdmUtZndrLTA1LnR4dCZndDsgYXMgYW4gSW5mb3JtYXRpb25hbA0KUkZD PGJyPg0KPGJyPg0KVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0 IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzPGJyPg0KZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rp b24uICZuYnNwO1BsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvDQp0aGU8YnI+DQpp ZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxMC0wNS0wNi4gRXhjZXB0aW9uYWxseSwg PGJyPg0KY29tbWVudHMgbWF5IGJlIHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBl aXRoZXIgY2FzZSwgcGxlYXNlIDxicj4NCnJldGFpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBTdWJq ZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuPGJyPg0KPGJyPg0KVGhlIGZpbGUg Y2FuIGJlIG9idGFpbmVkIHZpYTxicj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtbXBscy10cC1zdXJ2aXZlLWZ3ay0wNS50eHQ8YnI+DQo8YnI+DQo8YnI+ DQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhPGJyPg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9wdWJsaWMvcGlkdHJhY2tlci5jZ2k/Y29tbWFuZD12aWV3X2lkJmFtcDtk VGFnPTE4NDcyJmFtcDtyZmNfZmxhZz0wPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1w bHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHM8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0lu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3Jt YXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMm bmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3Mm bmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5i c3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5i c3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNw O3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhp cyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFp bCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRo Jm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRl ZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5i c3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hh dmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3Im bmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2Vk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMm bmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtz eXN0ZW0uDQo8L3ByZT4= --=_alternative 0030678A4825770E_=-- From wwwrun@core3.amsl.com Fri Apr 23 04:52:27 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A93FB28C57F; Fri, 23 Apr 2010 04:52:27 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Subject: New Liaison Statement, "Disposition of comments received in “Liaison LS162 - Comments on draft-ietf-mpls-tp-data-plane-01” (Ref # 023.03)" Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100423115227.A93FB28C57F@core3.amsl.com> Date: Fri, 23 Apr 2010 04:52:27 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, sob@harvard.edu, malcolm.betts@zte.com.cn, elisa.bellagamba@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, loa.andersson@ericsson.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 11:52:27 -0000 Title: Disposition of comments received in �Liaison LS162 - Comments on draft-ietf-mpls-tp-data-plane-01� (Ref # 023.03) Submission Date: 2010-04-23 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=881 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com elisa.bellagamba@ericsson.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com sob@harvard.edu Purpose: For information Body: see attachment Attachment(s): Disposition of comments received in �Liaison LS162 - Comments on draft-ietf-mpls-tp-data-plane-01� (Ref # 023.03) (https://datatracker.ietf.org/documents/LIAISON/file997.doc) From agmalis@gmail.com Fri Apr 23 10:45:19 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696673A6907 for ; Fri, 23 Apr 2010 10:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfv8-fBP15So for ; Fri, 23 Apr 2010 10:45:19 -0700 (PDT) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by core3.amsl.com (Postfix) with ESMTP id 2D89F3A6899 for ; Fri, 23 Apr 2010 10:45:19 -0700 (PDT) Received: by gxk3 with SMTP id 3so4837865gxk.13 for ; Fri, 23 Apr 2010 10:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=LEdQ9U797gG8VRenHtOetJvbM2lC5/HWbmCSUxbNCo8=; b=HK40BAETQxcAx22OdlVCzsL1DRZVlOZDbUjRig5SOmOPzN0UEiOKD6Qu9YeyC+GxCp usnAoJqJfPD34aqpmx7IchQVZWej8sVhTaDhL1lb5y064nBrxuOV7WYGRiOCm39kuuAa jgWno52qrVt9hXY/f1dWe9D8MPQ8iJX5H02KI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=lxsHaILwqcOjALkXztLyVok6Jdm/FpmXFcxbxifEW3mdI92kNM6gVTN3dr4cV1/q3n KDZg4RWNWZ8J4u/xUWJWUQBRyCiUHs+pTjQZY+W6ablHNtgzOiX97/+u2Kl7dgLmboms O4csqpll5yGjiEKH8BNarWBvfd5IoSGNOj2OM= Received: by 10.101.183.23 with SMTP id k23mr577245anp.160.1272044704548; Fri, 23 Apr 2010 10:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.93.8 with HTTP; Fri, 23 Apr 2010 10:44:44 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 23 Apr 2010 13:44:44 -0400 Message-ID: To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] MPLS 2010 Conference - Call for Presentation Abstracts Extended X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 17:45:19 -0000 Note that the deadline for abstract submissions has been extended to April 30. Cheers, Andy ---------- Forwarded message ---------- From: Andrew G. Malis Date: Mon, Mar 22, 2010 at 7:39 PM Subject: MPLS 2010 Conference - Call for Presentation Abstracts To: mpls@ietf.org The MPLS 2010 International Conference, the 13th Annual International Conference on MPLS and Related Technologies, will be held October 24 - 27, 2010, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 23, 2010. If you want further information on MPLS 2010 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2010/call_for_papers/cfp.htm Many of these topics have been of interest to members of the MPLS WG in the past, and several people active in the working group have been presenters at past events. Regards and thanks, Andy Malis Co-chair, Technical Program Committee - MPLS 2010 Conference From adrian@olddog.co.uk Fri Apr 23 14:22:13 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BC93A6800; Fri, 23 Apr 2010 14:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbtBah-pJO2a; Fri, 23 Apr 2010 14:22:11 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id 92C4C3A6949; Fri, 23 Apr 2010 14:22:05 -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 o3NLLaTB009817; Fri, 23 Apr 2010 22:21:42 +0100 Received: from your029b8cecfe (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 o3NLLZYV009811; Fri, 23 Apr 2010 22:21:36 +0100 Message-ID: From: "Adrian Farrel" To: References: Date: Fri, 23 Apr 2010 22:21:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 21:22:13 -0000 Hi Liu, Thanks for reviewing. > 1 in section 1.3, there is a a describles for associated bidirection LSP > recovery > " This may also be the case for associated > bidirectional LSPs where the two directions of the LSP follow > different paths through the network. This causes direct interaction > between the recovery processes affecting the two directions of an > LSP, so that both directions of the LSP are recovered at the same > time (i.e., bidirectional recovery is a consequence of fate-sharing)." > IMO, this mean it should need to have fate-sharing for associated > bidirection lsp? > if one direction working path have failure, another direction working path > must switch into protection path? I think there is some confusion between bidirectional LSP and bidirectional recovery. It is possible that this text is too dense. Can I suggest to modify it as follows: OLD Co-routed bidirectional MPLS-TP LSPs are defined in a way that allows both directions of the LSP to follow the same route through the network. In this scenario, the operator often requires the directions to fate-share (that is, if one direction fails, both directions should cease to operate). This may also be the case for associated bidirectional LSPs where the two directions of the LSP follow different paths through the network. This causes direct interaction between the recovery processes affecting the two directions of an LSP, so that both directions of the LSP are recovered at the same time (i.e., bidirectional recovery is a consequence of fate-sharing). NEW Co-routed bidirectional MPLS-TP LSPs are defined in a way that allows both directions of the LSP to follow the same route through the network. In this scenario, the operator often requires the directions to fate-share (that is, if one direction fails, both directions should cease to operate). Associated bidirectional MPLS-TP LSPs exist where the two directions of a bidirectional LSP follow different paths through the network. An operator may also request fate-sharing for associated bidirectional LSPs. The requirement for fate-sharing causes a direct interaction between the recovery processes affecting the two directions of an LSP, so that both directions of the bidirecitonal LSP are recovered at the same time. This mode of recovery is termed bidirectional recovery and may be seen as a consequence of fate-sharing. END > 2 in section 2 Terminology and Reference > there are two the same definitions for Restoration > maybe delete one definitions for Restortion; Good catch. Thanks. > 3 there are MPLS-TP Section level and Link layer concept. I want to > know what difference between MPLS-TP Section Level and MPLS-TP Link > layer? Hmmm. In fact, we only mention "section level" once in the whole document. Section 4.4.1 has: A protection mechanism may be provided at the MPLS-TP link layer (which connects two MPLS-TP nodes). Such a mechanism can make use of the procedures defined in [RFC5586] to set up in-band communication channels at the MPLS-TP section level, to use these channels to monitor the health of the MPLS-TP link, and to coordinate the protection states between the ends of the MPLS-TP link. If I recall right, this text was gifted to us by the latest ITU-T liaison. Anyway, I think the point is that the section level OAM operates on a single link between a pair of MPLS-TP routers. The protection, of course, requires the use of multiple "parallel" links. So "section level" applies to a single link, and "link level" applies to a set of links. If this distinction continues to worry you, maybe the best approach would be to remove this reference to "section level". What do you think? > 4 Section 4.7.3 P2MP Linear Protection > As there is a requirement of P2MP support 1:n protection in RFC 5654, > so I suggest to add 1:n protection solution in this section or further > study for 1:n protection of p2mp ; You're right. R67B of RFC5654. I propose to add a new final paragraph to section 4.7.3. as follows. A 1:n protection scheme for P2MP transport paths is also required by [RFC5654]. Such a mechanism is for future study. OK? Many thanks, Adrian From liu.guoman@zte.com.cn Mon Apr 26 00:18:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76AFB3A687E; Mon, 26 Apr 2010 00:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.128 X-Spam-Level: X-Spam-Status: No, score=-95.128 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA-8JK4ADkwl; Mon, 26 Apr 2010 00:18:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D5F823A6888; Mon, 26 Apr 2010 00:17:58 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871570495873; Mon, 26 Apr 2010 15:13:29 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 83532.1680394169; Mon, 26 Apr 2010 15:17:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3Q7DZjF002820; Mon, 26 Apr 2010 15:13:35 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: "Adrian Farrel" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 26 Apr 2010 15:13:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-26 15:13:24, Serialize complete at 2010-04-26 15:13:24 Content-Type: multipart/alternative; boundary="=_alternative 0027B4F648257711_=" X-MAIL: mse2.zte.com.cn o3Q7DZjF002820 Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 07:18:14 -0000 This is a multipart message in MIME format. --=_alternative 0027B4F648257711_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QWRyaWFuDQp0aGFuayB5b3UgZm9yIHJlcGx5aW5nICwgSSB0aGluayBpdCBtYXliZSBtb3JlIGNs ZWFyIHRvIGNoYW5nZSBpdCANCmFjY29yZGluZyB0byB5b3VyIG9waW5pb25zIGZvciBldmVyeW9u ZS4NCg0KYmVzdCByZWdhcmRzDQpsaXUNCg0KDQoNCg0KDQoNCg0KIkFkcmlhbiBGYXJyZWwiIDxh ZHJpYW5Ab2xkZG9nLmNvLnVrPiANCjIwMTAtMDQtMjQgMDU6MjENCsfrtPC4tCC4+A0KIkFkcmlh biBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KDQoNCsrVvP7Iyw0KPGxpdS5ndW9tYW5A enRlLmNvbS5jbj4NCrOty80NCjxtcGxzQGlldGYub3JnPiwgPG1wbHMtdHBAaWV0Zi5vcmc+DQrW 98ziDQpSZTogW21wbHNdIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1tcGxzLXRwLXN1cnZpdmUtZndr IChNdWx0aXByb3RvY29sIExhYmVsIA0KU3dpdGNoaW5nIFRyYW5zcG9ydCBQcm9maWxlIFN1cnZp dmFiaWxpdHkgRnJhbWV3b3JrKSB0byBJbmZvcm1hdGlvbmFsIFJGQw0KDQoNCg0KDQoNCg0KSGkg TGl1LA0KDQpUaGFua3MgZm9yIHJldmlld2luZy4NCg0KPiAxIGluIHNlY3Rpb24gMS4zLCB0aGVy ZSBpcyBhIGEgZGVzY3JpYmxlcyBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbiBMU1ANCj4gcmVj b3ZlcnkNCj4gIiBUaGlzIG1heSBhbHNvIGJlIHRoZSBjYXNlIGZvciBhc3NvY2lhdGVkDQo+ICAg YmlkaXJlY3Rpb25hbCBMU1BzIHdoZXJlIHRoZSB0d28gZGlyZWN0aW9ucyBvZiB0aGUgTFNQIGZv bGxvdw0KPiAgIGRpZmZlcmVudCBwYXRocyB0aHJvdWdoIHRoZSBuZXR3b3JrLiAgVGhpcyBjYXVz ZXMgZGlyZWN0IGludGVyYWN0aW9uDQo+ICAgYmV0d2VlbiB0aGUgcmVjb3ZlcnkgcHJvY2Vzc2Vz IGFmZmVjdGluZyB0aGUgdHdvIGRpcmVjdGlvbnMgb2YgYW4NCj4gICBMU1AsIHNvIHRoYXQgYm90 aCBkaXJlY3Rpb25zIG9mIHRoZSBMU1AgYXJlIHJlY292ZXJlZCBhdCB0aGUgc2FtZQ0KPiAgIHRp bWUgKGkuZS4sIGJpZGlyZWN0aW9uYWwgcmVjb3ZlcnkgaXMgYSBjb25zZXF1ZW5jZSBvZiBmYXRl LXNoYXJpbmcpLiINCj4gSU1PLCB0aGlzIG1lYW4gaXQgc2hvdWxkIG5lZWQgdG8gaGF2ZSBmYXRl LXNoYXJpbmcgZm9yIGFzc29jaWF0ZWQNCj4gYmlkaXJlY3Rpb24gbHNwPw0KPiBpZiBvbmUgZGly ZWN0aW9uIHdvcmtpbmcgcGF0aCBoYXZlIGZhaWx1cmUsIGFub3RoZXIgZGlyZWN0aW9uIHdvcmtp bmcgDQpwYXRoDQo+IG11c3Qgc3dpdGNoIGludG8gcHJvdGVjdGlvbiBwYXRoPw0KDQpJIHRoaW5r IHRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIGJldHdlZW4gYmlkaXJlY3Rpb25hbCBMU1AgYW5kIA0K YmlkaXJlY3Rpb25hbCANCnJlY292ZXJ5Lg0KDQpJdCBpcyBwb3NzaWJsZSB0aGF0IHRoaXMgdGV4 dCBpcyB0b28gZGVuc2UuIENhbiBJIHN1Z2dlc3QgdG8gbW9kaWZ5IGl0IGFzIA0KZm9sbG93czoN Cg0KT0xEDQogICBDby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBNUExTLVRQIExTUHMgYXJlIGRlZmlu ZWQgaW4gYSB3YXkgdGhhdCBhbGxvd3MNCiAgIGJvdGggZGlyZWN0aW9ucyBvZiB0aGUgTFNQIHRv IGZvbGxvdyB0aGUgc2FtZSByb3V0ZSB0aHJvdWdoIHRoZQ0KICAgbmV0d29yay4gSW4gdGhpcyBz Y2VuYXJpbywgdGhlIG9wZXJhdG9yIG9mdGVuIHJlcXVpcmVzIHRoZSBkaXJlY3Rpb25zDQogICB0 byBmYXRlLXNoYXJlICh0aGF0IGlzLCBpZiBvbmUgZGlyZWN0aW9uIGZhaWxzLCBib3RoIGRpcmVj dGlvbnMNCiAgIHNob3VsZCBjZWFzZSB0byBvcGVyYXRlKS4gIFRoaXMgbWF5IGFsc28gYmUgdGhl IGNhc2UgZm9yIGFzc29jaWF0ZWQNCiAgIGJpZGlyZWN0aW9uYWwgTFNQcyB3aGVyZSB0aGUgdHdv IGRpcmVjdGlvbnMgb2YgdGhlIExTUCBmb2xsb3cNCiAgIGRpZmZlcmVudCBwYXRocyB0aHJvdWdo IHRoZSBuZXR3b3JrLiAgVGhpcyBjYXVzZXMgZGlyZWN0IGludGVyYWN0aW9uDQogICBiZXR3ZWVu IHRoZSByZWNvdmVyeSBwcm9jZXNzZXMgYWZmZWN0aW5nIHRoZSB0d28gZGlyZWN0aW9ucyBvZiBh bg0KICAgTFNQLCBzbyB0aGF0IGJvdGggZGlyZWN0aW9ucyBvZiB0aGUgTFNQIGFyZSByZWNvdmVy ZWQgYXQgdGhlIHNhbWUNCiAgIHRpbWUgKGkuZS4sIGJpZGlyZWN0aW9uYWwgcmVjb3ZlcnkgaXMg YSBjb25zZXF1ZW5jZSBvZiBmYXRlLXNoYXJpbmcpLg0KTkVXDQogICBDby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBNUExTLVRQIExTUHMgYXJlIGRlZmluZWQgaW4gYSB3YXkgdGhhdCBhbGxvd3MNCiAg IGJvdGggZGlyZWN0aW9ucyBvZiB0aGUgTFNQIHRvIGZvbGxvdyB0aGUgc2FtZSByb3V0ZSB0aHJv dWdoIHRoZQ0KICAgbmV0d29yay4gSW4gdGhpcyBzY2VuYXJpbywgdGhlIG9wZXJhdG9yIG9mdGVu IHJlcXVpcmVzIHRoZSBkaXJlY3Rpb25zDQogICB0byBmYXRlLXNoYXJlICh0aGF0IGlzLCBpZiBv bmUgZGlyZWN0aW9uIGZhaWxzLCBib3RoIGRpcmVjdGlvbnMNCiAgIHNob3VsZCBjZWFzZSB0byBv cGVyYXRlKS4NCg0KICAgQXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIE1QTFMtVFAgTFNQcyBleGlz dCB3aGVyZSB0aGUgdHdvIGRpcmVjdGlvbnMNCiAgIG9mIGEgYmlkaXJlY3Rpb25hbCBMU1AgZm9s bG93IGRpZmZlcmVudCBwYXRocyB0aHJvdWdoIHRoZSBuZXR3b3JrLg0KICAgQW4gb3BlcmF0b3Ig bWF5IGFsc28gcmVxdWVzdCBmYXRlLXNoYXJpbmcgZm9yIGFzc29jaWF0ZWQNCiAgIGJpZGlyZWN0 aW9uYWwgTFNQcy4NCg0KICAgVGhlIHJlcXVpcmVtZW50IGZvciBmYXRlLXNoYXJpbmcgY2F1c2Vz IGEgZGlyZWN0IGludGVyYWN0aW9uIGJldHdlZW4NCiAgIHRoZSByZWNvdmVyeSBwcm9jZXNzZXMg YWZmZWN0aW5nIHRoZSB0d28gZGlyZWN0aW9ucyBvZiBhbiBMU1AsIHNvDQogICB0aGF0IGJvdGgg ZGlyZWN0aW9ucyBvZiB0aGUgYmlkaXJlY2l0b25hbCBMU1AgYXJlIHJlY292ZXJlZCBhdCB0aGUN CiAgIHNhbWUgdGltZS4gVGhpcyBtb2RlIG9mIHJlY292ZXJ5ICBpcyB0ZXJtZWQgYmlkaXJlY3Rp b25hbCByZWNvdmVyeQ0KICAgYW5kIG1heSBiZSBzZWVuIGFzIGEgY29uc2VxdWVuY2Ugb2YgZmF0 ZS1zaGFyaW5nLg0KRU5EDQoNCj4gMiBpbiBzZWN0aW9uIDIgVGVybWlub2xvZ3kgYW5kIFJlZmVy ZW5jZQ0KPiAgdGhlcmUgYXJlIHR3byB0aGUgc2FtZSBkZWZpbml0aW9ucyBmb3IgUmVzdG9yYXRp b24NCj4gIG1heWJlIGRlbGV0ZSBvbmUgZGVmaW5pdGlvbnMgZm9yIFJlc3RvcnRpb247DQoNCkdv b2QgY2F0Y2guDQpUaGFua3MuDQoNCj4gMyB0aGVyZSBhcmUgTVBMUy1UUCBTZWN0aW9uIGxldmVs IGFuZCBMaW5rIGxheWVyIGNvbmNlcHQuIEkgd2FudCB0bw0KPiAga25vdyB3aGF0IGRpZmZlcmVu Y2UgYmV0d2VlbiBNUExTLVRQIFNlY3Rpb24gTGV2ZWwgYW5kIE1QTFMtVFAgTGluaw0KPiBsYXll cj8NCg0KSG1tbS4NCkluIGZhY3QsIHdlIG9ubHkgbWVudGlvbiAic2VjdGlvbiBsZXZlbCIgb25j ZSBpbiB0aGUgd2hvbGUgZG9jdW1lbnQuDQpTZWN0aW9uIDQuNC4xIGhhczoNCiAgIEEgcHJvdGVj dGlvbiBtZWNoYW5pc20gbWF5IGJlIHByb3ZpZGVkIGF0IHRoZSBNUExTLVRQIGxpbmsgbGF5ZXIN CiAgICh3aGljaCBjb25uZWN0cyB0d28gTVBMUy1UUCBub2RlcykuICBTdWNoIGEgbWVjaGFuaXNt IGNhbiBtYWtlIHVzZSBvZg0KICAgdGhlIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBbUkZDNTU4Nl0g dG8gc2V0IHVwIGluLWJhbmQgY29tbXVuaWNhdGlvbg0KICAgY2hhbm5lbHMgYXQgdGhlIE1QTFMt VFAgc2VjdGlvbiBsZXZlbCwgdG8gdXNlIHRoZXNlIGNoYW5uZWxzIHRvDQogICBtb25pdG9yIHRo ZSBoZWFsdGggb2YgdGhlIE1QTFMtVFAgbGluaywgYW5kIHRvIGNvb3JkaW5hdGUgdGhlDQogICBw cm90ZWN0aW9uIHN0YXRlcyBiZXR3ZWVuIHRoZSBlbmRzIG9mIHRoZSBNUExTLVRQIGxpbmsuDQpJ ZiBJIHJlY2FsbCByaWdodCwgdGhpcyB0ZXh0IHdhcyBnaWZ0ZWQgdG8gdXMgYnkgdGhlIGxhdGVz dCBJVFUtVCBsaWFpc29uLg0KDQpBbnl3YXksIEkgdGhpbmsgdGhlIHBvaW50IGlzIHRoYXQgdGhl IHNlY3Rpb24gbGV2ZWwgT0FNIG9wZXJhdGVzIG9uIGEgDQpzaW5nbGUgDQpsaW5rIGJldHdlZW4g YSBwYWlyIG9mIE1QTFMtVFAgcm91dGVycy4gVGhlIHByb3RlY3Rpb24sIG9mIGNvdXJzZSwgDQpy ZXF1aXJlcyANCnRoZSB1c2Ugb2YgbXVsdGlwbGUgInBhcmFsbGVsIiBsaW5rcy4gU28gInNlY3Rp b24gbGV2ZWwiIGFwcGxpZXMgdG8gYSANCnNpbmdsZSANCmxpbmssIGFuZCAibGluayBsZXZlbCIg YXBwbGllcyB0byBhIHNldCBvZiBsaW5rcy4NCg0KSWYgdGhpcyBkaXN0aW5jdGlvbiBjb250aW51 ZXMgdG8gd29ycnkgeW91LCBtYXliZSB0aGUgYmVzdCBhcHByb2FjaCB3b3VsZCANCmJlIA0KdG8g cmVtb3ZlIHRoaXMgcmVmZXJlbmNlIHRvICJzZWN0aW9uIGxldmVsIi4gV2hhdCBkbyB5b3UgdGhp bms/DQoNCj4gNCBTZWN0aW9uIDQuNy4zIFAyTVAgTGluZWFyIFByb3RlY3Rpb24NCj4gIEFzIHRo ZXJlIGlzIGEgcmVxdWlyZW1lbnQgb2YgUDJNUCBzdXBwb3J0IDE6biBwcm90ZWN0aW9uIGluIFJG QyA1NjU0LA0KPiAgc28gSSBzdWdnZXN0IHRvIGFkZCAxOm4gcHJvdGVjdGlvbiBzb2x1dGlvbiBp biB0aGlzIHNlY3Rpb24gb3IgZnVydGhlcg0KPiAgc3R1ZHkgZm9yIDE6biBwcm90ZWN0aW9uIG9m IHAybXAgOw0KDQpZb3UncmUgcmlnaHQuIFI2N0Igb2YgUkZDNTY1NC4NCg0KSSBwcm9wb3NlIHRv IGFkZCBhIG5ldyBmaW5hbCBwYXJhZ3JhcGggdG8gc2VjdGlvbiA0LjcuMy4gYXMgZm9sbG93cy4N Cg0KICAgQSAxOm4gcHJvdGVjdGlvbiBzY2hlbWUgZm9yIFAyTVAgdHJhbnNwb3J0IHBhdGhzIGlz IGFsc28gcmVxdWlyZWQgYnkNCiAgIFtSRkM1NjU0XS4gU3VjaCBhIG1lY2hhbmlzbSBpcyBmb3Ig ZnV0dXJlIHN0dWR5Lg0KDQpPSz8NCg0KTWFueSB0aGFua3MsDQpBZHJpYW4NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLg0K --=_alternative 0027B4F648257711_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFkcmlhbjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhhbmsgeW91IGZvciByZXBseWluZyAsIEkg dGhpbmsgaXQNCm1heWJlIG1vcmUgY2xlYXIgdG8gY2hhbmdlIGl0IGFjY29yZGluZyB0byB5b3Vy IG9waW5pb25zIGZvciBldmVyeW9uZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPmJlc3QgcmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+bGl1PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRp diBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzQlPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtBZHJpYW4gRmFycmVsJnF1b3Q7 DQombHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA0LTI0IDA1OjIxPC9mb250Pg0KPHRhYmxlIGJvcmRl cj4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRl cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+x+u08Li0ILj4PGJyPg0KJnF1b3Q7QWRy aWFuIEZhcnJlbCZxdW90OyAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDs8L2ZvbnQ+PC9kaXY+ PC90YWJsZT4NCjxicj4NCjx0ZCB3aWR0aD02NSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4mbHQ7bGl1Lmd1b21hbkB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCAmbHQ7bXBscy10cEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbbXBsc10gTGFzdCBDYWxsOiBkcmFmdC1pZXRmLW1wbHMtdHAtc3Vydml2 ZS1md2sNCihNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBUcmFuc3BvcnQgUHJvZmlsZSBT dXJ2aXZhYmlsaXR5IEZyYW1ld29yaykNCnRvIEluZm9ybWF0aW9uYWwgUkZDPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5IaSBMaXUsPGJy Pg0KPGJyPg0KVGhhbmtzIGZvciByZXZpZXdpbmcuPGJyPg0KPGJyPg0KJmd0OyAxIGluIHNlY3Rp b24gMS4zLCB0aGVyZSBpcyBhIGEgZGVzY3JpYmxlcyBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlv bg0KTFNQPGJyPg0KJmd0OyByZWNvdmVyeTxicj4NCiZndDsgJnF1b3Q7IFRoaXMgbWF5IGFsc28g YmUgdGhlIGNhc2UgZm9yIGFzc29jaWF0ZWQ8YnI+DQomZ3Q7ICZuYnNwOyBiaWRpcmVjdGlvbmFs IExTUHMgd2hlcmUgdGhlIHR3byBkaXJlY3Rpb25zIG9mIHRoZSBMU1AgZm9sbG93PGJyPg0KJmd0 OyAmbmJzcDsgZGlmZmVyZW50IHBhdGhzIHRocm91Z2ggdGhlIG5ldHdvcmsuICZuYnNwO1RoaXMg Y2F1c2VzIGRpcmVjdA0KaW50ZXJhY3Rpb248YnI+DQomZ3Q7ICZuYnNwOyBiZXR3ZWVuIHRoZSBy ZWNvdmVyeSBwcm9jZXNzZXMgYWZmZWN0aW5nIHRoZSB0d28gZGlyZWN0aW9ucw0Kb2YgYW48YnI+ DQomZ3Q7ICZuYnNwOyBMU1AsIHNvIHRoYXQgYm90aCBkaXJlY3Rpb25zIG9mIHRoZSBMU1AgYXJl IHJlY292ZXJlZCBhdCB0aGUNCnNhbWU8YnI+DQomZ3Q7ICZuYnNwOyB0aW1lIChpLmUuLCBiaWRp cmVjdGlvbmFsIHJlY292ZXJ5IGlzIGEgY29uc2VxdWVuY2Ugb2YgZmF0ZS1zaGFyaW5nKS4mcXVv dDs8YnI+DQomZ3Q7IElNTywgdGhpcyBtZWFuIGl0IHNob3VsZCBuZWVkIHRvIGhhdmUgZmF0ZS1z aGFyaW5nIGZvciBhc3NvY2lhdGVkPGJyPg0KJmd0OyBiaWRpcmVjdGlvbiBsc3A/PGJyPg0KJmd0 OyBpZiBvbmUgZGlyZWN0aW9uIHdvcmtpbmcgcGF0aCBoYXZlIGZhaWx1cmUsIGFub3RoZXIgZGly ZWN0aW9uIHdvcmtpbmcNCnBhdGg8YnI+DQomZ3Q7IG11c3Qgc3dpdGNoIGludG8gcHJvdGVjdGlv biBwYXRoPzxicj4NCjxicj4NCkkgdGhpbmsgdGhlcmUgaXMgc29tZSBjb25mdXNpb24gYmV0d2Vl biBiaWRpcmVjdGlvbmFsIExTUCBhbmQgYmlkaXJlY3Rpb25hbA0KPGJyPg0KcmVjb3ZlcnkuPGJy Pg0KPGJyPg0KSXQgaXMgcG9zc2libGUgdGhhdCB0aGlzIHRleHQgaXMgdG9vIGRlbnNlLiBDYW4g SSBzdWdnZXN0IHRvIG1vZGlmeSBpdA0KYXMgPGJyPg0KZm9sbG93czo8YnI+DQo8YnI+DQpPTEQ8 YnI+DQogJm5ic3A7IENvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIE1QTFMtVFAgTFNQcyBhcmUgZGVm aW5lZCBpbiBhIHdheSB0aGF0DQphbGxvd3M8YnI+DQogJm5ic3A7IGJvdGggZGlyZWN0aW9ucyBv ZiB0aGUgTFNQIHRvIGZvbGxvdyB0aGUgc2FtZSByb3V0ZSB0aHJvdWdoIHRoZTxicj4NCiAmbmJz cDsgbmV0d29yay4gSW4gdGhpcyBzY2VuYXJpbywgdGhlIG9wZXJhdG9yIG9mdGVuIHJlcXVpcmVz IHRoZSBkaXJlY3Rpb25zPGJyPg0KICZuYnNwOyB0byBmYXRlLXNoYXJlICh0aGF0IGlzLCBpZiBv bmUgZGlyZWN0aW9uIGZhaWxzLCBib3RoIGRpcmVjdGlvbnM8YnI+DQogJm5ic3A7IHNob3VsZCBj ZWFzZSB0byBvcGVyYXRlKS4gJm5ic3A7VGhpcyBtYXkgYWxzbyBiZSB0aGUgY2FzZSBmb3IgYXNz b2NpYXRlZDxicj4NCiAmbmJzcDsgYmlkaXJlY3Rpb25hbCBMU1BzIHdoZXJlIHRoZSB0d28gZGly ZWN0aW9ucyBvZiB0aGUgTFNQIGZvbGxvdzxicj4NCiAmbmJzcDsgZGlmZmVyZW50IHBhdGhzIHRo cm91Z2ggdGhlIG5ldHdvcmsuICZuYnNwO1RoaXMgY2F1c2VzIGRpcmVjdCBpbnRlcmFjdGlvbjxi cj4NCiAmbmJzcDsgYmV0d2VlbiB0aGUgcmVjb3ZlcnkgcHJvY2Vzc2VzIGFmZmVjdGluZyB0aGUg dHdvIGRpcmVjdGlvbnMgb2YNCmFuPGJyPg0KICZuYnNwOyBMU1AsIHNvIHRoYXQgYm90aCBkaXJl Y3Rpb25zIG9mIHRoZSBMU1AgYXJlIHJlY292ZXJlZCBhdCB0aGUgc2FtZTxicj4NCiAmbmJzcDsg dGltZSAoaS5lLiwgYmlkaXJlY3Rpb25hbCByZWNvdmVyeSBpcyBhIGNvbnNlcXVlbmNlIG9mIGZh dGUtc2hhcmluZykuPGJyPg0KTkVXPGJyPg0KICZuYnNwOyBDby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCBNUExTLVRQIExTUHMgYXJlIGRlZmluZWQgaW4gYSB3YXkgdGhhdA0KYWxsb3dzPGJyPg0KICZu YnNwOyBib3RoIGRpcmVjdGlvbnMgb2YgdGhlIExTUCB0byBmb2xsb3cgdGhlIHNhbWUgcm91dGUg dGhyb3VnaCB0aGU8YnI+DQogJm5ic3A7IG5ldHdvcmsuIEluIHRoaXMgc2NlbmFyaW8sIHRoZSBv cGVyYXRvciBvZnRlbiByZXF1aXJlcyB0aGUgZGlyZWN0aW9uczxicj4NCiAmbmJzcDsgdG8gZmF0 ZS1zaGFyZSAodGhhdCBpcywgaWYgb25lIGRpcmVjdGlvbiBmYWlscywgYm90aCBkaXJlY3Rpb25z PGJyPg0KICZuYnNwOyBzaG91bGQgY2Vhc2UgdG8gb3BlcmF0ZSkuPGJyPg0KPGJyPg0KICZuYnNw OyBBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTVBMUy1UUCBMU1BzIGV4aXN0IHdoZXJlIHRoZSB0 d28gZGlyZWN0aW9uczxicj4NCiAmbmJzcDsgb2YgYSBiaWRpcmVjdGlvbmFsIExTUCBmb2xsb3cg ZGlmZmVyZW50IHBhdGhzIHRocm91Z2ggdGhlIG5ldHdvcmsuPGJyPg0KICZuYnNwOyBBbiBvcGVy YXRvciBtYXkgYWxzbyByZXF1ZXN0IGZhdGUtc2hhcmluZyBmb3IgYXNzb2NpYXRlZDxicj4NCiAm bmJzcDsgYmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCjxicj4NCiAmbmJzcDsgVGhlIHJlcXVpcmVt ZW50IGZvciBmYXRlLXNoYXJpbmcgY2F1c2VzIGEgZGlyZWN0IGludGVyYWN0aW9uIGJldHdlZW48 YnI+DQogJm5ic3A7IHRoZSByZWNvdmVyeSBwcm9jZXNzZXMgYWZmZWN0aW5nIHRoZSB0d28gZGly ZWN0aW9ucyBvZiBhbiBMU1AsDQpzbzxicj4NCiAmbmJzcDsgdGhhdCBib3RoIGRpcmVjdGlvbnMg b2YgdGhlIGJpZGlyZWNpdG9uYWwgTFNQIGFyZSByZWNvdmVyZWQgYXQNCnRoZTxicj4NCiAmbmJz cDsgc2FtZSB0aW1lLiBUaGlzIG1vZGUgb2YgcmVjb3ZlcnkgJm5ic3A7aXMgdGVybWVkIGJpZGly ZWN0aW9uYWwNCnJlY292ZXJ5PGJyPg0KICZuYnNwOyBhbmQgbWF5IGJlIHNlZW4gYXMgYSBjb25z ZXF1ZW5jZSBvZiBmYXRlLXNoYXJpbmcuPGJyPg0KRU5EPGJyPg0KPGJyPg0KJmd0OyAyIGluIHNl Y3Rpb24gMiBUZXJtaW5vbG9neSBhbmQgUmVmZXJlbmNlPGJyPg0KJmd0OyAmbmJzcDt0aGVyZSBh cmUgdHdvIHRoZSBzYW1lIGRlZmluaXRpb25zIGZvciBSZXN0b3JhdGlvbjxicj4NCiZndDsgJm5i c3A7bWF5YmUgZGVsZXRlIG9uZSBkZWZpbml0aW9ucyBmb3IgUmVzdG9ydGlvbjs8YnI+DQo8YnI+ DQpHb29kIGNhdGNoLjxicj4NClRoYW5rcy48YnI+DQo8YnI+DQomZ3Q7IDMgdGhlcmUgYXJlIE1Q TFMtVFAgU2VjdGlvbiBsZXZlbCBhbmQgTGluayBsYXllciBjb25jZXB0LiBJIHdhbnQgdG88YnI+ DQomZ3Q7ICZuYnNwO2tub3cgd2hhdCBkaWZmZXJlbmNlIGJldHdlZW4gTVBMUy1UUCBTZWN0aW9u IExldmVsIGFuZCBNUExTLVRQDQpMaW5rPGJyPg0KJmd0OyBsYXllcj88YnI+DQo8YnI+DQpIbW1t Ljxicj4NCkluIGZhY3QsIHdlIG9ubHkgbWVudGlvbiAmcXVvdDtzZWN0aW9uIGxldmVsJnF1b3Q7 IG9uY2UgaW4gdGhlIHdob2xlIGRvY3VtZW50Ljxicj4NClNlY3Rpb24gNC40LjEgaGFzOjxicj4N CiAmbmJzcDsgQSBwcm90ZWN0aW9uIG1lY2hhbmlzbSBtYXkgYmUgcHJvdmlkZWQgYXQgdGhlIE1Q TFMtVFAgbGluayBsYXllcjxicj4NCiAmbmJzcDsgKHdoaWNoIGNvbm5lY3RzIHR3byBNUExTLVRQ IG5vZGVzKS4gJm5ic3A7U3VjaCBhIG1lY2hhbmlzbSBjYW4NCm1ha2UgdXNlIG9mPGJyPg0KICZu YnNwOyB0aGUgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFtSRkM1NTg2XSB0byBzZXQgdXAgaW4tYmFu ZCBjb21tdW5pY2F0aW9uPGJyPg0KICZuYnNwOyBjaGFubmVscyBhdCB0aGUgTVBMUy1UUCBzZWN0 aW9uIGxldmVsLCB0byB1c2UgdGhlc2UgY2hhbm5lbHMgdG88YnI+DQogJm5ic3A7IG1vbml0b3Ig dGhlIGhlYWx0aCBvZiB0aGUgTVBMUy1UUCBsaW5rLCBhbmQgdG8gY29vcmRpbmF0ZSB0aGU8YnI+ DQogJm5ic3A7IHByb3RlY3Rpb24gc3RhdGVzIGJldHdlZW4gdGhlIGVuZHMgb2YgdGhlIE1QTFMt VFAgbGluay48YnI+DQpJZiBJIHJlY2FsbCByaWdodCwgdGhpcyB0ZXh0IHdhcyBnaWZ0ZWQgdG8g dXMgYnkgdGhlIGxhdGVzdCBJVFUtVCBsaWFpc29uLjxicj4NCjxicj4NCkFueXdheSwgSSB0aGlu ayB0aGUgcG9pbnQgaXMgdGhhdCB0aGUgc2VjdGlvbiBsZXZlbCBPQU0gb3BlcmF0ZXMgb24gYSBz aW5nbGUNCjxicj4NCmxpbmsgYmV0d2VlbiBhIHBhaXIgb2YgTVBMUy1UUCByb3V0ZXJzLiBUaGUg cHJvdGVjdGlvbiwgb2YgY291cnNlLCByZXF1aXJlcw0KPGJyPg0KdGhlIHVzZSBvZiBtdWx0aXBs ZSAmcXVvdDtwYXJhbGxlbCZxdW90OyBsaW5rcy4gU28gJnF1b3Q7c2VjdGlvbiBsZXZlbCZxdW90 Ow0KYXBwbGllcyB0byBhIHNpbmdsZSA8YnI+DQpsaW5rLCBhbmQgJnF1b3Q7bGluayBsZXZlbCZx dW90OyBhcHBsaWVzIHRvIGEgc2V0IG9mIGxpbmtzLjxicj4NCjxicj4NCklmIHRoaXMgZGlzdGlu Y3Rpb24gY29udGludWVzIHRvIHdvcnJ5IHlvdSwgbWF5YmUgdGhlIGJlc3QgYXBwcm9hY2ggd291 bGQNCmJlIDxicj4NCnRvIHJlbW92ZSB0aGlzIHJlZmVyZW5jZSB0byAmcXVvdDtzZWN0aW9uIGxl dmVsJnF1b3Q7LiBXaGF0IGRvIHlvdSB0aGluaz88YnI+DQo8YnI+DQomZ3Q7IDQgU2VjdGlvbiA0 LjcuMyBQMk1QIExpbmVhciBQcm90ZWN0aW9uPGJyPg0KJmd0OyAmbmJzcDtBcyB0aGVyZSBpcyBh IHJlcXVpcmVtZW50IG9mIFAyTVAgc3VwcG9ydCAxOm4gcHJvdGVjdGlvbiBpbg0KUkZDIDU2NTQs PGJyPg0KJmd0OyAmbmJzcDtzbyBJIHN1Z2dlc3QgdG8gYWRkIDE6biBwcm90ZWN0aW9uIHNvbHV0 aW9uIGluIHRoaXMgc2VjdGlvbg0Kb3IgZnVydGhlcjxicj4NCiZndDsgJm5ic3A7c3R1ZHkgZm9y IDE6biBwcm90ZWN0aW9uIG9mIHAybXAgOzxicj4NCjxicj4NCllvdSdyZSByaWdodC4gUjY3QiBv ZiBSRkM1NjU0Ljxicj4NCjxicj4NCkkgcHJvcG9zZSB0byBhZGQgYSBuZXcgZmluYWwgcGFyYWdy YXBoIHRvIHNlY3Rpb24gNC43LjMuIGFzIGZvbGxvd3MuPGJyPg0KPGJyPg0KICZuYnNwOyBBIDE6 biBwcm90ZWN0aW9uIHNjaGVtZSBmb3IgUDJNUCB0cmFuc3BvcnQgcGF0aHMgaXMgYWxzbyByZXF1 aXJlZA0KYnk8YnI+DQogJm5ic3A7IFtSRkM1NjU0XS4gU3VjaCBhIG1lY2hhbmlzbSBpcyBmb3Ig ZnV0dXJlIHN0dWR5Ljxicj4NCjxicj4NCk9LPzxicj4NCjxicj4NCk1hbnkgdGhhbmtzLDxicj4N CkFkcmlhbjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9m b250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0 eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZu YnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3Bl cnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJz cDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVu dGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNw O29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5i c3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNw O3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZu YnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5i c3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNw O2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9y Jm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7 YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7 dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlm eSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2Uu Jm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4m bmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJz cDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0027B4F648257711_=-- From davari@broadcom.com Mon Apr 26 10:36:01 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82373A6B01; Mon, 26 Apr 2010 10:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZTuMWxGBzqU; Mon, 26 Apr 2010 10:35:59 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 0BD6A3A6AC3; Mon, 26 Apr 2010 10:35:57 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 26 Apr 2010 10:35:33 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 26 Apr 2010 10:35:33 -0700 From: "Shahram Davari" To: "mpls@ietf.org" , "mpls-tp@ietf.org" Date: Mon, 26 Apr 2010 10:35:32 -0700 Thread-Topic: Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC Thread-Index: AcrlEKMJKW4co4rgQzWwQkyryVUYFgAVcNFg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F03BB408@SJEXCHCCR02.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CB116F31G104468192-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BB408SJEXCHCCR02co_ Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:36:01 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BB408SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I have a comment regarding this draft. This draft states that an MPLS-TP tunnel can be protected in one of its seg= ments without use of a PST. This I assume is something similar to FRR detou= r protection. What is not clear in the draft is how is OAM (and not control= plane) used to detect failure so that an intermediate node can perform pro= tection. As we know an intermediate node can't initiate BFD. Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BB408SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a comment regarding this draft.

 

This draft states that an MPLS-TP tunnel can be protected in= one of its segments without use of a PST. This I assume is something similar to= FRR detour protection. What is not clear in the draft is how is OAM (and not control plane) used to detect failure so that an intermediate node can perf= orm protection. As we know an intermediate node can’t initiate BFD.<= /o:p>

 

Thanks,

Shahram

 

 
--_000_2C2F1EBA8050E74EA81502D5740B4BD693F03BB408SJEXCHCCR02co_-- From nurit.sprecher@nsn.com Mon Apr 26 11:05:06 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517DE28C20D; Mon, 26 Apr 2010 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEurC8ssl4X1; Mon, 26 Apr 2010 11:05:00 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 3B13A28C1FD; Mon, 26 Apr 2010 11:05:00 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3QI4hsR001898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Apr 2010 20:04:43 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3QI4hhp007314; Mon, 26 Apr 2010 20:04:43 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 20:04:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAE56A.F26F41DA" Date: Mon, 26 Apr 2010 20:04:38 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640217BCC6@DEMUEXC014.nsn-intra.net> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F03BB408@SJEXCHCCR02.corp.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC thread-index: AcrlEKMJKW4co4rgQzWwQkyryVUYFgAVcNFgAAAz9YA= References: <2C2F1EBA8050E74EA81502D5740B4BD693F03BB408@SJEXCHCCR02.corp.ad.broadcom.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Shahram Davari" , , X-OriginalArrivalTime: 26 Apr 2010 18:04:43.0085 (UTC) FILETIME=[F279E7D0:01CAE56A] Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" Subject: Re: [mpls] [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:05:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAE56A.F26F41DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shaharm, I cannot recall that we used the statement exactly as appears below, but in principle this is correct. RFC 4873 provides a solution for segment protection, without using a PST.=20 The draft is a framework and it introduces various elements of control to trigger the recovery action (e.g. OAM signaling, network failure detection, control-plane signaling, administrative commands, etc.), different levels of recovery, different mechanisms, etc.=20 It is correct that in order to monitor a segment of a path using OAM we need a PST, because OAM messages may be initiated only by MEPs which reside at the endpoints of a path. But there other elements of controls that can be used as well and the framework introduce them as well. RFC 4873 for example makes use of the control-plane signaling to trigger a recovery.=20 Best regards, Nurit =20 P.S. please note that FRR is limited in its applicability as it handles uni-directional protection switching only! =20 =20 From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Shahram Davari Sent: Monday, April 26, 2010 8:36 PM To: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC =20 Hi, =20 I have a comment regarding this draft. =20 This draft states that an MPLS-TP tunnel can be protected in one of its segments without use of a PST. This I assume is something similar to FRR detour protection. What is not clear in the draft is how is OAM (and not control plane) used to detect failure so that an intermediate node can perform protection. As we know an intermediate node can't initiate BFD. =20 Thanks, Shahram =20 =20 ------_=_NextPart_001_01CAE56A.F26F41DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shaharm,

I cannot recall that we used the statement exactly as = appears below, but in principle this is correct.  RFC 4873 = provides a solution for segment protection, without using a = PST.

The draft is a framework and it introduces various = elements of control to trigger the recovery action (e.g. OAM signaling, network = failure detection, control-plane signaling, administrative commands, etc.), = different levels of recovery, different mechanisms, etc.

It is correct that in order to monitor a segment of a = path using OAM we need a PST, because OAM messages may be initiated only = by MEPs which reside at the endpoints of a path. But there = other elements of controls that can be used as well and the framework = introduce them as well. RFC 4873 for example makes use of the control-plane signaling = to trigger a recovery.

Best regards,

Nurit

 

P.S. please note that FRR is limited in its applicability = as it handles uni-directional protection switching only!

 

=

 

From:= mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of ext Shahram Davari
Sent: Monday, April 26, 2010 8:36 PM
To: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability = Framework) to Informational RFC

 

Hi,

 

I have a comment regarding this = draft.

 

This draft states that an MPLS-TP tunnel can be protected = in one of its segments without use of a PST. This I assume is something similar = to FRR detour protection. What is not clear in the draft is how is OAM (and not control plane) used to detect failure so that an intermediate node can = perform protection. As we know an intermediate node can’t initiate = BFD.

 

Thanks,

Shahram

 

 
------_=_NextPart_001_01CAE56A.F26F41DA-- From wwwrun@core3.amsl.com Tue Apr 27 09:35:39 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 345B93A679C; Tue, 27 Apr 2010 09:35:38 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100427163539.345B93A679C@core3.amsl.com> Date: Tue, 27 Apr 2010 09:35:39 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, malcolm.betts@zte.com.cn, elisa.bellagamba@ericsson.com, dward@juniper.net, yoichi.maeda@ntt-at.co.jp, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, loa.andersson@ericsson.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, hklam@alcatel-lucent.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "Liaison on Disposition of Disposition of Comments in Liaison 160 (ref #019.03)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 16:35:39 -0000 Title: Liaison on Disposition of Disposition of Comments in Liaison 160 (ref #019.03) Submission Date: 2010-04-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=886 From: Loa Andersson(IETF MPLS WG) To: SG15, Q9, Q10, Q12, and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn hklam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int dward@juniper.net adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com elisa.bellagamba@ericsson.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For information Body: see attachment Attachment(s): Disposition of Comments in Liaison 160 (https://datatracker.ietf.org/documents/LIAISON/file1009.doc) From swallow@cisco.com Tue Apr 27 10:39:07 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCD53A6922; Tue, 27 Apr 2010 10:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.801 X-Spam-Level: X-Spam-Status: No, score=-7.801 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehcyW5tQmn4O; Tue, 27 Apr 2010 10:39:06 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BEAA03A684D; Tue, 27 Apr 2010 10:39:05 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIq+1ktAZnwM/2dsb2JhbACbdlhxpzCaHgKFDAQ X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105732502" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2010 17:38:49 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3RHcnot009702; Tue, 27 Apr 2010 17:38:49 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 12:38:49 -0500 Received: from 10.98.32.165 ([10.98.32.165]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 17:38:48 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Apr 2010 13:38:47 -0400 From: George Swallow To: Diego Caviglia , Attila Takacs , Loa Andersson , , , , Message-ID: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAAAvpBAE/7lf1w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 27 Apr 2010 17:38:49.0235 (UTC) FILETIME=[7EB8F630:01CAE630] Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:39:08 -0000 Diego - On 4/2/10 2:58 AM, "Diego Caviglia" wrote: > Hi, > Some more comments from me more ore less on the same route as Attila. >=20 > =B7 Section 1.1 >=20 > o PSC is also used as Packet Switching Capable for OSPF-TE The term is now not used in the document, so I will take it out of the list= . > =B7 Section 2 >=20 > o Tunnel I think that here a reference to the actual identifier of= the > quoted entity could help I mean a reference to Section 5 I'm going to rewrite the note. Maybe able to work in the forward reference you propose if I can make the text flow. > =B7 Section 4 >=20 > o would be good to have a short explanation why numbered interface= s are > not in the scope of MPLS-TP I'm not trying to rule them out. Right now I'm trying to get to something that is useable in an IP-less environment as well as an IP environment. We have yet to start serious work on the signaling. We can add these if we need them then. > =B7 Section 5 >=20 > o Even if section 2 points to 3209 than the Tunnel Identifier chos= en is > different from what is defined in 3209, Extended Tunnel ID field is missi= ng > while there are two different Tunnel Num that is not clear how they works= . I > think here the same convention used in 3209 and in GMPLS signaling would = be > good to avoid to have two or more Tunnel identifiers for MPLS-TP networks > using GMPLS.=20 In section 5.3 I show the mapping to GMPLS. The extended tunnel-id gets filled in with the destination address. You will note that the destination tunnel number doesn't show up at all. What I have in mind is that the dest tunnel number would be carried in a new object with the semantic that this tunnel "connects-to" a particular tunnel number at the destination. The object could be filled in by the source (in which case the destination woul= d verify and accept or reject) or left empty (in which case the destination would return its chosen value in the RESV). > o Why MPLS-TP tunnels must be associated to a LIH? Why MPLS-TP tu= nnels > need to be configured as FA? Does that imply that in case OSPF-TE is used= it > must advertise MPLS-TP tunnels as FA each time a new tunnel is created? The IF-ID names the access point to the tunnel. PWs and LSP can be routed through the interface (AP if you prefer). They do not need to be advertise= d in OSPF. =20 > =B7 Section 5.2 I think that sentence "The format of a Tunnel_ID is= :" > should be "The format of a LSP_ID is:" same for the globally unique case. Yes. Typo - thanks for pointing it out. > =B7 Section 5.3 addresses some of my above concern about usage of t= unnel > and lsp identifiers even if is not a 1:1 mapping given that the Dst-Tunne= l_Num > is not mapped in GMPLS Tunnel ID Addressed above. BR ...George > =B7 Remaining of the docs is still WP > =20 >=20 > BR >=20 > Diego >=20 >=20 > line >=20 >=20 >=20 > DIEGO CAVIGLIA=20 > Strategic Product Manager >=20 >=20 > Ericsson Italy > Product Line PAIB > Via A. Negrone 1/A > Genoa, Italy > Phone +390106003736 > Mobile +393357181762 > diego.caviglia@ericsson.com > www.ericsson.com=20 >=20 >=20 >=20 > Ericsson >=20 >=20 >=20 >=20 >=20 >=20 > This Communication is Confidential. We only send and receive email on the > basis of the term set out at www.ericsson.com/email_disclaimer >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of A= ttila > Takacs > Sent: venerd=EC 2 aprile 2010 8.54 > To: Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; > ccamp@ietf.org > Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-0= 1 >=20 > Hi Matthew and George, >=20 > Please find some comments/questions below. >=20 > -In Section 5.1 you have: >=20 > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num >=20 > What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num? > Is it there to support associated unidirectional Tunnels/LSPs? If so it s= hould > be called out in the text. >=20 > Same applies to the globally unique case. >=20 > -In Section 5.2 you simply append one LSP_Num to the above. This is a bit > confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums would= be > needed too, wouldn't it? >=20 > -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tunnel_Nu= m. So > this means that we may have two different tunnels identified with > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this intenti= onal, > e.g., the associated unidirectional case? This should be clarified. >=20 >=20 > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. >=20 >=20 > -Section 7 has a note saying to be aligned with the OAM fwk, is this stil= l to > be done? >=20 > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel l= evel > and not at the LSP level? > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? >=20 > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. >=20 > -Section 8 talks about open issues? When will these be addressed? >=20 > Thanks, > Attila=20 >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Loa Andersson >> Sent: Friday, March 12, 2010 12:33 AM >> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >>=20 >> All, >>=20 >> this is to start an MPLS working group last call on >> draft-ietf-mpls-tp-identifiers-01 >>=20 >> There is a discussion on the OAM model for MS-PWs where we >> haven't been able to come to conclusion. Once we reach >> agreement the document will be updated. Comments in this area >> are welcome during the working group last call. >>=20 >>=20 >> Please send your comments to the mpls-tp@ietf.org mailing list. >>=20 >> The working group last ends eob April 2nd. >>=20 >> /Loa >>=20 >> -- >>=20 >> Loa Andersson >>=20 >> Sr Strategy and Standards Manager >> Ericsson /// >> phone: +46 10 717 52 13 >> +46 767 72 92 13 >>=20 >> email: loa.andersson@ericsson.com >> loa@pi.nu >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From swallow@cisco.com Tue Apr 27 10:51:28 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370DD28C138; Tue, 27 Apr 2010 10:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVOcQDPKBYiE; Tue, 27 Apr 2010 10:51:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B22E33A69AC; Tue, 27 Apr 2010 10:51:23 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOLA1kutJV2a/2dsb2JhbACcTnGnHJofAoUMBA X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105598920" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2010 17:51:11 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o3RHpAAK022590; Tue, 27 Apr 2010 17:51:10 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 12:51:10 -0500 Received: from 10.98.32.165 ([10.98.32.165]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 17:51:10 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Apr 2010 13:51:08 -0400 From: George Swallow To: Sriganesh Kini , Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Message-ID: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBc0WnZb3W+AQWTpuJTuXgXymZDgQ8Q2QwBPN49pE= In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F52E4835FCC@EUSAACMS0703.eamcs.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2010 17:51:10.0575 (UTC) FILETIME=[389877F0:01CAE632] Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:51:28 -0000 Sri - See inline: On 4/2/10 9:11 AM, "Sriganesh Kini" wrote: > Hi, > > 1) section 5.1 - "At each endpoint a tunnel is uniquely identified by the > Source Node_ID and a locally assigned tunnel number." > a) Should "Source" be replaced by the "endpoint's" since later the > "Dst-Node_ID" is used? Agree - will make change. > b) Useful to clarify the scope of "uniquely identified" before this > statement. Will do my best. > C) Should there be a similar identifier at each intermediate node besides > the endpoints? The midpoints need to have this (not a similar) identifier too. Either through configuration or through signaling. > 2) Section 5.2 - Does any LSR own the "LSP_num" space? If so pls state that. In the provisioned case, it would be the provisioning system. In the signaled case, the end that initiates the signaling. ...George > Thanks > > - Sri > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Loa Andersson >> Sent: Thursday, March 11, 2010 3:33 PM >> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >> >> All, >> >> this is to start an MPLS working group last call on >> draft-ietf-mpls-tp-identifiers-01 >> >> There is a discussion on the OAM model for MS-PWs where we >> haven't been able to come to conclusion. Once we reach >> agreement the document will be updated. Comments in this area >> are welcome during the working group last call. >> >> >> Please send your comments to the mpls-tp@ietf.org mailing list. >> >> The working group last ends eob April 2nd. >> >> /Loa >> >> -- >> >> Loa Andersson >> >> Sr Strategy and Standards Manager >> Ericsson /// >> phone: +46 10 717 52 13 >> +46 767 72 92 13 >> >> email: loa.andersson@ericsson.com >> loa@pi.nu >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From lucyyong@huawei.com Tue Apr 27 15:37:49 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB1A3A67E6; Tue, 27 Apr 2010 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.219 X-Spam-Level: * X-Spam-Status: No, score=1.219 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF0TBIyS5mqu; Tue, 27 Apr 2010 15:37:40 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9BD1B3A67D2; Tue, 27 Apr 2010 15:37:39 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1K002XR4642T@szxga04-in.huawei.com>; Wed, 28 Apr 2010 06:37:16 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1K0045W46445@szxga04-in.huawei.com>; Wed, 28 Apr 2010 06:37:16 +0800 (CST) Received: from y736742 ([10.124.12.148]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1K00H05461FO@szxml06-in.huawei.com>; Wed, 28 Apr 2010 06:37:16 +0800 (CST) Date: Tue, 27 Apr 2010 17:37:13 -0500 From: Yong Lucy To: 'pwe3' , mpls@ietf.org Message-id: <00ab01cae65a$2ff12b60$940c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_wy9JhKlkyBNPP+t6O1jFGw)" Thread-index: AcrmWi5eElLekKb4TiG87Xlhyj4GaQ== Subject: [mpls] Large FLow Classificaiton in Flow Aware Transport X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 22:37:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wy9JhKlkyBNPP+t6O1jFGw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I recap the comments raised during IETF77 meeting. Some are from the PWE3 meeting and some from offline discussions. Hope this gives some clarification and bring up further mailing discussion. The draft proposal (draft-yong-pwe3-enhanced-ecmp-lfat-01) is to use one of the TC bits in the flow label to indicate large flow. TC bits in flow label described in FAT-PW are not used and are not interpreted by LSR. Comments and Responses: 1) No use for the proposal. would need to update all equipment to get this to work. A while ago we agreed to not standardize ECMP process. Lucy: Some carriers see the value of it. There is no need to update all equipment to get this work. The backward compatibility is supported as described in section 6. Partially upgrading can improve some segments while keeping other segments remain the same. The intention of the draft is not for standardizing ECMP process. It is about standardizing large flow classification indication in PSN. The draft layout may lead this confusion. We will modify the draft and move enhanced ECMP process description to appendix as one implementation example to use large flow classification. We will change the draft title to "large flow classification in flow aware transport over PSN" and upload soon. 2) would need to go through MPLS WG for issue on standardizing ECMP. Label stack is always MPLS label stack so MPLS WG would need to OK change of TC semantics. Needs a co-review in MPLS WG and they must approve. Lucy: The draft is not for standardizing ECMP. (sorry for the confusion). The draft does not change the semantics of a label stack entry defined by RFC3032 because the flow label is never on the top of label stack. As FAT-PW draft indicates that the interpretation of TC bits in the flow label by LSR is undefined. This draft proposes one definition. 3) If you can get MPLS WG to agree, one of the issues is that you are marking at a PE where the PE may or may not know what is or isn't a big flow. Limitations on PEs ability to determine what a big flow is. Would need to tell easily and ubiquitously what a big flow is. Lucy: In our proposal, large flows in this context are the top rate ranked flows. It is relevant to other flows not the link capacity. Enhanced ECMP process just needs a small set of large flows for load balancing, therefore, it can pick by statistics, i.e. not necessary all the large flows. The method works well even some large flows placed by hashing function. The backward compatibility in the draft would deal with this. 4) we haven't standardized anything on ECMP. Many will look at bottom of stack to look at IP address or anything else to hash on. If I'm a PE router with lots of L3VPN traffic and some PWs, how do I know if this is a flow label or VPN label. Lucy: This is not for ECMP standardization. We propose one method to differentiate the flow label from IP packet, PW label, and LSP label at the bottom of label stack. This is: check the first nibble to separate IP and MPLS packets; for MPLS packets, use TTL value (=0) to check the flow label packets. 5) this is addressing an important issue. Simulations showed a lot of traffic and the flows are large enough. Cases in well engineered network where situation is much worse than shown. Drafts have been submitting in past that gained no traction. To use a method other than just hashing, but may be ways to do this without changing label or MPLS. Lucy: The simulation use Internet traffic pattern. For carrier network, it has a lot of L2VPN traffic carried as single flow, so the situation is worse. We work on additional simulation to include such type of traffic. It confirms the statement. As Internet traffic grow with higher and higher bit rate flows, the problem will become more and more severe. We need to aim on this real problem. 6) there was a proposal to solve this 10 years ago with no protocol changes. This is not needed. Lucy: Need clarification which proposal refers to. If it is OMP, the draft proposes the different method from OMP. OMP suggest using routing protocol to advertise individual ECMP path TE information in the network. The draft is about large flow classification indication so LSR can use a set of large flows in performing load balance over ECMP paths effectively. 7) Changes too much about MPLS processing Lucy: It is not that additional process. Gaining is obvious too. 8) did the simulations deal with coming and going of flows? How to address flow fluctuation? Lucy: we are working on additional simulations. That will include flow coming and going situation and include much higher bit rate flows, and a "permanent flow" whose rate may change over time to make it as small flow at a time or a large flow at another time. The latter case likes a VPWS as a flow. Be glad to show some simulation result to the group. 9) Signaling can be used for this, why using marking? Lucy: today, signaling a PW is used per a service basis such as VPWS or VPLS. But one VPWS or VPLS may contain many flows, the draft address this situation. It is hard for carrier to signal individual large flow within VPLS over PSN networks. 10) If there is incentive to enhanced ECMP, why not do large flow recognition at local LSR for the purpose? PE based large flow recognition and marking do not apply well at individual LSR. Lucy: High bit rate flow is relevant to other flows. Operator can set large flow criteria. Having each LSR performs larger flow recognition add complex to each LSR and may impact the service performance. Large flow classification is easier, we think. Today, DiffServ enables the network to perform different service treatments. Large flow classification enables network to perform different flow treatments over ECMP operation. Comments and suggestion are welcome. Regards, Lucy --Boundary_(ID_wy9JhKlkyBNPP+t6O1jFGw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT 
Hi,
 
I recap the comments raised during IETF77 meeting. Some are from the PWE3 meeting and some from offline discussions. Hope this gives some clarification and bring up further mailing discussion.
 
The draft proposal (draft-yong-pwe3-enhanced-ecmp-lfat-01) is to use one of the TC bits in the flow label to indicate large flow. TC bits in flow label described in FAT-PW are not used and are not interpreted by LSR. 
 
Comments and Responses:
          
1) No use for the proposal. would need to update all equipment to get this to work.  A while ago we agreed to not standardize ECMP process. 
 
Lucy: Some carriers see the value of it. There is no need to update all equipment to get this work. The backward compatibility is supported as described in section 6. Partially upgrading can improve some segments while keeping other segments remain the same. The intention of the draft is not for standardizing ECMP process. It is about standardizing large flow classification indication in PSN. The draft layout may lead this confusion. We will modify the draft and move enhanced ECMP process description to appendix as one implementation example to use large flow classification. We will change the draft title to “large flow classification in flow aware transport over PSN” and upload soon.
 
2) would need to go through MPLS WG for issue on standardizing ECMP. Label stack is always MPLS label stack so MPLS WG would need to OK change of TC semantics.  Needs a co-review in MPLS WG and they must approve.
 
Lucy: The draft is not for standardizing ECMP. (sorry for the confusion). The draft does not change the semantics of a label stack entry defined by RFC3032 because the flow label is never on the top of label stack. As FAT-PW draft indicates that the interpretation of TC bits in the flow label by LSR is undefined. This draft proposes one definition.
 
3) If you can get MPLS WG to agree, one of the issues is that you are marking at a PE where the PE may or may not know what is or isn't a big flow.  Limitations on PEs ability to determine what a big flow is. Would need to tell easily and ubiquitously what a big flow is.
 
Lucy: In our proposal, large flows in this context are the top rate ranked flows. It is relevant to other flows not the link capacity. Enhanced ECMP process just needs a small set of large flows for load balancing, therefore, it can pick by statistics, i.e. not necessary all the large flows. The method works well even some large flows placed by hashing function. The backward compatibility in the draft would deal with this.
          
4) we haven't standardized anything on ECMP. Many will look at bottom of stack to look at IP address or anything else to hash on. If I'm a PE router with lots of L3VPN traffic and some PWs, how do I know if this is a flow label or VPN label.
 
Lucy: This is not for ECMP standardization. We propose one method to differentiate the flow label from IP packet, PW label, and LSP label at the bottom of label stack. This is: check the first nibble to separate IP and MPLS packets; for MPLS packets, use TTL value (=0) to check the flow label packets.  
 
5) this is addressing an important issue.  Simulations showed a lot of traffic and the flows are large enough.  Cases in well engineered network where situation is much worse than shown.  Drafts have been submitting in past that gained no traction.  To use a method other than just hashing, but may be ways to do this without changing label or MPLS.
 
Lucy: The simulation use Internet traffic pattern. For carrier network, it has a lot of L2VPN traffic carried as single flow, so the situation is worse. We work on additional simulation to include such type of traffic. It confirms the statement. As Internet traffic grow with higher and higher bit rate flows, the problem will become more and more severe. We need to aim on this real problem.
 
6) there was a proposal to solve this 10 years ago with no protocol changes.  This is not needed.
 
Lucy: Need clarification which proposal refers to. If it is OMP, the draft proposes the different method from OMP. OMP suggest using routing protocol to advertise individual ECMP path TE information in the network. The draft is about large flow classification indication so LSR can use a set of large flows in performing load balance over ECMP paths effectively.
 
7) Changes too much about MPLS processing
 
Lucy: It is not that additional process. Gaining is obvious too. 
 
8) did the simulations deal with coming and going of flows? How to address flow fluctuation?
 
Lucy: we are working on additional simulations. That will include flow coming and going situation and include much higher bit rate flows, and a “permanent flow” whose rate may change over time to make it as small flow at a time or a large flow at another time. The latter case likes a VPWS as a flow. Be glad to show some simulation result to the group.
 
9) Signaling can be used for this, why using marking?
 
Lucy: today, signaling a PW is used per a service basis such as VPWS or VPLS. But one VPWS or VPLS may contain many flows, the draft address this situation. It is hard for carrier to signal individual large flow within VPLS over PSN networks.  
 
10) If there is incentive to enhanced ECMP, why not do large flow recognition at local LSR for the purpose? PE based large flow recognition and marking do not apply well at individual LSR.
 
Lucy: High bit rate flow is relevant to other flows. Operator can set large flow criteria. Having each LSR performs larger flow recognition add complex to each LSR and may impact the service performance. Large flow classification is easier, we think. Today, DiffServ enables the network to perform different service treatments. Large flow classification enables network to perform different flow treatments over ECMP operation.
 
Comments and suggestion are welcome.
 
 
Regards,
Lucy
 
 
          
 

 

 

--Boundary_(ID_wy9JhKlkyBNPP+t6O1jFGw)-- From dai.xuehui@zte.com.cn Wed Apr 28 01:49:33 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9103A67B2; Wed, 28 Apr 2010 01:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.439 X-Spam-Level: X-Spam-Status: No, score=-97.439 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MISSING_SUBJECT=1.762, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COWSPUJmd2-J; Wed, 28 Apr 2010 01:49:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C6C253A65A6; Wed, 28 Apr 2010 01:49:31 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887813339890; Wed, 28 Apr 2010 16:45:08 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.3729454058; Wed, 28 Apr 2010 16:49:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3S8keeZ029300; Wed, 28 Apr 2010 16:49:03 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn) MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:53:50, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:53:50, Serialize complete at 2010-04-28 16:53:50, S/MIME Sign failed at 2010-04-28 16:53:51: =?GB2312?B?1dKyu7W9seDC68Pc1L8=?=, S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:54:16, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:54:16, Serialize complete at 2010-04-28 16:54:16, S/MIME Sign failed at 2010-04-28 16:54:16: =?GB2312?B?1dKyu7W9seDC68Pc1L8=?=, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:48:53, Serialize complete at 2010-04-28 16:48:53 To: rahul@juniper.net, kireeti@juniper.net, swallow@cisco.com X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: dai.xuehui@zte.com.cn Date: Wed, 28 Apr 2010 16:46:50 +0800 Content-Type: multipart/alternative; boundary="=_alternative 0030EA2148257713_=" X-MAIL: mse2.zte.com.cn o3S8keeZ029300 Cc: mpls@ietf.org, "rtg-bfd@ietf.org" Subject: [mpls] (no subject) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 08:49:33 -0000 This is a multipart message in MIME format. --=_alternative 0030EA2148257713_= Content-Type: text/plain; charset="US-ASCII" Hi all, In RFC4379, Section 4.3 - "Sending an MPLS Echo Request", The Router Alert option MUST be set in the IP header. In draft-ietf-bfd-mpls-07, section-7 "Encapsulation", I can *NOT* find anything about "the Router Alert Option". IMO, the MPLS-BFD refer to RFC4379; why are they *NOT* the same on the operation of "Router Alert Option"? Best Regards. --=_alternative 0030EA2148257713_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj5IaSBhbGwsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJAy87M5SI+SW4gUkZDNDM3OSwgU2VjdGlvbiA0LjMgLSAmcXVv dDtTZW5kaW5nDQphbiBNUExTIEVjaG8gUmVxdWVzdCZxdW90OywgVGhlIFJvdXRlciBBbGVydCBv cHRpb24gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iQMvOzOUiPk1VU1Q8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj4NCmJlIHNldCBpbiB0aGUgSVAgaGVhZGVyLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQMvOzOUiPkluIGRyYWZ0LWlldGYt YmZkLW1wbHMtMDcsIHNlY3Rpb24tNyAmcXVvdDtFbmNhcHN1bGF0aW9uJnF1b3Q7LA0KSSBjYW4g Kk5PVCogZmluZCBhbnl0aGluZyBhYm91dCAmcXVvdDt0aGUgUm91dGVyIEFsZXJ0IE9wdGlvbiZx dW90Oy48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj5JTU8sIHRo ZSBNUExTLUJGRCByZWZlciB0byBSRkM0Mzc5OyB3aHkNCmFyZSB0aGV5ICZuYnNwOypOT1QqIHRo ZSBzYW1lIG9uIHRoZSBvcGVyYXRpb24gb2YgJnF1b3Q7Um91dGVyIEFsZXJ0IE9wdGlvbiZxdW90 Oz8NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+QmVzdCBSZWdhcmRzLjxicj4NCjwvZm9udD4NCg== --=_alternative 0030EA2148257713_=-- From dai.xuehui@zte.com.cn Wed Apr 28 01:51:08 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D088C3A65A6; Wed, 28 Apr 2010 01:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.32 X-Spam-Level: X-Spam-Status: No, score=-98.32 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcBp-YpZA-VX; Wed, 28 Apr 2010 01:51:08 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 7C0233A68E4; Wed, 28 Apr 2010 01:51:07 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887813339890; Wed, 28 Apr 2010 16:46:19 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.3729454058; Wed, 28 Apr 2010 16:50:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3S8oOVs037057; Wed, 28 Apr 2010 16:50:26 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn) To: rahul@juniper.net, kireeti@juniper.net, swallow@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: dai.xuehui@zte.com.cn Date: Wed, 28 Apr 2010 16:48:14 +0800 X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:55:40, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:55:40, Serialize complete at 2010-04-28 16:55:40, S/MIME Sign failed at 2010-04-28 16:55:40: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-28 16:50:16, Serialize complete at 2010-04-28 16:50:16 Content-Type: multipart/alternative; boundary="=_alternative 00310AE148257713_=" X-MAIL: mse2.zte.com.cn o3S8oOVs037057 Cc: mpls@ietf.org, "rtg-bfd@ietf.org" Subject: [mpls] doubt about "IP Router Alert Option" between MPLS-BFD & LSP-Ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 08:51:08 -0000 This is a multipart message in MIME format. --=_alternative 00310AE148257713_= Content-Type: text/plain; charset="US-ASCII" Hi all, In RFC4379, Section 4.3 - "Sending an MPLS Echo Request", The Router Alert option MUST be set in the IP header. In draft-ietf-bfd-mpls-07, section-7 "Encapsulation", I can *NOT* find anything about "the Router Alert Option". IMO, the MPLS-BFD refer to RFC4379; why are they *NOT* the same on the operation of "Router Alert Option"? BR. Xuehui --=_alternative 00310AE148257713_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj5IaSBhbGwsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJAy87M5SI+SW4gUkZDNDM3OSwgU2VjdGlvbiA0LjMgLSAmcXVv dDtTZW5kaW5nDQphbiBNUExTIEVjaG8gUmVxdWVzdCZxdW90OywgVGhlIFJvdXRlciBBbGVydCBv cHRpb24gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iQMvOzOUiPk1VU1Q8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj4NCmJlIHNldCBpbiB0aGUgSVAgaGVhZGVyLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQMvOzOUiPkluIGRyYWZ0LWlldGYt YmZkLW1wbHMtMDcsIHNlY3Rpb24tNyAmcXVvdDtFbmNhcHN1bGF0aW9uJnF1b3Q7LA0KSSBjYW4g Kk5PVCogZmluZCBhbnl0aGluZyBhYm91dCAmcXVvdDt0aGUgUm91dGVyIEFsZXJ0IE9wdGlvbiZx dW90Oy48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkDLzszlIj5JTU8sIHRo ZSBNUExTLUJGRCByZWZlciB0byBSRkM0Mzc5OyB3aHkNCmFyZSB0aGV5ICZuYnNwOypOT1QqIHRo ZSBzYW1lIG9uIHRoZSBvcGVyYXRpb24gb2YgJnF1b3Q7Um91dGVyIEFsZXJ0IE9wdGlvbiZxdW90 Oz88L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkJSLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WHVlaHVpPGJy Pg0KPC9mb250Pg0K --=_alternative 00310AE148257713_=-- From swallow@cisco.com Thu Apr 29 07:19:05 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB043A6B0A; Thu, 29 Apr 2010 07:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.226 X-Spam-Level: X-Spam-Status: No, score=-8.226 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJwmjgn6ploq; Thu, 29 Apr 2010 07:19:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 817833A6C06; Thu, 29 Apr 2010 07:14:50 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAMUx2UutJV2Z/2dsb2JhbACBP5pyXXGkNpoIAoUOBA X-IronPort-AV: E=Sophos;i="4.52,295,1270425600"; d="scan'208,217";a="106314741" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2010 14:14:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o3TEELY1018355; Thu, 29 Apr 2010 14:14:22 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 09:14:03 -0500 Received: from 10.98.32.165 ([10.98.32.165]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Apr 2010 14:14:02 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 29 Apr 2010 10:14:01 -0400 From: George Swallow To: Shahram Davari , Loa Andersson , , , , Message-ID: Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczT1LsEVDiSwTX2v9QSMrvpjyAAA7NaQCYvTuPM= In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68171AE5BF5@SJEXCHCCR02.corp.ad.broadcom.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3355380842_133468876" X-OriginalArrivalTime: 29 Apr 2010 14:14:03.0322 (UTC) FILETIME=[3892E9A0:01CAE7A6] Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:19:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3355380842_133468876 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Shahram - See inline On 3/11/10 7:27 PM, "Shahram Davari" wrote: > Hi, >=20 > Couple of comments: >=20 > 1) Why the Interface_ID is 32-bit while the Tunnel_ID is 16-bit? Do we ne= ed to > support more interfaces than tunnels? GS: Planning to change scope of Tunnel_ID. Just needs to be unique in the context of the Session Object as defined in 3209 with source address used a= s the extended tunnel-id > 2) The draft defines the Global_Tunnel_ID as: > Src-Global_ID::Src-Node_ID::Src-Tunnel_Num:: > Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num >=20 > This seems to define a bidirectional tunnel. Is that the intent? If so pl= ease > clarify. If not then why Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num is ne= eded? >=20 GS: The scope is bidirectional. But I suppose it can be applied to unidirectional as well. I still don=B9t understand the requirement for unidirectional =AD seems to be that bidirectional with 0 data-bandwidth in th= e reverse direction would do better as you would have a return path for OAM and DCC etc. >=20 > 3) Is section 5.2 talking about unidirectional LSP or bidirectional LSP? >=20 GS: Ditto >=20 > 4) Section 7.1.2.1 says: > Since a MEG pertains to a single MPLS-TP Tunnel, IP compatible ME= G_IDs > for MPLS-TP Tunnels are simply the corresponding Tunnel_IDs >=20 > Assuming the Tunnel_ID is a unidirectional ID, then this statement implie= s > that for the reverse direction a different MEG_ID is required. Is that th= e > intent? If so why? >=20 GS: Not unidirectional! >=20 > 5) Why are drafts part of the normative references? >=20 Cut and paste error actually! Thanks for pointing it out! >=20 > 6) Will section 8 (open issues) be removed before publishing? This sectio= n > implies that the MEP and MIP definition is not yet aligned with framework= ? >=20 GS: Yes >=20 > Regards, > Shahram >=20 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa > Andersson > Sent: Thursday, March 11, 2010 3:33 PM > To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >=20 > All, >=20 > this is to start an MPLS working group last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > There is a discussion on the OAM model for MS-PWs where we haven't been > able to come to conclusion. Once we reach agreement the document will > be updated. Comments in this area are welcome during the working group > last call. >=20 >=20 > Please send your comments to the mpls-tp@ietf.org mailing list. >=20 > The working group last ends eob April 2nd. >=20 > /Loa >=20 > -- >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager > Ericsson /// > phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 > email: loa.andersson@ericsson.com > loa@pi.nu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 --B_3355380842_133468876 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:14pt'>Shahram= -<BR> <BR> See inline<BR> <BR> <BR> On 3/11/10 7:27 PM, "Shahram Davari" <<a href=3D"davari@broadcom= .com">davari@broadcom.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'>Hi,<BR> <BR> Couple of comments:<BR> <BR> 1) Why the Interface_ID is 32-bit while the Tunnel_ID is 16-bit? Do we need= to support more interfaces than tunnels?<BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'><BR> GS:  Planning to change scope of Tunnel_ID.  Just needs to be uni= que in the context of the Session Object as defined in 3209 with source addr= ess used as the extended tunnel-id<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'>2) The draft defines the Global_Tunnel_ID as:<BR>       Src-Global_ID::Src-Node_ID::Src-Tunnel_= Num:: Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num<BR> <BR> This seems to define a bidirectional tunnel. Is that the intent? If so plea= se clarify. If not then why Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num is ne= eded?<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>GS: The scope is bidirectional.  But I suppose it c= an be applied to unidirectional as well.  I still don’t understan= d the requirement for unidirectional – seems to be that bidirectional = with 0 data-bandwidth in the reverse direction would do better as you would = have a return path for OAM and DCC etc.<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> 3) Is section 5.2 talking about unidirectional LSP or bidirectional LSP?<BR= > <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>GS: Ditto<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> 4) Section 7.1.2.1 says:<BR>         Since a MEG pertains to a s= ingle MPLS-TP Tunnel, IP compatible MEG_IDs for MPLS-TP Tunnels are simply t= he corresponding Tunnel_IDs<BR> <BR> Assuming the Tunnel_ID is a unidirectional ID, then this statement implies = that for the reverse direction a different MEG_ID is required. Is that the i= ntent? If so why?<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>GS: Not unidirectional!<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> 5) Why are drafts part of the normative references?<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>Cut and paste error actually!  Thanks for pointing = it out!<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> 6) Will section 8 (open issues) be removed before publishing? This section = implies that the MEP and MIP definition is not yet aligned with framework?<B= R> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>GS: Yes<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> Regards,<BR> Shahram<BR> <BR> <BR> <BR> -----Original Message-----<BR> From: <a href=3D"mpls-bounces@ietf.org">mpls-bounces@ietf.org</a> [<a href=3D"m= ailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org</a>] On Behalf Of = Loa Andersson<BR> Sent: Thursday, March 11, 2010 3:33 PM<BR> To: <a href=3D"mpls@ietf.org">mpls@ietf.org</a>; <a href=3D"mpls-tp@ietf.org">m= pls-tp@ietf.org</a>; <a href=3D"pwe3@ietf.org">pwe3@ietf.org</a>; <a href=3D"cca= mp@ietf.org">ccamp@ietf.org</a><BR> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01<BR> <BR> All,<BR> <BR> this is to start an MPLS working group last call on<BR> draft-ietf-mpls-tp-identifiers-01<BR> <BR> There is a discussion on the OAM model for MS-PWs where we haven't been<BR> able to come to conclusion. Once we reach agreement the document will<BR> be updated. Comments in this area are welcome during the working group<BR> last call.<BR> <BR> <BR> Please send your comments to the <a href=3D"mpls-tp@ietf.org">mpls-tp@ietf.or= g</a> mailing list.<BR> <BR> The working group last ends eob April 2nd.<BR> <BR> /Loa<BR> <BR> --<BR> <BR> Loa Andersson<BR> <BR> Sr Strategy and Standards Manager<BR> Ericsson ///<BR>    phone:  +46 10 717 52 13<BR>            +46 767 7= 2 92 13<BR> <BR>    email:  <a href=3D"loa.andersson@ericsson.com">loa.and= ersson@ericsson.com</a><BR>            <a href=3D"= loa@pi.nu">loa@pi.nu</a><BR> <BR> <BR> <BR> <BR> _______________________________________________<BR> mpls mailing list<BR> <a href=3D"mpls@ietf.org">mpls@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/m= ailman/listinfo/mpls</a><BR> <BR> <BR> _______________________________________________<BR> mpls mailing list<BR> <a href=3D"mpls@ietf.org">mpls@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/m= ailman/listinfo/mpls</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3355380842_133468876-- From wwwrun@core3.amsl.com Fri Apr 30 02:59:33 2010 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A931228C1C7; Fri, 30 Apr 2010 02:59:33 -0700 (PDT) From: Greg Jones(ITU-T SG 15) <tsbsg15@itu.int> To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100430095933.A931228C1C7@core3.amsl.com> Date: Fri, 30 Apr 2010 02:59:33 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, malcolm.betts@zte.com.cn, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS169 - Draft revised Recommendation G.8110.1 for consent [ref#031.01]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Apr 2010 09:59:33 -0000 Title: LS169 - Draft revised Recommendation G.8110.1 for consent [ref#031.01] Submission Date: 2010-04-30 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=887 Please reply by 2010-05-28 From: Greg Jones(ITU-T SG 15) <tsbsg15@itu.int> To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@zte.com.cn Purpose: For action Body: SG 15 plans to consent draft revised Recommendation G.8110.1 �Architecture of MPLS Transport Profile (MPLS-TP) layer network� at the plenary meeting to be held in Geneva 31 May � 11 June, 2010. Attached is a copy of G.8110.1 that will be presented at the meeting, we request that you review this document. Please note that this draft revised Recommendation will not be proposed for consent unless all of the IETF drafts that have been normatively referenced have completed the IETF and ITU-T review process and are approved. Attach: TD234/PLEN �G.8110.1 for consent� Attachment(s): LS169 - Draft revised Recommendation G.8110.1 for consent [ref#031.01] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1010.pdf) LS169 - Draft revised Recommendation G.8110.1 for consent [ref#031.01] - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1011.pdf) From root@core3.amsl.com Fri Apr 30 11:45:01 2010 Return-Path: <root@core3.amsl.com> X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AFA6128C0F8; Fri, 30 Apr 2010 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100430184501.AFA6128C0F8@core3.amsl.com> Date: Fri, 30 Apr 2010 11:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-p2mp-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Apr 2010 18:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Author(s) : I. Minei, et al. Filename : draft-ietf-mpls-ldp-p2mp-09.txt Pages : 37 Date : 2010-04-30 This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. These extensions are also referred to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/ MP2MP LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-p2mp-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-p2mp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-30113010.I-D@ietf.org> --NextPart--