From malcolm.betts@zte.com.cn Fri Apr 1 00:26:56 2011 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 70A653A69B5 for ; Fri, 1 Apr 2011 00:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.468 X-Spam-Level: X-Spam-Status: No, score=-101.468 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, 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 Nd01+Q6OBtLI for ; Fri, 1 Apr 2011 00:26:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 965953A691A for ; Fri, 1 Apr 2011 00:26:48 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 5083806486374; Fri, 1 Apr 2011 15:27:17 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 22671.806486374; Fri, 1 Apr 2011 15:26:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p317Pxo6020973 for ; Fri, 1 Apr 2011 15:26:00 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: To: mpls@ietf.org 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, 1 Apr 2011 02:26:01 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-01 15:26:01, Serialize complete at 2011-04-01 15:26:01 Content-Type: multipart/alternative; boundary="=_alternative 0028D20C85257865_=" X-MAIL: mse02.zte.com.cn p317Pxo6020973 Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? 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, 01 Apr 2011 07:26:56 -0000 This is a multipart message in MIME format. --=_alternative 0028D20C85257865_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable All, True that in most cases an IP stack is present somewhere in most nodes to=20 support a management interface. However, this does not mean that high=20 bandwidth or high reliability access is provided to that stack from the=20 cards that support the forwarding plane functionality. Typically in small = transport nodes the card supporting the management interface has a low=20 bandwidth and is non-redundant since if that card fails the forwarding=20 plane is not affected (including OAM and protection). This is the reason=20 that MPLS-TP forwarding and dataplane OAM must run IP free. This requirement was one of the primary inputs from the ITU and I am very=20 surprised that people are raising questions at this stage. Regards, Malcolm venkatesan mahalingam =20 Sent by: mpls-bounces@ietf.org 31/03/2011 04:12 PM To "Santiago Alvarez (saalvare)" , mpls ,=20 Alexander Vainshtein cc Subject Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that = MPLS-TP is IP-free? Hi, I think, we need at least an IP host stack on every node along the MPLS-TP = path to support the IP based management operations (ex. SNMP). Thanks, Venkat. On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) < saalvare@cisco.com> wrote: MPLS-TP nodes would need an IP host stack to be able to source/sink IP=20 traffic for management (e.g. SNMP). An LSR should not have an IP routing=20 function with the exception of a LER where IP acts as a client. That IP=20 routing/forwarding function should be defined in RFC 1812. Cheers. =20 SA -- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein Sent: Thursday, March 31, 2011 10:31 AM To: Luca Martini (lmartini) Cc: mpls@ietf.org Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean = that MPLS-TP is IP-free? =20 Luca and all, What I have been trying to say at the mike today can be essentially=20 reduced to a very simple statement: =20 The ?requirement? for IP-free MPLS-TP is very vague and requires=20 clarification. =20 MPLS-TP nodes presumably have to be managed (especially if they are=20 supposed to operate independent of any control plane). And personally I do = not believe they are going to be managed by connecting a local terminal=20 via a serial cable to each of these nodes (of course you are free to=20 disagreeJ). =20 =20 This assumes a Management Communication Network (MCN), and , IMHO, this=20 assumption is ensconced in RFC 5951 (which states that typically MPLS-TP=20 nods can be expected o have addresses on the MCN) while RFC 5718 provides=20 the required infrastructure for the MCN over G-ACH. =20 Of course we can pretend that we do not know which network protocol will=20 run on top of the MCN (and some people have been arguing that we should=20 select the OSI stack for that purpose in the early days of the MPLS-TP=20 work); but I would expect that within the IETF refusal to use IP in this=20 role should not be taken too seriouslyJ. The recent work on SNMP MIBs=20 architecture for MPLS-TP looks to me as an additional confirmation. =20 Hence it seems safe to assume that each MPLS-TP node will run at least a=20 host IP stack (not necessarily in the forwarding path). =20 Once we agree on that, we could stop reinventing ?TCP/IP for poor? with=20 proprietary solutions for reliability, fragmentation/reassembly,=20 congestion avoidance etc. =20 My 2c, Sasha =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 =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 --=_alternative 0028D20C85257865_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
All,

True that in most cases an IP stack is present somewhere in most nodes to support a management interface.  = ;However, this does not mean that high bandwidth or high reliability access is provid= ed to that stack from the cards that support the forwarding plane functionalit= y.  Typically in small transport nodes the card supporting the management interface has a low bandwidth and is non-redundant since if that card fails the forwarding plane is not affected (including OAM and protection).  = This is the reason that MPLS-TP forwarding and dataplane OAM must run IP free.

This requirement was one of the prim= ary inputs from the ITU and I am very surprised that people are raising questio= ns at this stage.

Regards,

Malcolm



venkatesan mahalingam= <venkatflex@gmail.com>
Sent by: mpls-bounces@ietf.org

31/03/2011 04:12 PM

To
"Santiago Alvarez (saalvare)&qu= ot; <saalvare@cisco.com>, mpls <mpls@ietf.org>, Alexander Vainshtein <alexander.vainshtein@ecitele.com>
cc
Subject
Re: [mpls] Do we need to reinvent TC= P/IP, or what does it really mean that MPLS-TP is IP-free?





Hi,

I think, we need at least an IP host stack on every node along the MPLS-TP path to support the IP based management operations (ex. SNMP).

Thanks,
Venkat.
On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalv= are) <= saalvare@cisco.com> wrote:
MPLS-TP nodes would need an IP host stack to be able to source/sink IP traffic for management (e.g. SNMP).  An LSR should not have an IP routing function with the exception of a LER where IP acts as a client. That IP routing/forwarding function should be defined in RFC 1812.

Cheers.

 

SA

--

From: mpls-b= ounces@ietf.org [mailto:<= font size=3D2 color=3Dblue>mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Thursday, March 31, 2011 10:31 AM
To: Luca Martini (lmartini)
Cc: mpls@ietf.org
Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?

 

Luca and all,

What I have been trying to say at the mike today can be essentially reduced to a very simple statement:

 

The “requirement” for IP-free MPLS-TP is very= vague and requires clarification.

 

MPLS-TP nodes presumably have to be managed (especially if they are supposed to operate independent of any control plane). And personally I do not believe they are going to be managed by connecting a local terminal via a serial cable to each of these nodes (of course you are free to disagreeJ).  

 

This assumes a Management Communication Network (MCN), and , IMHO, this assumption is ensconced in RFC 5951 (which states that typically MPLS-TP nods can be expected o have addresses on the MCN) while RFC 5718 provides the required infrastructure for the MCN over G-ACH.

 

Of course we can pretend that we do not know which network protocol will run on top of the MCN (and some people have been arguing that we should select the OSI stack for that purpose in the early days of the MPLS-TP work); but I would expect that within the IETF refusal to use IP in this role should not be taken too seriouslyJ. The recent work  on SNMP MIBs architecture for MPLS-TP looks to me as an additional confirmation.

 

Hence it seems safe to assume that each MPLS-TP node will run at least a host IP stack (not necessarily in the forwarding path).

 

Once we agree on that, we could stop reinventing “T= CP/IP for poor”  with proprietary solutions for reliability, fragmenta= tion/reassembly, congestion avoidance etc.

 

My 2c,

     Sasha

 

=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
mp= ls@ietf.org
https://www.ietf.org/mailman/listin= fo/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
--=_alternative 0028D20C85257865_=-- From neil.2.harrison@bt.com Fri Apr 1 00:48:49 2011 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 39C533A6BD7 for ; Fri, 1 Apr 2011 00:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=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 sS1NggeVOlCF for ; Fri, 1 Apr 2011 00:48:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id CC4943A6BEC for ; Fri, 1 Apr 2011 00:48:47 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 1 Apr 2011 08:50:26 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.67]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 1 Apr 2011 08:50:26 +0100 From: To: , , , Date: Fri, 1 Apr 2011 08:50:22 +0100 Thread-Topic: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? Thread-Index: Acvv3+9Vr6/U4OwJR2yQjMnNvDsvgwAWKNxQ Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4401BCDA725@EMV62-UKRD.domain1.systemhost.net> References: <96327EF53EF71A48806DE2DFC034D57F0E3E9C14@xmb-sjc-22b.amer.cisco.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? 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, 01 Apr 2011 07:48:49 -0000 TWlnaHQgYmUgd29ydGggdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IGxheWVyZWQgbmV0d29ya3Mg d29yayBhbmQgaG93IHRoaXMgdmFyaWVzIGluIHRoZSAzIG5ldHdvcmsgbW9kZXMgb2YgY28tY3Ms IGNvLXBzLCBjbC1wcy4NCg0KLQlJbiB0aGUgY2wtcHMgY2FzZSB0aGUgdHJhZmZpYyB1bml0cyBv ZiB0aGUgRFAgYW5kIHRoZWlyIGFzc29jaWF0ZWQgQ1AvTVAgcHJvdG9jb2xzIGFsbCB1c2UgdGhl IHNhbWUvc2luZ2xlIERQIGxheWVyIG5ldHdvcmsuDQoNCi0JSW4gdGhlIGNvLWNzIGNhc2UgdGhl IHRyYWZmaWMgRFAgbGF5ZXIgbmV0d29yayBpcyBmb3JjZWQgdG8gYmUgYXQgbGVhc3QgbG9naWNh bGx5IGRpc2pvaW50IGZyb20gdGhlIENQL01QIGxheWVyIG5ldHdvcmsgKGFzIGlzIHRoZSBjYXNl IHdpdGggR01QTFMpLi4uLi5hbmQgdGhpcyBpcyBhbHNvIGEgdmVyeSBnb29kIGRlc2lnbiBwcmlu Y2lwbGUgZm9yIHRoZSBjby1wcyBtb2RlIGZvciBzZWN1cml0eSBhbmQgb3RoZXIgcmVhc29ucy4N CiANCi0JSW4gdGhlIGNvLXBzIG1vZGUgb25lIG5lZWRzIHRvIGFwcGx5IGEgY29uc2Npb3VzIGRl c2lnbiBkZWNpc2lvbiB0byBoYXZlIHRoZSBDUC9NUCBsb2dpY2FsbHkgT09CIHdydCB0byB0aGUg dHJhZmZpYyBEUCAoaWUgaXQncyBub3QgYXV0b21hdGljYWxseSBmb3JjZWQgbGlrZSBpdCBpcyB3 aXRoIHRoZSBjby1jcyBtb2RlKS4gIEluZGVlZCwgd2UgYXJlIG5vdyBmaW5hbGx5IGdldHRpbmcg cm91bmQgdG8gZG9pbmcgdGhpcyB3aXRoIE1QTFMtVFAuDQoNClRoZSByZWFzb24gdGhlIGRpZmZl cmVudCBuZXR3b3JrIG1vZGVzIGV4aXN0IGNvbWVzIGZyb20gdGhlIHBoeXNpY3Mgb2YgaG93IG9u ZSBjYXJ2ZXMgdXAgYSBzcGFjZS9mcmVxL3RpbWUgKGNhcGFjaXR5KSByZXNvdXJjZSBhbmQgdGhl biBsYWJlbHMgaXQgKGVnIHRvIGRpc3Rpbmd1aXNoIGRpZmZlcmVudCBjbGllbnQgdXNlcnMpLg0K DQpBIG1vcmUgZm9ybWFsIGRlc2NyaXB0aW9uIG9mIHdoYXQgaXMgZ29pbmcgb24gaGVyZSBjYW4g YmUgZm91bmQgaW4gRy44MDAuDQoNCk5vdGU6ICBBbGwgMyBuZXR3b3JrcyBtb2RlcyBhcmUgZGlm ZmVyZW50IGFuZCBhbGwgYXJlIHJlcXVpcmVkIGZvciBhIGZ1bGwtc2VydmljZSBvcGVyYXRvciAo aWUgb25lIG1vZGUvdGVjaG5vbG9neSBjYW5ub3QgZG8taXQtYWxsIHdlbGwvZWZmaWNpZW50bHkp Li4uLi53aGljaCBpcyBvZiBjb3Vyc2Ugd2h5IHdlIGhhdmUgTVBMUyAoY28tcHMuLi5zb3J0LW9m IGFueXdheSkgYW5kIEdNUExTIChjby1jcykgdG8gY29tcGxlbWVudCBJUCAoY2wtcHMpLiAgIE5v dGUgYWxzbyB0aGF0IGluIHRoZSBjby1jcyBhbmQgY28tcHMgbW9kZXMgd2UgZXNzZW50aWFsbHkg aGF2ZSBhICduZXR3b3JrIHN5c3RlbScgYXMgdGhlIHRyYWZmaWMgRFAgbGF5ZXIgbmV0d29yayBh bmQgdGhlIENQL01QIERQIGxheWVyIG5ldHdvcmsgYXJlIGxvZ2ljYWxseSBkaXNqb2ludCwgYW5k IHRoZSBuZXR3b3JrIG1vZGUgb2YgdGhlIENQL01QIGlzIGludmFyaWFibHkgY2wtcHMgYW5kIElQ LWJhc2VkIHdoZXJlYXMgdGhlIHRyYWZmaWMgRFAgbmV0d29yayBtb2RlIGlzIG9idmlvdXNseSBl aXRoZXIgY28tY3Mgb3IgY28tcHMgaW4gbmF0dXJlLiAgDQoNCkkgaG9wZSB0aGF0IGhlbHBzIGFz IEkgb2Z0ZW4gc2VlIHF1aXRlIGEgYml0IG9mIGNvbmZ1c2lvbiBhYm91dCB0aGUgYWJvdmUgcG9p bnRzLg0KDQpyZWdhcmRzLCBOZWlsDQoNCkJUIERlc2lnbg0KDQpUaGlzIGVtYWlsIGNvbnRhaW5z IEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwu DQpJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBh Ym92ZS4gSWYgeW91J3JlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCwgbm90ZSB0aGF0IGRp c2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9u DQppcyBwcm9oaWJpdGVkLiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIGxldCBtZSBrbm93IGltbWVkaWF0ZWx5DQpvbiB0aGUgZW1haWwgYWRkcmVzcyBhYm92 ZS4gVGhhbmsgeW91Lg0KV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29y ZCB5b3VyIGVtYWlscy4NCkJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KUmVnaXN0ZXJl ZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFBIDdBSg0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kIG5vOiAxODAwMDAwDQo9PT09DQoNCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHZlbmthdGVzYW4g bWFoYWxpbmdhbQ0KU2VudDogMzEgTWFyY2ggMjAxMSAyMToxMg0KVG86IFNhbnRpYWdvIEFsdmFy ZXogKHNhYWx2YXJlKTsgbXBsczsgQWxleGFuZGVyIFZhaW5zaHRlaW4NClN1YmplY3Q6IFJlOiBb bXBsc10gRG8gd2UgbmVlZCB0byByZWludmVudCBUQ1AvSVAsIG9yIHdoYXQgZG9lcyBpdCByZWFs bHkgbWVhbiB0aGF0IE1QTFMtVFAgaXMgSVAtZnJlZT8NCg0KSGksDQoNCkkgdGhpbmssIHdlIG5l ZWQgYXQgbGVhc3QgYW4gSVAgaG9zdCBzdGFjayBvbiBldmVyeSBub2RlIGFsb25nIHRoZSBNUExT LVRQIHBhdGggdG8gc3VwcG9ydCB0aGUgSVAgYmFzZWQgbWFuYWdlbWVudCBvcGVyYXRpb25zIChl eC4gU05NUCkuDQoNClRoYW5rcywNClZlbmthdC4NCk9uIFRodSwgTWFyIDMxLCAyMDExIGF0IDM6 NTkgUE0sIFNhbnRpYWdvIEFsdmFyZXogKHNhYWx2YXJlKSA8c2FhbHZhcmVAY2lzY28uY29tPiB3 cm90ZToNCk1QTFMtVFAgbm9kZXMgd291bGQgbmVlZCBhbiBJUCBob3N0IHN0YWNrIHRvIGJlIGFi bGUgdG8gc291cmNlL3NpbmsgSVAgdHJhZmZpYyBmb3IgbWFuYWdlbWVudCAoZS5nLiBTTk1QKS7C oCBBbiBMU1Igc2hvdWxkIG5vdCBoYXZlIGFuIElQIHJvdXRpbmcgZnVuY3Rpb24gd2l0aCB0aGUg ZXhjZXB0aW9uIG9mIGEgTEVSIHdoZXJlIElQIGFjdHMgYXMgYSBjbGllbnQuIFRoYXQgSVAgcm91 dGluZy9mb3J3YXJkaW5nIGZ1bmN0aW9uIHNob3VsZCBiZSBkZWZpbmVkIGluIFJGQyAxODEyLg0K Q2hlZXJzLg0KwqANClNBDQotLQ0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZGVyIFZhaW5zaHRlaW4N ClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAzMSwgMjAxMSAxMDozMSBBTQ0KVG86IEx1Y2EgTWFydGlu aSAobG1hcnRpbmkpDQpDYzogbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogW21wbHNdIERvIHdlIG5l ZWQgdG8gcmVpbnZlbnQgVENQL0lQLCBvciB3aGF0IGRvZXMgaXQgcmVhbGx5IG1lYW4gdGhhdCBN UExTLVRQIGlzIElQLWZyZWU/DQrCoA0KTHVjYSBhbmQgYWxsLA0KV2hhdCBJIGhhdmUgYmVlbiB0 cnlpbmcgdG8gc2F5IGF0IHRoZSBtaWtlIHRvZGF5IGNhbiBiZSBlc3NlbnRpYWxseSByZWR1Y2Vk IHRvIGEgdmVyeSBzaW1wbGUgc3RhdGVtZW50Og0KwqANCiAgICAgIFRoZSDigJxyZXF1aXJlbWVu dOKAnSBmb3IgSVAtZnJlZSBNUExTLVRQIGlzIHZlcnkgdmFndWUgYW5kIHJlcXVpcmVzIGNsYXJp ZmljYXRpb24uDQrCoA0KTVBMUy1UUCBub2RlcyBwcmVzdW1hYmx5IGhhdmUgdG8gYmUgbWFuYWdl ZCAoZXNwZWNpYWxseSBpZiB0aGV5IGFyZSBzdXBwb3NlZCB0byBvcGVyYXRlIGluZGVwZW5kZW50 IG9mIGFueSBjb250cm9sIHBsYW5lKS4gQW5kIHBlcnNvbmFsbHkgSSBkbyBub3QgYmVsaWV2ZSB0 aGV5IGFyZSBnb2luZyB0byBiZSBtYW5hZ2VkIGJ5IGNvbm5lY3RpbmcgYSBsb2NhbCB0ZXJtaW5h bCB2aWEgYSBzZXJpYWwgY2FibGUgdG8gZWFjaCBvZiB0aGVzZSBub2RlcyAob2YgY291cnNlIHlv dSBhcmUgZnJlZSB0byBkaXNhZ3JlZeKYuikuIMKgDQrCoA0KVGhpcyBhc3N1bWVzIGEgTWFuYWdl bWVudCBDb21tdW5pY2F0aW9uIE5ldHdvcmsgKE1DTiksIGFuZCAsIElNSE8sIHRoaXMgYXNzdW1w dGlvbiBpcyBlbnNjb25jZWQgaW4gUkZDIDU5NTEgKHdoaWNoIHN0YXRlcyB0aGF0IHR5cGljYWxs eSBNUExTLVRQIG5vZHMgY2FuIGJlIGV4cGVjdGVkIG8gaGF2ZSBhZGRyZXNzZXMgb24gdGhlIE1D Tikgd2hpbGUgUkZDIDU3MTggcHJvdmlkZXMgdGhlIHJlcXVpcmVkIGluZnJhc3RydWN0dXJlIGZv ciB0aGUgTUNOIG92ZXIgRy1BQ0guDQrCoA0KT2YgY291cnNlIHdlIGNhbiBwcmV0ZW5kIHRoYXQg d2UgZG8gbm90IGtub3cgd2hpY2ggbmV0d29yayBwcm90b2NvbCB3aWxsIHJ1biBvbiB0b3Agb2Yg dGhlIE1DTiAoYW5kIHNvbWUgcGVvcGxlIGhhdmUgYmVlbiBhcmd1aW5nIHRoYXQgd2Ugc2hvdWxk IHNlbGVjdCB0aGUgT1NJIHN0YWNrIGZvciB0aGF0IHB1cnBvc2UgaW4gdGhlIGVhcmx5IGRheXMg b2YgdGhlIE1QTFMtVFAgd29yayk7IGJ1dCBJIHdvdWxkIGV4cGVjdCB0aGF0IHdpdGhpbiB0aGUg SUVURiByZWZ1c2FsIHRvIHVzZSBJUCBpbiB0aGlzIHJvbGUgc2hvdWxkIG5vdCBiZSB0YWtlbiB0 b28gc2VyaW91c2x54pi6LiBUaGUgcmVjZW50IHdvcmsgwqBvbiBTTk1QIE1JQnMgYXJjaGl0ZWN0 dXJlIGZvciBNUExTLVRQIGxvb2tzIHRvIG1lIGFzIGFuIGFkZGl0aW9uYWwgY29uZmlybWF0aW9u Lg0KwqANCkhlbmNlIGl0IHNlZW1zIHNhZmUgdG8gYXNzdW1lIHRoYXQgZWFjaCBNUExTLVRQIG5v ZGUgd2lsbCBydW4gYXQgbGVhc3QgYSBob3N0IElQIHN0YWNrIChub3QgbmVjZXNzYXJpbHkgaW4g dGhlIGZvcndhcmRpbmcgcGF0aCkuDQrCoA0KT25jZSB3ZSBhZ3JlZSBvbiB0aGF0LCB3ZSBjb3Vs ZCBzdG9wIHJlaW52ZW50aW5nIOKAnFRDUC9JUCBmb3IgcG9vcuKAnSDCoHdpdGggcHJvcHJpZXRh cnkgc29sdXRpb25zIGZvciByZWxpYWJpbGl0eSwgZnJhZ21lbnRhdGlvbi9yZWFzc2VtYmx5LCBj b25nZXN0aW9uIGF2b2lkYW5jZSBldGMuDQrCoA0KTXkgMmMsDQrCoMKgwqDCoCBTYXNoYQ0KwqAN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMg bWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCg0K From adrian@olddog.co.uk Fri Apr 1 05:19:33 2011 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 89C263A683D; Fri, 1 Apr 2011 05:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 ZaDKlR4bhQZ3; Fri, 1 Apr 2011 05:19:32 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 34C8328C218; Fri, 1 Apr 2011 05:15:30 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p31CGNvM000476; Fri, 1 Apr 2011 13:16:23 +0100 Received: from 950129200 (dhcp-55ae.meeting.ietf.org [130.129.85.174]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p31CGJ2e000327; Fri, 1 Apr 2011 13:16:19 +0100 From: "Adrian Farrel" To: Date: Fri, 1 Apr 2011 14:16:19 +0200 Message-ID: <138701cbf066$9d292180$d77b6480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1388_01CBF077.60B1F180" X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AcvwZo2TLrthv6q+THORq9RH++pNag== Cc: mpls@ietf.org, 'Eliot Lear' , statements@ietf.org, yoichi.maeda@ttc.or.jp, adrian.Farrel@huawei.com, iesg@ietf.org, stbryant@cisco.com Subject: [mpls] Response to Your Liaison COM15-LS293-E X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:19:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1388_01CBF077.60B1F180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ITU-T SG15 PoC: Greg Jones (Counsellor SG15) From: IESG Response Contact: Adrian Farrel Technical Contact: Stewart Bryant Cc: Eliot Lear (IETF liaison manager to the ITU-T) Adrian Farrel (IETF Routing Area Director) Stewart Bryant (IETF Routing Area Director and IETF liaison manager to the ITU-T for MPLS) MPLS Working Group Yoichi Maeda (Chair ITU-T SG15) Stephen Trowbridge (Chair ITU-T SG15 WP3) Purpose: In Response Related Liaison: https://datatracker.ietf.org/liaison/1033/ Title: Response to Your Liaison COM15-LS293-E Attachment Liaison Body: Response-to-COM15-LS293-E.pdf ------=_NextPart_000_1388_01CBF077.60B1F180 Content-Type: application/pdf; name="Response-to-COM15-LS293-E.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Response-to-COM15-LS293-E.pdf" JVBERi0xLjUKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1dWY8kxREWyxqbGWRgYXa4u4cdTA94e+s+wMaSJcuSxYtX80b7CctIlmgJ /OP895xVeX2RGVGZNdPsGpCoqcnKM+KLM2N+2hb7stoW07/24fsfz54977c//Odsfr19/lfz8PMP Zz+dDft6+md+gc/f/7j98636cNiW5b5otrf/Oiv24zg2he613PbVtm/Hfdttb388+273ys1TNWTX VmO1ezA9F/1Q12W5e/VGvR9G9d/u4fRYDmW3+9XcuhnrbvcafPhr1aCqu7oqd79Rj0XTl3XZqO/K afCm2r0+NWiaaujpIIfjOf74hu/n8PPUUVf3VR+N3xZF1diZN1017H479zJ0dVn0uzdvprXXTUma +E7IbKcZVvW4e2t+qsth9/Y0cNv2nZqQ/+jR9NT247h7B2f87tygKMcW2l64J1g3u6Bu95j56nC8 cDuHn6mRp9dqbjuzbWPXDr3d57YjrXHs4+vTnpRV0ZhzHdqq213CM+kQPtVTHZth2L03DdN16uzf v/nH7d/Oqqbf98WgqOr2n4qSPrhxex1vZtvV6lymLey6rtp9OD02QzdOpzHNrFQH+hG0/dj18Akc B/TwGjlau355h9wqNvheH1/ZVmqjj49873YD+sZSU7ChsM/baXTVX4PTu5wnMgzN7grHe+zn4bsY yNbAKO7ToSSdH46f+v17EDdS+9bTcaFTsi9P5rlX3US905E+tWf6tGr3daUPVoQIoFizGPUfMs0G W9uzaZrdPH3Nxdd69/oetiwmS92DJ2I/RIAgZETfSsIfGMk3RpZ0bHgki52JcxzcmtSqz/mRP5va DpU6KBgLUIOdgR8rWP+0inLa43fnKQw9IXlC2tf4A9ALDLhxlAv8AVv1jsBC8W7qJq/OrKJ40lBT 1VT7fmgtQBjhMc/CsG859jVB6d95bIYBL/yjxNbynGB/LUx8Pm9HocaG3bsWGEYa/LCbflHUbdvh RA4306eKqdsWTgmmcThC6/fnLSvU05Uwa2nBALd+3+G7e6zgGDJap+hveYfHiVxVa7XwfVs2Bkv0 8T8t232nSeALDebFdOxfwrPEnyj5NVL1RPFAaCKkY/kWQSVnkyKeM3tUVdWYZlA/7u/1uFVRI7Mf jtjdNaNuDW2tQFkrOWMxWkbSYPzt2e0X3+2ezi3LagZPXhVZtZZlbAwUQIKvMf5P8pCAO44ObfDZ gyxIiHPpy4dca6+cocppaXgF4odaGLc+aZYpmcRoIhZ+AYUAqa/d75dEo8UryrExbM50VCvuHGoL yHeFz8/mFk3fj22Fc/dwB4r8WvCB16CdSTh9RffWznAt25vp2f3m5jbWdN3szsA0t2SxQD9ED7Ab tvcbRgR0vDrFu9JhTcANijvBYnPyExbXBoyJ0kasmpDeAhC4ogw1b3BbI2OQFl6fQgXBvtsK3MkZ Rv57fr9yDM7IttEYGIBFXygDkgeLD+ZJUIz/0GOeti7Vs9XGJ1h6ZSatUmno8BFQPasoPBPVuQv8 0vGI350cvBAMU0vJuCOMscfs4zwdiUXYBcJ3xawmd0WJLCRBBwwNBlXpDEnJ2oOh965xRHLzdzCL KwcLCc5sAfn1LyTkd3pACHMwgjyY64ZAjFm+9UPcVWUz5p+CiWYganvo8xFVr3WWGfSOPQYOnZiP cBzeV+TZoSJwxBtfgXZiDTzfiTB/URO0r7WtURUtMW7emxpXiv6qWnB1ve08IPWN94D4t82N95YA TbTOXfEWfNbNO9h17bjrwQoD2eZNImGWnsj9HL6AIWr39ksDGK3a257RNVozma5yLp9ojrOy3zeU adK8tXYhfnTvcEKXFe4hu8mfMAtQ64L5HI4C9tlZkFUB7vAA++k8dNUM1DpP+5uI+kOcgRYIrHpB NDoHTQAr4YwFxyEFFk0NCCyiLF5hj7BGD9o5pAvOgcRpJ7x24VtaC62ooCfqneaG4u0J/H1sthLo klzPxNXLuIyCHX7kHOSgsrGebPksqCIXysxQ05/eq59yhLtgF2w0qFTlfhidAQN9RBZoaEPJ5md6 AdFpzc0fORRY4pjYvGLUCYnB2elAZ3q0puzJOoheILm1MvSLE2ml7tOceEO810aTsewEuwK/39Jd ZXUbQzvEBDqCt0JyXBAHTrSDMyA98VqMt0GGWegsGCmSn9uQQEf4U54Swh1rsUyYYL3spYc2yZHB WWlGr1cveyG+RQwnv0bi7UzTNu+oBnKS3KEg6S6caAU3BCt6Jf1YwBXC0Nov16n+HRxJ/vJNIC+z fD3lSmdPjlPeNfbyhS7Vqr0CQOYAtYSFzjXDN+DBcMOBJZF2Fx4DHvtHAIEA3AgimONDpSSyDmb+ fob8QTjR8wL/5SU8S5JZ0gYSlkUg6vkouRBA44NRAgyQaKg1xYwbenBSyKCR98UyKlC3G92vreXX DiXf7VdOTUF1mnpiWX5b8o9lco5mP7sBAJoEzRz7Ho7G5pmcGI3FAwmrtpQ/OcJn3TqglgJTQgcm 2DjUd/UeVJmQwk2ZhvesnZ4O7rFC4dIjFNExzgWY9gdLzkpze29MEH04EI6SxD+vFguxj6wQS6i9 NDnZMaww96Kcn6XfuMPxsRtCcN4aDa/zztu6xI2gDhJOOsTBqilGFas+gd02zQ2MId1zyW8PvCTO 4mWnulrTolM9jNit9BjTJABwnUMgb9lj3nRZHnOGBJZd5oEOlHJ6nhY3xZgRnzQBM742GlWz7/rK IigfqFmw0+wYGWi72gBllSrJVcBEhKQIvwzQVvnh5c8qjY9JvpgxOY3PbJjynt4gc8rUG0QYc0Nh ilOtSPxKyEBCnPFPySAya99Y3GV5kvcqr9YbXQQHYGSd2phhxfJz9YIF8oxIfCWbOu4dxJa44wlx Xtu4lNJ4LGCINjdn5USOlDDULOKC529+V6QVsroOUXBIRiIOKazmeM6hhLQGFhpIzO5BdJ4DAf0s bgejLDTotVEWIfXcdvIVhNGo6WzRY7OJZd8MBoZ76woNJ+AFDCK7jwKvi2scasNZ5liur/SeTCo5 d53DJTaQUKkwspbvxa8xLxXHLwccVqAL8UGJKSIC1k1SDgq+v5QThzCMzn4pJy+0hQqCXIEHqi1r xQuEMU8BX5KBF8qL04X87RIXxUa8y6kpW79L5CLLUCyX3d9Cv/h8zSBaTwJUcho4zYnR9IBayKrg k8kEmbM6CpfLGOWCBHFxnxHMG3BR7lSmkYlvY7su9CBf8SB2iVlvXApOxkTYKw38xYSHbIN34rkt pjNIySgXHEZIDhzZWbNMsBuX6tx1rRyY6uqhqqliJESYBHaSc0m8UgHd817WjQApOQbQQggmSJ9j UwIvrSo+N4bviGzg9TCiRFjEk/bMeCSqqibTQwMoFpyKgKWsRnJQ4GNeciwbakBkYYz2AE7YbNnZ nuH1HNIejZuY/eCrdWGhRZsnCAqlPClJfeEcQ0i8F0pyVvN6yeFIdj3GwlPFUyyBhlIbyJkX+PK1 K3CcMKm7QJ+xXrd0hWHdHTI2aSSPd/173m0tZebJOLcqLjQLWfUDDslnw4gDAgwejlfitCh2HiOL eRj7jgmoaYsnzr1USBRmtEmJvN51shgIIiGWCQLgBkGUFFJL3u9kLHjDgQXbwUu5RPAE9oJ3VC+F tcOdFTxSoA9ZKycOHbA+Z0bnYbz1rkNymc6CqZzOGNBeQpGz09sgHotBvmkJ1ajw8M3gJXNT0g45 YOuXeldybiTdlWTzEDHIZhMd24ZLdCQaBY9DvEoUaLdy3iNBNEYurYvg/eIXUshhUGWVFSP3U1eX 7jHeNT1aHzWEEHkgCAM480uQg6h6sebQctI1763PiO6thQudLBwkOqJ05fWu8NJrEA0j0Ch40+3M 7+NMT4r4lEnDMgT1QVutyYuUvIoKFmM9J8EZQUSUpQ5+lT7aS2J++US3IGxYNylLQENNvbuBMFm+ C47Owwyvp6T1p26bCDnipSlvAC19rjumqn/E5uZDlgqkuDeurZQfbu7mddMSW++d5Ek2I73dtfVD f8xO3r4VrxBggjyk51MOcN/R2AsjjXgTSMj/kASLzMtZziGrY4NuTmx9y/AB8JvDSWeKBWHMnPCA /9azffryrcSUJ2IiLyYCtLbnqlXAudSE4IjwT1GQbCmLIV1pJWLqWZoHtqhFADjd9KWrjCTxHN0D Kolc87My+aNNp350wUtJRYO5Cqz3tcu3khxXp1BLvYdv3T21lJgNokNOueBjq/4+Hgkk8e4OyeGK xgX2QpRV6DKM7US5aGR4CzKZcQhDBUIcIpUyZu2RkbZkhTq0EGuM2IUi/f9heuyLWmk1MAmt8zx7 Xha+2lQ57IvSFJAZ5wIyu//e3P57alX6Vq36f12YNB+FBHMDqFlVVvux6x1jpO/Q+fXmCr1u2Z6/ X/oGj6k+rCxFZZIpg/5UrSbHeMxVyw0z86UMe0L3jgHh7R91H2U3Vr9A8PJOF0MW0jlcPm6tZFhL s8m6QEPOGZysPgoq6FiDLxSl/WtF250Ert2caE7yCXDXdyZed5K82cREdiL4LoUJzBHlBGFT9+de RLmplHM8WatEyr1Yl0hC5UDb0dsisGByDlL2NAmE8rL/5d8FS+V7AM9XHcfzsBohu5wHk4xcUgKf hB2DcnPMJq6N/QqYQuObjPMN1+w0qKWwvLRiCBcpHWfpPg/vQ9Pnk8PwYmDDBoMWUgtAjJE7ezk1 MhbSqxIJo2wQhHfASwaNHQkMrFREhsTGolwrb3OcWkOOc7pz45GWmSUNOYvIdVy0V6urGO+7H4Sk YDwUpidKPQkRU9JVtB9iCpTiD/lJcEBBlRSUTadO5EYOWL42B4HJmie8TCcJjWyfYJRyCnkRY1CM TcoLjUl4qWrZMczJAHEoWBqnS/xbI1Elh4BEA6mkH8nlR11Hs3vEvyQt9VWQydKjd+kUA9ddhg2T 4BahqO5JkIumIpVBeVW9Ji/71C+U7Wt+1PX9IPSzOtM42Iso14YlVFY8VneRfpKdTh3ra610E4VN BDaFLZCpEA+KQGbOyUrVFlIBWVodlFOMJ1luacwbkhIKWBGodt1yivenM06kutzxslwusZrSu9OX 5Yl5QYorcYeV7g83USrnjL2IuZ1ApKAuJpO24JC5akrxkEupgubwUGyu4u9TXzxayCPvEw4ZsYgO ikKaznOURGokjG1hCdvP/28RStfN6OXc5/O2lN1ALt9hxMwUzp+X85VzJbF5J6HPvqrKZip/YKVm 3TLqcIbpuupCp0l+L/qoDqKt6w7Oe1bTeGGHJmhW5Nho1rAT1nUbCWvq737qHN5lp/STEzm8EzkE WRCAOV1SIr7VkqAHNlbnhT3JKfHz8rDhlQWSJyg48mJPVajsEKd5hGkhKiynliz4o2QFnNcYpBKy GXQqiiOa9ymoG9ir174Rti0MtCNbiCJVKlgU4kyYXt8oL0YpXPmibzkv7aBT/skGQo+rLKnwQvO8 3SjEpbgbdzuGXD0MYVNxEoDiedCt/4Gwm+g34/3TJr6hA3xYPib7qrhW/2chNxCYItnfNEFpTgsj 0ybzMJA8X8XzIgRnsVIPPRF/ZdCG6+2Ks49JnQaGwUrjyC73jS8mEzKrFvrCSqXkerC82cLXGfya 8bcY7liC01t/mGvl64oGGGrnLE2UPbIwXZ+9h3ynMJY+rPy7hGF6POsDjuIUcRY8F6WSUmsQCLKu DNgCTFCVKe2GiMuFRHcBY0/cyhK9J7mDC9zA6qKC43ld+Qw25hOD4uzDtbeU+9qJbqcx9/4PamUW mh5X3pickxG5bPkAXVPFT/gyLOnafznnC32L3vuME3YKSnwjeNp75GJCmIQLCZclxHpg6NoWeZdV vHwtkmkwFjlseWha2/gj9i3CglyEBa/HWCbLKBhw5NPKpJJqlkik7+5fi9Xb0XzTE1igzWQnaWYe 93XBF4jMciHwN3rvwjauzQLfMK4+qRhAVg07LtotIkxUan0xEgjuBSm9KYhZUEbX54IKO1//Tbxl KoWimK1euqIqNrnmuEin1VoeZ031E1+d4O0FjL8Htc04M5C/fyr8DQVoAfBNw84iMTPpG6RWxblA tukUqjC9hqGxc5eA0jcdKQWglfWMNBvpxpNY3lrg5ZwK16VLdSd6dUqtkOIpK6pTUq/5Gp1m4P7E iJRmMp0CinKxhHKqgPIqh/zhKKV4+RJifEJHMncMY24MCMjVoi0kuFnSIrFs+dVkLqo9N6w4+cYd SwxyAQg+UgR8w9YzFG1/F98hgQniS/eUuDVeNDUpd7OTvz4OY6Tv1r+YiqqXwbLc40p9hv+SNz6z XC5BQVa9u8ihUnUv4Wo4+9cfJOP31H/A5X5B7TA1wCgi305Bhs9pQsDXEAyQE8dZrztXy4erFOKB RdgOYfNQDxA1GfZuj2898FOSiwRYUFioEWCb8Jl3sXq3WgdZ7Q/wEbBf3PqY41/6r2XU+7pumJoh OX9D7+WYHqyPzeCFWQ7cvn4gSNq4MEBMlnin5RtHMf6JMJL8A/4tmNDBHZYl8eSPX0nX3FAt+QYx l8txBZrGvr3KAZniXsR6xvsTSFD/91r4ZayMfaEFl5FEIvYTF3nSfUp/XkGsfDlR019uz/6u/v0f DTOybmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iago0OTUyCmVuZG9iagoxNSAwIG9iago8PC9MZW5n dGggMTYgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy9W22PHMURVuBMzDkKBnNn kpjc2saw6+SW6Z6emR4EVjAhSFG+BN23bD4RBSmSV4L8fyn9Ov1UT9XO3tqKfR/25nr6pV6eeqqq 96dVs1V61fj/+cMPr84//35Y/fjf8/B49f136cPPP57/dG63rf8XHuDnH16tXt64F+1KqW1jVjf/ Pm+24ziaJs6qVoNeDd247e3q5tX5P9Z2c91sddu3Wq3f3rjV7eh+1mf+o7KqX3/iBzSDbVul1vfw lyv8Bd79MLzbqLFb7352n5u+dT9q/e7G7Unpxqx3e3misvIH/lM3jGTGBzj24eZaNVtrjXtL+XMa vVab6TwPwp/Hzhh6ig/DYNu3sNjlNMFFeDYaa90+L6YB+SiDHnDie/ze3/W7MEbbYf0WjtjtixTK aBWeKW2mmbshb3nsOzfJWdnUY3x+iZu9J7xRloTp4e9JHkOftGg73a+3RY4XUTYdFcLbm3/e/PVc d822G51l3fzLWRNMeoWbiQpUndZum1Gvfd/rJCbVK7t+r34ahIcLrvKMVhk33Bt46x4XIxAlM01i W2Gdx3Tuachu/8T/Ymw/9lmTs0Fk3SJsSR1gYLLGavOJQ0A/Z8IsMGS3L5o922htt50yXmnXSWvX qtsaG1WXvK3VlcvDVionmnwSfP+pH6LM2PZg3hRjvN76rpUgBtFj7T83WuuRnvwWvl4Gw0Ee8E5L fBkmLCpNJ7Vk+5Kvz5TlBz/mgQhWexIkpHsyQTJh1QxqqLwQx/g52tFS555cD8Z+MLkPPOSHEusC b0j+3zoT6lUGgCu/BTfW4BZ2+xXOASC0nYCPt+wK064OApwahmDyBWqi/bRdR5AN9HU2IdsyBMPE sPQzP4P1wALvFbf7VbFQPBaNJbeCAB9BYP+AKvko/N8BdS/YVYj5ELBIKvZo0fZRz8/ClsygWgeF JUhKrlBG3DJespTk9XwoSF12oenx02DKxHnvBHTrmkaLgZ/sjVgjHLGII/hTnJDA1mXhHXtAxAE2 UNZclO5ufyW6EW8MxZrArE/lFwVsHkTMcMZlxiFjBkRq+Ej84pkUM9HFT46fXjwZtgjtmUYQ2AsB zJyCU7jbTwQlXFFnj/Na3bZ9hb7cSZY0sduTZYmYsgQIjhUsBc9IqOmiMoyN+DK2aqjhI2kbycad QhPeK7zjOpxJaWfcU+Iw7T/acUBbY0bUE7J09JsV71BsWOZ5OYEiENacOCZ/LxD6pd//0LR9p9cv pqcvihBT4HCqTFjqTGqofnkK7n7BHSBupOsdCJdsaQIuAESBVcF+4vy9O0gxwYrnSk6I/j3ZA0x9 a7OHEwIiXCTCYbZdhg6R+RIcv54z+Mr6Sw4B6w3w4m2IghDoydrSu5eCRIgP09Qm29ZSbkfWeTOJ x1dxiOpHbUVl3hM0LmR5XwW/aEz2w2CRc+4+E+NlGV3TF28wHn0SdzmUm1fMqQrRVd2ijCFQw6U4 xTulROWYisiEf3pO8ihe2V7Eq4Dzjir/vxAqwyoCVHlphlGZufunTsu4oaOtoHaNGcydaqURgKyH zwxBL4A1J3uLf3dJ9rbVcdAfI77oeRwK1Ha3nzYrUN7s9KkSlceC9DCNzSomOex0DjaVvp1T0A2V 2hluWKoikOmFEDUnG25yGFtsCVcUnDOTjc4qKBtFstF0hyopmemBxA6noDLzWvEzw4iUsxibWbIZ XNpl2VCHVokVKvJ8RQNLDmA8lEuxXcoVeJ5MRpOAU0ctNjzDft4JRqwcAXmY+V2dIZyxTy/4ZYRo c8blOXymX5SmmUJjCDwwx5zPjN4aIR7TbZCIlTSPjFmOQnLViokQi4GKeK2QJYvRaVaBOhUJ5vX5 ktHngW119LlPRHFxxJ5pXdSloWx1QbGi7Uam3SXsT4j/t/Ob5wc6KxnPhBrKJfOp7Jy85PfIADiW VWpUIpEC9AVCOLXUyqmNVImz/0TsGHpj13x/ZdnWciVmbMaM6UblBNLaQY4LEoBLdJcW0afhUE4D uCC0ZNadCtkDihGxMkJ+u+2anummyCVUKaEnR2Ny+2xIw9hpcYNlEaasS2YQYPctKm2mRDmJwSeb QuqEnUO+onZyCkOgvGgazl7i8hG1xBrIoz4h+ZCapqRTCugFDlR8ZSVMIjjLYn3ws8AgdNPZ9adF /x95afQ9aeWYCBjKrj/2+3Xy6d1Mj9inSPPLDJkKNy3wRuJvU46TZNI1nRHKNldVBOEOt9zVEQo+ grqF5IBNzeZQKhh/BUZA6UrJVHd9IYPZH/ktRANSbSc5CeVmxIAB4piyDuFG+UQF6R5Qd5rG3o50 Lq38kGQlMAspVhfImtrXr4OiMq4wZP6xIAcin7qcGxmiBC012bjONuETTWO8Ybi/3PznPP0aWQi4 NgAFNHv5ixvwtKSTAEsUuXI6+mX4ZILMZ3yoK2vejyjRjEO77tPj1vvstZOBcfJZ/ymWvXs99iPg F2Qd8w5lLHukerJLDb9mhzjHhqacAI0od77n8rLIFXFumDeNYCQIWK79YH2WNH8I2PG7AgJEd8Xm WC+D5TqGK1BgCLszedRl0d/6GZwTaEsyOmHlXxYNSJ4CW3qSyNHos/gMgVJsLzFcWDuZ1tBr02en GkQZHdnZgQOl4/eNIT3fX+OyxDIZciZshtRbP+O097mYgANKEiln8CoYXp6JNQc+YJBuUEDwJosg ZFGzG0qEK6nW2dqAXCnaVKdH7VhD4RW/KzAEYi9O8IsgvGiLWFTaiy5eiqJ8PWp+Y8BoJDJsD7rU qLjcDnSWtBorsQyAJEW70BDJWUicPgrZpdJGt0XEdv0+yKmdWBk+LQxu2Tdhk8IdJxhRDGg1mTR/ uQQWK8zxD/Cp7JbyySoAtr3j5aojlVaIMo8Wo8w3QQK6dz+YiQIAy7luFSrDGckQTSE6m00yao+Z c4iuB2MN4dhYkN89GAvqwAHcMXnJ0LiUWsooBLQnscU/bZzoC5zwHYnl2FLBXpn4DcNeiDK92drB ckSbC4azikBogC/x5d/4h47eOlMmfsW7S0V2mYIlvRIhyrMEtY2fUNu26+DGVhGFxMuXa6tQ3jyG osPcyS5N0wwHYkYVf1W6h5AZcVIexBDn7a0z5G2L0QRvDEg1RIk8VmGEvWlUHGWcgkDUuWn88ptg S77HCWjwxTT0iMy9oEm4580FyJD9HRcgG2v7oRY1EyDF2yF8xkSYFgsDwu25aV5g6lCrJHggmHiB iU+nhn2MmS4e9KR5gNHxeQSBcdgaNYFAy4amRR682yuUfh7xiJ3tPvs0Abd2QX+y8bQ3Iej9fjHo AX3a7YvPM8Tjz2hzy8EKbPkA1+Jo0ey+x6y2w+xuRrkPx7dD/fV8gneiYzjY4WtXdzel4EkcBxQ9 TBmFRNwrt4DMK0cYUlldvlfK2h715T29C1uiXzB3227LFV7p6m9dL6vc7I1HYyZDgq8LvHbNCoQ1 w87o1NnAWo2XoFaVXOu2RSziLMSpKHDs75U4ldA5BKpj0xe+wkkymHmxk9RYDtlhvOrBNugoQE87 qlIaDi2kmjOmNXlsROih8Vz2YzariRWlVvnpWA88KquB4D+3yKqD38wLDkJeswzyNK+pimVmEdGJ IkmacASf4fESKQKPhcd9h+vbDZuEwDRARUs/gK/zAQUglJP4SM7krzCN4Q9JrPTua91M5Pmy0EE4 Ca8wFYQB0vXtWH4dt4PiL0sKF6elPBCG3AHeg9ojYQ3/AO+iex+TvxyhhjeTKBGkYL6TQu7YZHg8 Iqs5otkxjw5JbWwWswybR+JwdgIoT5eGH9S2Cgo/AsxqCRFmSla3Bfe6kXjEYpR3hi/3cZQ77Nx/ 8gEVcbdUnJ7PKHe8Lcbi8fuLeIzGv/SNWbDh2dW3Y75yygdX4Pivg954EH4e0C4JPHx9rJD7ymaQ JEdjRVupvv8k4hjbbSVl2gkqTu/vn0Q1Y2VJO7eevvUiXftmIewxYjFzDGvErjJpJcM92Tw1nAi4 b9UpJTpk3gR2Jd0Kgf1xX6mtgu4xsWqcFHA8l3cbjHWW9EWV5sQ6U1Qli9ApSQwXtEgbddn34U5t SY7/UqxPvhfF5OC3aZmUMtXdCJXtiKWlyYP4eb6YLmCBdg62RzpMJ4kvHjZWwRWPUN7JSCBfaeWb lfx3GWixKCbdZmsmblbK5Qh8qEI47n02SmKrhE2BsCR2KCZ3U86R5j1pta/l75vwl0H4lKkE6e9m QToXi704v705/7v7/z+Ocow1ZW5kc3RyZWFtCmVuZG9iagoxNiAwIG9iagozMTcxCmVuZG9iago0 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMiAw IFIKL0ZvbnQgMTMgMCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRvYmoKMTQgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE3IDAgUgovRm9udCAx OCAwIFIKPj4KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFn ZXMgL0tpZHMgWwo0IDAgUgoxNCAwIFIKXSAvQ291bnQgMgo+PgplbmRvYmoKMSAwIG9iago8PC9U eXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgovT3BlbkFjdGlvbiBbNCAwIFIgL0ZpdF0KL01ldGFk YXRhIDIyIDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZQovT1BNIDE+PmVu ZG9iagoxMiAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMyAwIG9iago8PC9SOAo4IDAgUi9S MTAKMTAgMCBSL1IxMQoxMSAwIFI+PgplbmRvYmoKMTcgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKMTggMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMjAgMCBvYmoKPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCA1NzU+PnN0cmVhbQp4nF2UwW7bMBBE7/4K/YHJJUXFgMFLesmhQdH2B2SJ CnyILCjOIX/fmdm6hx4mwFjk7r5dZo/PL99e1uu9O/7Yb9Ovdu+W6zrv7eP2uU+tu7S363qI1s3X 6f7X6e/0Pm6H4/P3cfv9tbUOB9ri/nV8b8efFvRL9DvTbW4f2zi1fVzf2uEcQj0vSz20df7vUzn5 jcvyOBqrK/S5wlp1hfJEm6orlJ42V1ewQNtXV8gn2lJdIevwUF2hT7RP1RXyQHuqrjAo71hdoUTa S3WF0min6grlQjtXVxgUuVVX6JV3qa5gM2xEL6gQEiNHsEbxJh6OYI3OW2jBGp13oQVrFO9gtGCN 4i3kjWCNAiwTLeCiA7KqCLgowKxQgIsCzKoKcFGAWXcBFwWYlAhwUYBJiQAXBZgUGXBRgIWtwygk WN41wJkAB87IAGcOyLsGOBOgsbEGOHNAdsMAZwIcOCMDoPlA2RwDq/lAlQisJt6iw2A152WfDawm 3sSHZGA18SZVBVYTby8LVhNvFhFYTbyD8oLVxDswMgJIyDvSgjU5L3uF/kmwzIuGScjLUAmsSbyJ ifAEJJTBd4UjEixnlMCaxGucETgkfCUvJnNOAjQlAlwSYK8yAJd8oCoScEmAxtYlwCUBGt9GAlzy F8sZZcBlAWbOCO2UYBkqAy4LMDMU3pqEvARE/yR8JRH+ESVYFokxSmiOQgEuCxCYXBaPrcC9wQX0 2Dfd9Lnvbb1rS2kLcftc1/ZvkW23jbc66PAHnoEu+wplbmRzdHJlYW0KZW5kb2JqCjggMCBvYmoK PDwvQmFzZUZvbnQvUlJUVlVJK1RUMUZvMDAvRm9udERlc2NyaXB0b3IgOSAwIFIvVG9Vbmljb2Rl IDIwIDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDcxL1dpZHRoc1sgNDg5IDUy MiA1MDAgMjI5IDI1MCA0ODkgNDU3IDYzMSAzMzcgNDc5IDUyMiA0NTcgMzkyIDY0MiAzMDUKNTEx IDUxMSAzMDUgNTIyIDM0OCAyMjkgMjI5IDc5NCA1MzMgNjY0IDg1OSA0MjQgNTExIDUxMSA1MTEg NTIyCjUyMiA1MjIgNDI0IDI1MCA1MjIgNzE4IDQ1NyA1NDQgNDY4IDU3NyA1MTEgNTExIDUxMSA2 MjAgNDU3IDUyMgoyMzkgNDU3IDQzNSA1MTEgNTExIDMwNSAzMDUgMjUwIDg5MiAzMDUgMzA1IDQ4 OSAyNzIgNDAyIDM5MiA1MDAKNjQyIDMxNSA1NDQgNTY1IDUyMiA2MjAgMzkyIDUxMV0KL0VuY29k aW5nIDIxIDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1R5cGUvRW5jb2Rp bmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMS9nMTAwL2czNDYv ZzI4Ni9nMy9nNDcvZzI4L2c5NC9nMzkvZzQxMC9nMjU4L2czNzQvZzM2NC9nNDAwL2cxMDQvZzg4 Mi9nMTAwNQovZzEwMDkvZzI5Ni9nMzgxL2czOTYvZzM0OS9nMzY3L2czNzMvZzE4L2c3NS9nNjgv ZzYyL2cxMDA2L2cxMDEzL2cxMDA3L2cyODIvZzI3MQovZzM5My9nMjcyL2c4NTYvZzQzNy9nNDQ5 L2czOC9nOTAvZzMzNi9nNC9nMTAxMi9nMTAwNC9nODcvZzI0L2c0NDgvZzM5NS9nMzYxCi9nNDU1 L2c0NTQvZzEwMTAvZzEwMDgvZzg5Ni9nODk3L2c4NTMvZzExNi9nODk0L2c4OTUvZzEyMi9nODU1 L2c5MTkvZzg3Ni9nOTUxL2c2OQovZzU4L2cxNy9nMTE1L2c2MC9nNDQvZzQ2MC9nMTAxMV0+Pgpl bmRvYmoKMTAgMCBvYmoKPDwvQmFzZUZvbnQvU3ltYm9sL1R5cGUvRm9udAovU3VidHlwZS9UeXBl MT4+CmVuZG9iagoxMSAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EvVHlwZS9Gb250Ci9TdWJ0 eXBlL1R5cGUxPj4KZW5kb2JqCjkgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt ZS9SUlRWVUkrVFQxRm8wMC9Gb250QkJveFstMjAgLTE3OCA4NTkgNzE3XS9GbGFncyA0Ci9Bc2Nl bnQgNzE3Ci9DYXBIZWlnaHQgNzE3Ci9EZXNjZW50IC0xNzgKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1W IDEyOAovQ2hhclNldCgvZzEwMC9nMTAwNC9nMTAwNS9nMTAwNi9nMTAwNy9nMTAwOC9nMTAwOS9n MTAxMC9nMTAxMS9nMTAxMi9nMTAxMy9nMTA0L2cxMTUvZzExNi9nMTIyL2cxNy9nMTgvZzI0L2cy NTgvZzI3MS9nMjcyL2cyOC9nMjgyL2cyODYvZzI5Ni9nMy9nMzM2L2czNDYvZzM0OS9nMzYxL2cz NjQvZzM2Ny9nMzczL2czNzQvZzM4L2czODEvZzM5L2czOTMvZzM5NS9nMzk2L2c0L2c0MDAvZzQx MC9nNDM3L2c0NC9nNDQ4L2c0NDkvZzQ1NC9nNDU1L2c0NjAvZzQ3L2c1OC9nNjAvZzYyL2c2OC9n NjkvZzc1L2c4NTMvZzg1NS9nODU2L2c4Ny9nODc2L2c4ODIvZzg5NC9nODk1L2c4OTYvZzg5Ny9n OTAvZzkxOS9nOTQvZzk1MSkvRm9udEZpbGUzIDE5IDAgUj4+CmVuZG9iagoxOSAwIG9iago8PC9G aWx0ZXIvRmxhdGVEZWNvZGUKL1N1YnR5cGUvVHlwZTFDL0xlbmd0aCAxMzIxNz4+c3RyZWFtCnic zbwJeBvXlSYKOBJYSRzH6YQJFTPp2OnsS9uWbUm2kzheFcuWLVGWLYmSSIoiuIMECYAACKCwFFBV t6qAQgEFFAASAAkSXEWK4iKRlqzFlhfFe5x00knceUm/STI93a/zXjdIglK/cwuUbKfTMz2Z7833 BJGSwLp1b917zn/+/5wDaTUbrtNotVpiz57bHjbceiv++22W4sMr/7RSuxFd/yF0/YbPf0Szgf7q XyJ07S/Xl6HKR37wFytPf2L5pY8vu27UPAL30GzQfFjzMc0nNJ/UfEZTqfmC5kuar2m+qblVs1mz RXOP5rua+zUPaX6geVyzS7NH84ymWlOjOaLRa1o0Bk23xqLp1Tg1Xo1fgzSCRtLImoSmT5PVDGlG NROaac0JzYJmUXNGc07zguZlzauaNzXvaH6q+YXm/9D8n5rfa/5R8wfNv2pWNVe012l12g9rb9D+ hX7brfrbbr11m37z5rv0t2+7S3+HfvPW2+Ct227Xb4Z/ws/gnTu26bdu0W++a4v+dvjXls36O+7Y qr9tK1xxp37Lnfptt8H4u/CoW/V3bYVL4TZ33gnD7tLfdbt+2523wT/v0N++Vb0dvLcN3/9W/Wb8 x2b9nVvx21v1d2zBf8K3LfqtMPPtW+H37frbbrsT/rlFvw1usOU2/V236rfeuRkmht94GfBzmAxu dvuW2/V34J/iC+GWW+/Es912G7wBK9lyh/6OzXDr2+Gp7oK/4weCm2+FVd4Bi96sLuFO+HaHRqN5 5Cuf+OpffO2TX//UN8q/+elvfebbFX+96Tu3aj/73duuu+l7t3+o8r7NGz73/Ts2fv7+O3V/+cBd ZV94cAtx80NbP3zLw9s+8sVH7v7oX91z/Zc+fu/HvnzjDRptQEtrGS2rRVpOy2sFbVAb0orasFbS RrRRrayNaeNaRZvQJrUpbZ+2X5vWZrRZ7YB2UJvTDmmHtXntiHZUO6Yd105oJ7XHtFPaae1x7Yz2 hHZWO6ed1y5oT2pPaRe1S9pntae1Z7TPac9qz2nPay9on9e+oL2ofVH7kvZl7SvaS9ofal/VbMfW d512x3X2DQ9sPKL7uu4K0fZh80fqP/rRj/78+sev/+cbuj6++0bPJ+b/gv/koU898anipys+zX/m uxW3Vyx8tu6mXZUHPpf4/NIX7vnCd29Wbmn54iNfPPmlni9HvvKtr6x97TNfe+frLd/452999dtf +vb8X//Lbd+8/YbN2+54/M6Gu+66a2XrX29t3nb9tpfuXrrn2L2O77i/+8Pv3fS9f/x+9/2bH6h4 4A83rP7jaiZXjijkp2naH6B9NEV7WCdDsjZkRnbkQCRH8h7Bx/sFKhgQ6WAgTEeJ4vWF552TjlH7 2CZH3pozZy3pzmRH3CA3ifUcUSxbW9IhivEzcE+K9jMU44Y7krQD7mjD9xRIzsPDPXlKoEOMwISQ SFRuOFaGcuE+RVaiiZDCE4UR3QQzzGbZLJ1mU+i0e94xY52xjHfnDEPt6aaYXjkqHkE16BB1hGwm G22tJiNhMnSY2npaLY32BleW7CdTjlRv0qb0JM1Kl2KMd8bb460Foni8ImoUrYKHJ3kfChBIV1RW bylHz5KzpmnT5NHcUymbYA2aBTNn4Jvggb609oPCvbpT7ExoUp6IDSey/dl0IhvNy0PBUTQB429Y HV/92vId5ehB8rHup7urmg/V6GsbnjE8adnVs91zP6pHDYJebAi1iB2SIdIlWSVrmBSpEBEI0UF1 C0Q2BF9hNookJooUFOGjKMpJnCSIghgMCkKQhxdHwBUBxaN40+4B7yA54jnmnXLPBRa5k+ysOC1P R8ZT+cF8NpNPHEtMhOfRaQLN+qcc487RnmFD1pBuTtbKtdED4pNcPdtIt9Ft/g7GyPcwrqA36pEC KZQjlgfLUEZMReRYNB5K88TymzqRCbIiHQqEAnBiPsHLeQU3ciMSGeken9PvcPucPLHWs6bR5YRB foDLoTwa595hL7kv2C9YFzunWqaa8/Xpw/0HpH3oKXW/dq9+brWsHG5g97n9pCfghm0u1w0ak4aI IdIWaketaK+n2l5vq+tqbjO0Go5aahy19mrfXl7PNIea5GbJGLckCNLpdnh7fbaAHVmRUbZkHQO2 Ye8xVHC5K04yc9Q0eZwct+V78uaMMdGWaAu3wFnUeo/Y9Lajnc16g95w0FRlq7I96r0PEfejneLT sX3xumTTQHO6a8gx6hjxjqNjKCtkQhkxE+6X03JK6Uslk6n+VLqPaEl0Z2zDvTnPMBpDM5FjyYnU WGYklzdnbXlynBz1HUen0OnoydRscnZwcixPjOaPZ+YT88qpyGkuzw4zA/Qgk/WnA0Qhp4uxEiWS IVIA18MmKRfJcvSifbHpWPPE/r7H+DbG4O9yd5OWXltPbw9p9nZ5jIFOZEQ7+w5ONk00Ldpe5IhJ diQ4KA9E00qiP9UnZ6RcZJCH44Ab/uLyoXI005tvybalD8eeEorOcIXZarc5HI5et9Pr9Dj8TtoB Lxe46KGBlgXTSdNL5E/RaTQXnIhORvLxdIrIJJJ9UkbKBLMoi89xZcPKZys33lAOQ9ysj/GyPjrA UuD4iGFoRHEB1s/5wGQ8vCfk5p0hB+8QejkrTxgZc8Dms3sdTtLuslEmqiPQQTchPfHVQnWZyIoM z4ZoPiAA7gi+99mblQJz8VIunihWXx7VIR9L0QwdKEGXlyUBaJwAMr3IhVwAXV6YnRICAh1keEZE YWJltPipMjfjFf0yFaX7UA7JfJQDT+PDgsiHQkFeCHIhPsQRhU/9VodeDp+TT8UW+qYHRgbzY+kp ZUqZDz/Lw6nRWSZL9QViAZmS/EE6SOGlEvCoPuTl8FpJvD+VG/oqN5hfLA/ZBRfy4j2iAlTASzsZ lwqxPbBWF+dEbhjo5yi8ToEWaYkofqjw2sa1Kd3NxUssfjR6E+3344dkPDQJg3thqAUe0wlY6gVs 9geZMALwEORgavmRyg0zFbwYDIUAOkLBiABvc3FeQUkuzWXZFKsghYmxEVqiwwGAdYqH2QkYVty5 ce3C6qlyML/uy5s2Lj+tK1pWNm28YfXcqnG5pxzd59nes9PyWMfT9YfqDx1o2mXcbdzu+i66H+2I VmWrMgfH9fP6OcNp68vWF9yvo58S6O3oa/2vpF/Kn505NbOweOz53MXBV2M/4X/MXCLPmy6YTrVM 1U7V5p/pe6JvZ2Q7+j62+/vB7BcDpzwnvbO9M+ZJ87hhSJ9u7DsUfZo7wNa69bZGa7vR1GpqsTWQ teRh6gDaR6B9YrVUKx1OHs20pJvzxumeqZ559xn+WWYucqxvKjkymB0fGEtOyydjs8Fn0dl1yN5Z eLcc7Xbvs9T0HGrXH20/2nqou8pRZX/cdz/ajp4Qn1b2Kocy+rx+yDBhme2ZcS/ioTPh6fgxZbJv NAeuPp6fyk3l5gZPDdSn9ZnWgdYBY86UNw/ZR1xj5Kh/Ek0T6KQ0lzqRnBmcmBybGJkbPJ06k3wx 8jr3Kvu8Z9GxZD9hHusYNQy2KHqlIVyP6gik97eQbWRLb5upw9zW0dnW1WrUm+p6ljrnu6e6poxj nTlDrj3dGmtVmsVG8BnYtdaVb5Wj4UDOPeAecPT1JK3JrpgBYk1bsIF7iN1ja2hpaO6pQVXIIBol k2RSzGkL0W8ZtIxYRyzHemZ6Xps4Mz29MDXbd0rdnrnL3ytHI1SezJE522BX1pRpzzRmmvvrsgcH 60wNphZLm7nDbDb1mHq7XIBEVCcyEGh7dt/JppMNP7T/mvsVe6lvfurkscwSekVFioMr96z8SzlQ ACfrRSQ2asbHBIB3YMTg/PDlFTwCeHrQK5CCkycFB+fgCTtjD9j9No+NtDps9h6LxdhjNLd26Ym1 X5e95/1+cBGf6v0O8CiYo0RcOP8HvX/1M2UIh1EcT8ExREHiI1wExbkErzBxCL4RNsysRzpaCCB4 EcXPlOWOZUcGBrNZAH2lP5aO9ofSoT4+zUOoZmUkszEmRsuMTEfpCPCjIE3g4TzD+Xm4AQcPh10f 1uRYt7vqlc+Xo6/4/tp2d+/Wjof0u/RPHDi4q+XJlvvtd6B70MPKntGq4UMLTc83nTe+7njX8Qvv 71FBQ6D/Jv0m9cvUz3NvTb049cLSqRcmLo69nfo77hfs6/YLhgvtJ2smq47tzj2s3K1sDX8L3YLN 4iFnObrEPO8/GzjtO+WZ8c44JxyjzuGewZ60JdmtdESMUnuwhatiDzr0xkZDh958kLBUO6q8O307 AtvRg+jroS3RH0QfTuzJ1g7U5FsneiYsc55F7jg7EcrH83KuL50lMtnkcHxcGY0ek2ak4+KcsMDP 86cw99DdsNxYeBMY5p95ULx6UKIQEiKcLMhwUEk+xSh40+kwpiRASAU4KA4f1JXPlKUrN5woR0d8 nb0Q1Qy+emA5HWGn4lA8Q2gGTUWGFSWhDIkz/AyTpxT4QbgTNVw9lNUvl6NH3U+anjHvbT10RF/f sB/4227zI567gZt8Za3hz+G04yVOG1fkVCgJnHZUl2fybI4dpkepYz4gb71TlmnTqDHXmmtL65V6 pTZ8CFXjk/uBoxw95563TPUcMw619xlSrXKr2BZsFdpgNZvXkoVv686y86FJ5Vh8pG8wN5DtG5En 4xPiFJr5X9j3yo1b/+c3vnL1pTKIdP9auSGIUai40fF1wxbDltqH9jxVVbX9yN0d9xq+4Sp+CBHF vM6BegWH7Ij6+oCUVG5w/xHnX9QVNjK/6/0bw0/bLtWe3Xu2aubRoe/lvxPfjL6hboqvHL3puWR/ yfai4ezRBf18NRh81eD3Y7cDH3jgiq/wkO6X7JvR89kX+hfHp+dn5vLn0pf6L0X+Bv1Gjca6/ZUb 33j/tsBRAmtwwba4YFsgFr9vWyiBCdI8i7dleaEMTdHHfOO+UXLYMeAYsCRNcZNsCLdyDezR3npD fWtt3cEq4vKH1zGJCeBg7QcxRa7fu3d9y99jJB+8t/c/fe//r/HuI2Wnz5+eXRpezD2rLPHHmYnA qHfUPezK2rP2dE/CkuqOdcvGsdF8fgikRq4vpxA5JRcdDA+GBoKD/EVmiZzpmTGPd+Sac42pI9FD cnWwGu0n1l4tu2H13tWPr24uR37EIBrRbAC+B5gAq35n6OKLl/+hgvHSwJIClA9OxkN7wMUc61wJ BCnn5F0QKIDyCP6QH0tS4EoXV/6BDoF4Cm8CDRVEQSQwAhLwk4NsAvkEdgwEL8bJKMYpfJpJsjFA 7Qg8ORFmgn64mgKqGShIl+0VQVKQC8EVOx4riJsE4IQicEOJl2G4wvXxSWBOURgexppt3Q3UjcMw 8pPVTOHRcmB/boB8LwQ4CHKAFn4Q15TPT/kcbpPL7Oh0tDhbHXpPrafWfTiwHxFb0PeUR/Lb80+e qL5QfVb/esfPjX/r+C/oX9C/KP81/27+3Zm3Tr9w+uKLC2+MvTn60+QvOWKGnQ5MUtPecc+IZ9Q1 7BoEw0mRkjfiDvnAACiVTPo44KK8ypwJgCgX41H3EywTmydDU0DOPawjZFdscbPSmexUWgCBGuKH wns5Yje711Vtqu6qb2463HzQuMeyw7oDlOzdaEvk/tRjfTtyz0zWTtScaFkyL5nOkyA9zrILoePK THw8PpTKK1kFhFJMCUf5EIhHgVXBAnyKg23hyWux8NzqrcVfgTmodu0HWMU+QwOwMlf90QVW7cG0 WgjwDEgCsOsQsVxb1mkwdhmtxp6uXqOry9XtM1JdfiPTgR5FVfGDuYO5hon2k23z5uecF50XfS+j 1wj0N9IbqVdSL+XOTZycnD8xsTj0bPZC7GU+z+SYAWqAGvRkyUHHoH2gZ9CS6853EAVtGQpxITAD 1QYACnmJg5MHE1IYGWwgCjJFpEXVgiDS+5GfqAS2ULxntav88NmaudrR2nxN4hBfxzR42i3t5q5O a4u1ydHgPeKpDdSiWlQdPBiuDR+OH001E8nmQUPeMmKe8sxzA2yG7w+D4oxmlGw82z8wMJDN5XOT RGENgHbjE5UbfrvytXJ0M/lN49bOu/QPHti1/4mdB7/Xen/bHfavoq+jLcqDow8O71qoPn/wXOMb pl92/9z1O1TQEuifYr/NvTv0i6m3ll44c/GlhXfGfzz2q9R/4/4r+0vHm4a32l+oXXxqqWrqkezd A9vkb6O/UiEX6Pjb1GuOS66XzedbF9tO1U3tG96X2xG/j/8+85jzGcO+9tqjLQdbq017HDsdO3yP ou0E+k744fiO2I5M1djB0eqZxtPGMx2XXD/mfsxeUp7Ln8nPTY8+O744cC52SXlZfBX9SOWHP1z5 zOpnAZoRiB3MC9UoS3sRmCwieYBoBG6PKNVVaQzNggpxpuUjCNBNCG0SBIxw4KpqxFIgYiUB43DE ktgwHS65qh8iFm1aO1JRLHz6T88FzJNxX5vLD2NobMB4ru7/cC6Fn2SyTIyK+0Me5MX3v2HZWfj7 3nK0PfAUWeeu623sNpgNHaYmR7OjzlcNcGblIBIC01WzayGcCGJEJkQgEVs4EpHEws35GJI4iQvz AGG8gH8FOUH9IfBNLOMQkUVpIRFOhWJyNBlVwv2hnDjITQH7Wv3uB0J5abExgMAEhPKrGyNe3Zh1 DvW9sv7KDX/7Pg51hDvKdoYdwKF86xwqrijK8DUOFX+PQzlXWyo3PF9+DWowxQfko2CHAwzFE2ua K4VrJAoU+/tIFI6PJRLlBRLlU0kULbCYRK0Wiv9WBvfACA0bBRggwnFGmAiAuALeGOVleLKIEAYv DamQz4k8sVqhZq2C4J6CH07RJ3g4DDzudV2u+7tK3Tdx6pO9mvoEsPbCatzqahzvW41qcNdWU6TL 1mqv/BsAFoThTTSO86BlsOG4WSfGNcAsD+dW47wPEC8QVA1IXHt89d8qmCtFHc62Mtem9LxvAwDs PjDlNRaZL0NDkbQSS8RSIrDI/0eXZfqYFJ2kFH/MI3siZMQpOcK9om35o1furQjplm9a3RZOS6lI fJOkROVIRJZiYiyoCAqfApKl0ckgXED9ByTQ/mFfyBv0hkgOpgf82ld2w8p84Z6iv5zFcZgKUH6m lFtxM24W54bW6S6P0w4UGC6OhLwUlIjlP1Tq7LwkhIPiJlGlG0A4uCjETZlXuBQbh8gJNhfAhCMI RJnzsr6Ab+0PlSu+CmAGyxc/Xfxo8V2adHts/k12ykg3lVLQgov38lTIz+OTR2FOCkYLNxZerYAY F/KHKGzCUvGdlf+rggIZhiIoLIREMRSMCuCbXIpLqxEf67QoGA8s1o8NCYcUoiBfbtjI6wrCSnNQ DoZDwU2icHUYQDCTYGNsjJZoEedI/IAXYNYUWfzJlU9W4Nh1J6aSzDrd838gAWW/RvcwkfS/j+4N lKHT9BxEbqB7vQO9QPeMcSPQvRaulj3SW2uoaz3859K9P4u9r02XLT27NL2Ue3ZwKbbEv8ScJk/0 zJknVfrWd0QG+iY+hXYQawtgGSsrf/fjcjBV8iqXYHx+WB8QadgcYu2NP+b3kxBCS+sBgxDC2BgE bAxJLskqrKqZWezOeD18AAdR4soflo+UYXIVhHfVjLNf9d1rObXV6GrL6ofLYRM8jE+FmQDjD/j9 bEDNJBDFT+vqiu9uLBA6GadU3WFS6AW8dSA3jSmlD68W/BYcH2cniWKF7nDx9+CVwD/Bn2lMi+BC CAFwkNj+8Ga7kQ/n97hS4AGGKc4Vfl9RHNfV4qEwM72J/aOhveuUH8cSzMdKcQQPPYGHluncrDdI yZSadUdRPsqB53BguxBa1vP9IkcUNunmCu9uLH5MvdwnU1G4PIuywYQYC0tSKAr+XKmbLbzDCXif N+EIERJEoLtR9eBhq9k4K6EoXeKrcOiw0cC6mdriTyoKY7qZwjvo6lBsM6WhWCOkuAQMjahDcf6f L2kEsPYjeGiZLsZI/pBbVLcXDmbtN4+V1+ONHy0teQKO6uMrP5kvhysg0iIgwgAkASD0rJO2IQu8 bNiO1eSnD2wZQyV8iUSxtbBSbC2uMFdBlloHWZBn4AGlzKdLcHJuwR+kMDCHEQS4kFyYXH6soti/ fI9fogEpNiGwOoACeKC4gLOfmfeRf5ALtEhjs8MuVKgt/rqiUF/4dSnIbgqWHIiLgGCKwWb0q2gQ RzE6CiEl5BeAsiJfwEt5i8m1LbCRa09uxJb57eVoOeqgehyki7T77Ryx9msdekY8GK2P1KWasobB tjHTtOO4/ZTvLDfPTvOTkYnQSGQwkoukwwkpJcpBiSPA9hmBDaoeKuD0kYf3qvlvrCr8GHJAOJXi aADvEEEHSMrqtXq6vO0+g7fZd5Q66jtC16Dvo0ejVZmq9MHR+rmGmfYzlpd7XnK/hX4JZFh+I/1K +qXR56bnj8+emjw7eDZ7MfYq/xbzInnadLrrRNv40fH6wYOJfcm94afQbqIVaO2z5fyvel6rO33k 2Sdy93JH2AZvm6PVZrSYjeZOe7uriWz2NzJ6YrlXzafc+g5mAgAUDAAFg/0igNm9ChSXD+k8yIPU Yw9SIhx6mIaYxMRQCmIFwBTE8yhornBQEiNiOCSFo0QhVOi7+OKpc5NnNk0vDi30z6ZnYtPipDjO j6IxlA8MuYe9OUfW2m9NmxIdcqfcKjbCIvVUE0m0kB0uo7PLYXbZXHaXi/LyAZVQ0DxgoYjDCotD YgwlMd1CEQJQK8zh8wdvBIcSI5IkxqP9sbSci4/ERuXx6LQ0FZ4OzXCvsOfcSzZi0TrTNdY22jqo TxxJ1oZr0WFUQ9f66nx1vTVdB7oONO49/OShXU9sv+++Yk2xqWL5RR0+ZDUSBsCIYSd4D++5Rk82 3lK5wfkWIC3r9HsDbr/PR/koj98LMRlwABFVOojCnAMIpCtMyqTkVMgUmXRkHPm1b650V5inzLOm WdOcZbbnBMHo+P3cfrRPfVUTlyEAqQVfBhcUwIi8jIv1rFMQACzBDWBL/alEVqRPiSdKiaxf6NLY HWglIPtln+yJklFXxBG1ypbCq2s/rEjr+5v7mvubks2p1lRzsjXVlmpNtCbaCF6HzjDn0EV0gT2P zhIrVWWIV/dYjQ/iOp8G7OETQBZiarzCJ7TO3f2IAYqytwzb15PLW8rRk96nbHvtTxmq9fUNtYdb qrqquh913Yf2omqxVqmN6dOtubbBjtGeKcu0/YRzkXCe9J72X6DO0S+gS+iccEF8PnRBPp88mzyb eTa3OHxy4sTM1InJpeHzmQvpS9EfcUSOzTE5OhcYCGQCA1SfX6ESvijYawijBnZOMCM1w4vtGuQ2 FtpuNd2Lk9sqftHAcynex+D6lytoF62iNWQKGkVjsFVo5Iid7FPOQ8bDRn2joc5QY37Gscex2/sk /WSflI5m5aw0GM1JuUg+lBdHgmPCOEe8xV50L1kXLTOdI01jzZkjsUPx6tB+9IxaPLGVo+PMpGfc N+bKW7PWbFeqNd4mN4QPc0a2izYGsEw2+Uwek7fbbSZ7SBvY253i/fJueVfiQKZpoGHIOOYY7Z3y zfHzzPHwWGo8MZTN5DPDiVFpMjoRPIamSulFfAR3rzxejnbTu327/U+ScBC2veZ9HQc7qpuP1DbV 6vd37rFU9Wz33IcMqJM3BA1CV9AkEuagNdQbdohkyBemRABqnDdXUB9SwPFxIQ5L7ZAAaieo5q6I CFBVJaBQqUA/lfEN+vOBPDVCT/CvMufjp3JLuemJkbnRueySciFxIfICeoVo7K617uvdb9vt3cE9 wD4R3d+/P10/1HasbcIy61h0nvKdQc+jC5FzybOp00Onjs0SUzMnR88NXsj+MP5j7jy76Jtzzjmm ekaNYx3DbemGgYZkbfywckDaJ+4NPSVUoV14px/oL0fvUm+TF8kXbIu4baBjuCXVkmiQavka5qi3 tbfNZjRbjD0GR7u72dtENaJmAh0JNkRapGals6873T1gHXONOqepee40+2x4MbGozGQmh1Qt/Nnl nsLPytHewAFPnfuwTW9qN7W2dTf06m0HfVXICtrRIlgFm9Ab6g3inSRFX9AvEgymmUGsVDDNY8JI AqGIuwniKgfHKilU6iYAp+NCPAHXQAyX/LiKKfsUfwJe/XQ/P8j0C4lQCiBPTspKOCPmQ8PCFFog VjeXIYHDqbGSAOYlHmtKTBZSbMlhIyBjIbKqZAGLbeLKA6q/6pc/VI66aavPRTk8ficQry8XB/9k Adfx30uXFgbXxsuADSBMx3DxEpQzBA8I6NiGZD6qSsIIPCou6WIxEgnKxLJ+ZTiIMSYEDF9SpQFO BcIQtSKaZpOgp4DsgD4JBzDbV6nx5dcLXy4D2UCFybBLsKJufPD/90q2nNGtbbu8f+PyPSv7wRci hX/ASvJP6Vr7uoIBGvjviwM/A3IsrO9lGLifxMVUcqz8x+S4svhldTO/sqwrRzvde83V5v3tR+qb 6hurO3dbd1l3eB5ENeiIcDTcEG4Kt8ltke6IRe6JkuBqhB9XiQFLmRATYUKwYzKYRxwlUFZIBaOi FBIlLszGqZS7j8y68i4i7xx3TXmOk7PUSW6BPS5OyJPySCKbHUj35eQROS+OoUk07Rt3jDry3bmO LGHINKWOyEfkg+LTcL436gIsTvr54Zz8aqoMV8hAhSTUM5J4EO2Y7AYB+kNAdnHRfaPuJDsjTsrT MNFAdijTl4uNKSPiJDqOhvw5b8474MxY07akSTHIndFWUc8R9Wwj1Uy2ONshxHc6LC4baXOSfh8H kyPYOQ5MBx56vbdGRikCSbyEZSIXhtAjYp4tBMVQKBxeD/ED8XwsL09Gp6Tp8GxoliNeZs96Fhyn 7MfNo4YxQ7ZZqU/Uh2vQQVQbqCcbSX1vq7nTYjCa2qytlkZHvZ9gy05Ss85p+7R1vHu4c8iQaUs0 JvXho6heFTD/uBrF51frryebPY2ONkuH1WAydvR0mtttOEHUSB71N3hq2H2IKP6X/1HJZEn3U+YV 77OO070nzJOGCcNgU7IuVScdgmDfwgAd9LWTHQ6Tw2g1d1tNFqPT4CKmvOOuMduYNW/KdgwY+lti eqVBrEM12Lxjyz8pR6OBvAfYlDPT04fLhK3RdqlO3AdH+vDaXYVndCeZKRFvUTbZ19+XjmelfCQX zKMRGP/TtV9BBKImXDj+5LozXf3til5uiB4OPcUTxfq1A4Wg7gRzDDjvSCSnDPRnU314u4fFcVwp xw0ly1PFeDkyMTa/h/L6Ah7Yg6hOja1YJvB+kQpR4UCUkegYUohK3TfKENaUUaCKYREfYxBnusLA 34hCVBdSqTRO4vGlVhIfUGkcnvEEXor0+T2wri2Vq98pbNGFUFC9VFjvPAEi5IGLyfXs1o1vqYyW 9bJuFa18gQCWfjjzS1z+0P/gnJbXdDgTHsL+D+oBZ7nUthY1Fw7SFOdXgI2p0hRkNUhanlgLrn1j +WFgiiFcacCL+oAYxuMYTAl9agLTD3KWxnV0Yu3htSPLsjofFm5BPA5z7fc1puDMe07NtjIMiDJQ rhR84RQPWUp+IUwD1QwDfIEDraPvR8oO7D1w5GnDPkOVY6eabK/OHfh3yfb3cu3jJ4mJ+Vk12X4+ dok/yyy55k0LXQtNszXEcroMS09wQRBbGABBbPExPsYlIJioAKjiFCbJcCaUGkwqV18FJbLysf9s gv1wuDZ8KN6QaiKSTf/ZBPsG/8qOkXIa9tUf8KtlKGDdAOa4ZceiJvjw5uNjgOjEU5j+QYQiaFXi 414+Orx2D27B8StqPgqiLqjQYERQQISmuCyXZtVcDCiO97gtPlximbjyzkZOV7i8+hYI8RCuPwVL iWZQoTyoI66fy7Ap2Jo4LTHBQJDiKQasGeSfY21bZXFnBXagHxQFMFTWBU8AyoHyUxTuGvLS2JaJ oqTzIl+QkvwRGmcSZIyFEHpwtggzAxyQuCAiClsqN14obtF5GV+IkoGm4YsBtEEg4SwFXK5ezKkU rSDpJIgn8IVTZdhFfbiTg8PGVrnyDq77rRQK/1aOHiOfMlWbqlvrjrTUNx8wYs64y/d4KWRF9OFm qU3uiBplCFngSB6J8IX90QDsojq7woE2BIIY4UtZErUjUuRAt/lTrhSErCEnkXeMu46T084F/xI3 w04GR+UxKa9k09m+viwgVi40iqbRpHfMNmTPmQcNGaKjv61fnwR0Tjb06VP6vsZMY3/bkGHEkDeN 22ZsU95T6Bw6G13sn0/P5Y9NjhDT+dnsUmJJeS5ygRthR+iRwCg1TOW8Q94Bd9rdTypenFMN4oQP 8B+eIjg4JORBJQWPFTHuA/OAp/pUdRAIqOqADNnkXskim+KESTZEW+U2qVGs5/RsK9Xp7SBNTmuv zebo8Zq93VQ36kINUkvKmOrImvIWIm8Z7zlmn7LBC75PWyZ7ps2jXfmOPA4G+lS9VIN7pFSnb1q2 l6N7vQ/aHrfvMD7ddLj5cF3jAdMB0x7X46gDdQggS0Jd4W6lO96d7Eqb+oyDHSNE8bqruUhAClyr w2CFc1zYF3C626PmOSHOA1Kw/2u5yPxQbiDXn+sbSgzEc/KgNCgOiDl+mH+NOe84ZTzVebxxpGbk UGafskt5IrQT7VBVj6UcnWQWfCeBuc9YJ2wT3cPtGUN/g1zDmxkLY6YsPrPb5DA7TT1dJpPJaOho IYrFslNVCzWzHXOtc44Fbo6dio5mRvoHhvsn+sfj09KcNBucRfPr28blr1am1C5p3zWCZ4WjAEwQ nDhJrbJwSlrrWLmp4vJNZX8mJfyfzJeuvVW2fGj5LcAJIDGbYFAQowXm5TKCYVyfOjBGS2yIXQcb CuEMoIfxBLxEwO11OR1r31+LVCwfWSvK1rCT928SfPgSVelFlnWFWyAgIytjY6y0ze8I2Kher8PT 6+l12YqVxboKMIuAWuMp9TwwuPTtVoMImD0PVJ0rBVUURCGgvCJRqCgMbyx8qgylhIQgY+4picDK g7KAWxNS8LBJRmZjdDQQDkiUiJvCSK4X2Uq5kesrN/Ss/vPVWEyWStqqL6kZXQ/rClkUa9yotCTb lKPKIaVGfib8OEc8yO5w7Dbu6dyvrz9UX926x/K4eYfrIfQA2hK/P7tjcMf4nhM1s4eXmi6Ynje9 RL7GEXPsieBsdE6aThzLEMsfK54rgwlDVNyP8SgHJBb3jl7r0cbNBmrn6PKtOtxXAdIKxESIEuEB eHgEHLSJNbIMWeheivQ7HKTF00Ma3a1kK9nmbvK2eJupZrop0Mw2oa+i2xP3jn1ndPvCUy8QT12o faP954af9f4G/RP65+Rvx94d/cXJty68eP6FNxZ+Nvmz8V+nfg8S8pR/3rvgPu6ZcBGTrhFn1jHo TLkkr+QNu3E/HWdHlmsY0FuO7vkABjQf6N7fXeXagYzIyJtCJrE7bIqZYmbF1GdOdqeNOWJtb9nV Mn1ApSk+tUx/rR7Bk5xH7dYF4RdiSmX6yg2/w/YcAsHIg/Tir/afxCCY4f4TCUVZCSfBSk0YpRJ6 8fqy/PDQQC6TSw/35ZRcfCg6HAH9GRzDit8FGNBxvGnk8MjhzNPKbmVX6LF1DOgpRwvMSd8CxgD7 hG2yawgwIK2PYAwwB8z+HsCAbqfF2d3TberqBgxoJYorZad2LdScAAyYdZwEDDgWHcmM9g8O902k J5TjgAEngnMlDKjc8K+rv/lgvRCCKuMC8yt1Kry/Xuh/r164/Pbar9be/t8FBcryr5YV3LXwnkLn pPVxJYWOkSBybZwKu+uqsrLslsqNvuPltCsAnAF4T8ANrgzLZBysHZkB5aw45ci7wJKBiuO0bSgQ pmNEcXC1fiOjKwpX6hkXA2M3BWCw99pgG2AHoAfqhcHOa4P9WLbHir+r3DBeEbjGk0p1u5gQB6qT AZ4EVAfFVZ6kLriUDaeIwsKVN3DdbnT1dR6blbiJD4qYQvJRNR+BedI6yaKjIHfDQCFV9gxBqvDs ldcrYOzx1deFECeqHEsNUOtjATGBYyXZGOwwGCc4MOAlIBrtDDiKv68sPg0c65EV7d+XIwtrp0l4 eTHD8vnJABkoddA76F6ml+6F061GR0JN8Wa5I23KEeZc77h7xjtN4Rbb5YHiJ8sAgtVG9IDaiA6a OIqli0qugioPU0tAnyg069QajfjvQmmJKH8wlJaIcrG5YFcb6YNqIUHA1gXah7vWSO93U+uN9PY1 Vod2RA/0taVbxu2LfIJRYCfiuK4OhxHB9Vxgo2CKQMZ5sE/Q1AECeC+IGA6n8V2qcFtZmS3cWQ50 ACeoPSxoGRY7C0gLivLCLwdpdllcJtLoMZKdvlZ/O9VKtyJiB9oV3ZfZl6kda55tmu08bX3J9oL7 TfQz9Gv5JwOXsq+MPHd8dnr25Ojp9Jn+C9GLHDHC5umhQJ7K+bKYcXlSrj5X3C35JAi/2EB4XDKk OB8m6KV8uoGxUvhhAyBpWFJ0yE7ZLluUnpgxDnRT/dDSvezO1tonaneabkdFHYGeCD0j18QOJfUZ Q7Z12DLmGLVP+XDHwyTo3uFYTskkBnB7U1yR5VCYJ9QeJxr3kcH8eJe9QH1dJaW1Mr/S8qbaFEGX hGNJ47G4ZgrCce05nRO5BG/EG6GA5BLHypDEh9dZdil9BbExFBXl5VuWr1SsfVrnYT0hn+yPgdEM YaPBqZT3jAYfFI5BCjByUVVPOOgDvuImf1X6Ei1lODKzXsbL4Oop1jmwN5Tb5137y7UrFct3g2ou 2U2wpDivKlVyXaF7KjfWlj9evOlA8XNtxZtbi7fYil9AxVtQ8Uup4hfHi385Xrz5VPHzLxZvCoJA gocEcUkxAT/udnCr2T0CCygvrgBxpc89qFgE6qnxtbY3DG8a3jC9aXm750eOt93veN+mfow/SfCO +CP5HflHyo/6fpR+O/tW/q38G6NvTr7JwS/QIVgIqNU6iY8iCC4cgR1YYqOAG7hcF8QtetgcKTUG Nq68PViO68HwRsAHp+JVqVwJxT24bwN7UhhFib8vqz98uGk/iJanXU+hA6hOrI/Xyy19hoGOAfNI 7zHHhHcGnUSn5fn0dHp6dHwmR8wMLPZdUM7Ll8Jv8kThxjd0aJIe9eZ9OTJr67OlzEpn1Ci1gNHV sXqq2dtCGtxGssvZQ9q8NtIV8HAEGAem0hwuhtI4l4ulVRTJKMHFwR8jYlSKRCOJSDY+IOeiwzIx Ko1HJsKTocngMf4Sc8G74DjVe9ycN+Tb043x2nhdaD+qItb+UFbcuvzt8uLNusNsnR/Ihgd0hcNk s1vJHtJEdUHw359sGOkYM8w6zvLzzGxsKjudmZmYXSQKVWWYCV5X0JSjA74Wm723t91Xi+qRIdyb 6FU842gJnYqMJlKpRD4yy82yeU/CkbCHW9Gh9fbq+9dbg0i1+x/LBwgvNNigH1joWsOVixW0Fwee gN8fwGLVDXEVf8zFCrHDhou9ICeBXKtpCIR78SLEsnP1lxsva3Uu1h32K1QskF5HURCJqutgUgbY hT/QQ6wEdFHYRbXqCwgRAi/lS3kU57pV25cny9F3Ave5H/B+3/FAz/2WB0wPGR7ufKjl4YbtuLiv tjmsyx81LQS0h8Dcx612flMQYmBxIi4dCtJLhc8uFT4/WvjCWOHmROGLqPAlVLilt/CF1sItbYWb DxQ+t6NwE1Hq9MLBer3JVIgCM0pyCtguhEOmVLJXQRfoBMcSbxY/f7Z480zxr2aKX+ovfhUVv7JO 6f7/1onyZzcePzd7evh07oxy5j9qRHmMWDtZ9sH0ldrHXRKlHlWU4uJBqQdL7eJWl3U1fbVv19O1 +4zwcu5Fu9C+aG26tr952DhpnOw5QS6SJ/0X0KvE8jwsv0Si8PJBUKntvzEuBdoVSBSKqbwVf3jq 2vLX0mVoT7Am0ia1yB1JU9KUtg64Bp15ahyI5QllbmxueH5+4SKx8uGyq53JwaAq1tQWg/fujWsZ IRqzq/d/tOGGVefyL5bZ8rXO/4BMrp/Gn2qhW+4sW7tuxeBTAjId2cRGOJVnRYBnlfJR/cCz1NYG JsziZifYMNwjRRW2r324IqVPHk01pOqT9al6QtAlppLHkzOp6dTx5HRh+/JHK3DeiIfbrbPNa7oz x4LyZBQaHiYgwjlgXw+QXgexdt1lw0bcCX7jB/g0mJZ73bCsagEId6SRgldQTxF8FveqEWs3Lvs3 rvn/N/VGXT5fVvjd8kdEcb1yFA5KQUmIrfeCJ64OZKNqN8m1AwO+yGJt7ff63KS3+LfFn1Usb1jr kFwgxahNEBQxh1Wl7JnKjRTuh6fw84D/wqhi6vI/VOCgDJqaotSGJbfaA/9+Ek6u98CDkQRLnxfc tXILIzHe4v2XbykNxiychihPk+/roMddAy5Vqr1/dDG5AlNKbAQ3NLNhwLBrxr9+ppys+m4afHe9 dZ4l1GQCJltwNIW2y/YKuGukcGDFzq23zqsmgYNy9AO+o9o3+15NnwsUWi73VgiejZGyQvOKHfPe 9zKf3NXO+9Jw3HUdfm946ZhK+H1+mS9HhhKx9QRcHLG2RUeyHtxjhQl2Hg0Gk6IsRiIhmSeWt5T6 Q1ncAqT2+V77lKma9Ti3fPPKLC5DWBgHlutAYN1uH1D7gI0xg6K0846gQ3CH8cem/TKdoBUmjT8S m+H7hISghOKRCMTosBJUhCSf4TMMmAqtBKI+ySN5RKfg4Ht5q9o2dfnRDaiL6YFp7OvT+NenwR/B L00TWp8mCdP0o8H3polFopIUFdVphAzODdPqNBQIf7foet80mIfWFQbKUbW31qa3NxjbWrpajUd7 asgaZzW1F7WgVr49ZBA7xa6wSbREbFJvhBS9EcIXoqJ0HMRQEg1cra1yYV6tnJUSwCFOYmVK8Sru PnfGTWTInCfvGXFPBKb5YWZYyIazYlpKxZLAlyPpSCqYhTCd82ccfc6UPdGtEJZYV8wgd0YMMXjJ hrhB6VS6kqasOW3LOUeced8xNIcmwhPKpDLen8/niPzARHo2MacsSuf4HDPIDNI5KhPop/p9KUqB hUSpcCBMAYbRuJMWDASnYDksVjABdmKFAuwXtycDE6dZnDYKcBTrEUhwUYdkjRBWyRw2St1hQ7CF NzBdAZPf7LN6HKTD5Xb47JTdbwNHNIRNik2xpnozTiLrGCTz7mEyj1+uvDPvGHbkbJmeAXOyK96h tIWa1c9p4kT4b682SbO4NQpHbSA9OKdSqvkY1h5b3qN2B8ELW7m/xMD5UvrYsd57qdZ88LirzdV7 1qb/qLnaey1H+d9JM/zR/7qw/PP1MlUQ52RA4Qk4t3utbxqI3ObXVRpXEjM49AJOqVUwChGXt+nU YKhyV/zfRQD9BtbFgP/iDkceuCuvmk6p6KsSs8LAaouuyBe/5vK6A160yUP7MZcC+r3ek5XCVodF EW6DL30sBwecUKhwprCnQgCswq0iIpihiJuDeQnhHgAQxgyusVzFGk7tXcQVpGKo4CzD0iiIQ12p wRRsQ8DdV+5r3Ve25c5ydDf5cNdO02NNe2tqa2v2tuw07zQ95P4OehA9Gn0ysyv99GjdXO1My2nT S90vut5CPydW5v9E8iXGX2uPAC/6d8mXy9ky9Li0VzmsHMo05NvzrROmGcdM70nfEneGXQjPJGaU yczQaH4kM60sKHPiGQQcYlxNDmEOcbV14INJHjxPSKW615JDl8fKbtBo/l8RcqEaCmVuZHN0cmVh bQplbmRvYmoKMjIgMCBvYmoKPDwvVHlwZS9NZXRhZGF0YQovU3VidHlwZS9YTUwvTGVuZ3RoIDE5 NzM+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6 a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRhIHhtbG5z Ong9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJhbWV3 b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8y Mi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+ CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSdhMjM4YTg5Ni01ZWI0LTExZTAtMDAwMC05YjE4 ODBmNDhhYWEnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlBy b2R1Y2VyPSdcMzc2XDM3N1wwMDA3XDAwMC1cMDAwUFwwMDBEXDAwMEZcMDAwIFwwMDBQXDAwMHJc MDAwaVwwMDBuXDAwMHRcMDAwZVwwMDByXDAwMCBcMDAwL1wwMDAgXDAwMGhcMDAwdFwwMDB0XDAw MHBcMDAwOlwwMDAvXDAwMC9cMDAwd1wwMDB3XDAwMHdcMDAwLlwwMDA3XDAwMC1cMDAwcFwwMDBk XDAwMGZcMDAwLlwwMDBjXDAwMG9cMDAwbVwwMDAgXDAwMC9cMDAwIFwwMDBQXDAwMGVcMDAwclww MDBzXDAwMG9cMDAwblwwMDBhXDAwMGxcMDAwIFwwMDBFXDAwMGRcMDAwaVwwMDB0XDAwMGlcMDAw b1wwMDBuXDAwMCBcMDAwXChcMDAwblwwMDBvXDAwMHRcMDAwIFwwMDByXDAwMGVcMDAwZ1wwMDBp XDAwMHNcMDAwdFwwMDBlXDAwMHJcMDAwZVwwMDBkXDAwMFwpJy8+CjxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSdhMjM4YTg5Ni01ZWI0LTExZTAtMDAwMC05YjE4ODBmNDhhYWEnIHhtbG5zOnht cD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyc+PHhtcDpNb2RpZnlEYXRlPjIwMTEtMDQt MDFUMTQ6MTE6MTIrMDI6MDA8L3htcDpNb2RpZnlEYXRlPgo8eG1wOkNyZWF0ZURhdGU+MjAxMS0w NC0wMVQxNDoxMToxMiswMjowMDwveG1wOkNyZWF0ZURhdGU+Cjx4bXA6Q3JlYXRvclRvb2w+VW5r bm93bkFwcGxpY2F0aW9uPC94bXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSdhMjM4YTg5Ni01ZWI0LTExZTAtMDAwMC05YjE4ODBmNDhh YWEnIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpE b2N1bWVudElEPSdhMjM4YTg5Ni01ZWI0LTExZTAtMDAwMC05YjE4ODBmNDhhYWEnLz4KPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2EyMzhhODk2LTVlYjQtMTFlMC0wMDAwLTliMTg4MGY0OGFh YScgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9 J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gt ZGVmYXVsdCc+XDM3NlwzNzdcMDAwTVwwMDBpXDAwMGNcMDAwclwwMDBvXDAwMHNcMDAwb1wwMDBm XDAwMHRcMDAwIFwwMDBXXDAwMG9cMDAwclwwMDBkXDAwMCBcMDAwLVwwMDAgXDAwMFJcMDAwZVww MDBzXDAwMHBcMDAwb1wwMDBuXDAwMHNcMDAwZVwwMDAtXDAwMHRcMDAwb1wwMDAtXDAwMENcMDAw T1wwMDBNXDAwMDFcMDAwNVwwMDAtXDAwMExcMDAwU1wwMDAyXDAwMDNcMDAwOVwwMDAtXDAwMDFc MDAwNTwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2VxPjxy ZGY6bGk+XDM3NlwzNzdcMDAwVVwwMDBzXDAwMGVcMDAwcjwvcmRmOmxpPjwvcmRmOlNlcT48L2Rj OmNyZWF0b3I+PC9yZGY6RGVzY3JpcHRpb24+CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/PgplbmRzdHJlYW0K ZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoXDM3NlwzNzdcMDAwN1wwMDAtXDAwMFBcMDAwRFww MDBGXDAwMCBcMDAwUFwwMDByXDAwMGlcMDAwblwwMDB0XDAwMGVcMDAwclwwMDAgXDAwMC9cMDAw IFwwMDBoXDAwMHRcMDAwdFwwMDBwXDAwMDpcMDAwL1wwMDAvXDAwMHdcMDAwd1wwMDB3XDAwMC5c MDAwN1wwMDAtXDAwMHBcMDAwZFwwMDBmXDAwMC5cMDAwY1wwMDBvXDAwMG1cMDAwIFwwMDAvXDAw MCBcMDAwUFwwMDBlXDAwMHJcMDAwc1wwMDBvXDAwMG5cMDAwYVwwMDBsXDAwMCBcMDAwRVwwMDBk XDAwMGlcMDAwdFwwMDBpXDAwMG9cMDAwblwwMDAgXDAwMFwoXDAwMG5cMDAwb1wwMDB0XDAwMCBc MDAwclwwMDBlXDAwMGdcMDAwaVwwMDBzXDAwMHRcMDAwZVwwMDByXDAwMGVcMDAwZFwwMDBcKSkK L0NyZWF0aW9uRGF0ZShEOjIwMTEwNDAxMTQxMTEyKzAyJzAwJykKL01vZERhdGUoRDoyMDExMDQw MTE0MTExMiswMicwMCcpCi9UaXRsZShcMzc2XDM3N1wwMDBNXDAwMGlcMDAwY1wwMDByXDAwMG9c MDAwc1wwMDBvXDAwMGZcMDAwdFwwMDAgXDAwMFdcMDAwb1wwMDByXDAwMGRcMDAwIFwwMDAtXDAw MCBcMDAwUlwwMDBlXDAwMHNcMDAwcFwwMDBvXDAwMG5cMDAwc1wwMDBlXDAwMC1cMDAwdFwwMDBv XDAwMC1cMDAwQ1wwMDBPXDAwME1cMDAwMVwwMDA1XDAwMC1cMDAwTFwwMDBTXDAwMDJcMDAwM1ww MDA5XDAwMC1cMDAwMVwwMDA1KQovQXV0aG9yKFwzNzZcMzc3XDAwMFVcMDAwc1wwMDBlXDAwMHIp Pj5lbmRvYmoKeHJlZgowIDIzCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwODcwOSAwMDAwMCBu IAowMDAwMDI2NTEyIDAwMDAwIG4gCjAwMDAwMDg2NDMgMDAwMDAgbiAKMDAwMDAwODMyMSAwMDAw MCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDUwMzcgMDAwMDAgbiAKMDAwMDAwODc5OSAw MDAwMCBuIAowMDAwMDA5NjI1IDAwMDAwIG4gCjAwMDAwMTA2MjEgMDAwMDAgbiAKMDAwMDAxMDQ5 NCAwMDAwMCBuIAowMDAwMDEwNTU2IDAwMDAwIG4gCjAwMDAwMDg4NDAgMDAwMDAgbiAKMDAwMDAw ODg3MCAwMDAwMCBuIAowMDAwMDA4NDgxIDAwMDAwIG4gCjAwMDAwMDUwNTcgMDAwMDAgbiAKMDAw MDAwODMwMCAwMDAwMCBuIAowMDAwMDA4OTIyIDAwMDAwIG4gCjAwMDAwMDg5NTIgMDAwMDAgbiAK MDAwMDAxMTE1OSAwMDAwMCBuIAowMDAwMDA4OTgyIDAwMDAwIG4gCjAwMDAwMTAwNjYgMDAwMDAg biAKMDAwMDAyNDQ2MiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDIzIC9Sb290IDEgMCBSIC9J bmZvIDIgMCBSCi9JRCBbPDNBRTg1QzkxQjg0RDBFMUVCMUIwRDlCODFDNzhCMUYxPjwzQUU4NUM5 MUI4NEQwRTFFQjFCMEQ5QjgxQzc4QjFGMT5dCj4+CnN0YXJ0eHJlZgoyNzI1NQolJUVPRgo= ------=_NextPart_000_1388_01CBF077.60B1F180-- From agmalis@gmail.com Fri Apr 1 05:33:51 2011 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 F16E128C254 for ; Fri, 1 Apr 2011 05:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.171 X-Spam-Level: ** X-Spam-Status: No, score=2.171 tagged_above=-999 required=5 tests=[AWL=-4.770, BAYES_00=-2.599, FR_P_END_P_MANY10=10.539, HTML_MESSAGE=0.001, 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 fcw2Y2-gJFNd for ; Fri, 1 Apr 2011 05:33:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 2FB0F28C208 for ; Fri, 1 Apr 2011 05:32:17 -0700 (PDT) Received: by vws12 with SMTP id 12so3108269vws.31 for ; Fri, 01 Apr 2011 05:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bjqA6TpB6I/UtFLt1OCY7A+KBR1Ig5fychX3zycyvlg=; b=ExEd83DDhYBZH29xY6sDJ7ef/WER6z4kllFXzqFE26K1G0Fsi+0JQX0RL/G07yA4rE 59drblmNaG1nzzQP7C2VFHQYefKh/7FJetoKOL8uevob1YM8+YPmeACWNg2TCAtL3Nll kvbpaVyG1cqlhLBNxYbIhtWPKRkWJZdkKC26I= 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 :cc:content-type; b=vq0Qb3PjTymhN1C52aGhGke5gGa7UkohGaS64VxPcn/Lp6KplQ947kTEpQr3lnxn6Z XaXyUSP+bHOId0dDk3hWA7So+trvLKH4bz1WXnaqQ98MwhHuQgVrWI7XLmW4cSCxpchm N9XRkqtPWJ4l4t3aCaePTZGuF+a6lUtQ+lvYM= Received: by 10.220.198.200 with SMTP id ep8mr1057654vcb.132.1301661237346; Fri, 01 Apr 2011 05:33:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.192.198 with HTTP; Fri, 1 Apr 2011 05:33:37 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 1 Apr 2011 14:33:37 +0200 Message-ID: To: Malcolm.BETTS@zte.com.cn Content-Type: multipart/alternative; boundary=90e6ba53a872ab8401049fda9f21 Cc: mpls@ietf.org Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? 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, 01 Apr 2011 12:33:51 -0000 --90e6ba53a872ab8401049fda9f21 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Malcolm, I 'm not aware of anything in the IETF specifications that's inconsistent with this requirement, which is clear in section 2.3 in RFC 5654 and sectio= n 2.1.4 in RFC 5860 (and perhaps elsewhere as well). Cheers, Andy On Fri, Apr 1, 2011 at 9:26 AM, wrote: > > All, > > True that in most cases an IP stack is present somewhere in most nodes to > support a management interface. However, this does not mean that high > bandwidth or high reliability access is provided to that stack from the > cards that support the forwarding plane functionality. Typically in smal= l > transport nodes the card supporting the management interface has a low > bandwidth and is non-redundant since if that card fails the forwarding pl= ane > is not affected (including OAM and protection). This is the reason that > MPLS-TP forwarding and dataplane OAM must run IP free. > > This requirement was one of the primary inputs from the ITU and I am very > surprised that people are raising questions at this stage. > > Regards, > > Malcolm > > > > *venkatesan mahalingam * > Sent by: mpls-bounces@ietf.org > > 31/03/2011 04:12 PM > To > "Santiago Alvarez (saalvare)" , mpls , > Alexander Vainshtein > cc > Subject > Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean tha= t > MPLS-TP is IP-free? > > > > > Hi, > > I think, we need at least an IP host stack on every node along the MPLS-T= P > path to support the IP based management operations (ex. SNMP). > > Thanks, > Venkat. > On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) <* > saalvare@cisco.com* > wrote: > MPLS-TP nodes would need an IP host stack to be able to source/sink IP > traffic for management (e.g. SNMP). An LSR should not have an IP routing > function with the exception of a LER where IP acts as a client. That IP > routing/forwarding function should be defined in RFC 1812. > > Cheers. > > > > SA > > -- > > *From:* *mpls-bounces@ietf.org* [mailto:* > mpls-bounces@ietf.org* ] *On Behalf Of *Alexander > Vainshtein* > Sent:* Thursday, March 31, 2011 10:31 AM* > To:* Luca Martini (lmartini)* > Cc:* *mpls@ietf.org* * > Subject:* [mpls] Do we need to reinvent TCP/IP, or what does it really > mean that MPLS-TP is IP-free? > > > > Luca and all, > > What I have been trying to say at the mike today can be essentially reduc= ed > to a very simple statement: > > > > The =A1=B0requirement=A1=B1 for IP-free MPLS-TP is very vague and require= s > clarification. > > > > MPLS-TP nodes presumably have to be managed (especially if they are > supposed to operate independent of any control plane). And personally I d= o > not believe they are going to be managed by connecting a local terminal v= ia > a serial cable to each of these nodes (of course you are free to disagree= J). > > > > > This assumes a Management Communication Network (MCN), and , IMHO, this > assumption is ensconced in RFC 5951 (which states that typically MPLS-TP > nods can be expected o have addresses on the MCN) while RFC 5718 provides > the required infrastructure for the MCN over G-ACH. > > > > Of course we can pretend that we do not know which network protocol will > run on top of the MCN (and some people have been arguing that we should > select the OSI stack for that purpose in the early days of the MPLS-TP > work); but I would expect that within the IETF refusal to use IP in this > role should not be taken too seriouslyJ. The recent work on SNMP MIBs > architecture for MPLS-TP looks to me as an additional confirmation. > > > > Hence it seems safe to assume that each MPLS-TP node will run at least a > host IP stack (not necessarily in the forwarding path). > > > > Once we agree on that, we could stop reinventing =A1=B0TCP/IP for poor=A1= =B1 with > proprietary solutions for reliability, fragmentation/reassembly, congesti= on > avoidance etc. > > > > My 2c, > > Sasha > > > > _______________________________________________ > 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 > > --90e6ba53a872ab8401049fda9f21 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 7bit Malcolm,


I 'm not aware of anything in the IETF specifications that's inconsistent with this requirement, which is clear in section 2.3 in RFC 5654 and section 2.1.4 in RFC 5860 (and perhaps elsewhere as well).

Cheers,
Andy

On Fri, Apr 1, 2011 at 9:26 AM, <Malcolm.BETTS@zte.com.cn> wrote:

All,

True that in most cases an IP stack is present somewhere in most nodes to support a management interface.  However, this does not mean that high bandwidth or high reliability access is provided to that stack from the cards that support the forwarding plane functionality.  Typically in small transport nodes the card supporting the management interface has a low bandwidth and is non-redundant since if that card fails the forwarding plane is not affected (including OAM and protection).  This is the reason that MPLS-TP forwarding and dataplane OAM must run IP free.

This requirement was one of the primary inputs from the ITU and I am very surprised that people are raising questions at this stage.

Regards,

Malcolm



venkatesan mahalingam <venkatflex@gmail.com>
Sent by: mpls-bounces@ietf.org

31/03/2011 04:12 PM

To
"Santiago Alvarez (saalvare)" <saalvare@cisco.com>, mpls <mpls@ietf.org>, Alexander Vainshtein <alexander.vainshtein@ecitele.com>
cc
Subject
Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?





Hi,

I think, we need at least an IP host stack on every node along the MPLS-TP path to support the IP based management operations (ex. SNMP).

Thanks,
Venkat.
On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) <saalvare@cisco.com> wrote:
MPLS-TP nodes would need an IP host stack to be able to source/sink IP traffic for management (e.g. SNMP).  An LSR should not have an IP routing function with the exception of a LER where IP acts as a client. That IP routing/forwarding function should be defined in RFC 1812.

Cheers.

 

SA

--

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Thursday, March 31, 2011 10:31 AM
To: Luca Martini (lmartini)
Cc: mpls@ietf.org
Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?

 

Luca and all,

What I have been trying to say at the mike today can be essentially reduced to a very simple statement:

 

The “requirement” for IP-free MPLS-TP is very vague and requires clarification.

 

MPLS-TP nodes presumably have to be managed (especially if they are supposed to operate independent of any control plane). And personally I do not believe they are going to be managed by connecting a local terminal via a serial cable to each of these nodes (of course you are free to disagreeJ).  

 

This assumes a Management Communication Network (MCN), and , IMHO, this assumption is ensconced in RFC 5951 (which states that typically MPLS-TP nods can be expected o have addresses on the MCN) while RFC 5718 provides the required infrastructure for the MCN over G-ACH.

 

Of course we can pretend that we do not know which network protocol will run on top of the MCN (and some people have been arguing that we should select the OSI stack for that purpose in the early days of the MPLS-TP work); but I would expect that within the IETF refusal to use IP in this role should not be taken too seriouslyJ. The recent work  on SNMP MIBs architecture for MPLS-TP looks to me as an additional confirmation.

 

Hence it seems safe to assume that each MPLS-TP node will run at least a host IP stack (not necessarily in the forwarding path).

 

Once we agree on that, we could stop reinventing “TCP/IP for poor”  with proprietary solutions for reliability, fragmentation/reassembly, congestion avoidance etc.

 

My 2c,

     Sasha

 

_______________________________________________
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


--90e6ba53a872ab8401049fda9f21-- From fjjc@tid.es Fri Apr 1 06:57:00 2011 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 E86D13A681C for ; Fri, 1 Apr 2011 06:56:59 -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 YRXXutnV5AVY for ; Fri, 1 Apr 2011 06:56:57 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by core3.amsl.com (Postfix) with ESMTP id DF9AB3A67FC for ; Fri, 1 Apr 2011 06:56:56 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIZ00EWJ85JKI@tid.hi.inet> for mpls@ietf.org; Fri, 01 Apr 2011 15:58:31 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 15.95.02936.233D59D4; Fri, 01 Apr 2011 15:29:22 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIZ00EWG85JKI@tid.hi.inet> for mpls@ietf.org; Fri, 01 Apr 2011 15:58:31 +0200 (MEST) Received: from [10.95.50.20] (10.95.67.43) by htcasmad1.hi.inet (10.95.67.73) with Microsoft SMTP Server id 8.3.83.0; Fri, 01 Apr 2011 15:58:31 +0200 Date: Fri, 01 Apr 2011 15:56:41 +0200 From: Javier Jimenez In-reply-to: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> To: undisclosed-recipients: ; Cc: "mpls@ietf.org" Message-id: <4D95D999.604@tid.es> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 X-AuditID: 0a5f4068-b7c9eae000000b78-05-4d95d3321a60 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsXCFe/ApWt0eaqvwdWjoha3lq5kdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsYvR1gKpgtUTJlyi7mBcS5vFyMHh5CAlMSpj6VdjJwcEgIm EnPmHmCCsMUkLtxbz9bFyAVUspFR4tbvVawgCREBGYm5sx+zQiR+MEqcOnqZEcKZziix5+MO NpAqFgFViUmvpoKNYhNQknjUeBOsW1hAS+LuzUOMIDangLfEphUP2EFsZgFliffPJ4LFeQUU JR6+fMkOYQtK/Jh8jwWixlri1LeVzBC2tsSTdxdYQT4QFciRaPmuDRIWEvCSOH/iNfMERqFZ SLpnIemehaR7ASPzKkax4qSizPSMktzEzJx0A0O9jEy9zLzUkk2MkKDN2MG4fKfKIUYBDkYl Hl6Bf1N8hVgTy4orcw8xSnIwKYnyzro+1VeILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK9hL1CO NyWxsiq1KB8mJcPBoSTB23wTKCVYlJqeWpGWmQOMTZg0EwcnSDsPUHs1SA1vcUFibnFmOkT+ FKMqx+K1U/cxCrHk5eelSonzdoAUCYAUZZTmwc15xSgOdLAwxAgeYHKBm/AKaDgT0PCjE8CG lyQipKQaGHlrelsVumxvT971wtXrmE2JCZ9ygWda3Y2qqcfZ7ITm20Z/2lb861jq7I2WyRGG hjpKDxkXsol/6H07+8tW+a8FPe7nT04PmpfxsXbz86Lrv/5vm3lG/rWebKjJ7o552Tk+vmyz JjgELuhfsSbr0hZTRpOUohq++qYtwtFXOmbrL3KOKPyXrcRSnJFoqMVcVJwIAEj3i0TrAgAA References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> Subject: [mpls] Questions on seamless 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: Fri, 01 Apr 2011 13:57:00 -0000 Hi all, Here in Telef=F3nica we are pushing for MPLS E2E solutions, and it seems the seamless MPLS draft respresents a great starting point. Congratulations to the authors for this nice piece of work. I have two questions, not being involved in the draft so far: 1.- The draft proposes to use the next-hop-self in the outwards direction (with respect to an specific regional area) and to leave next-hop-unchanged for the incoming traffic. This approach requires that some routing information is flooded from the core area to the regional ones (specificallly, reachability to the ABRs). I'm sure this design increases the scalability of the solution, but two concerns come to my mind= : - Wouldn't it be cleaner to perform the next-hop-self in both directions? I come from the transport world, where things tend to be symetrical (and easier to understand for humans). - More specifically, when migrating to a seamless architecture, it may be the case that the IGPs are already different in the core and in the regions (also the label distribution protocols), and it could not be possible to flood external IGP information into the regional areas or the operator would prefer to keep IGP clear from external influece (for that reason you have BGP). In summary, would there be room for two options (and which are the pros & cons) or just the one recommended in the draft? 2.- Right now, VPLS services are typically offered only on a regional basis due to scalability issues. How would a VPLS service scale on top of a seamless MPLS architecture? Is this requirement part of the architecture or has been intentionally removed? Kind regards, Javier Jimenez Telef=F3nica Research Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From venkatflex@gmail.com Fri Apr 1 07:40:32 2011 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 70BB93A6863 for ; Fri, 1 Apr 2011 07:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.517 X-Spam-Level: ** X-Spam-Status: No, score=2.517 tagged_above=-999 required=5 tests=[AWL=-6.024, BAYES_00=-2.599, FR_P_END_P_MANY10=10.539, HTML_MESSAGE=0.001, J_CHICKENPOX_75=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 hcMaGaMfttMf for ; Fri, 1 Apr 2011 07:40:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 9F5AB3A6835 for ; Fri, 1 Apr 2011 07:40:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so3239100vxg.31 for ; Fri, 01 Apr 2011 07:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=TeUXqJazowlIFCUsuA4NmgYc0srNh9GBbkLwOZgUkAA=; b=iklbqlI7kVG+n8nmUjeqSVCDGfM+Goa6Wu8ZyP9pjckLGycH41S+AXRoJwQxhmgKA/ +yXH8h8p2SygSW7M/t7+tSS6+qG7WEGYAoBC4+d9Bc/rSUSBfqUXDaAzid3ahJqt2+Vj GDhtlmYIffJvg4RgAVF49MwrTz2G9ZnczT61E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IGxzovr7Sw0rNQzHG7oqZ4rEEVB+trkBrzzk6idwmcva2mfvkwDLuA458FCXsIpE9L J9kcipRSIJ+BME51VESZV1ZBnhM9KtuIw6DWQUfVo2LzYHuLDqOlj1BuAu6YCE17zdGc 5y0J0qqrgLXsIbbnHF1V9kHyJCuRIO6gy5dag= MIME-Version: 1.0 Received: by 10.52.92.161 with SMTP id cn1mr5638041vdb.253.1301668929686; Fri, 01 Apr 2011 07:42:09 -0700 (PDT) Received: by 10.52.164.230 with HTTP; Fri, 1 Apr 2011 07:42:09 -0700 (PDT) Date: Fri, 1 Apr 2011 10:42:09 -0400 Message-ID: From: venkatesan mahalingam To: mpls Content-Type: multipart/alternative; boundary=20cf3071ced82b4c9c049fdc6aef Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? 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, 01 Apr 2011 14:40:32 -0000 --20cf3071ced82b4c9c049fdc6aef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, If we don't have the host IP stack on every node in the -TP network, we may have to follow the management channel as given in the RFC 5960, 2.5. Management Channel. IMO, this channel can be used to configure the remote Non-IP systems using management messages. Thanks, Venkat. Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? ------------------------------ - *To*: Malcolm.BETTS at zte.com.cn - *Subject*: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? - *From*: "Andrew G. Malis" > - *Date*: Fri, 1 Apr 2011 14:33:37 +0200 - *Cc*: mpls at ietf.org - *Delivered-to*: mpls at core3.amsl.com - *Dkim-signature*: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dgmai= l.com; s=3Dgamma; h=3Ddomainkey-signature:mime-version:in-reply-to:references:f= rom:date :message-id:subject:to:cc:content-type; bh=3DbjqA6TpB6I/UtFLt1OCY7A+KBR1Ig5fychX3zycyvlg=3D; b=3DExEd83DDhYBZH29xY6sDJ7ef/WER6z4kllFXzqFE26K1G0Fsi+0JQX0RL/G07yA4rE 59drblmNaG1nzzQP7C2VFHQYefKh/7FJetoKOL8uevob1YM8+YPmeACWNg2TCAtL3Nll kvbpaVyG1cqlhLBNxYbIhtWPKRkWJZdkKC26I=3D - *Domainkey-signature*: a=3Drsa-sha1; c=3Dnofws; d=3Dgmail.com; s=3Dgam= ma; h=3Dmime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=3Dvq0Qb3PjTymhN1C52aGhGke5gGa7UkohGaS64VxPcn/Lp6KplQ947kTEpQr3lnxn6Z XaXyUSP+bHOId0dDk3hWA7So+trvLKH4bz1WXnaqQ98MwhHuQgVrWI7XLmW4cSCxpchm N9XRkqtPWJ4l4t3aCaePTZGuF+a6lUtQ+lvYM=3D - *In-reply-to*: > - *List-archive*: - *List-help*: > - *List-id*: Multi-Protocol Label Switching WG - *List-post*: > - *List-subscribe*: , < mailto:mpls-request@ietf.org?subject=3Dsubscribe > - *List-unsubscribe*: , < mailto:mpls-request@ietf.org?subject=3Dunsubscribe > - *References*: > > ------------------------------ Malcolm, I 'm not aware of anything in the IETF specifications that's inconsistent with this requirement, which is clear in section 2.3 in RFC 5654 and sectio= n 2.1.4 in RFC 5860 (and perhaps elsewhere as well). Cheers, Andy On Fri, Apr 1, 2011 at 9:26 AM, wrote: > > All, > > True that in most cases an IP stack is present somewhere in most nodes to > support a management interface. However, this does not mean that high > bandwidth or high reliability access is provided to that stack from the > cards that support the forwarding plane functionality. Typically in smal= l > transport nodes the card supporting the management interface has a low > bandwidth and is non-redundant since if that card fails the forwarding pl= ane > is not affected (including OAM and protection). This is the reason that > MPLS-TP forwarding and dataplane OAM must run IP free. > > This requirement was one of the primary inputs from the ITU and I am very > surprised that people are raising questions at this stage. > > Regards, > > Malcolm > > > > *venkatesan mahalingam * > Sent by: mpls-bounces at ietf.org > > 31/03/2011 04:12 PM > To > "Santiago Alvarez (saalvare)" , mpls ietf.org>, Alexander Vainshtein > cc > Subject > Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean tha= t > MPLS-TP is IP-free? > > > > > Hi, > > I think, we need at least an IP host stack on every node along the MPLS-T= P > path to support the IP based management operations (ex. SNMP). > > Thanks, > Venkat. > On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) <*saalvare a= t > cisco.com* > wrote: > MPLS-TP nodes would need an IP host stack to be able to source/sink IP > traffic for management (e.g. SNMP). An LSR should not have an IP routing > function with the exception of a LER where IP acts as a client. That IP > routing/forwarding function should be defined in RFC 1812. > > Cheers. > > > > SA > > -- > > *From:* *mpls-bounces at ietf.org* [mailto:*mp= ls-bounces > at ietf.org* ] *On Behalf Of *Alexander > Vainshtein* > Sent:* Thursday, March 31, 2011 10:31 AM* > To:* Luca Martini (lmartini)* > Cc:* *mpls at ietf.org* * > Subject:* [mpls] Do we need to reinvent TCP/IP, or what does it really > mean that MPLS-TP is IP-free? > > > > Luca and all, > > What I have been trying to say at the mike today can be essentially reduc= ed > to a very simple statement: > > > > The =93requirement=94 for IP-free MPLS-TP is very vague and requires > clarification. > > > > MPLS-TP nodes presumably have to be managed (especially if they are > supposed to operate independent of any control plane). And personally I d= o > not believe they are going to be managed by connecting a local terminal v= ia > a serial cable to each of these nodes (of course you are free to disagree= J). > > > > > This assumes a Management Communication Network (MCN), and , IMHO, this > assumption is ensconced in RFC 5951 (which states that typically MPLS-TP > nods can be expected o have addresses on the MCN) while RFC 5718 provides > the required infrastructure for the MCN over G-ACH. > > > > Of course we can pretend that we do not know which network protocol will > run on top of the MCN (and some people have been arguing that we should > select the OSI stack for that purpose in the early days of the MPLS-TP > work); but I would expect that within the IETF refusal to use IP in this > role should not be taken too seriouslyJ. The recent work on SNMP MIBs > architecture for MPLS-TP looks to me as an additional confirmation. > > > > Hence it seems safe to assume that each MPLS-TP node will run at least a > host IP stack (not necessarily in the forwarding path). > > > > Once we agree on that, we could stop reinventing =93TCP/IP for poor=94 w= ith > proprietary solutions for reliability, fragmentation/reassembly, congesti= on > avoidance etc. > > > > My 2c, > > Sasha > > > > _______________________________________________ > mpls mailing list* > **mpls at ietf.org* * > **https://www.ietf.org/mailman/listinfo/mpls* > > _______________________________________________ > mpls mailing list > mpls at ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --20cf3071ced82b4c9c049fdc6aef Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,
If we don't have the host IP stack on every node in = the -TP network, we may have to follow the management channel as given in t= he=A0RFC 5960, 2.5. =A0Management Channel.

IMO, th= is channel can be used to configure the remote Non-IP systems using managem= ent messages.

Thanks,
Venkat.

Re: [mpls] Do we nee= d to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?<= /h1>
<= ul style=3D"font-family: 'Times New Roman'; font-size: medium; ">To:=A0Malcolm.BET= TS at zte.com.cn
  • Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what doe= s it really mean that MPLS-TP is IP-free?
  • From: "Andr= ew G. Malis" <agmalis at g= mail.com>
  • Date: Fri, 1 Apr 2011 14:33:37 +0200
  • Cc:=A0mpls at ietf.org
  • Delive= red-to:=A0mpls at core3.amsl.com=
  • Dkim-signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d= =3Dgmail.com; s=3Dgamma; h=3Ddomainkey-sig= nature:mime-version:in-reply-to:references:from:date :message-id:subject:to= :cc:content-type; bh=3DbjqA6TpB6I/UtFLt1OCY7A+KBR1Ig5fychX3zycyvlg=3D; b=3D= ExEd83DDhYBZH29xY6sDJ7ef/WER6z4kllFXzqFE26K1G0Fsi+0JQX0RL/G07yA4rE 59drblmN= aG1nzzQP7C2VFHQYefKh/7FJetoKOL8uevob1YM8+YPmeACWNg2TCAtL3Nll kvbpaVyG1cqlhL= BNxYbIhtWPKRkWJZdkKC26I=3D
  • Domainkey-signature: a=3Drsa-sha1; c=3Dnofws; d=3Dgmail.com; s=3Dgamma; h=3Dmime-version:in-reply-to:ref= erences:from:date:message-id:subject:to :cc:content-type; b=3Dvq0Qb3PjTymhN= 1C52aGhGke5gGa7UkohGaS64VxPcn/Lp6KplQ947kTEpQr3lnxn6Z XaXyUSP+bHOId0dDk3hWA= 7So+trvLKH4bz1WXnaqQ98MwhHuQgVrWI7XLmW4cSCxpchm N9XRkqtPWJ4l4t3aCaePTZGuF+a= 6lUtQ+lvYM=3D
  • In-reply-to: <OF6D81D565.7BAC9316-ON8525786= 5.0026AEAF-85257865.0028D20F at zte.com.cn>
  • List-archive= : <http://www= .ietf.org/mail-archive/web/mpls>
  • List-help: <mailto:mpls-request@ietf.org?subject=3Dhelp>
  • Li= st-id: Multi-Protocol Label Switching WG <mpls.ietf.org>
  • List-post: <mailto:mpls@ie= tf.org>
  • List-subscribe: <https://www.ietf.org/mailman/listinfo/mpls<= /a>>, <m= ailto:mpls-request@ietf.org?subject=3Dsubscribe>
  • List-unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-requ= est@ietf.org?subject=3Dunsubscribe>
  • References: <AANLkTi=3D0kyD+QhCdWL2E6bHbtO0r3A-ZQ= x=3DVovS7TajS at mail.gmail.com> <OF6D81D565.7BAC= 9316-ON85257865.0026AEAF-85257865.0028D20F at zte.com.cn>
    • Malcolm,

    I 'm not aware of anything in the IETF specifications that= 9;s inconsistent with this requirement, which is clear in section 2.3 in RF= C 5654 and section 2.1.4 in RFC 5860 (and perhaps elsewhere as well).
    =
    Cheers,
    Andy

    On Fri, Apr 1, 2011 at 9:26 AM,=A0<Malcolm.BETTS at zte.com.cn>=A0wrote:

    All,=A0

    True that in most cases an IP stack is present s= omewhere in most nodes to support a management interface. =A0However, this = does not mean that high bandwidth or high reliability access is provided to= that stack from the cards that support the forwarding plane functionality.= =A0Typically in small transport nodes the card supporting the management i= nterface has a low bandwidth and is non-redundant since if that card fails = the forwarding plane is not affected (including OAM and protection). =A0Thi= s is the reason that MPLS-TP forwarding and dataplane OAM must run IP free.= =A0

    This requirement was one of the pr= imary inputs from the ITU and I am very surprised that people are raising q= uestions at this stage.=A0

    Regards,=A0

    Malcolm=A0



    <= p>

    venkatesan mahalingam <venkatfle= x at gmail.com>=A0
    Sent by:=A0mpls-bounces at ietf.or= g

    31/03/2011 04:12 PM

    		 "Santiago Alvarez (saalvare)&qu= ot; <saalvare at cisco.com>, mpls <mpls at ietf.org>, Al= exander Vainshtein <alexander.vainshtein at ecitele.com>
    To
    cc
    Subject
    		Re: [mpls] Do we need to reinvent= TCP/IP, or what does it really mean that MPLS-TP is IP-free?





    Hi,=A0

    I think, we need at least an IP host stack on every node along the MPLS-= TP path to support the IP based management operations (ex. SNMP).=A0=

    Thanks,=A0
    Venkat.= =A0
    On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (= saalvare) <saalvare at cisco.= com> wrote:=A0
    MPLS-TP nodes would need an IP host stac= k to be able to source/sink IP traffic for management (e.g. SNMP).=A0 An LS= R should not have an IP routing function with the exception of a LER where = IP acts as a client. That IP routing/forwarding function should be defined = in RFC 1812.

    Cheers.

    =A0

    SA

    --

    From:=A0mpls-bounces at ietf.org=A0[mailto:mpls-bounces = at ietf.org]=A0On Beha= lf Of=A0Alexander Vainshtein
    Sent:    =A0Thursday, March 31, 2011 10:31 AM
    To:    =A0Luca Martini = (lmartini)
    Cc:    =A0    mpls at ie= tf.org
    Subject:    =A0[mpls] Do we need to reinvent TCP/IP, or what does it really= mean that MPLS-TP is IP-free?

    =A0

    =

    Luca and all,

    What I have= been trying to say at the mike today can be essentially reduced to a very = simple statement:

    =A0

    The =93requirement=94= for IP-free MPLS-TP is very vague and requires clarification.

    =A0

    MPLS-TP nodes presumabl= y have to be managed (especially if they are supposed to operate independen= t of any control plane). And personally I do not believe they are going to = be managed by connecting a local terminal via a serial cable to each of the= se nodes (of course you are free to disagreeJ). =A0

    =A0

    This assumes a Manage= ment Communication Network (MCN), and , IMHO, this assumption is ensconced = in RFC 5951 (which states that typically MPLS-TP nods can be expected o hav= e addresses on the MCN) while RFC 5718 provides the required infrastructure= for the MCN over G-ACH.

    =A0

    Of course we can pret= end that we do not know which network protocol will run on top of the MCN (= and some people have been arguing that we should select the OSI stack for t= hat purpose in the early days of the MPLS-TP work); but I would expect that= within the IETF refusal to use IP in this role should not be taken too ser= iouslyJ.= The recent work =A0on SNMP MIBs architecture for MPLS-TP looks to me as an= additional confirmation.

    =A0

    Hence it seems safe t= o assume that each MPLS-TP node will run at least a host IP stack (not nece= ssarily in the forwarding path).

    =A0

    Once we agree on that, we could stop reinventing =93T= CP/IP for poor=94 =A0with proprietary solutions for reliability, fragmentat= ion/reassembly, congestion avoidance etc.

    =A0

    My 2c,

    <= font size=3D"3">=A0=A0=A0=A0 Sasha

    =A0= =A0

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

    ___________________________________________= ____
    mpls mailing list
    mpls at ietf.org
    https://w= ww.ietf.org/mailman/listinfo/mpls

    <= /p>

    --20cf3071ced82b4c9c049fdc6aef-- From Alexander.Vainshtein@ecitele.com Fri Apr 1 13:50:04 2011 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 A257D28C0D6 for ; Fri, 1 Apr 2011 13:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.019, 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 C1gQLs3Bz4FT for ; Fri, 1 Apr 2011 13:50:02 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 0C2B928B23E for ; Fri, 1 Apr 2011 13:50:01 -0700 (PDT) X-AuditID: 93eaf2e8-b7cf3ae000003b5b-c0-4d963a77cca1 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id CB.A5.15195.77A369D4; Fri, 1 Apr 2011 23:49:59 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 1 Apr 2011 23:51:40 +0300 From: Alexander Vainshtein To: "Malcolm.BETTS@zte.com.cn" Date: Fri, 1 Apr 2011 23:51:40 +0300 Thread-Topic: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? Thread-Index: AcvwPnD36uGxQ/imS0atmZlrzC5p1AAbKZdW 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_A3C5DF08D38B6049839A6F553B331C76D722D0E7ACILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? 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, 01 Apr 2011 20:50:04 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7ACILPTMAIL02eci_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Malcolm, Lots of thanks for a prompt response. I see it as the first step (presumably of many to follow) towards clarifyin= g the requirement of keeping MPLS-TP IP-free. Please see more inline below. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Malcolm.BE= TTS@zte.com.cn [Malcolm.BETTS@zte.com.cn] Sent: Friday, April 01, 2011 10:26 AM To: mpls@ietf.org Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really m= ean that MPLS-TP is IP-free? All, True that in most cases an IP stack is present somewhere in most nodes to s= upport a management interface. [[Sasha]] Great, we seem to be in agreement here! However, this does not mean that high bandwidth or high reliability access = is provided to that stack from the cards that support the forwarding plane = functionality. [[Sasha]] This is fully understood and, in most cases, not r= equired IMO. Luca's draft provides a very good example for that. Typically in small transport nodes the card supporting the management inter= face has a low bandwidth [[Sasha]] Please see above and is non-redundant si= nce if that card fails the forwarding plane is not affected (including OAM = and protection). [[Sasha]] This is a very strong assumption that is not in any way related t= o having - ort not having - IP stack. IMHO you say that ability of a transport node to response to a protection = switch requests MUST NOT involve not just the the CP (which is a valid requ= irement), but also none of the HW components that are inv olved with teh CP= operation. Did I read you correctly? If yes, why have ITU-T never specifie= d such a requirement explicitly? If this requirement was stated, it would strongly affect protection mechani= sms because I would expect that, where applicable, Working and Protecting L= SPs would be terminated on different cards. And of course, processing of OAM messages (sent and received in the data pl= ane) must not affect in any way the cHW component that deals (among other t= hings) with management etc. Last but not least, from my (admittedly, outdated) experience when. almost = 20 years ago, I have been designing management communication stacks for th= e traditional (SONET/SDH) transport nodes, the operators consider loss of m= anagement communication with such a node as a critical issue in spite of al= l available OAM. Unless this attitude has undergone a drastic change, I wou= ld suspect that a node with reduddant data plane and non-redundant control = plane would not be the first choice for a small transport node... This is the reason that MPLS-TP forwarding and dataplane OAM must run IP f= ree. [[Sasha]] As you've said in your presentation in the Routing Area Open at t= his IETF meeting, one has to be pragmatic in standards. Trying to purge MPL= S-TP of any reliance on IP looks to me like going far beyond pragmatism. This requirement was one of the primary inputs from the ITU and I am very s= urprised that people are raising questions at this stage. Regards, Malcolm venkatesan mahalingam Sent by: mpls-bounces@ietf.org 31/03/2011 04:12 PM To "Santiago Alvarez (saalvare)" , mpls , Alexander Vainshtein cc Subject Re: [mpls] Do we need to reinvent TCP/IP, or what does it really me= an that MPLS-TP is IP-free? Hi, I think, we need at least an IP host stack on every node along the MPLS-TP = path to support the IP based management operations (ex. SNMP). Thanks, Venkat. On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) > wrote: MPLS-TP nodes would need an IP host stack to be able to source/sink IP traf= fic for management (e.g. SNMP). An LSR should not have an IP routing funct= ion with the exception of a LER where IP acts as a client. That IP routing/= forwarding function should be defined in RFC 1812. Cheers. SA -- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Alexander Vainshte= in Sent: Thursday, March 31, 2011 10:31 AM To: Luca Martini (lmartini) Cc: mpls@ietf.org Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean = that MPLS-TP is IP-free? Luca and all, What I have been trying to say at the mike today can be essentially reduced= to a very simple statement: The =93requirement=94 for IP-free MPLS-TP is very vague and requires clarif= ication. MPLS-TP nodes presumably have to be managed (especially if they are suppose= d to operate independent of any control plane). And personally I do not bel= ieve they are going to be managed by connecting a local terminal via a seri= al cable to each of these nodes (of course you are free to disagree:)). This assumes a Management Communication Network (MCN), and , IMHO, this ass= umption is ensconced in RFC 5951 (which states that typically MPLS-TP nods = can be expected o have addresses on the MCN) while RFC 5718 provides the re= quired infrastructure for the MCN over G-ACH. Of course we can pretend that we do not know which network protocol will ru= n on top of the MCN (and some people have been arguing that we should selec= t the OSI stack for that purpose in the early days of the MPLS-TP work); bu= t I would expect that within the IETF refusal to use IP in this role should= not be taken too seriously:). The recent work on SNMP MIBs architecture f= or MPLS-TP looks to me as an additional confirmation. Hence it seems safe to assume that each MPLS-TP node will run at least a ho= st IP stack (not necessarily in the forwarding path). Once we agree on that, we could stop reinventing =93TCP/IP for poor=94 wit= h proprietary solutions for reliability, fragmentation/reassembly, congesti= on avoidance etc. My 2c, Sasha _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7ACILPTMAIL02eci_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Malcolm,
    Lots of thanks for a prompt response.
     
    I see it as the first step (presumably&= nbsp;of many to follow) towards clarifying the requirement of keepin= g MPLS-TP IP-free.
     
    Please see more inline below.
     
    Regards,
         Sasha
     
        
     
    From: mpls-bounce= s@ietf.org [mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn [M= alcolm.BETTS@zte.com.cn]
    Sent: Friday, April 01, 2011 10:26 AM
    To: mpls@ietf.org
    Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it r= eally mean that MPLS-TP is IP-free?


    All,

    True that in most cases an IP stack is= present somewhere in most nodes to support a management interface. 
    [[Sasha]] Great= , we seem to be in agreement here!
    However, this does not mean that = high bandwidth or high reliability access is provided to that stack from th= e cards that support the forwarding plane functionality. [[Sasha]] This is fully understood and, in most cases, not required IMO. Luca's draft provides a very good ex= ample for that.
     
    Typically in small transport node= s the card supporting the management interface has a low bandwidth [[Sasha]] Please see above and is non-redund= ant since if that card fails the forwarding plane is not affected (includin= g OAM and protection). 
     
    [[Sasha]]= This is a very strong assumption that is not in any way related to having = - ort not having - IP stack.
    IMHO  you say t= hat ability of a transport node to response to a protection switch&nbs= p;requests MUST NOT involve not just the the CP (which is a valid requireme= nt), but also none of the HW components that are inv olved with teh CP operation. Did I read you correctly? If yes, why have IT= U-T never specified such a requirement explicitly?
     
    If this requirement = was stated, it would strongly affect protection mechanisms becaus= e I would expect that, where applicable, Working and Protecting LSPs&n= bsp;would be terminated on different cards.
     
    And of course, proce= ssing of OAM messages (sent and received in the data plane) must not affect= in any way the cHW component that deals (among other things) with manageme= nt etc.
     
     
    Last but not least, = from my (admittedly, outdated) experience when. almost 20 years ago, I &nbs= p;have been designing management communication stacks for the traditio= nal (SONET/SDH) transport nodes, the operators consider loss of management communication with such a node as a critical issue in s= pite of all available OAM. Unless this attitude has undergone a drastic cha= nge, I would suspect that a node with reduddant data plane and non-redundan= t control plane would not be the first choice for a small transport node...
     
     This is the reason that MPL= S-TP forwarding and dataplane OAM must run IP free.

     

    [[Sasha]] As you've sa= id in your presentation in the Routing Area Open at this IETF meeting, one = has to be pragmatic in standards. Trying to purge MPLS-TP of any reliance o= n IP looks to me like going far beyond pragmatism.



    This requirement was one of the primar= y inputs from the ITU and I am very surprised that people are raising quest= ions at this stage.

    Regards,

    Malcolm



    venkatesan mahali= ngam <venkatflex@gmail.com>
    Sent by: mpls-bounces@ietf.org

    31/03/2011 04:12 PM

    To
    		 "Santiago Alvarez (saalvare)&= quot; <saalvare@cisco.com>, mpls <mpls@ietf.org>, Alexander Vai= nshtein <alexander.vainshtein@ecitele.com>
    cc
    Subject
    		Re: [mpls] Do we need to reinvent = TCP/IP, or what does it really mean that MPLS-TP is IP-free?





    Hi,

    I think, we need at least an IP host stack on every node a= long the MPLS-TP path to support the IP based management operations (ex. SN= MP).

    Thanks,
    Venkat.
    On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvar= e) <saalvare@cisco.com> wrote:
    MPLS-TP nodes would need an IP host stac= k to be able to source/sink IP traffic for management (e.g. SNMP).  An= LSR should not have an IP routing function with the exception of a LER whe= re IP acts as a client. That IP routing/forwarding function should be defined in RFC 1812.

    Cheers.

    SA

    --

    From: mpls-bounces@iet= f.org [mailto:mpl= s-bounces@ietf.org] On Behalf Of Alexander Vainshtein
    Sent:     Thursday, March 31, 2011 10:31 AM
    To:     Luca Martini (lmartini)
    Cc:         mpls@ietf.org
    Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really m= ean that MPLS-TP is IP-free?

    Luca and all,

    What I have been trying to say at the mike today can be= essentially reduced to a very simple statement:

    The =93requirement=94 for IP-free MPLS-TP is very vague= and requires clarification.

    MPLS-TP nodes presumably have to be managed (especially= if they are supposed to operate independent of any control plane). And per= sonally I do not believe they are going to be managed by connecting a local= terminal via a serial cable to each of these nodes (of course you are free to disagreeJ).  

    This assumes a Management Communication Network (MCN), = and , IMHO, this assumption is ensconced in RFC 5951 (which states that typ= ically MPLS-TP nods can be expected o have addresses on the MCN) while RFC = 5718 provides the required infrastructure for the MCN over G-ACH.

    Of course we can pretend that we do not know which netw= ork protocol will run on top of the MCN (and some people have been arguing = that we should select the OSI stack for that purpose in the early days of t= he MPLS-TP work); but I would expect that within the IETF refusal to use IP in this role should not be taken to= o seriouslyJ. The recent work  on SNMP MIBs architecture for MPLS-TP looks to = me as an additional confirmation.

    Hence it seems safe to assume that each MPLS-TP node wi= ll run at least a host IP stack (not necessarily in the forwarding path).

    Once we agree on that, we could stop reinventing =93TCP= /IP for poor=94  with proprietary solutions for reliability, fragmenta= tion/reassembly, congestion avoidance etc.

    My 2c,

         Sasha



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

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

    --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7ACILPTMAIL02eci_-- From ben@niven-jenkins.co.uk Sat Apr 2 01:32:38 2011 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 172E33A6A60 for ; Sat, 2 Apr 2011 01:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.57 X-Spam-Level: X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 L-1+RFxOqFmD for ; Sat, 2 Apr 2011 01:32:36 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 0C5AE3A6A5A for ; Sat, 2 Apr 2011 01:32:36 -0700 (PDT) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.202]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Q5wHS-0007gW-5i; Sat, 02 Apr 2011 09:34:16 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 Message-Id: Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Sat, 2 Apr 2011 09:33:48 +0100 To: Andrew G. Malis X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Malcolm.BETTS@zte.com.cn, mpls@ietf.org Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? 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, 02 Apr 2011 08:32:38 -0000 Colleagues, I wasn't in the MPLS WG session so do not have the full context of the = discussion but as the editor of RFC5654 maybe I can help with the = context of what RFC5654 says regarding IP. The wording of the IP related = requirements (e.g. requirement 36) was much debated and the wording in = the final RFC was very carefully chosen. The requirement as stated is that MPLS-TP nodes & networks must be able = to be operated and configured without individual nodes being required to = have an IP forwarding capability. There is not a requirement in RFC5654 = for MPLS-TP nodes to be able to be operated and configured in the = complete absence of IP. In other words it is reasonable to assume MPLS-TP boxes MUST be able to = source & sink IP packets with a source/destination IP address that is = assigned to that MPLS-TP node/box for operation/configuration (i.e. = management) but that must be possible without requiring that MPLS-TP = boxes are capable of performing IP routing or forwarding of packets with = a destination IP address that is assigned to a different node in the = network. HTH Ben On 1 Apr 2011, at 13:33, Andrew G. Malis wrote: > Malcolm, >=20 > I 'm not aware of anything in the IETF specifications that's = inconsistent with this requirement, which is clear in section 2.3 in RFC = 5654 and section 2.1.4 in RFC 5860 (and perhaps elsewhere as well). >=20 > Cheers, > Andy >=20 > On Fri, Apr 1, 2011 at 9:26 AM, wrote: >=20 > All,=20 >=20 > True that in most cases an IP stack is present somewhere in most nodes = to support a management interface. However, this does not mean that = high bandwidth or high reliability access is provided to that stack from = the cards that support the forwarding plane functionality. Typically in = small transport nodes the card supporting the management interface has a = low bandwidth and is non-redundant since if that card fails the = forwarding plane is not affected (including OAM and protection). This = is the reason that MPLS-TP forwarding and dataplane OAM must run IP = free.=20 >=20 > This requirement was one of the primary inputs from the ITU and I am = very surprised that people are raising questions at this stage.=20 >=20 > Regards,=20 >=20 > Malcolm=20 >=20 >=20 >=20 >=20 > venkatesan mahalingam =20 > Sent by: mpls-bounces@ietf.org > 31/03/2011 04:12 PM >=20 > To > "Santiago Alvarez (saalvare)" , mpls = , Alexander Vainshtein > cc > Subject > Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean = that MPLS-TP is IP-free? >=20 >=20 >=20 >=20 >=20 > Hi,=20 >=20 > I think, we need at least an IP host stack on every node along the = MPLS-TP path to support the IP based management operations (ex. SNMP).=20= >=20 > Thanks,=20 > Venkat.=20 > On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) = wrote:=20 > MPLS-TP nodes would need an IP host stack to be able to source/sink IP = traffic for management (e.g. SNMP). An LSR should not have an IP = routing function with the exception of a LER where IP acts as a client. = That IP routing/forwarding function should be defined in RFC 1812. > Cheers. >=20 > =20 > SA >=20 > -- >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Alexander Vainshtein > Sent: Thursday, March 31, 2011 10:31 AM > To: Luca Martini (lmartini) > Cc: mpls@ietf.org > Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really = mean that MPLS-TP is IP-free? >=20 > =20 > Luca and all, >=20 > What I have been trying to say at the mike today can be essentially = reduced to a very simple statement: >=20 > =20 > The =93requirement=94 for IP-free MPLS-TP is very vague and requires = clarification. >=20 > =20 > MPLS-TP nodes presumably have to be managed (especially if they are = supposed to operate independent of any control plane). And personally I = do not believe they are going to be managed by connecting a local = terminal via a serial cable to each of these nodes (of course you are = free to disagreeJ). =20 >=20 > =20 > This assumes a Management Communication Network (MCN), and , IMHO, = this assumption is ensconced in RFC 5951 (which states that typically = MPLS-TP nods can be expected o have addresses on the MCN) while RFC 5718 = provides the required infrastructure for the MCN over G-ACH. >=20 > =20 > Of course we can pretend that we do not know which network protocol = will run on top of the MCN (and some people have been arguing that we = should select the OSI stack for that purpose in the early days of the = MPLS-TP work); but I would expect that within the IETF refusal to use IP = in this role should not be taken too seriouslyJ. The recent work on = SNMP MIBs architecture for MPLS-TP looks to me as an additional = confirmation. >=20 > =20 > Hence it seems safe to assume that each MPLS-TP node will run at least = a host IP stack (not necessarily in the forwarding path). >=20 > =20 > Once we agree on that, we could stop reinventing =93TCP/IP for poor=94 = with proprietary solutions for reliability, fragmentation/reassembly, = congestion avoidance etc. >=20 > =20 > My 2c, >=20 > Sasha >=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 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=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 From ben@niven-jenkins.co.uk Sat Apr 2 01:56:58 2011 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 271E93A676A for ; Sat, 2 Apr 2011 01:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 d3oZBUx4tADt for ; Sat, 2 Apr 2011 01:56:56 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 2E5943A6407 for ; Sat, 2 Apr 2011 01:56:56 -0700 (PDT) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.202]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Q5wfE-0000Sd-4q; Sat, 02 Apr 2011 09:58:36 +0100 References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> <07F7D7DED63154409F13298786A2ADC903D20B53@EXRAD5.ad.rad.co.il> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Sat, 2 Apr 2011 09:58:32 +0100 To: Christopher LILJENSTOLPE X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "mpls@ietf.org" , "Mallette, Edwin" Subject: Re: [mpls] seamless 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: Sat, 02 Apr 2011 08:56:58 -0000 Chris, Totally agree. Yaakov, I haven't read draft-leymann-mpls-seamless-mpls-03 in its entirety but I = did read the security considerations section and my interpretation was = that that statement you quote, and the sentence that follows, i.e. Nevertheless the unauthorized access to such in device SHOULD NOT impose any security risks to the MPLS infrastructure itself. Seamless MPLS must be stable regarding attacks against access and aggregation nodes running MPLS. Is not making a claim that there are no security risks in that = deployment model but rather is stating a requirement that the = architecture/etc SHOULD consider the security risks and minimise them. The security considerations section is rather short and I interpreted = the text in there as introductory text which is preamble to the = identified sub-sctions that are currently marked TBD. Assuming my interpretation is correct (and I am sure the draft's authors = can confirm/deny that) then the question I guess is whether you feel = that further text needs to be developed before adopting the draft as a = WG document or whether that can done by the WG after the draft is = adopted? Ben On 29 Mar 2011, at 21:45, Christopher LILJENSTOLPE wrote: > Greetings, >=20 > Let me second this set of concerns. In an SP network, I can elect not = to extend my IGP into uncontrolled spaces, and, instead use control = plane protocols that I can apply policy to (BGP comes to mind). The = document does talk about hierarchy, and using BGP to distribute labels = (anyone care to think about the number of non-aggregateable labels in a = large network that BGP would have to distribute, btw?). However, there = is no mention of the security implications of defining the correct (or = incorrect) aggregation/protocol boundary. =20 >=20 > In the not too distant future, some lazy operator decides that statics = are too hard, and extends the IGP down to the access nodes (which are = not physically controlled - may even be on customer prem) - Customer = does some "research" and injects routes into said IGP after = circumventing default passwords - sit back and watch the fun and = fireworks. Anyone who says that the service provider won't be lazy = and/or won't deploy with default or well-known passwords - I have MANY = cases to prove otherwise.... >=20 > If we think this work is valid, then we REALLY need to cover this in = detail in the architecture and security sections. I am not, however, = indicating that I do think it is a good idea.... >=20 > Chris >=20 > On 30Mar2011, at 03.09, Yaakov Stein wrote: >=20 >> That is not quite the kind of attack I was worried about. >>=20 >> Someone able to inject packets into an MPLS network >> can wreak more havoc than a monster truck. >>=20 >> Y(J)S >>=20 >> From: Mallette, Edwin [mailto:Edwin.Mallette@bhnis.com] >> Sent: Tuesday, March 29, 2011 18:53 >> To: Yaakov Stein; mpls@ietf.org >> Subject: Re: [mpls] seamless MPLS >>=20 >> This made me laugh, but I'm going to go out on a limb here and say = the type of access meant was physical access. For instance, if I take = out my monster truck and physically access said DSLAM by running over = the street cabinet that wouldn't have any real risk to the MPLS = infrastructure - just to the DSLAM. But a slightly modified wording = might help. >>=20 >> Ed >>=20 >> From: Yaakov Stein > >> Date: Tue, 29 Mar 2011 11:44:24 -0400 >> To: "mpls@ietf.org" = > >> Subject: [mpls] seamless MPLS >>=20 >> Before draft-leymann-mpls-seamless-mpls-03 is moved to become a WG = draft, >> I would like to clarify the security implications. >>=20 >> The security section of this draft starts very well : >>=20 >> In a typical MPLS deployment the use of MPLS is limited to = relatively >> small network consisting of core and edge nodes. Those nodes are >> under full control of the services provider and placed at locations >> where only authorized personal has access (this also includes >> physical access to the nodes). With the extensions of MPLS towards >> access and aggregation nodes not all nodes will be "locked away" in >> secure locations. Small access nodes like DSLAMs will be located = in >> street cabinets, potentially offering access to the "interested >> researcher". >>=20 >> I couldn't have stated this any better myself. >> However it then goes on to say : >>=20 >> Nevertheless the unauthorized access to such in = device >> SHOULD NOT impose any security risks to the MPLS infrastructure >> itself. >>=20 >> I would love to hear the reasoning behind this statement. >>=20 >> Y(J)S >>=20 >>=20 >> ________________________________ >> CONFIDENTIALITY NOTICE: This e-mail may contain information that is = privileged, confidential or otherwise protected from disclosure. If you = are not the intended recipient of this e-mail, please notify the sender = immediately by return e-mail, purge it and do not disseminate or copy = it. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 > --- > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Check my PGP key here: > https://www.asgaard.org/~cdl/cdl.asc >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From wim.henderickx@alcatel-lucent.com Sat Apr 2 04:04:32 2011 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 D4BBE3A67A8 for ; Sat, 2 Apr 2011 04:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.721 X-Spam-Level: X-Spam-Status: No, score=-5.721 tagged_above=-999 required=5 tests=[AWL=0.528, 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 D5Gd4V7RMRyD for ; Sat, 2 Apr 2011 04:04:31 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 6C7033A67A7 for ; Sat, 2 Apr 2011 04:04:31 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p32B68aO007072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 2 Apr 2011 13:06:11 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 2 Apr 2011 13:06:08 +0200 From: "Henderickx, Wim (Wim)" To: Javier Jimenez Date: Sat, 2 Apr 2011 13:06:06 +0200 Thread-Topic: [mpls] Questions on seamless MPLS Thread-Index: AcvwdOpCvS2KSmS0QPaHc3mh0lneCgAsIsSw Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67182EA529@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> <4D95D999.604@tid.es> In-Reply-To: <4D95D999.604@tid.es> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions on seamless 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: Sat, 02 Apr 2011 11:04:32 -0000 In-line -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Jav= ier Jimenez Sent: vrijdag 1 april 2011 15:57 Cc: mpls@ietf.org Subject: [mpls] Questions on seamless MPLS Hi all, Here in Telef=F3nica we are pushing for MPLS E2E solutions, and it seems the seamless MPLS draft respresents a great starting point. Congratulations to the authors for this nice piece of work. I have two questions, not being involved in the draft so far: 1.- The draft proposes to use the next-hop-self in the outwards direction (with respect to an specific regional area) and to leave next-hop-unchanged for the incoming traffic. This approach requires that some routing information is flooded from the core area to the regional ones (specificallly, reachability to the ABRs). I'm sure this design increases the scalability of the solution, but two concerns come to my mind= : - Wouldn't it be cleaner to perform the next-hop-self in both directions? I come from the transport world, where things tend to be symetrical (and easier to understand for humans). WH> when you perform NH self you will install a LBL entry for every LBL pre= fix and would result in a bigger LFIB. - More specifically, when migrating to a seamless architecture, it may be the case that the IGPs are already different in the core and in the regions (also the label distribution protocols), and it could not be possible to flood external IGP information into the regional areas or the operator would prefer to keep IGP clear from external influece (for that reason you have BGP). In summary, would there be room for two options (and which are the pros & cons) or just the one recommended in the draft? WH> the reason of the current architecture is due to scalability as outline= d above 2.- Right now, VPLS services are typically offered only on a regional basis due to scalability issues. How would a VPLS service scale on top of a seamless MPLS architecture? Is this requirement part of the architecture or has been intentionally removed? WH> VPLS scale is orthogonal of the seamless MPLS architecture and it depen= ds on the MAC@, replication/P2MP LSP architecture, end-points, use of H-VPL= S, etc. Seamless MPLS is not changing these parameters for VPLS services, V= PLS will just use the seamless MPLS architecture Kind regards, Javier Jimenez Telef=F3nica Research Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Sat Apr 2 10:19:38 2011 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 46BA53A6867 for ; Sat, 2 Apr 2011 10:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YVea9cn9ZfM for ; Sat, 2 Apr 2011 10:19:37 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 5B7CB3A685B for ; Sat, 2 Apr 2011 10:19:35 -0700 (PDT) X-AuditID: 93eaf2e8-b7cf3ae000003b5b-42-4d975aa5d712 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id 85.09.15195.5AA579D4; Sat, 2 Apr 2011 20:19:33 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 2 Apr 2011 20:21:15 +0300 From: Alexander Vainshtein To: Benjamin Niven-Jenkins Date: Sat, 2 Apr 2011 20:21:15 +0300 Thread-Topic: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? Thread-Index: AcvxEMdpzzC9L3vhTDGP48ZIfDzLBQACGSg/ 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: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "Malcolm.BETTS@zte.com.cn" , "mpls@ietf.org" Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? 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, 02 Apr 2011 17:19:38 -0000 Ben, Lots of thanks for a prompt and clarifying response. To make things a bit more clear, the context for my question at the mike an= d the consequent email thread was Luca's draft on aggregation of PW status = (https://datatracker.ietf.org/doc/draft-martini-pwe3-status-aggregation-pro= tocol/?include_text=3D1) and associated presentation (http://www.ietf.org/p= roceedings/80/slides/mpls-21.ppt). The proposed protocol was supposed to run on top of G-ACh/GAL in the tunnel= LSP between a pair of PEs and would take care of such issues as reliable d= elivery, fragmentation of messages etc. Congestion avoidance and security h= ave not been mentioned, but I would expect them to appear in some future ve= rsions (e.g., in response to the comments from the Transport and/or Securit= y Directorates:-). That is why I said that using TCP/IP on top of G-ACh/GAL as the bearer of s= uch a protocol looked a perfectly natural thing to do. Of course this woul= d not require any IP forwarding capabilities. =20 Hopefully this note would be useful. Regards, Sasha ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Benjamin N= iven-Jenkins [ben@niven-jenkins.co.uk] Sent: Saturday, April 02, 2011 11:33 AM To: Andrew G.Malis Cc: Malcolm.BETTS@zte.com.cn; mpls@ietf.org Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it rea= lly mean that MPLS-TP is IP-free? Colleagues, I wasn't in the MPLS WG session so do not have the full context of the disc= ussion but as the editor of RFC5654 maybe I can help with the context of wh= at RFC5654 says regarding IP. The wording of the IP related requirements (e= .g. requirement 36) was much debated and the wording in the final RFC was v= ery carefully chosen. The requirement as stated is that MPLS-TP nodes & networks must be able to = be operated and configured without individual nodes being required to have = an IP forwarding capability. There is not a requirement in RFC5654 for MPLS= -TP nodes to be able to be operated and configured in the complete absence = of IP. In other words it is reasonable to assume MPLS-TP boxes MUST be able to sou= rce & sink IP packets with a source/destination IP address that is assigned= to that MPLS-TP node/box for operation/configuration (i.e. management) but= that must be possible without requiring that MPLS-TP boxes are capable of = performing IP routing or forwarding of packets with a destination IP addres= s that is assigned to a different node in the network. HTH Ben On 1 Apr 2011, at 13:33, Andrew G. Malis wrote: > Malcolm, > > I 'm not aware of anything in the IETF specifications that's inconsistent= with this requirement, which is clear in section 2.3 in RFC 5654 and secti= on 2.1.4 in RFC 5860 (and perhaps elsewhere as well). > > Cheers, > Andy > > On Fri, Apr 1, 2011 at 9:26 AM, wrote: > > All, > > True that in most cases an IP stack is present somewhere in most nodes to= support a management interface. However, this does not mean that high ban= dwidth or high reliability access is provided to that stack from the cards = that support the forwarding plane functionality. Typically in small transp= ort nodes the card supporting the management interface has a low bandwidth = and is non-redundant since if that card fails the forwarding plane is not a= ffected (including OAM and protection). This is the reason that MPLS-TP fo= rwarding and dataplane OAM must run IP free. > > This requirement was one of the primary inputs from the ITU and I am very= surprised that people are raising questions at this stage. > > Regards, > > Malcolm > > > > > venkatesan mahalingam > Sent by: mpls-bounces@ietf.org > 31/03/2011 04:12 PM > > To > "Santiago Alvarez (saalvare)" , mpls ,= Alexander Vainshtein > cc > Subject > Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean tha= t MPLS-TP is IP-free? > > > > > > Hi, > > I think, we need at least an IP host stack on every node along the MPLS-T= P path to support the IP based management operations (ex. SNMP). > > Thanks, > Venkat. > On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) wrote: > MPLS-TP nodes would need an IP host stack to be able to source/sink IP tr= affic for management (e.g. SNMP). An LSR should not have an IP routing fun= ction with the exception of a LER where IP acts as a client. That IP routin= g/forwarding function should be defined in RFC 1812. > Cheers. > > > SA > > -- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of A= lexander Vainshtein > Sent: Thursday, March 31, 2011 10:31 AM > To: Luca Martini (lmartini) > Cc: mpls@ietf.org > Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mea= n that MPLS-TP is IP-free? > > > Luca and all, > > What I have been trying to say at the mike today can be essentially reduc= ed to a very simple statement: > > > The =93requirement=94 for IP-free MPLS-TP is very vague and requires clar= ification. > > > MPLS-TP nodes presumably have to be managed (especially if they are suppo= sed to operate independent of any control plane). And personally I do not b= elieve they are going to be managed by connecting a local terminal via a se= rial cable to each of these nodes (of course you are free to disagreeJ). > > > This assumes a Management Communication Network (MCN), and , IMHO, this a= ssumption is ensconced in RFC 5951 (which states that typically MPLS-TP nod= s can be expected o have addresses on the MCN) while RFC 5718 provides the = required infrastructure for the MCN over G-ACH. > > > Of course we can pretend that we do not know which network protocol will = run on top of the MCN (and some people have been arguing that we should sel= ect the OSI stack for that purpose in the early days of the MPLS-TP work); = but I would expect that within the IETF refusal to use IP in this role shou= ld not be taken too seriouslyJ. The recent work on SNMP MIBs architecture = for MPLS-TP looks to me as an additional confirmation. > > > Hence it seems safe to assume that each MPLS-TP node will run at least a = host IP stack (not necessarily in the forwarding path). > > > Once we agree on that, we could stop reinventing =93TCP/IP for poor=94 w= ith proprietary solutions for reliability, fragmentation/reassembly, conges= tion avoidance etc. > > > My 2c, > > Sasha > > > > _______________________________________________ > 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= From rajiva@cisco.com Sun Apr 3 04:00:42 2011 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 88BBF3A67B2 for ; Sun, 3 Apr 2011 04:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.322 X-Spam-Level: X-Spam-Status: No, score=-10.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 wqU4w3eDVmzg for ; Sun, 3 Apr 2011 04:00:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9E2733A6989 for ; Sun, 3 Apr 2011 04:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=179; q=dns/txt; s=iport; t=1301828543; x=1303038143; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=MRezeaMvdq1Le3lJLdFFagwgc5x8/HcwxHj9vCJyCh0=; b=fHZ5poPah5UGPmivwg2BccJr66tfY9+m10rAyApVdhrjq5ivYuLANz8l +SIPeTC7R1wgn/hn65VU1u8h+i8Yi4NZd0rWT14kBGGU9BZ053+NRs3W9 rTa9UKiMW9eg7BzwjGdLe94PXZW3mYhKT+bfHl7DbNWcsQkv+x4xmMwNn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQHAAdTmE2tJXG9/2dsb2JhbACYY4x+d6YVmnKFawSFR4s9 X-IronPort-AV: E=Sophos;i="4.63,291,1299456000"; d="scan'208";a="288316754" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2011 11:02:23 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p33B2N2b024042; Sun, 3 Apr 2011 11:02:23 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Apr 2011 06:02:23 -0500 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: Sun, 3 Apr 2011 06:02:21 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C04905E0F@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG adoption of draft-asati-pignataro-ldp-gtsm-00 Thread-Index: AcvwvsiNMfDFLY+PQz+Em3AavRZ7JQ== From: "Rajiv Asati (rajiva)" To: X-OriginalArrivalTime: 03 Apr 2011 11:02:23.0391 (UTC) FILETIME=[9C1DF2F0:01CBF1EE] Cc: mpls@ietf.org Subject: [mpls] WG adoption of draft-asati-pignataro-ldp-gtsm-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: Sun, 03 Apr 2011 11:00:42 -0000 Given the positive feedback during the WG meeting last Thu, the authors would like to request the adoption of draft-asati-pignataro-ldp-gtsm-00. Thanks. Cheers, Rajiv =20 From yaakov_s@rad.com Sun Apr 3 06:00:46 2011 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 5A7263A67DB for ; Sun, 3 Apr 2011 06:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, 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 TwUPIAPCxo6M for ; Sun, 3 Apr 2011 06:00:44 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 78EEC3A6979 for ; Sun, 3 Apr 2011 06:00:41 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 03 Apr 2011 16:02:19 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 3 Apr 2011 16:02:17 +0300 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Sun, 3 Apr 2011 16:02:17 +0300 From: Yaakov Stein To: Benjamin Niven-Jenkins Thread-Topic: [mpls] seamless MPLS Thread-Index: AcvuH8gC1BPbKnOiSXS6qnyu9KaPAf//8b+A///rY8CAAGYeAIAFcy0A//39pwA= Date: Sun, 3 Apr 2011 13:02:16 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D22CA8@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> <07F7D7DED63154409F13298786A2ADC903D20B53@EXRAD5.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Mallette, Edwin" , Christopher LILJENSTOLPE Subject: Re: [mpls] seamless 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: Sun, 03 Apr 2011 13:00:46 -0000 QmVuDQoNCkkgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgc29tZSBwbGF1c2libGUgZXhwbGFuYXRpb24g b24gaG93IHRoZSBzZWN1cml0eSBpc3N1ZXMNCmRldGFpbGVkIGluIHNlY3Rpb24gNC4yIG9mIFJG QyA1OTIwIGNhbiBiZSBhZGRyZXNzZWQsDQpiZWZvcmUgY29uc2lkZXJpbmcgdGhpcyB0ZWNobmlx dWUuDQoNClRoZSBJRVRGIHNwZW50IGFuIGVub3Jtb3VzIGVmZm9ydCB0byBlbnN1cmUgdGhhdCBN UExTLVRQIHdvdWxkIG5vdCBicmVhayBleGlzdGluZyBNUExTIG5ldHdvcmtzLCANCmV2ZW4gd2hl biBpbnRlcmNvbm5lY3Rpb24gb2YgVFAgYW5kIG5vbi1UUCBuZXR3b3JrcyB3YXMgbm90IGJlaW5n IGNvbnNpZGVyZWQuIA0KDQpIZXJlIGlzIGEgbWV0aG9kIGRlc2lnbmVkIHByZWNpc2VseSB0byBp bnRlcmNvbm5lY3QgZXhpc3RpbmcgbmV0d29ya3Mgd2l0aCBvbmVzIG9mIGR1YmlvdXMgc2VjdXJp dHkuDQpJdCB3b3VsZG4ndCBtYWtlIHNlbnNlIHRvIGFkb3B0IHRoaXMgYXMgYSBXRyBkcmFmdCB3 aXRob3V0IGhlYXJpbmcgaG93IHRoaXMgd29uJ3QgYnJpbmcgZG93bg0KYWxsIG9mIG91ciBleGlz dGluZyBuZXR3b3Jrcy4gDQoNClJGQyA1OTIwIHNlY3Rpb24gNS4zIHN1Z2dlc3RzIHNvbHV0aW9u cywgc3VjaCBhcyB0aGUgdXNlIG9mIGZpcmV3YWxscy4NCldlcmUgc3Ryb25nIG1hbmRhdG9yeSBk YXRhLXBsYW5lIGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbXMgc3BlbGxlZCBvdXQgaW4gdGhpcyBk b2N1bWVudCwNCnRoZW4gSSB3b3VsZCBoYXZlIG5vIG9iamVjdGlvbiB0byBhZG9wdGluZyBpdCBh cyBhIFdHIGRyYWZ0Lg0KDQpZKEopUw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEJlbmphbWluIE5pdmVuLUplbmtpbnMgW21haWx0bzpiZW5Abml2ZW4tamVua2lucy5j by51a10gDQpTZW50OiBTYXR1cmRheSwgQXByaWwgMDIsIDIwMTEgMTE6NTkNClRvOiBDaHJpc3Rv cGhlciBMSUxKRU5TVE9MUEUNCkNjOiBZYWFrb3YgU3RlaW47IG1wbHNAaWV0Zi5vcmc7IE1hbGxl dHRlLCBFZHdpbg0KU3ViamVjdDogUmU6IFttcGxzXSBzZWFtbGVzcyBNUExTDQoNCkNocmlzLA0K DQpUb3RhbGx5IGFncmVlLg0KDQpZYWFrb3YsDQoNCkkgaGF2ZW4ndCByZWFkIGRyYWZ0LWxleW1h bm4tbXBscy1zZWFtbGVzcy1tcGxzLTAzIGluIGl0cyBlbnRpcmV0eSBidXQgSSBkaWQgcmVhZCB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhbmQgbXkgaW50ZXJwcmV0YXRpb24g d2FzIHRoYXQgdGhhdCBzdGF0ZW1lbnQgeW91IHF1b3RlLCBhbmQgdGhlIHNlbnRlbmNlIHRoYXQg Zm9sbG93cywgaS5lLg0KDQogICBOZXZlcnRoZWxlc3MgdGhlIHVuYXV0aG9yaXplZCBhY2Nlc3Mg dG8gc3VjaCBpbiBkZXZpY2UNCiAgIFNIT1VMRCBOT1QgaW1wb3NlIGFueSBzZWN1cml0eSByaXNr cyB0byB0aGUgTVBMUyBpbmZyYXN0cnVjdHVyZQ0KICAgaXRzZWxmLiAgU2VhbWxlc3MgTVBMUyBt dXN0IGJlIHN0YWJsZSByZWdhcmRpbmcgYXR0YWNrcyBhZ2FpbnN0DQogICBhY2Nlc3MgYW5kIGFn Z3JlZ2F0aW9uIG5vZGVzIHJ1bm5pbmcgTVBMUy4NCg0KSXMgbm90IG1ha2luZyBhIGNsYWltIHRo YXQgdGhlcmUgYXJlIG5vIHNlY3VyaXR5IHJpc2tzIGluIHRoYXQgZGVwbG95bWVudCBtb2RlbCBi dXQgcmF0aGVyIGlzIHN0YXRpbmcgYSByZXF1aXJlbWVudCB0aGF0IHRoZSBhcmNoaXRlY3R1cmUv ZXRjIFNIT1VMRCBjb25zaWRlciB0aGUgc2VjdXJpdHkgcmlza3MgYW5kIG1pbmltaXNlIHRoZW0u DQoNClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHJhdGhlciBzaG9ydCBh bmQgSSBpbnRlcnByZXRlZCB0aGUgdGV4dCBpbiB0aGVyZSBhcyBpbnRyb2R1Y3RvcnkgdGV4dCB3 aGljaCBpcyBwcmVhbWJsZSB0byB0aGUgaWRlbnRpZmllZCBzdWItc2N0aW9ucyB0aGF0IGFyZSBj dXJyZW50bHkgbWFya2VkIFRCRC4NCg0KQXNzdW1pbmcgbXkgaW50ZXJwcmV0YXRpb24gaXMgY29y cmVjdCAoYW5kIEkgYW0gc3VyZSB0aGUgZHJhZnQncyBhdXRob3JzIGNhbiBjb25maXJtL2Rlbnkg dGhhdCkgdGhlbiB0aGUgcXVlc3Rpb24gSSBndWVzcyBpcyB3aGV0aGVyIHlvdSBmZWVsIHRoYXQg ZnVydGhlciB0ZXh0IG5lZWRzIHRvIGJlIGRldmVsb3BlZCBiZWZvcmUgYWRvcHRpbmcgdGhlIGRy YWZ0IGFzIGEgV0cgZG9jdW1lbnQgb3Igd2hldGhlciB0aGF0IGNhbiBkb25lIGJ5IHRoZSBXRyBh ZnRlciB0aGUgZHJhZnQgaXMgYWRvcHRlZD8NCg0KQmVuDQoNCg0KT24gMjkgTWFyIDIwMTEsIGF0 IDIxOjQ1LCBDaHJpc3RvcGhlciBMSUxKRU5TVE9MUEUgd3JvdGU6DQoNCj4gR3JlZXRpbmdzLA0K PiANCj4gTGV0IG1lIHNlY29uZCB0aGlzIHNldCBvZiBjb25jZXJucy4gIEluIGFuIFNQIG5ldHdv cmssIEkgY2FuIGVsZWN0IG5vdCB0byBleHRlbmQgbXkgSUdQIGludG8gdW5jb250cm9sbGVkIHNw YWNlcywgYW5kLCBpbnN0ZWFkIHVzZSBjb250cm9sIHBsYW5lIHByb3RvY29scyB0aGF0IEkgY2Fu IGFwcGx5IHBvbGljeSB0byAoQkdQIGNvbWVzIHRvIG1pbmQpLiAgVGhlIGRvY3VtZW50IGRvZXMg dGFsayBhYm91dCBoaWVyYXJjaHksIGFuZCB1c2luZyBCR1AgdG8gZGlzdHJpYnV0ZSBsYWJlbHMg KGFueW9uZSBjYXJlIHRvIHRoaW5rIGFib3V0IHRoZSBudW1iZXIgb2Ygbm9uLWFnZ3JlZ2F0ZWFi bGUgbGFiZWxzIGluIGEgbGFyZ2UgbmV0d29yayB0aGF0IEJHUCB3b3VsZCBoYXZlIHRvIGRpc3Ry aWJ1dGUsIGJ0dz8pLiAgSG93ZXZlciwgdGhlcmUgaXMgbm8gbWVudGlvbiBvZiB0aGUgc2VjdXJp dHkgaW1wbGljYXRpb25zIG9mIGRlZmluaW5nIHRoZSBjb3JyZWN0IChvciBpbmNvcnJlY3QpIGFn Z3JlZ2F0aW9uL3Byb3RvY29sIGJvdW5kYXJ5LiAgDQo+IA0KPiBJbiB0aGUgbm90IHRvbyBkaXN0 YW50IGZ1dHVyZSwgc29tZSBsYXp5IG9wZXJhdG9yIGRlY2lkZXMgdGhhdCBzdGF0aWNzIGFyZSB0 b28gaGFyZCwgYW5kIGV4dGVuZHMgdGhlIElHUCBkb3duIHRvIHRoZSBhY2Nlc3Mgbm9kZXMgKHdo aWNoIGFyZSBub3QgcGh5c2ljYWxseSBjb250cm9sbGVkIC0gbWF5IGV2ZW4gYmUgb24gY3VzdG9t ZXIgcHJlbSkgLSBDdXN0b21lciBkb2VzIHNvbWUgInJlc2VhcmNoIiBhbmQgaW5qZWN0cyByb3V0 ZXMgaW50byBzYWlkIElHUCBhZnRlciBjaXJjdW12ZW50aW5nIGRlZmF1bHQgcGFzc3dvcmRzIC0g c2l0IGJhY2sgYW5kIHdhdGNoIHRoZSBmdW4gYW5kIGZpcmV3b3Jrcy4gICBBbnlvbmUgd2hvIHNh eXMgdGhhdCB0aGUgc2VydmljZSBwcm92aWRlciB3b24ndCBiZSBsYXp5IGFuZC9vciB3b24ndCBk ZXBsb3kgd2l0aCBkZWZhdWx0IG9yIHdlbGwta25vd24gcGFzc3dvcmRzIC0gSSBoYXZlIE1BTlkg Y2FzZXMgdG8gcHJvdmUgb3RoZXJ3aXNlLi4uLg0KPiANCj4gSWYgd2UgdGhpbmsgdGhpcyB3b3Jr IGlzIHZhbGlkLCB0aGVuIHdlIFJFQUxMWSBuZWVkIHRvIGNvdmVyIHRoaXMgaW4gZGV0YWlsIGlu IHRoZSBhcmNoaXRlY3R1cmUgYW5kIHNlY3VyaXR5IHNlY3Rpb25zLiAgSSBhbSBub3QsIGhvd2V2 ZXIsIGluZGljYXRpbmcgdGhhdCBJIGRvIHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhLi4uLg0KPiAN Cj4gQ2hyaXMNCj4gDQo+IE9uIDMwTWFyMjAxMSwgYXQgMDMuMDksIFlhYWtvdiBTdGVpbiB3cm90 ZToNCj4gDQo+PiBUaGF0IGlzIG5vdCBxdWl0ZSB0aGUga2luZCBvZiBhdHRhY2sgSSB3YXMgd29y cmllZCBhYm91dC4NCj4+IA0KPj4gU29tZW9uZSBhYmxlIHRvIGluamVjdCBwYWNrZXRzIGludG8g YW4gTVBMUyBuZXR3b3JrDQo+PiBjYW4gd3JlYWsgbW9yZSBoYXZvYyB0aGFuIGEgbW9uc3RlciB0 cnVjay4NCj4+IA0KPj4gWShKKVMNCj4+IA0KPj4gRnJvbTogTWFsbGV0dGUsIEVkd2luIFttYWls dG86RWR3aW4uTWFsbGV0dGVAYmhuaXMuY29tXQ0KPj4gU2VudDogVHVlc2RheSwgTWFyY2ggMjks IDIwMTEgMTg6NTMNCj4+IFRvOiBZYWFrb3YgU3RlaW47IG1wbHNAaWV0Zi5vcmcNCj4+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gc2VhbWxlc3MgTVBMUw0KPj4gDQo+PiBUaGlzIG1hZGUgbWUgbGF1Z2gs IGJ1dCBJJ20gZ29pbmcgdG8gZ28gb3V0IG9uIGEgbGltYiBoZXJlIGFuZCBzYXkgdGhlIHR5cGUg b2YgYWNjZXNzIG1lYW50IHdhcyBwaHlzaWNhbCBhY2Nlc3MuICAgRm9yIGluc3RhbmNlLCBpZiBJ IHRha2Ugb3V0IG15IG1vbnN0ZXIgdHJ1Y2sgYW5kIHBoeXNpY2FsbHkgYWNjZXNzIHNhaWQgRFNM QU0gYnkgcnVubmluZyBvdmVyIHRoZSBzdHJlZXQgY2FiaW5ldCB0aGF0IHdvdWxkbid0IGhhdmUg YW55IHJlYWwgcmlzayB0byB0aGUgTVBMUyBpbmZyYXN0cnVjdHVyZSAtIGp1c3QgdG8gdGhlIERT TEFNLiAgQnV0IGEgc2xpZ2h0bHkgbW9kaWZpZWQgd29yZGluZyBtaWdodCBoZWxwLg0KPj4gDQo+ PiBFZA0KPj4gDQo+PiBGcm9tOiBZYWFrb3YgU3RlaW4gPHlhYWtvdl9zQHJhZC5jb208bWFpbHRv OnlhYWtvdl9zQHJhZC5jb20+Pg0KPj4gRGF0ZTogVHVlLCAyOSBNYXIgMjAxMSAxMTo0NDoyNCAt MDQwMA0KPj4gVG86ICJtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiIgPG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Pg0KPj4gU3ViamVjdDogW21wbHNdIHNlYW1s ZXNzIE1QTFMNCj4+IA0KPj4gQmVmb3JlIGRyYWZ0LWxleW1hbm4tbXBscy1zZWFtbGVzcy1tcGxz LTAzIGlzIG1vdmVkIHRvIGJlY29tZSBhIFdHIGRyYWZ0LA0KPj4gSSB3b3VsZCBsaWtlIHRvIGNs YXJpZnkgIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMuDQo+PiANCj4+IFRoZSBzZWN1cml0eSBz ZWN0aW9uIG9mIHRoaXMgZHJhZnQgc3RhcnRzIHZlcnkgd2VsbCA6DQo+PiANCj4+ICAgSW4gYSB0 eXBpY2FsIE1QTFMgZGVwbG95bWVudCB0aGUgdXNlIG9mIE1QTFMgaXMgbGltaXRlZCB0byByZWxh dGl2ZWx5DQo+PiAgIHNtYWxsIG5ldHdvcmsgY29uc2lzdGluZyBvZiBjb3JlIGFuZCBlZGdlIG5v ZGVzLiAgVGhvc2Ugbm9kZXMgYXJlDQo+PiAgIHVuZGVyIGZ1bGwgY29udHJvbCBvZiB0aGUgc2Vy dmljZXMgcHJvdmlkZXIgYW5kIHBsYWNlZCBhdCBsb2NhdGlvbnMNCj4+ICAgd2hlcmUgb25seSBh dXRob3JpemVkIHBlcnNvbmFsIGhhcyBhY2Nlc3MgKHRoaXMgYWxzbyBpbmNsdWRlcw0KPj4gICBw aHlzaWNhbCBhY2Nlc3MgdG8gdGhlIG5vZGVzKS4gIFdpdGggdGhlIGV4dGVuc2lvbnMgb2YgTVBM UyB0b3dhcmRzDQo+PiAgIGFjY2VzcyBhbmQgYWdncmVnYXRpb24gbm9kZXMgbm90IGFsbCBub2Rl cyB3aWxsIGJlICJsb2NrZWQgYXdheSIgaW4NCj4+ICAgc2VjdXJlIGxvY2F0aW9ucy4gIFNtYWxs IGFjY2VzcyBub2RlcyBsaWtlIERTTEFNcyB3aWxsIGJlIGxvY2F0ZWQgaW4NCj4+ICAgc3RyZWV0 IGNhYmluZXRzLCBwb3RlbnRpYWxseSBvZmZlcmluZyBhY2Nlc3MgdG8gdGhlICJpbnRlcmVzdGVk DQo+PiAgIHJlc2VhcmNoZXIiLg0KPj4gDQo+PiBJIGNvdWxkbid0IGhhdmUgc3RhdGVkIHRoaXMg YW55IGJldHRlciBteXNlbGYuDQo+PiBIb3dldmVyIGl0IHRoZW4gZ29lcyBvbiB0byBzYXkgOg0K Pj4gDQo+PiAgICAgICAgICAgICAgICAgTmV2ZXJ0aGVsZXNzIHRoZSB1bmF1dGhvcml6ZWQgYWNj ZXNzIHRvIHN1Y2ggaW4gZGV2aWNlDQo+PiAgIFNIT1VMRCBOT1QgaW1wb3NlIGFueSBzZWN1cml0 eSByaXNrcyB0byB0aGUgTVBMUyBpbmZyYXN0cnVjdHVyZQ0KPj4gICBpdHNlbGYuDQo+PiANCj4+ IEkgd291bGQgbG92ZSB0byBoZWFyIHRoZSByZWFzb25pbmcgYmVoaW5kIHRoaXMgc3RhdGVtZW50 Lg0KPj4gDQo+PiBZKEopUw0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGUtbWFpbCBtYXkgY29udGFp biBpbmZvcm1hdGlvbiB0aGF0IGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBvciBvdGhlcndp c2UgcHJvdGVjdGVkIGZyb20gZGlzY2xvc3VyZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCBvZiB0aGlzIGUtbWFpbCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGJ5IHJldHVybiBlLW1haWwsIHB1cmdlIGl0IGFuZCBkbyBub3QgZGlzc2VtaW5hdGUg b3IgY29weSBpdC4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4gbXBsc0BpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IA0KPiAtLS0NCj4g5p2O5p+v 552/DQo+IENoZWNrIG15IFBHUCBrZXkgaGVyZToNCj4gaHR0cHM6Ly93d3cuYXNnYWFyZC5vcmcv fmNkbC9jZGwuYXNjDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= From Thomas.Beckhaus@telekom.de Sun Apr 3 12:34:58 2011 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 8E1F93A67D7 for ; Sun, 3 Apr 2011 12:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoZ+NEFXGQ4S for ; Sun, 3 Apr 2011 12:34:57 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 8D1793A63D3 for ; Sun, 3 Apr 2011 12:34:56 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 03 Apr 2011 21:36:35 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.34]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Sun, 3 Apr 2011 21:36:35 +0200 From: To: Date: Sun, 3 Apr 2011 21:36:33 +0200 Thread-Topic: [mpls] Questions on seamless MPLS Thread-Index: AcvwdOpCvS2KSmS0QPaHc3mh0lneCgAsIsSwAEMfV1A= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0184E73823@HE111648.emea1.cds.t-internal.com> References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> <4D95D999.604@tid.es> <14C7F4F06DB5814AB0DE29716C4F6D67182EA529@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67182EA529@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] Questions on seamless 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: Sun, 03 Apr 2011 19:34:58 -0000 Javier, see in line (TB) Thomas > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Henderickx, Wim (Wim) > Sent: Saturday, April 02, 2011 1:06 PM > To: Javier Jimenez > Cc: mpls@ietf.org > Subject: Re: [mpls] Questions on seamless MPLS > > In-line > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Javier Jimenez > Sent: vrijdag 1 april 2011 15:57 > Cc: mpls@ietf.org > Subject: [mpls] Questions on seamless MPLS > > Hi all, > > Here in Telef=F3nica we are pushing for MPLS E2E solutions, and it seems > the seamless MPLS draft respresents a great starting point. > Congratulations to the authors for this nice piece of work. > > I have two questions, not being involved in the draft so far: > 1.- The draft proposes to use the next-hop-self in the outwards > direction (with respect to an specific regional area) and to leave > next-hop-unchanged for the incoming traffic. This approach > requires that > some routing information is flooded from the core area to the regional > ones (specificallly, reachability to the ABRs). I'm sure this design > increases the scalability of the solution, but two concerns > come to my mind: > - Wouldn't it be cleaner to perform the next-hop-self in both > directions? I come from the transport world, where things tend to be > symetrical (and easier to understand for humans). > > WH> when you perform NH self you will install a LBL entry for > every LBL prefix and would result in a bigger LFIB. > > - More specifically, when migrating to a seamless architecture, it may > be the case that the IGPs are already different in the core and in the > regions (also the label distribution protocols), and it could not be > possible to flood external IGP information into the regional areas or > the operator would prefer to keep IGP clear from external > influece (for > that reason you have BGP). > In summary, would there be room for two options (and which > are the pros > & cons) or just the one recommended in the draft? > > WH> the reason of the current architecture is due to > scalability as outlined above > TB> we had exaclty this discussion regarding a next hop self (NHS) for inco= mming traffic. In an single IGP scenario, the NHS is not required (in our d= iscussion, symmetry was also a topic - but we are neigher physicists nor tr= ansport people). So we decided to avoid it because of scalability reasons a= s Wim explained. But there are certain scenarios, where a NHS for incomming= traffic is preferred or required. > 2.- Right now, VPLS services are typically offered only on a regional > basis due to scalability issues. How would a VPLS service scale on top > of a seamless MPLS architecture? Is this requirement part of the > architecture or has been intentionally removed? > > WH> VPLS scale is orthogonal of the seamless MPLS > architecture and it depends on the MAC@, replication/P2MP LSP > architecture, end-points, use of H-VPLS, etc. Seamless MPLS > is not changing these parameters for VPLS services, VPLS will > just use the seamless MPLS architecture TB> With the Seamless-MPLS approach, we consider different VPLS scenarios: = H-VPLS, flat VPLS or also a combination of PW based backhaul to a VSI on a = central PE (section 10.1.3 of rfc4762). This does not fix the scalability p= roblem of Ethernet, but provide some possible solutions (e.g. easy backhaul= ing to a high scaling PE). > > Kind regards, > Javier Jimenez > Telef=F3nica Research > > Este mensaje se dirige exclusivamente a su destinatario. > Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de > correo electr=F3nico en el enlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We > only send and receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > 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 Internet-Drafts@ietf.org Mon Apr 4 09:45:03 2011 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 399A728C118; Mon, 4 Apr 2011 09:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, 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 TFiyeoxtG4xI; Mon, 4 Apr 2011 09:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BB153A69C8; Mon, 4 Apr 2011 09:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110404164502.19312.84212.idtracker@localhost> Date: Mon, 04 Apr 2011 09:45:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-mldp-recurs-fec-01.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, 04 Apr 2011 16:45:03 -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 : Using mLDP through a Backbone where there is no Route to the Root Author(s) : I. Wijnands, et al. Filename : draft-ietf-mpls-mldp-recurs-fec-01.txt Pages : 12 Date : 2011-04-04 The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, if the route to the root node is a BGP route, and the intermediate nodes are part of a BGP-free core, this is not possible. This document specifies procedures which enable a MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address which is known to the intermediate nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-recurs-fec-01.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-mldp-recurs-fec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-04093711.I-D@ietf.org> --NextPart-- From aldrin.ietf@gmail.com Mon Apr 4 10:09:49 2011 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 4F72A3A6A08 for ; Mon, 4 Apr 2011 10:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] 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 jsFhSn8H5o9g for ; Mon, 4 Apr 2011 10:09:48 -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 A63143A6A06 for ; Mon, 4 Apr 2011 10:09:48 -0700 (PDT) Received: by gyf3 with SMTP id 3so2639845gyf.31 for ; Mon, 04 Apr 2011 10:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=aO0tJTUx6M79+pwBQCEQC++rQ3cjA99/BM9WhN/SrEM=; b=tSJ4Fr0HacR6jfbebB+XSAk50xXglrB0eedfbZIlp+vGL6o1zMHDtED0m91M1WXXb0 4Ky4ysnXOgFSONNmnnpsKV0ByJOmbi8OZ3va4KSucxDmhUH2uw8StG5mTAX6iFb+W3Xm xYArjEvA3qPpFNjlYec41jDKkw6VvnM/g90r8= 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=XIKPAwOKvXj3pwURJciSq6ef68ngWZ4VKwfBWiHZ0/TQaPSgci1voxIXpxK+AAK1ok JGrq83YXYjiG1fbMknKNHEDw+yzhvG/VowvHylLetNlemZwIlvFhBDN4yaMfi/TzMuWb 05vSuZ3eB7+Jc4Vrx8SeAOi1IJFMUGVWtfRj4= MIME-Version: 1.0 Received: by 10.236.154.165 with SMTP id h25mr6051537yhk.365.1301937091109; Mon, 04 Apr 2011 10:11:31 -0700 (PDT) Received: by 10.147.82.18 with HTTP; Mon, 4 Apr 2011 10:11:31 -0700 (PDT) Date: Mon, 4 Apr 2011 10:11:31 -0700 Message-ID: From: Sam Aldrin To: mpls-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=20cf303f6d1ed5e36104a01ad9fd Cc: mpls@ietf.org, venkatesan.mahalingam@aricent.com, Kannan.Sampath@aricent.com Subject: [mpls] WG adoption of draft-vkst-mpls-tp-te-mib-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: Mon, 04 Apr 2011 17:09:49 -0000 --20cf303f6d1ed5e36104a01ad9fd Content-Type: text/plain; charset=ISO-8859-1 We have received good feedback at WG meeting on Tuesday and over emails regarding the "draft-vkst-mpls-tp-te-mib-00". The authors would like to request to adopt this as a WG draft. thanks -sam --20cf303f6d1ed5e36104a01ad9fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    We have received good feedback at WG meeting on = Tuesday and over emails regarding the "draft-vkst-mpls-tp-te-mib-00&qu= ot;.
    The authors would like to request to adopt this as a WG dra= ft.

    thanks
    -sam=
    --20cf303f6d1ed5e36104a01ad9fd-- From wwwrun@core3.amsl.com Thu Apr 7 19:07:59 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 387523A6834; Thu, 7 Apr 2011 19:07:58 -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: <20110408020759.387523A6834@core3.amsl.com> Date: Thu, 7 Apr 2011 19:07:59 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, lear@cisco.com, loa.andersson@ericsson.com, yoichi.maeda@ttc.or.jp, kam.lam@alcatel-lucent.com, ahmpls-tp@lists.itu.int, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "Response to 5 liaisons with comments on MPLS WG documents (ref #053.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, 08 Apr 2011 02:07:59 -0000 Title: Response to 5 liaisons with comments on MPLS WG documents (ref #053.01) Submission Date: 2011-04-07 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1040 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ttc.or.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int adrian.farrel@huawei.com rcallon@juniper.net lear@cisco.com stbryant@cisco.com mpls@ietf.org swallow@cisco.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com rcallon@juniper.net Purpose: In response Body: Thank you for your liaisons: LS298 - Response to request for early review on two MPLS WG documents [Ref #048.02] LS285 - Review of "draft-ietf-mpls-tp-linear-protection-04 (ref #049.01)" [ref #049.02] LS295 - Reply to the IETF MPLS working group last call on "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks (ref #051.01)" (ref #051.02) LS281 - Comments on the IETF MPLS working group last call on "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile" draft-ietf-mpls-tp-cc-cv-rdi-03 (ref #050.01)" (ref #050.02) LS289 - Reply to the IETF MPLS working group last call on "MPLS Fault Management OAM (ref #047.01)" (ref #047.02) Your comments will be considered along with all other comments received by the authors, and the resolution of all comments will be presented on the MPLS mailing list with new versions of the drafts being produced as necessary. We will notify you via ahmpls-tp@lists.itu.int when the working group has consensus on each document. Loa Andersson on behalf of the mpls wg co-chairs Attachment(s): No document has been attached From loa@pi.nu Fri Apr 8 17:01:20 2011 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 375A63A6905 for ; Fri, 8 Apr 2011 17:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIWbHHJl3tGN for ; Fri, 8 Apr 2011 17:01:19 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 369973A6820 for ; Fri, 8 Apr 2011 17:01:19 -0700 (PDT) Received: from [10.100.1.97] (unknown [203.47.135.90]) (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 009D72A8001; Sat, 9 Apr 2011 02:03:01 +0200 (CEST) Message-ID: <4D9FA231.6090707@pi.nu> Date: Sat, 09 Apr 2011 10:02:57 +1000 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mpls@ietf.org References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> In-Reply-To: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 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, 09 Apr 2011 00:01:20 -0000 Working Group, this working group last call has ended! There have been comments, could authors/editors please resolve the comments, share the resoloution with the working group mailing and publish a new version of the draft. /Loa on behalf of the working group chairs On 2011-03-16 10:26, loa@pi.nu wrote: > Working Group, > > this is to start a 3 week working group last call on > > draft-ietf-mpls-tp-on-demand-cv-03 > > Please send comments to the working group mailing list > mpls@ietf.org > > The working group last call ends on April 8, 2011. > > /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 loa@pi.nu Fri Apr 8 17:38:19 2011 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 803353A6820 for ; Fri, 8 Apr 2011 17:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.143 X-Spam-Level: X-Spam-Status: No, score=-101.143 tagged_above=-999 required=5 tests=[AWL=-1.456, BAYES_00=-2.599, SUSPICIOUS_RECIPS=2.912, 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 4PA0fewP1dRh for ; Fri, 8 Apr 2011 17:38:18 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 673C63A681E for ; Fri, 8 Apr 2011 17:38:18 -0700 (PDT) Received: from [10.100.1.97] (unknown [203.47.135.90]) (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 A5A242A8001; Sat, 9 Apr 2011 02:40:00 +0200 (CEST) Message-ID: <4D9FAADC.4010508@pi.nu> Date: Sat, 09 Apr 2011 10:39:56 +1000 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mpls-mp-ldp-reqs@tools.ietf.org, draft-ietf-mpls-tp-cc-cv-rdi@tools.ietf.org, draft-ietf-mpls-tp-fault@tools.ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org, draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: [mpls] formally closing 5 outsstanding mpls wg last calls 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, 09 Apr 2011 00:38:19 -0000 MPLS wg. we have some working group last calls that has not formally been closed. This mail is to close the following wg last calls LC on publishing draft-ietf-mpls-mp-ldp-reqs-06 as an Informational RFC with Historic status ended March 26th - we have support for requesting prublication with Historic status LC for draft-ietf-mpls-tp-identifiers-04 ended March 18th - there were comments, the authors need to consider these comments and publish a new version LC for draft-ietf-mpls-tp-fault-03 ended February 28th - there were comments, could the authors please resolve them, share the resolution on the mpls wg mailing list and publish a new draft LC for draft-ietf-mpls-tp-linear-protection-04 ended February 28th - there were comments, the authors has resolved these and they been shared on the mpls wg mailing list, a new version (-06) has been published; however the wg chairs has pointed out that the security and IANA sections needs to be completed, could the authors please do this and publish a new version of the document LC for draft-ietf-mpls-tp-cc-cv-rdi-03 ended February 28th - there were comments, the authors are close to completing the comment resolution, once this is done the authors should publish the new version and share the resolution of the comments on the mpls wg mailing list. /Loa on behalf of the mpls wg co-chairs -- 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 nurit.sprecher@nsn.com Mon Apr 11 09:51:30 2011 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 95DE028C151 for ; Mon, 11 Apr 2011 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.494 X-Spam-Level: X-Spam-Status: No, score=-5.494 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] 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 VK337MQPO4TY for ; Mon, 11 Apr 2011 09:51:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 7BBBF28C147 for ; Mon, 11 Apr 2011 09:51:28 -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 p3BGpOwM012028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2011 18:51:25 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3BGpJjO023612; Mon, 11 Apr 2011 18:51:24 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 18:51: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_01CBF868.B11F8111" Date: Mon, 11 Apr 2011 18:51:22 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403A62507@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS-TP CC-CV-RDI Thread-Index: Acv4aK/DoQcq08XcSPCl0V4Wl5d+eg== From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "David Ward" , "ext David Allan I" , "John E Drake" , "Nitin Bahadur" X-OriginalArrivalTime: 11 Apr 2011 16:51:24.0386 (UTC) FILETIME=[B13A3420:01CBF868] Cc: mpls@ietf.org, "Schink, Helmut \(NSN - DE/Munich\)" Subject: [mpls] MPLS-TP CC-CV-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, 11 Apr 2011 16:51:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF868.B11F8111 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, Slide 14 of the attached, says that "This document an enhancement to RFC 5884/5885....But it still requires two new code points as it will not be perfectly backwards compatible...." http://tools.ietf.org/agenda/80/slides/mpls-9.pdf It is my understanding that the extension done to BFD is completely compatible with BFD.=20 Can you please clarify this point? Is the solution being defined in draft cc-cv-rdi is compatible with BFD?=20 Is it also possible for CC-CV-RDI and existing BFD to be compatible today given only the proper configuration? Best regards, Nurit =20 ------_=_NextPart_001_01CBF868.B11F8111 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear = authors,

    Slide 14 of the attached, = says that "This document an enhancement to RFC 5884/5885....But it = still requires two new code points as it will not be perfectly = backwards compatible...."

    http://tools.i= etf.org/agenda/80/slides/mpls-9.pdf

    It is my understanding that the extension done to BFD = is completely compatible with BFD.

    Can you please clarify this point? Is the solution = being defined in draft cc-cv-rdi is compatible with BFD? =

    Is it also possible for CC-CV-RDI = and existing BFD to be compatible today given only the proper = configuration?

    Best = regards,

    Nurit

     

    ------_=_NextPart_001_01CBF868.B11F8111-- From wwwrun@rfc-editor.org Mon Apr 11 12:21:00 2011 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 570183A6AF4; Mon, 11 Apr 2011 12:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 tpLkNAX2YGGm; Mon, 11 Apr 2011 12:20:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C34603A6B41; Mon, 11 Apr 2011 12:20:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 77B90E0784; Mon, 11 Apr 2011 12:20:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110411192059.77B90E0784@rfc-editor.org> Date: Mon, 11 Apr 2011 12:20:59 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6215 on MPLS Transport Profile User-to-Network and Network-to-Network Interfaces 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, 11 Apr 2011 19:21:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6215 Title: MPLS Transport Profile User-to-Network and Network-to-Network Interfaces Author: M. Bocci, L. Levrau, D. Frost Status: Informational Stream: IETF Date: April 2011 Mailbox: matthew.bocci@alcatel-lucent.com, lieven.levrau@alcatel-lucent.com, danfrost@cisco.com Pages: 6 Characters: 13619 Updates: RFC5921 I-D Tag: draft-ietf-mpls-tp-uni-nni-03.txt URL: http://www.rfc-editor.org/rfc/rfc6215.txt The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI. 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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Internet-Drafts@ietf.org Wed Feb 16 10:00:02 2011 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 DA99F3A6EE4; Wed, 16 Feb 2011 10:00:02 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: multipart boundary is missing, or contains CR or LF X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 Fs5smSPnxhW0; Wed, 16 Feb 2011 10:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF873A6CAF; Wed, 16 Feb 2011 10:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundry="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110216180001.2646.79833.idtracker@localhost> Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-security-framework-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 16 Feb 2011 18:00:03 -0000 X-Original-Date: Wed, 16 Feb 2011 10:00:01 -0800 X-List-Received-Date: Wed, 16 Feb 2011 18:00:03 -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 Security Framework Author(s) : N. Bitar, et al Filename : draft-ietf-mpls-tp-security-framework-00.txt Pages : 25 Date : 2011-02-16 This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). Extended from MPLS technologies, MPLS-TP introduces new OAM capabilities, transport oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects that are relevant in the context of MPLS-TP specifically. It describes the security requirements for MPLS-TP; potential securities threats and migration procedures for MPLS-TP networks and MPLS-TP inter-connection to MPLS and GMPLS networks. 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. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-00.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-security-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16095733.I-D@ietf.org> --NextPart-- From david.i.allan@ericsson.com Mon Apr 11 15:19:30 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DA25E0683 for ; Mon, 11 Apr 2011 15:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=1.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq6njwn4mN2y for ; Mon, 11 Apr 2011 15:19:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 0FE28E0672 for ; Mon, 11 Apr 2011 15:19:18 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3BM8NNQ001089; Mon, 11 Apr 2011 17:08:27 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 11 Apr 2011 18:08:19 -0400 From: David Allan I To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , David Ward , John E Drake , Nitin Bahadur Date: Mon, 11 Apr 2011 18:08:16 -0400 Thread-Topic: MPLS-TP CC-CV-RDI Thread-Index: Acv4aK/DoQcq08XcSPCl0V4Wl5d+egAAN4XA Message-ID: <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> References: <077E41CFFD002C4CAB7DFA4386A5326403A62507@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326403A62507@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_60C093A41B5E45409A19D42CF7786DFD51D548E241EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:19:30 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD51D548E241EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nurit It is backwards compatible in the sense that the new code points allow the = additional behaviors specified for MPLS TP to be disambiguated from existi= ng RFC 5884/5 behaviors - this is the addition of the GAL, the source MEP TLV, interleaving of = CC and CV PDUs, and accepting the TP-FAULT inputs as valid state machine in= puts. It is not perfectly backwards compatible in that the addition of the GAL an= d new code points means deployed implementations will not support the new e= ncap and TLV without an upgrade .... RFC 5885 is close but not an exact mat= ch due to the addition of the Source MEP ID TLV. Some implementation tweaks= are required. hope this helps Dave ________________________________ From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Monday, April 11, 2011 9:51 AM To: David Ward; David Allan I; John E Drake; Nitin Bahadur Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, Helmut = (NSN - DE/Munich) Subject: MPLS-TP CC-CV-RDI Dear authors, Slide 14 of the attached, says that "This document an enhancement to RFC 58= 84/5885....But it still requires two new code points as it will not be perf= ectly backwards compatible...." http://tools.ietf.org/agenda/80/slides/mpls-9.pdf It is my understanding that the extension done to BFD is completely compati= ble with BFD. Can you please clarify this point? Is the solution being defined in draft c= c-cv-rdi is compatible with BFD? Is it also possible for CC-CV-RDI and existing BFD to be compatible today g= iven only the proper configuration? Best regards, Nurit --_000_60C093A41B5E45409A19D42CF7786DFD51D548E241EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi Nurit
     
    It is backwards compatible in the sense that=20 the new code points allow the additional  behaviors specified = for=20 MPLS TP to be disambiguated from existing RFC 5884/5=20 behaviors
      &n= bsp; - this is the addition of the GAL, th= e source=20 MEP TLV, interleaving of CC and CV PDUs, and accepting the TP-FAULT inputs = as=20 valid state machine inputs.
     
    It is not perfectly backwards compatible in that t= he=20 addition of the GAL and new code points means deployed implementations= will=20 not support the new encap and TLV without an upgrade .... RFC 5885 is = close=20 but not an exact match due to the addition of the Source MEP ID TLV. S= ome=20 implementation tweaks are required.
     
    hope this helps
    Dave
     <= /DIV>
    From: Sprec= her, Nurit=20 (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com]
    Sent: Mo= nday,=20 April 11, 2011 9:51 AM
    To: David Ward; David Allan I; John E Drak= e;=20 Nitin Bahadur
    Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);=20 mpls@ietf.org; Schink, Helmut (NSN - DE/Munich)
    Subject: MPLS-TP= =20 CC-CV-RDI

    Dear authors,

    Slide 14 of the attached, says that "This document = an=20 enhancement to RFC 5884/5885....But it still requires two new code points a= s it=20 will not be perfectly backwards compatible...."

    http://tools.iet= f.org/agenda/80/slides/mpls-9.pdf

    It is my understanding that the extension done to BFD = is=20 completely compatible with BFD.

    Can you please clarify this point? Is the solution bei= ng=20 defined in draft cc-cv-rdi is compatible with BFD?

    Is it also possible for CC-CV-RDI and existing BFD to = be=20 compatible today given only the proper configuration?

    Best regards,

    Nurit

     

    --_000_60C093A41B5E45409A19D42CF7786DFD51D548E241EUSAACMS0703e_-- From curtis@occnc.com Mon Apr 11 20:27:54 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BF715E069F for ; Mon, 11 Apr 2011 20:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyKW4DXUnxuB for ; Mon, 11 Apr 2011 20:27:53 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id ACBF7E0663 for ; Mon, 11 Apr 2011 20:27:53 -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 p3C3Rp0Q023230; Mon, 11 Apr 2011 23:27:51 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Mon, 11 Apr 2011 18:08:16 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> Date: Mon, 11 Apr 2011 23:27:51 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , David Ward , "Schink, Helmut \(NSN - DE/Munich\)" Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 12 Apr 2011 03:27:54 -0000 In message <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> David Allan I writes: > > Hi Nurit > > It is backwards compatible in the sense that the new code points allow > the additional behaviors specified for MPLS TP to be disambiguated > from existing RFC 5884/5 behaviors > > - this is the addition of the GAL, the source MEP TLV, > interleaving of CC and CV PDUs, and accepting the TP-FAULT > inputs as valid state machine inputs. > > It is not perfectly backwards compatible in that the addition of the > GAL and new code points means deployed implementations will not > support the new encap and TLV without an upgrade .... RFC 5885 is > close but not an exact match due to the addition of the Source MEP ID > TLV. Some implementation tweaks are required. The usual way to handle an extension to an existing protocol is to use a capability negotiation, not assign a new code point. > hope this helps > Dave > > ________________________________ > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com] > Sent: Monday, April 11, 2011 9:51 AM > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > Subject: MPLS-TP CC-CV-RDI > > Dear authors, > > Slide 14 of the attached, says that "This document an enhancement to > RFC 5884/5885....But it still requires two new code points as it will > not be perfectly backwards compatible...." > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > It is my understanding that the extension done to BFD is completely > compatible with BFD. > Can you please clarify this point? Is the solution being defined in > draft cc-cv-rdi is compatible with BFD? > Is it also possible for CC-CV-RDI and existing BFD to be compatible > today given only the proper configuration? > Best regards, > Nurit From nurit.sprecher@nsn.com Mon Apr 11 22:58:34 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E978E0730 for ; Mon, 11 Apr 2011 22:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=1.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kkZUKQn6FW0 for ; Mon, 11 Apr 2011 22:58:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfc.amsl.com (Postfix) with ESMTP id 9893BE072D for ; Mon, 11 Apr 2011 22:58:32 -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 p3C5wQV1019462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 07:58:27 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3C5wFKU000793; Tue, 12 Apr 2011 07:58:26 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 07:58: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_01CBF8D6.A2451E31" Date: Tue, 12 Apr 2011 07:58:23 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403A62593@DEMUEXC014.nsn-intra.net> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS-TP CC-CV-RDI Thread-Index: Acv4aK/DoQcq08XcSPCl0V4Wl5d+egAAN4XAABrksAA= References: <077E41CFFD002C4CAB7DFA4386A5326403A62507@DEMUEXC014.nsn-intra.net> <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext David Allan I" , "David Ward" , "John E Drake" , "Nitin Bahadur" X-OriginalArrivalTime: 12 Apr 2011 05:58:24.0396 (UTC) FILETIME=[A28BECC0:01CBF8D6] Cc: mpls@ietf.org, "Schink, Helmut \(NSN - DE/Munich\)" Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 05:58:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF8D6.A2451E31 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, Thanks for your response. In the IETF we define protocols, so I believe it would be correct to say that the extension to the BFD protocol is fully compatible with BFD.=20 Best regards, Nurit =20 From: ext David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Tuesday, April 12, 2011 1:08 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; Nitin Bahadur Cc: mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) Subject: RE: MPLS-TP CC-CV-RDI =20 Hi Nurit =20 It is backwards compatible in the sense that the new code points allow the additional behaviors specified for MPLS TP to be disambiguated from existing RFC 5884/5 behaviors - this is the addition of the GAL, the source MEP TLV, interleaving of CC and CV PDUs, and accepting the TP-FAULT inputs as valid state machine inputs. =20 It is not perfectly backwards compatible in that the addition of the GAL and new code points means deployed implementations will not support the new encap and TLV without an upgrade .... RFC 5885 is close but not an exact match due to the addition of the Source MEP ID TLV. Some implementation tweaks are required.=20 =20 hope this helps Dave =20 ________________________________ From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com]=20 Sent: Monday, April 11, 2011 9:51 AM To: David Ward; David Allan I; John E Drake; Nitin Bahadur Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) Subject: MPLS-TP CC-CV-RDI Dear authors, Slide 14 of the attached, says that "This document an enhancement to RFC 5884/5885....But it still requires two new code points as it will not be perfectly backwards compatible...." http://tools.ietf.org/agenda/80/slides/mpls-9.pdf It is my understanding that the extension done to BFD is completely compatible with BFD.=20 Can you please clarify this point? Is the solution being defined in draft cc-cv-rdi is compatible with BFD?=20 Is it also possible for CC-CV-RDI and existing BFD to be compatible today given only the proper configuration? Best regards, Nurit =20 ------_=_NextPart_001_01CBF8D6.A2451E31 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi David,

    Thanks for your = response.

    In the IETF we define protocols, so I believe it = would be correct to say that the extension to the BFD protocol is fully = compatible with BFD.

    Best regards,

    Nurit

     

    From:= = ext David Allan I [mailto:david.i.allan@ericsson.com]
    Sent: = Tuesday, April 12, 2011 1:08 AM
    To: Sprecher, Nurit (NSN - = IL/Hod HaSharon); David Ward; John E Drake; Nitin Bahadur
    Cc: = mpls@ietf.org; Schink, Helmut (NSN - DE/Munich)
    Subject: RE: = MPLS-TP CC-CV-RDI

     

    Hi= Nurit

     

    It= is backwards compatible in the sense that the new code points allow the = additional  behaviors specified for MPLS TP to be disambiguated = from existing RFC 5884/5 behaviors

        - = this is the addition of the GAL, the source MEP TLV, interleaving of CC = and CV PDUs, and accepting the TP-FAULT inputs as valid state machine = inputs.

     

    It= is not perfectly backwards compatible in that the addition of the = GAL and new code points means deployed implementations will not support = the new encap and TLV without an upgrade .... RFC 5885 is close but = not an exact match due to the addition of the Source MEP ID TLV. = Some implementation tweaks are required.

     

    ho= pe this helps

    Da= ve

     

    From:= = Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com] =
    Sent: Monday, April 11, 2011 9:51 AM
    To: David = Ward; David Allan I; John E Drake; Nitin Bahadur
    Cc: Sprecher, = Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, Helmut (NSN - = DE/Munich)
    Subject: MPLS-TP CC-CV-RDI

    Dear = authors,

    Slide 14 of the attached, = says that "This document an enhancement to RFC 5884/5885....But it = still requires two new code points as it will not be perfectly = backwards compatible...."

    http://tools.i= etf.org/agenda/80/slides/mpls-9.pdf

    It is my understanding that the extension done to BFD = is completely compatible with BFD.

    Can you please clarify this point? Is the solution = being defined in draft cc-cv-rdi is compatible with BFD? =

    Is it also possible for CC-CV-RDI = and existing BFD to be compatible today given only the proper = configuration?

    Best = regards,

    Nurit

     

    ------_=_NextPart_001_01CBF8D6.A2451E31-- From Alexander.Vainshtein@ecitele.com Tue Apr 12 00:25:17 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CDDADE0782 for ; Tue, 12 Apr 2011 00:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1OVy6GisDI9 for ; Tue, 12 Apr 2011 00:25:15 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id A6C49E077E for ; Tue, 12 Apr 2011 00:25:14 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-a8-4da3fdf49641 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id FA.1D.02691.4FDF3AD4; Tue, 12 Apr 2011 10:23:32 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 12 Apr 2011 10:25:12 +0300 From: Alexander Vainshtein To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Date: Tue, 12 Apr 2011 10:25:11 +0300 Thread-Topic: MPLS-TP CC-CV-RDI Thread-Index: Acv4aK/DoQcq08XcSPCl0V4Wl5d+egAAN4XAABrksAAAAsNWSg== Message-ID: References: <077E41CFFD002C4CAB7DFA4386A5326403A62507@DEMUEXC014.nsn-intra.net> <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se>, <077E41CFFD002C4CAB7DFA4386A5326403A62593@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326403A62593@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_A3C5DF08D38B6049839A6F553B331C76D722D0E7C5ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUy+dWnL7pf/i72Nfg9w9zi4fntzBZH/3aw WCy695fRYs5dZ4tbS1eyWjT0trNZ3L6/nd2B3ePX16tsHkuW/GTyuN50ld3j5/qr7AEsUVw2 Kak5mWWpRfp2CVwZK95uZCloLqs42TmXrYHxT0oXIweHhICJxKSdtl2MnECmmMSFe+vZuhi5 OIQEdjNKrLs4hRnCmcYocf7oDSaQKjYBW4lNq++ygdgiAm4SFxYcBytiFljNJLFy4UewIhYB VYlny66zgtjCAnISc0/eZYVokJc4s34RI4TtJPF28zwwm1fAX2J69w52iG0PGSX+LHwONohT IEDi1rZWsG2MQPd9P7UGLM4sIC5x68l8Joi7BSSW7DnPDGGLSrx8/I8Vol5U4k77ekaI+nyJ 2aceQy0TlDg58wkLRL2kxMEVN1gmMIrNQjJ2FpKWWUhaIOJ6EjemTmGDsLUlli18zQxh60rM +HeIBVl8ASP7KkbRzJyCkqTcdAMjvdTkzJLUnFS95PzcTYyQeH6xg/H2Gc1DjNIcLErivCuO TvEVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwGh9YY7ulnviCbsK2a9duVqeLbvssmGVoJzE 1Euaat4erRmT3Zg7Jp22qOaepMmmesDz7OH1B2S3e1pzVJfuVfXtirieb/nuws+lGluNpq0o fSrNP7Vt9dtLnaoesdaf70/6dufDtOWO9bIRXeu+Pvw/60lbmcq+4M9e19fuL5mgsyHDdeGD gwZKLMUZiYZazEXFiQAIDxnvtQIAAA== Cc: "mpls@ietf.org" , David Ward , "Schink, Helmut \(NSN - DE/Munich\)" Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 07:25:18 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7C5ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nurit and all, A couple of additional points. 1. Dropping the Poll/Final scheme has been shown to be highly problematic= both per se (e.g. due to potential false LOC detection immediately after t= he end points have been configured, especially if the detection interval is= very short) and when it comes to interoperability with the existing implem= entations (e.g., if they use the BFD slow start as defined in RFC 5880 in o= rder to program HW accelerators that would take care of BFD at the desired = high rate). This has been discussed during the Prague meeting (both at the = mike and in private talks with Dave), and still has to be resolved. 2. IMHO the user that is only interested in proactive and fast CC/RDI (bu= t not in proactive CV) could safely run BFD over GAL/G-ACh using the code p= oint and procedures defined in RFC 5885 (which in its turn assumes the proc= edures defined in 5880) "as is". In order to provide a backward compatible = solution, this option should be explicitly specified in the draft, preferab= ly as MUST to implement. 3. Proactive CV as defined in the draft definitely needs a new code point= because it relies on a Source MEP ID TLV as the G-ACh TLV, and these TLVs = are or are not expected by the receiver based on the G-ACh type. So it will= not be backward compatible with the existing implementations, and this fac= t MUST be explicitly spelled out in the draft. My 2c, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Sprecher, = Nurit (NSN - IL/Hod HaSharon) [nurit.sprecher@nsn.com] Sent: Tuesday, April 12, 2011 8:58 AM To: ext David Allan I; David Ward; John E Drake; Nitin Bahadur Cc: mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) Subject: Re: [mpls] MPLS-TP CC-CV-RDI Hi David, Thanks for your response. In the IETF we define protocols, so I believe it would be correct to say th= at the extension to the BFD protocol is fully compatible with BFD. Best regards, Nurit From: ext David Allan I [mailto:david.i.allan@ericsson.com] Sent: Tuesday, April 12, 2011 1:08 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; Niti= n Bahadur Cc: mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) Subject: RE: MPLS-TP CC-CV-RDI Hi Nurit It is backwards compatible in the sense that the new code points allow the = additional behaviors specified for MPLS TP to be disambiguated from existi= ng RFC 5884/5 behaviors - this is the addition of the GAL, the source MEP TLV, interleaving of = CC and CV PDUs, and accepting the TP-FAULT inputs as valid state machine in= puts. It is not perfectly backwards compatible in that the addition of the GAL an= d new code points means deployed implementations will not support the new e= ncap and TLV without an upgrade .... RFC 5885 is close but not an exact mat= ch due to the addition of the Source MEP ID TLV. Some implementation tweaks= are required. hope this helps Dave ________________________________ From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Monday, April 11, 2011 9:51 AM To: David Ward; David Allan I; John E Drake; Nitin Bahadur Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, Helmut = (NSN - DE/Munich) Subject: MPLS-TP CC-CV-RDI Dear authors, Slide 14 of the attached, says that "This document an enhancement to RFC 58= 84/5885....But it still requires two new code points as it will not be perf= ectly backwards compatible...." http://tools.ietf.org/agenda/80/slides/mpls-9.pdf It is my understanding that the extension done to BFD is completely compati= ble with BFD. Can you please clarify this point? Is the solution being defined in draft c= c-cv-rdi is compatible with BFD? Is it also possible for CC-CV-RDI and existing BFD to be compatible today g= iven only the proper configuration? Best regards, Nurit --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7C5ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Nurit and all,
     
    A couple of additional points.
     
    1. Dropping the Poll/Final scheme has been = shown to be highly problematic both per se (e.g. due to potential false LOC detection immediately afte= r the end points have been configured, especially if the detection interval= is very short) and when it comes to interoperability with the existing imp= lementations (e.g., if they use the BFD slow start as defined in RFC 5880 in order to program HW accelerat= ors that would take care of BFD at the desired high rate). This has been di= scussed during the Prague meeting (both at the mike and in private talks wi= th Dave), and still has to be resolved.
    2. IMHO the user that is only i= nterested in proactive and fast CC/RDI (but not in proactive CV) could safe= ly run BFD over GAL/G-ACh using the code point and procedures=  defined in RFC 5885 (which in its turn assumes the procedures defined in 5880) "as is". In order to= provide a backward compatible solution, this option should be explicitly s= pecified in the draft, preferably as MUST to implement.
    3. Proactive CV as defined in the draf= t definitely needs a new code point because it relies on a Source MEP = ID TLV as the G-ACh TLV, and these TLVs are or are not expect= ed by the receiver based on the G-ACh type. So it will not be backward compatible with the existing implementati= ons, and this fact MUST be explicitly spelled out in the draft.
      4. =

    My 2c,

         Sasha

    From: mpl= s-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Sprec= her, Nurit (NSN - IL/Hod HaS= haron) [nurit.sprecher@nsn.com]
    Sent: Tuesday, April 12, 2011 8:58 AM
    To: ext David Allan I; David Ward; John E Drake; Nitin Bahadur
    Cc: mpls@ietf.org; Schink, Helmut (NSN -= DE/Munich)
    Subject: Re: [mpls] MPLS-TP CC-CV-RDI

    Hi David,

    Thanks for your respo= nse.

    In the IETF we define= protocols, so I believe it would be correct to say that the extension to t= he BFD protocol is fully compatible with BFD.

    Best regards,<= /p>

    Nurit

     

    From: ext David Allan I [mailto:david.i.allan@ericss= on.com]
    Sent: Tuesday, April 12, 2011 1:08 AM
    To: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; Nitin<= a> Bahadur
    Cc: mpls@ietf.org; Schink, Helmut (NSN -= DE/Munich)
    Subject: RE: MPLS-TP CC-CV-RDI

     

    Hi Nurit

     

    It is backwards compatible in the sense that th= e new code points allow the additional  behaviors specified for MPLS T= P to be disambiguated from existing RFC 5884/5 behaviors

        - this is the addition of the GAL, the source MEP TLV, interlea= ving of CC and CV PDUs, and accepting the TP-FAULT inputs as valid state ma= chine inputs.

     

    It is not perfectly backwards compatible in tha= t the addition of the GAL and new code points means deployed implement= ations will not support the new encap and TLV without an upgrade .... RFC 5885 is close but not an exact ma= tch due to the addition of the Source MEP ID TLV. Some implementation = tweaks are required.

     

    hope this helps

    Dave

     

    From: Sprecher, N= urit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com]
    Sent: Monday, April 11, 2011 9:51 AM
    To: David Ward; David Allan I; John E Drake; Nitin Bahadur
    Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, Helmut (NSN - DE/Munich)
    Subject: MPLS-TP CC-CV-RDI

    Dear authors,

    Slide 14 of the attached, says that "This do= cument an enhancement to RFC 5884/5885....But it still requires two new cod= e points as it will not be perfectly backwards compatible...."

    http://tools.ietf.org/agenda/80/slides/mpls-= 9.pdf

    It is my understanding that the extension done to BF= D is completely compatible with BFD.

    Can you please clarify this point? Is the solution b= eing defined in draft cc-cv-rdi is compatible w= ith BFD?

    Is it also possible for CC-CV-RDI and existing BFD t= o be compatible today given only the proper configuration?

    Best regards,

    Nurit

     

    --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7C5ILPTMAIL02eci_-- From eric.gray@ericsson.com Tue Apr 12 03:31:43 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E27CBE0750 for ; Tue, 12 Apr 2011 03:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfKPcxEONmBF for ; Tue, 12 Apr 2011 03:31:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 379FEE06B6 for ; Tue, 12 Apr 2011 03:31:41 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3CAVexu029772 for ; Tue, 12 Apr 2011 05:31:41 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 12 Apr 2011 06:31:33 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 12 Apr 2011 06:31:32 -0400 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- Thread-Index: Acvvcq9LO5722CTzTLK5LX79v4QIfgA5oc7wAijcrYA= Message-ID: 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 Subject: [mpls] FW: Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 10:31:44 -0000 Resending this message in plain text (too big)... ________________________________ From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Friday, April 01, 2011 6:41 AM To: Greg Mirsky; Alexander Vainshtein Cc: hideki.endo.es@hitachi.com; mpls@ietf.org; Manuel.Paul@telekom.de; Rolf= .Winter@neclab.eu Subject: RE: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand= -cv- Out of curiosity, where would you expand it (i.e. - where would you suggest= we say this)? ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Thursday, March 31, 2011 3:10 AM To: Alexander Vainshtein Cc: hideki.endo.es@hitachi.com; Eric Gray; mpls@ietf.org; Manuel.Paul@telek= om.de; Rolf.Winter@neclab.eu Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand= -cv- Dear Sasha and All, considering that LSP ping can specify the return path for the LSP Echo Repl= y, I'd expand capability to LSP ping MEP-to-MIP to all MPLS-TP constructs, = bi-directional as well as unidirectional. The return path might be directed= over an LSP which is in reverse direction that is not necessarily is assoc= iated with LSP that been tested by LSP Echo Request. Regards, Greg On Wed, Mar 30, 2011 at 11:43 PM, Alexander Vainshtein wrote: Hideki, Eric, and all, I believe that ability to do ping MEP-to-MIP should not be preclude= d (at least for co-routed bidirectional LSPs). Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf Of > hideki.endo.es@hitachi.com > Sent: Thursday, March 31, 2011 8:24 AM > To: mpls@ietf.org; eric.gray@ericsson.com; aldrin.ietf@gmail.com > Cc: Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu > Subject: Re: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on- > demand-cv- > > Hi Eric and Sam, > > I'm sorry for my incorrect understanding on DSMAP TLV. > According to Sam, We can use DSMAP in both of ping and trace rout= e. > > However, I have a concern. > Eric, you said; > > Ping mode would be strictly MEP-to-MEP. At least, that > >is the way it is intended to work in our draft. > > On the other hand, RFC5860, MPLS-TP OAM reqs, says; > 2.2.3. Connectivity Verifications > > This function SHOULD be performed on-demand between End Points= and > Intermediate Points of PWs and LSPs, and between End Points of= PWs, > LSPs, and Sections. > > and; > > 2.2.4. Route Tracing > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between End Points and > Intermediate > Points of PWs and LSPs, and between End Points of PWs, LSPs, a= nd > Sections. > > Why do you restrict ping mode to only for between MEPs? > Do you mean that On-demand CV doesn't satisfy all of OAM reqs? > > BR, > Hideki > > >Hideki, > > > > Ping mode would be strictly MEP-to-MEP. At least, that > >is the way it is intended to work in our draft. > > > > Why would you need per-interface MIP information in this > >case? > > > > If someone wanted to do LSP-Ping to a specific interface= , > >I am uncertain why it would be incorrect to use the DSMAP TLV. > > > >-- > >Eric > > > >-----Original Message----- > >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.= com] > >Sent: Wednesday, March 30, 2011 5:43 PM > >To: Eric Gray; mpls@ietf.org > >Cc: Rolf.Winter@neclab.eu; Manuel.Paul@telekom.de > >Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf= -mpls- > tp-on-demand-cv-03 > >Importance: High > > > >Eric, > > > >In my understanding, DSMAP TLV is only for trace route, isn't it= ? > >We need specific interface information for ping mode of on-deman= d CV. > > > >BR, > >Hideki > > > >>Hideki, > >> > >> If you want to include specific interface information, > >>you can include a DSMAP (or DDMAP) TLV as defined by RFC > >>4379, and extended by this draft (in combination with the > >>draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). > >> > >> Would this not do what you're looking for? > >> > >>-- > >>Eric > >> > >>-----Original Message----- > >>From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi= .com] > >>Sent: Wednesday, March 30, 2011 11:33 AM > >>To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; > Manuel.Paul@telekom.de > >>Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls= -tp- > on-demand-cv-03 > >>Importance: High > >> > >>Hi, > >> > >>I have one comment on IDs in draft-on-demand-cv. > >>The interface-D is missing in the current draft, there is only = Node- > ID. > >>You need at least the interface ID to support per-interface MIP= . > >> > >>BR, > >>Hideki > >> > >>> > >>>Dear All, > >>> > >>>I really appreciate the consideration on the per-interface MIP > support and the discussion moving forward. > >>> > >>> > >>>From an operator's perspective, it is very important that the > support for per-interface MIPs is covered by the definitions. > >>> > >>>Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-ma= p, > there was already a solution proposal, using the TTL. Enhanced > solutions have been thorougly discussed during this IETF meeting.= It it > to be expected that there will be ways to solve both the fast pat= h and > fate-sharing requirement. > >>> > >>> > >>>I second the proposal initially made by Rolf, to include addit= ional > text to document the per-interface MIP addressing for the on-dema= nd-cv > and for other OAM tools. > >>> > >>> > >>>Best regards, > >>>Manuel > >>> > >>> > >>>Deutsche Telekom AG > >>>Group Technology > >>>Manuel Paul > >>>SA3-11 > >>>Goslarer Ufer 35-37, 10589 Berlin > >>>+49 30 3497 - 4394 (Tel.) > >>>+49 30 3497 - 4956 (Fax) > >>>+49 171 8634032 (Mobil) > >>>E-Mail: mailto:manuel.paul@telekom.de > >>>http://www.telekom.com > >>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] O= n > Behalf Of > >>>> Rolf Winter > >>>> Sent: Monday, March 28, 2011 3:03 PM > >>>> To: Eric Gray; hideki.endo.es@hitachi.com > >>>> Cc: mpls@ietf.org > >>>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls= -tp- > on-demand- > >>>> cv-03 > >>>> > >>>> Eric, > >>>> > >>>> I generally agree but I think there is one case actually whi= ch > needs a > >>>> closer look in this regard (which I hinted at earlier), whic= h are > the per- > >>>> interface MIPs. Your TTL expires (the actual addressing bit = here), > the > >>>> identifier tells you it is not intended for the ingress MIP,= so it > needs > >>>> to be forwarded to the egress MIP through the forwarding eng= ine. > Now if > >>>> you pull the packet out of the fast path and inject it back = in, is > the OAM > >>>> packet still fate sharing? If you can do this in HW on the l= ine > card, then > >>>> it will and it will just be forwarded as normal. I know this= is a > >>>> different draft, but this will be in particular important fo= r > performance > >>>> monitoring. > >>>> > >>>> Best, > >>>> > >>>> Rolf > >>>> > >>>> > >>>> > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victori= a > Road, London > >>>> W3 6BL | Registered in England 2832014 > >>>> > >>>> > >>>> > -----Original Message----- > >>>> > From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> > Sent: Montag, 28. M=E4rz 2011 14:45 > >>>> > To: hideki.endo.es@hitachi.com; Rolf Winter > >>>> > Cc: mpls@ietf.org > >>>> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-= ietf- > mpls-tp- > >>>> > on-demand-cv-03 > >>>> > > >>>> > Hideki, > >>>> > > >>>> > What you're saying is true, but not relevant in this > >>>> > case. The "addresses" in this discussion are not used to > >>>> > determine how to forward OAM packets. They are used only > >>>> > by the recipient MIP/MEP to verify that the OAM packet was > >>>> > properly delivered. > >>>> > > >>>> > By the way, this discussion is an indication of the > >>>> > confusing injected by calling these things addresses. My > >>>> > mistake and I bring it up now to help to stem the tide of > >>>> > further comments resulting from that confusion. > >>>> > > >>>> > In the version we post after last call is complete, > >>>> > we will be changing the source and destination "address" > >>>> > TLVs to source and destination "identifier" TLVs. > >>>> > > >>>> > We will also be correcting the reference to DSMAP, > >>>> > and DDMAP, address TLVs (which is incorrect, because the > >>>> > format for DSMAP/DDMAP doesn't include a "length" field). > >>>> > > >>>> > The format of the Downstream Mapping (DSMAP) TLV is > >>>> > defined in RFC 4379, and we are not changing the format > >>>> > of that TLV. > >>>> > > >>>> > These changes are driven by last call comments we > >>>> > have already received (see Joel Halpern's comments on the > >>>> > mailing list) and are - in part - to correct accidental > >>>> > use of the word "address" for source and destination > >>>> > identifier TLVs (which is what we had discussed before > >>>> > I generated the -03 version among the authors of several > >>>> > of the current set of MPLS-TP drafts). > >>>> > > >>>> > In the case of source and destination identifiers, > >>>> > these will be used exclusively to verify that an OAM PDU > >>>> > has been correctly received by its intended recipient. > >>>> > Because this is an on-demand connectivity verification > >>>> > protocol, that is expected to be used only on those > >>>> > occasions when there is a network problem that needs to > >>>> > be diagnosed, and the information is not seen (and not > >>>> > visible - without layer violations), optimizing these > >>>> > objects for software makes sense. > >>>> > > >>>> > In addition, since either may be included (which > >>>> > includes the possibility of including both), it is the > >>>> > case already that we would then need to decide which is > >>>> > to go first - assuming we wanted to do this (which we > >>>> > do not). > >>>> > > >>>> > -- > >>>> > Eric > >>>> > > >>>> > -----Original Message----- > >>>> > From: hideki.endo.es@hitachi.com > [mailto:hideki.endo.es@hitachi.com] > >>>> > Sent: Monday, March 28, 2011 8:11 AM > >>>> > To: Eric Gray; Rolf.Winter@neclab.eu > >>>> > Cc: mpls@ietf.org > >>>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf= -mpls- > tp-on- > >>>> > demand-cv-03 > >>>> > Importance: High > >>>> > > >>>> > Hi Eric and Rolf, > >>>> > > >>>> > I'm sorry for interrupting. > >>>> > > >>>> > I agree with Rolf regarding the per-interface MIP discussi= on. > >>>> > We have to consider the HW implementation aspect, > >>>> > because trapping of an OAM packet is HW rule/functionality= even > in > >>>> > routers. > >>>> > > >>>> > If every OAM packet is trapped to CPU > >>>> > and the OAM packets which should NOT be processed in the > Interface > >>>> > are returned to Data-plane, > >>>> > it is different forwarding path from user packets, > >>>> > which is NOT the Connectivity Verification of the user pat= h. > >>>> > > >>>> > Therefore, we should take the HW aspect and flexibilty int= o > account > >>>> > concurrently. > >>>> > If an address TLV MUST be the first in TLVs, > >>>> > it is enough to make HW implementation easy. > >>>> > > >>>> > BR, > >>>> > Hideki > >>>> > > >>>> > > >>>> > > >>>> > >Rolf, > >>>> > > > >>>> > > The words you propose are okay with me. > >>>> > > > >>>> > > I thought the MIP/interface and address location issues > >>>> > >were separate. > >>>> > > > >>>> > > I've personally had problems with protocol specificatio= ns > >>>> > >that require ordering of TLVs. In particular, this is no= t very > >>>> > >robust in terms of "future-proofing." What happens if ne= w TLVs > >>>> > >are added later on; for instance, suppose at some point w= e have > >>>> > >multiple "address" TLVs? > >>>> > > > >>>> > > Also, the fact that implementations are allowed to atta= ch > >>>> > >TLVs in any arbitrary order allows considerable flexibilt= y in > >>>> > >implementation. Messages can be built in arbitrarily man= y > ways. > >>>> > >This too can be a future-proofing issue. > >>>> > > > >>>> > > I would prefer not to start down the road of requiring = a > >>>> > >subset of TLVs to appear in a certain order, and saying w= e have > >>>> > >one TLV that needs to be first is doing just that. > >>>> > > > >>>> > >-- > >>>> > >Eric > >>>> > > > >>>> > >-----Original Message----- > >>>> > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >>>> > >Sent: Monday, March 28, 2011 6:19 AM > >>>> > >To: Eric Gray > >>>> > >Cc: mpls@ietf.org > >>>> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-= mpls- > tp-on- > >>>> > demand-cv-03 > >>>> > >Importance: High > >>>> > > > >>>> > >Hi, > >>>> > > > >>>> > >I still think there is a logical error. Let me explain. I= n case > there > >>>> > is no IP you simply cannot use it. You say you could enabl= e IP > but then > >>>> > that is not a case where there is no IP. In order to be > constructive > >>>> > here is a text change suggestion: > >>>> > > > >>>> > >"In certain MPLS-TP deployment scenarios IP addressing mi= ght > not be > >>>> > available. In those cases On-demand CV and/or route tracin= g MUST > be run > >>>> > without IP addressing, using the ACH channel type specifie= d in > Section > >>>> > 3. In other cases it might be available, however, it may b= e > preferred > >>>> > to use some form of non-IP encapsulation. In those cases, = the > >>>> > procedures as outlined in section 3 SHOULD also be used." > >>>> > > > >>>> > >Regarding the per-interface MIP discussion. The HW aspect= also > popped > >>>> > up in the PWE3 session and I think this is an important > consideration, > >>>> > in particular for OAM. Even if we talk about TLVs, we coul= d make > it a > >>>> > MUST that an Address TLV is always the first one to appear= . If > you can > >>>> > facilitate an easy implementation in hardware, I see no re= ason > to > >>>> > deliberately not do it. > >>>> > > > >>>> > >Best, > >>>> > > > >>>> > >Rolf > >>>> > > > >>>> > > > >>>> > >NEC Europe Limited | Registered Office: NEC House, 1 Vict= oria > Road, > >>>> > London W3 6BL | Registered in England 2832014 > >>>> > > > >>>> > > > >>>> > >> -----Original Message----- > >>>> > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> > >> Sent: Montag, 28. M=E4rz 2011 11:43 > >>>> > >> To: Rolf Winter > >>>> > >> Cc: loa@pi.nu; mpls@ietf.org > >>>> > >> Subject: RE: [mpls] Working Group Las Call on draft-iet= f- > mpls-tp-on- > >>>> > >> demand-cv-03 > >>>> > >> > >>>> > >> Rolf, > >>>> > >> > >>>> > >> With regard to the use of SHOULD (verses MUST) = - the > intent > >>>> > >> (according to RFC 2119 - see the quote below) is consis= tent > with > >>>> > >> this case. If - for some reason - one had a really goo= d > reason to > >>>> > >> use IP addressing in some specific case, one could take= steps > to > >>>> > >> make IP addressing available. > >>>> > >> > >>>> > >> This could be said to introduce a logical disco= nnect, > but we > >>>> > >> are saved from going down that path by the fact that th= e > statement > >>>> > >> also includes the case where (for some reason) there is= a > case in > >>>> > >> which some other addressing scheme might be preferred. = In > many of > >>>> > >> the cases where another addressing scheme may be prefer= red, > it is > >>>> > >> still possible (in fact likely) that IP addressing is > available. > >>>> > >> > >>>> > >> Otherwise, it would not have been necessary to > distinguish > >>>> > >> this case from the one in which IP addressing is not > available. > >>>> > >> > >>>> > >> For the case where IP addressing is not the pre= ferred > mode, > >>>> > >> we are recommending a mode in which it is not necessary= . > >>>> > >> > >>>> > >> With regard to having addresses located in the = same > place, > >>>> > >> this protocol is meant for connectivity testing on an o= n- > demand > >>>> > >> basis and is therefore not optimized for processing in > hardware. > >>>> > >> > >>>> > >> Whether addresses or identifiers, if we are tal= king > about > >>>> > >> TLV contents, there are issues with trying to guarantee > location > >>>> > >> of specific content, because of the fact that the TLV i= n > question > >>>> > >> will probably follow other TLVs - thus making locations > difficult > >>>> > >> to predict in any case. > >>>> > >> > >>>> > >> With regard to needing more text on per-interfa= ce > MIPs, do > >>>> > >> you have specific suggestions as to what text we might = add? > >>>> > >> > >>>> > >> I understand (from discussion with WG chairs) t= hat we > are > >>>> > >> not allowed to explicitly address last call comments du= ring > the > >>>> > >> IETF meeting in Prague, because the last call is still > ongoing > >>>> > >> at that time. > >>>> > >> > >>>> > >> -- > >>>> > >> Eric > >>>> > >> > >>>> > >> PS - > >>>> > >> From RFC 2119 - > >>>> > >> 'SHOULD This word, or the adjective "RECOMMENDED", me= an > that there > >>>> > >> may exist valid reasons in particular circums= tances > to > >>>> > >> ignore a particular item, but the full implic= ations > must > >>>> > >> be understood and carefully weighed before ch= oosing > a > >>>> > >> different course.' > >>>> > >> > >>>> > >> -----Original Message----- > >>>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.o= rg] On > Behalf > >>>> > Of > >>>> > >> Rolf Winter > >>>> > >> Sent: Tuesday, March 22, 2011 4:57 AM > >>>> > >> To: loa@pi.nu; mpls@ietf.org > >>>> > >> Subject: Re: [mpls] Working Group Las Call on draft-iet= f- > mpls-tp-on- > >>>> > >> demand-cv-03 > >>>> > >> > >>>> > >> Hi, > >>>> > >> > >>>> > >> some comments below: > >>>> > >> > >>>> > >> Section 1.3 says: " In certain MPLS-TP deployment scena= rios > IP > >>>> > >> addressing might not be > >>>> > >> available or it may be preferred to use some form of= non- > IP > >>>> > >> encapsulation for On-demand CV, route tracing and BF= D > packets. > >>>> > In > >>>> > >> such scenarios, On-demand CV and/or route tracing SH= OULD > be run > >>>> > >> without IP addressing..." > >>>> > >> > >>>> > >> I am not sure the "SHOULD" is right here. If no IP addr= essing > is > >>>> > >> available, this thing MUST be run without IP addressing= , > mustn't it? > >>>> > >> > >>>> > >> I think some additional text regarding per-interface MI= P > addressing > >>>> > >> would be nice. As far as I understand the document, all= TLVs > will be > >>>> > >> inside the LSP ping packet (rather than as ACH TLVs). > >>>> > >> > >>>> > >> Some people had concerns earlier, that addressing infor= mation > should > >>>> > be > >>>> > >> in a fixed location for easier processing. Is this the = case > here I > >>>> > >> wonder? > >>>> > >> > >>>> > >> It would be nice if you could address this in your > presentation in > >>>> > >> Prague. > >>>> > >> > >>>> > >> Thanks, > >>>> > >> > >>>> > >> Rolf > >>>> > >> > >>>> > >> > >>>> > >> NEC Europe Limited | Registered Office: NEC House, 1 Vi= ctoria > Road, > >>>> > >> London W3 6BL | Registered in England 2832014 > >>>> > >> > >>>> > >> > >>>> > >> > -----Original Message----- > >>>> > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf= .org] > On > >>>> > Behalf > >>>> > >> Of > >>>> > >> > loa@pi.nu > >>>> > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > >>>> > >> > To: mpls@ietf.org > >>>> > >> > Cc: MPLS-TP ad hoc team > >>>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-= mpls- > tp-on- > >>>> > >> demand- > >>>> > >> > cv-03 > >>>> > >> > > >>>> > >> > Working Group, > >>>> > >> > > >>>> > >> > this is to start a 3 week working group last call on > >>>> > >> > > >>>> > >> > draft-ietf-mpls-tp-on-demand-cv-03 > >>>> > >> > > >>>> > >> > Please send comments to the working group mailing lis= t > >>>> > >> > mpls@ietf.org > >>>> > >> > > >>>> > >> > The working group last call ends on April 8, 2011. > >>>> > >> > > >>>> > >> > /Loa > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > _______________________________________________ > >>>> > >> > 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 From eric.gray@ericsson.com Tue Apr 12 03:33:20 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D061E0709 for ; Tue, 12 Apr 2011 03:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1CjdVXzvGQP for ; Tue, 12 Apr 2011 03:33:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id E7207E06F5 for ; Tue, 12 Apr 2011 03:33:17 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3CAXHlq001386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Apr 2011 05:33:17 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 12 Apr 2011 06:33:16 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 12 Apr 2011 06:33:13 -0400 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- Thread-Index: AcvvcrZX3jWOPDV/TuajgvUbcmgzoQJijoKA Message-ID: 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 Subject: [mpls] FW: Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 10:33:20 -0000 Resending this message in plain text (too big) ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Thursday, March 31, 2011 3:10 AM To: Alexander Vainshtein Cc: hideki.endo.es@hitachi.com; Eric Gray; mpls@ietf.org; Manuel.Paul@telek= om.de; Rolf.Winter@neclab.eu Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand= -cv- Dear Sasha and All, considering that LSP ping can specify the return path for the LSP Echo Repl= y, I'd expand capability to LSP ping MEP-to-MIP to all MPLS-TP constructs, = bi-directional as well as unidirectional. The return path might be directed= over an LSP which is in reverse direction that is not necessarily is assoc= iated with LSP that been tested by LSP Echo Request. Regards, Greg On Wed, Mar 30, 2011 at 11:43 PM, Alexander Vainshtein wrote: Hideki, Eric, and all, I believe that ability to do ping MEP-to-MIP should not be preclude= d (at least for co-routed bidirectional LSPs). Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf Of > hideki.endo.es@hitachi.com > Sent: Thursday, March 31, 2011 8:24 AM > To: mpls@ietf.org; eric.gray@ericsson.com; aldrin.ietf@gmail.com > Cc: Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu > Subject: Re: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on- > demand-cv- > > Hi Eric and Sam, > > I'm sorry for my incorrect understanding on DSMAP TLV. > According to Sam, We can use DSMAP in both of ping and trace rout= e. > > However, I have a concern. > Eric, you said; > > Ping mode would be strictly MEP-to-MEP. At least, that > >is the way it is intended to work in our draft. > > On the other hand, RFC5860, MPLS-TP OAM reqs, says; > 2.2.3. Connectivity Verifications > > This function SHOULD be performed on-demand between End Points= and > Intermediate Points of PWs and LSPs, and between End Points of= PWs, > LSPs, and Sections. > > and; > > 2.2.4. Route Tracing > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between End Points and > Intermediate > Points of PWs and LSPs, and between End Points of PWs, LSPs, a= nd > Sections. > > Why do you restrict ping mode to only for between MEPs? > Do you mean that On-demand CV doesn't satisfy all of OAM reqs? > > BR, > Hideki > > >Hideki, > > > > Ping mode would be strictly MEP-to-MEP. At least, that > >is the way it is intended to work in our draft. > > > > Why would you need per-interface MIP information in this > >case? > > > > If someone wanted to do LSP-Ping to a specific interface= , > >I am uncertain why it would be incorrect to use the DSMAP TLV. > > > >-- > >Eric > > > >-----Original Message----- > >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.= com] > >Sent: Wednesday, March 30, 2011 5:43 PM > >To: Eric Gray; mpls@ietf.org > >Cc: Rolf.Winter@neclab.eu; Manuel.Paul@telekom.de > >Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf= -mpls- > tp-on-demand-cv-03 > >Importance: High > > > >Eric, > > > >In my understanding, DSMAP TLV is only for trace route, isn't it= ? > >We need specific interface information for ping mode of on-deman= d CV. > > > >BR, > >Hideki > > > >>Hideki, > >> > >> If you want to include specific interface information, > >>you can include a DSMAP (or DDMAP) TLV as defined by RFC > >>4379, and extended by this draft (in combination with the > >>draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). > >> > >> Would this not do what you're looking for? > >> > >>-- > >>Eric > >> > >>-----Original Message----- > >>From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi= .com] > >>Sent: Wednesday, March 30, 2011 11:33 AM > >>To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; > Manuel.Paul@telekom.de > >>Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls= -tp- > on-demand-cv-03 > >>Importance: High > >> > >>Hi, > >> > >>I have one comment on IDs in draft-on-demand-cv. > >>The interface-D is missing in the current draft, there is only = Node- > ID. > >>You need at least the interface ID to support per-interface MIP= . > >> > >>BR, > >>Hideki > >> > >>> > >>>Dear All, > >>> > >>>I really appreciate the consideration on the per-interface MIP > support and the discussion moving forward. > >>> > >>> > >>>From an operator's perspective, it is very important that the > support for per-interface MIPs is covered by the definitions. > >>> > >>>Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-ma= p, > there was already a solution proposal, using the TTL. Enhanced > solutions have been thorougly discussed during this IETF meeting.= It it > to be expected that there will be ways to solve both the fast pat= h and > fate-sharing requirement. > >>> > >>> > >>>I second the proposal initially made by Rolf, to include addit= ional > text to document the per-interface MIP addressing for the on-dema= nd-cv > and for other OAM tools. > >>> > >>> > >>>Best regards, > >>>Manuel > >>> > >>> > >>>Deutsche Telekom AG > >>>Group Technology > >>>Manuel Paul > >>>SA3-11 > >>>Goslarer Ufer 35-37, 10589 Berlin > >>>+49 30 3497 - 4394 (Tel.) > >>>+49 30 3497 - 4956 (Fax) > >>>+49 171 8634032 (Mobil) > >>>E-Mail: mailto:manuel.paul@telekom.de > >>>http://www.telekom.com > >>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] O= n > Behalf Of > >>>> Rolf Winter > >>>> Sent: Monday, March 28, 2011 3:03 PM > >>>> To: Eric Gray; hideki.endo.es@hitachi.com > >>>> Cc: mpls@ietf.org > >>>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls= -tp- > on-demand- > >>>> cv-03 > >>>> > >>>> Eric, > >>>> > >>>> I generally agree but I think there is one case actually whi= ch > needs a > >>>> closer look in this regard (which I hinted at earlier), whic= h are > the per- > >>>> interface MIPs. Your TTL expires (the actual addressing bit = here), > the > >>>> identifier tells you it is not intended for the ingress MIP,= so it > needs > >>>> to be forwarded to the egress MIP through the forwarding eng= ine. > Now if > >>>> you pull the packet out of the fast path and inject it back = in, is > the OAM > >>>> packet still fate sharing? If you can do this in HW on the l= ine > card, then > >>>> it will and it will just be forwarded as normal. I know this= is a > >>>> different draft, but this will be in particular important fo= r > performance > >>>> monitoring. > >>>> > >>>> Best, > >>>> > >>>> Rolf > >>>> > >>>> > >>>> > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victori= a > Road, London > >>>> W3 6BL | Registered in England 2832014 > >>>> > >>>> > >>>> > -----Original Message----- > >>>> > From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> > Sent: Montag, 28. M=E4rz 2011 14:45 > >>>> > To: hideki.endo.es@hitachi.com; Rolf Winter > >>>> > Cc: mpls@ietf.org > >>>> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-= ietf- > mpls-tp- > >>>> > on-demand-cv-03 > >>>> > > >>>> > Hideki, > >>>> > > >>>> > What you're saying is true, but not relevant in this > >>>> > case. The "addresses" in this discussion are not used to > >>>> > determine how to forward OAM packets. They are used only > >>>> > by the recipient MIP/MEP to verify that the OAM packet was > >>>> > properly delivered. > >>>> > > >>>> > By the way, this discussion is an indication of the > >>>> > confusing injected by calling these things addresses. My > >>>> > mistake and I bring it up now to help to stem the tide of > >>>> > further comments resulting from that confusion. > >>>> > > >>>> > In the version we post after last call is complete, > >>>> > we will be changing the source and destination "address" > >>>> > TLVs to source and destination "identifier" TLVs. > >>>> > > >>>> > We will also be correcting the reference to DSMAP, > >>>> > and DDMAP, address TLVs (which is incorrect, because the > >>>> > format for DSMAP/DDMAP doesn't include a "length" field). > >>>> > > >>>> > The format of the Downstream Mapping (DSMAP) TLV is > >>>> > defined in RFC 4379, and we are not changing the format > >>>> > of that TLV. > >>>> > > >>>> > These changes are driven by last call comments we > >>>> > have already received (see Joel Halpern's comments on the > >>>> > mailing list) and are - in part - to correct accidental > >>>> > use of the word "address" for source and destination > >>>> > identifier TLVs (which is what we had discussed before > >>>> > I generated the -03 version among the authors of several > >>>> > of the current set of MPLS-TP drafts). > >>>> > > >>>> > In the case of source and destination identifiers, > >>>> > these will be used exclusively to verify that an OAM PDU > >>>> > has been correctly received by its intended recipient. > >>>> > Because this is an on-demand connectivity verification > >>>> > protocol, that is expected to be used only on those > >>>> > occasions when there is a network problem that needs to > >>>> > be diagnosed, and the information is not seen (and not > >>>> > visible - without layer violations), optimizing these > >>>> > objects for software makes sense. > >>>> > > >>>> > In addition, since either may be included (which > >>>> > includes the possibility of including both), it is the > >>>> > case already that we would then need to decide which is > >>>> > to go first - assuming we wanted to do this (which we > >>>> > do not). > >>>> > > >>>> > -- > >>>> > Eric > >>>> > > >>>> > -----Original Message----- > >>>> > From: hideki.endo.es@hitachi.com > [mailto:hideki.endo.es@hitachi.com] > >>>> > Sent: Monday, March 28, 2011 8:11 AM > >>>> > To: Eric Gray; Rolf.Winter@neclab.eu > >>>> > Cc: mpls@ietf.org > >>>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf= -mpls- > tp-on- > >>>> > demand-cv-03 > >>>> > Importance: High > >>>> > > >>>> > Hi Eric and Rolf, > >>>> > > >>>> > I'm sorry for interrupting. > >>>> > > >>>> > I agree with Rolf regarding the per-interface MIP discussi= on. > >>>> > We have to consider the HW implementation aspect, > >>>> > because trapping of an OAM packet is HW rule/functionality= even > in > >>>> > routers. > >>>> > > >>>> > If every OAM packet is trapped to CPU > >>>> > and the OAM packets which should NOT be processed in the > Interface > >>>> > are returned to Data-plane, > >>>> > it is different forwarding path from user packets, > >>>> > which is NOT the Connectivity Verification of the user pat= h. > >>>> > > >>>> > Therefore, we should take the HW aspect and flexibilty int= o > account > >>>> > concurrently. > >>>> > If an address TLV MUST be the first in TLVs, > >>>> > it is enough to make HW implementation easy. > >>>> > > >>>> > BR, > >>>> > Hideki > >>>> > > >>>> > > >>>> > > >>>> > >Rolf, > >>>> > > > >>>> > > The words you propose are okay with me. > >>>> > > > >>>> > > I thought the MIP/interface and address location issues > >>>> > >were separate. > >>>> > > > >>>> > > I've personally had problems with protocol specificatio= ns > >>>> > >that require ordering of TLVs. In particular, this is no= t very > >>>> > >robust in terms of "future-proofing." What happens if ne= w TLVs > >>>> > >are added later on; for instance, suppose at some point w= e have > >>>> > >multiple "address" TLVs? > >>>> > > > >>>> > > Also, the fact that implementations are allowed to atta= ch > >>>> > >TLVs in any arbitrary order allows considerable flexibilt= y in > >>>> > >implementation. Messages can be built in arbitrarily man= y > ways. > >>>> > >This too can be a future-proofing issue. > >>>> > > > >>>> > > I would prefer not to start down the road of requiring = a > >>>> > >subset of TLVs to appear in a certain order, and saying w= e have > >>>> > >one TLV that needs to be first is doing just that. > >>>> > > > >>>> > >-- > >>>> > >Eric > >>>> > > > >>>> > >-----Original Message----- > >>>> > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >>>> > >Sent: Monday, March 28, 2011 6:19 AM > >>>> > >To: Eric Gray > >>>> > >Cc: mpls@ietf.org > >>>> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-= mpls- > tp-on- > >>>> > demand-cv-03 > >>>> > >Importance: High > >>>> > > > >>>> > >Hi, > >>>> > > > >>>> > >I still think there is a logical error. Let me explain. I= n case > there > >>>> > is no IP you simply cannot use it. You say you could enabl= e IP > but then > >>>> > that is not a case where there is no IP. In order to be > constructive > >>>> > here is a text change suggestion: > >>>> > > > >>>> > >"In certain MPLS-TP deployment scenarios IP addressing mi= ght > not be > >>>> > available. In those cases On-demand CV and/or route tracin= g MUST > be run > >>>> > without IP addressing, using the ACH channel type specifie= d in > Section > >>>> > 3. In other cases it might be available, however, it may b= e > preferred > >>>> > to use some form of non-IP encapsulation. In those cases, = the > >>>> > procedures as outlined in section 3 SHOULD also be used." > >>>> > > > >>>> > >Regarding the per-interface MIP discussion. The HW aspect= also > popped > >>>> > up in the PWE3 session and I think this is an important > consideration, > >>>> > in particular for OAM. Even if we talk about TLVs, we coul= d make > it a > >>>> > MUST that an Address TLV is always the first one to appear= . If > you can > >>>> > facilitate an easy implementation in hardware, I see no re= ason > to > >>>> > deliberately not do it. > >>>> > > > >>>> > >Best, > >>>> > > > >>>> > >Rolf > >>>> > > > >>>> > > > >>>> > >NEC Europe Limited | Registered Office: NEC House, 1 Vict= oria > Road, > >>>> > London W3 6BL | Registered in England 2832014 > >>>> > > > >>>> > > > >>>> > >> -----Original Message----- > >>>> > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> > >> Sent: Montag, 28. M=E4rz 2011 11:43 > >>>> > >> To: Rolf Winter > >>>> > >> Cc: loa@pi.nu; mpls@ietf.org > >>>> > >> Subject: RE: [mpls] Working Group Las Call on draft-iet= f- > mpls-tp-on- > >>>> > >> demand-cv-03 > >>>> > >> > >>>> > >> Rolf, > >>>> > >> > >>>> > >> With regard to the use of SHOULD (verses MUST) = - the > intent > >>>> > >> (according to RFC 2119 - see the quote below) is consis= tent > with > >>>> > >> this case. If - for some reason - one had a really goo= d > reason to > >>>> > >> use IP addressing in some specific case, one could take= steps > to > >>>> > >> make IP addressing available. > >>>> > >> > >>>> > >> This could be said to introduce a logical disco= nnect, > but we > >>>> > >> are saved from going down that path by the fact that th= e > statement > >>>> > >> also includes the case where (for some reason) there is= a > case in > >>>> > >> which some other addressing scheme might be preferred. = In > many of > >>>> > >> the cases where another addressing scheme may be prefer= red, > it is > >>>> > >> still possible (in fact likely) that IP addressing is > available. > >>>> > >> > >>>> > >> Otherwise, it would not have been necessary to > distinguish > >>>> > >> this case from the one in which IP addressing is not > available. > >>>> > >> > >>>> > >> For the case where IP addressing is not the pre= ferred > mode, > >>>> > >> we are recommending a mode in which it is not necessary= . > >>>> > >> > >>>> > >> With regard to having addresses located in the = same > place, > >>>> > >> this protocol is meant for connectivity testing on an o= n- > demand > >>>> > >> basis and is therefore not optimized for processing in > hardware. > >>>> > >> > >>>> > >> Whether addresses or identifiers, if we are tal= king > about > >>>> > >> TLV contents, there are issues with trying to guarantee > location > >>>> > >> of specific content, because of the fact that the TLV i= n > question > >>>> > >> will probably follow other TLVs - thus making locations > difficult > >>>> > >> to predict in any case. > >>>> > >> > >>>> > >> With regard to needing more text on per-interfa= ce > MIPs, do > >>>> > >> you have specific suggestions as to what text we might = add? > >>>> > >> > >>>> > >> I understand (from discussion with WG chairs) t= hat we > are > >>>> > >> not allowed to explicitly address last call comments du= ring > the > >>>> > >> IETF meeting in Prague, because the last call is still > ongoing > >>>> > >> at that time. > >>>> > >> > >>>> > >> -- > >>>> > >> Eric > >>>> > >> > >>>> > >> PS - > >>>> > >> From RFC 2119 - > >>>> > >> 'SHOULD This word, or the adjective "RECOMMENDED", me= an > that there > >>>> > >> may exist valid reasons in particular circums= tances > to > >>>> > >> ignore a particular item, but the full implic= ations > must > >>>> > >> be understood and carefully weighed before ch= oosing > a > >>>> > >> different course.' > >>>> > >> > >>>> > >> -----Original Message----- > >>>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.o= rg] On > Behalf > >>>> > Of > >>>> > >> Rolf Winter > >>>> > >> Sent: Tuesday, March 22, 2011 4:57 AM > >>>> > >> To: loa@pi.nu; mpls@ietf.org > >>>> > >> Subject: Re: [mpls] Working Group Las Call on draft-iet= f- > mpls-tp-on- > >>>> > >> demand-cv-03 > >>>> > >> > >>>> > >> Hi, > >>>> > >> > >>>> > >> some comments below: > >>>> > >> > >>>> > >> Section 1.3 says: " In certain MPLS-TP deployment scena= rios > IP > >>>> > >> addressing might not be > >>>> > >> available or it may be preferred to use some form of= non- > IP > >>>> > >> encapsulation for On-demand CV, route tracing and BF= D > packets. > >>>> > In > >>>> > >> such scenarios, On-demand CV and/or route tracing SH= OULD > be run > >>>> > >> without IP addressing..." > >>>> > >> > >>>> > >> I am not sure the "SHOULD" is right here. If no IP addr= essing > is > >>>> > >> available, this thing MUST be run without IP addressing= , > mustn't it? > >>>> > >> > >>>> > >> I think some additional text regarding per-interface MI= P > addressing > >>>> > >> would be nice. As far as I understand the document, all= TLVs > will be > >>>> > >> inside the LSP ping packet (rather than as ACH TLVs). > >>>> > >> > >>>> > >> Some people had concerns earlier, that addressing infor= mation > should > >>>> > be > >>>> > >> in a fixed location for easier processing. Is this the = case > here I > >>>> > >> wonder? > >>>> > >> > >>>> > >> It would be nice if you could address this in your > presentation in > >>>> > >> Prague. > >>>> > >> > >>>> > >> Thanks, > >>>> > >> > >>>> > >> Rolf > >>>> > >> > >>>> > >> > >>>> > >> NEC Europe Limited | Registered Office: NEC House, 1 Vi= ctoria > Road, > >>>> > >> London W3 6BL | Registered in England 2832014 > >>>> > >> > >>>> > >> > >>>> > >> > -----Original Message----- > >>>> > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf= .org] > On > >>>> > Behalf > >>>> > >> Of > >>>> > >> > loa@pi.nu > >>>> > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > >>>> > >> > To: mpls@ietf.org > >>>> > >> > Cc: MPLS-TP ad hoc team > >>>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-= mpls- > tp-on- > >>>> > >> demand- > >>>> > >> > cv-03 > >>>> > >> > > >>>> > >> > Working Group, > >>>> > >> > > >>>> > >> > this is to start a 3 week working group last call on > >>>> > >> > > >>>> > >> > draft-ietf-mpls-tp-on-demand-cv-03 > >>>> > >> > > >>>> > >> > Please send comments to the working group mailing lis= t > >>>> > >> > mpls@ietf.org > >>>> > >> > > >>>> > >> > The working group last call ends on April 8, 2011. > >>>> > >> > > >>>> > >> > /Loa > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > _______________________________________________ > >>>> > >> > 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 From eric.gray@ericsson.com Tue Apr 12 03:35:26 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1DC36E0705 for ; Tue, 12 Apr 2011 03:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmw6mn7V5wKn for ; Tue, 12 Apr 2011 03:35:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 3717EE0704 for ; Tue, 12 Apr 2011 03:35:24 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3CAZNo3029889 for ; Tue, 12 Apr 2011 05:35:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 12 Apr 2011 06:35:17 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 12 Apr 2011 06:35:15 -0400 Thread-Topic: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt Thread-Index: AcvkeK8hutvfRZeXSZymrltxfoQJoAACOzwgAAZzYNADsf3Q8ACZOGDAAM05kyA= Message-ID: 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 Subject: [mpls] FW: Comments on draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 10:35:26 -0000 =20 Resending this in plain text (too big) ________________________________ From: Lavanya Srivatsa [mailto:lavanya.srivatsa@aricent.com]=20 Sent: Friday, April 08, 2011 4:39 AM To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); mpls@ietf.org Cc: Lavanya Srivatsa Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt I am re-sending my mail since I am unable to see this in the MPLS or the MP= LS-TP mailing pages! =20 ________________________________ From: Lavanya Srivatsa=20 Sent: Tuesday, April 05, 2011 3:25 PM To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); MPLS TP; mpls@ietf.org Cc: Lavanya Srivatsa Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt =20 Hi Yaacov, =20 Thanks for your prompt response. I apologize for my delayed response.=20 Please see my comments inlined with [LS]. =20 Thanks Lavanya =20 ________________________________ From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:yaacov.weingarten@= nsn.com]=20 Sent: Thursday, March 17, 2011 6:44 PM To: Lavanya Srivatsa; MPLS TP; mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt =20 Lavanya, hi =20 See my comments below =20 Hope this helps BR, yaacov =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Lavanya Srivatsa Sent: Thursday, March 17, 2011 11:16 AM To: MPLS TP; mpls@ietf.org Subject: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt =20 To the authors, =20 I have a list of protection switching scenarios that do not seem to result = in expected behaviour if operating as per this draft. I have proposed solut= ions/alternate text. I would appreciate your comments/confirmation on the s= ame. =20 Scenario 1 Assume that there is a revertive protection switching group set up between = routers R1 and R5 for working LSP1 and protection LSP2=20 =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 FS on R5 =E0 FS clear on R5 [Result]=20 Both R1 and R5 going to Normal state with NR(0,0) [Problem]=20 The above is an incorrect state on R1 since the local Signal Fail still exi= sts and has not been cleared. So R1 should have moved back to the local Pro= tecting Failure state transmitting SF(1,1) instead of going to the NR(0,0) = state. =20 yw> First off see in the comment resolution, row#80. =20 To explain more fully - you just stopped your scenario one step too soon - = When R1 returns to Normal state it will then immediately receive the SF ind= ication and go into Protecting Failure. In essence, as pointed out in the = comment in row #80 of the LC comments the state machine dictates that you t= ransition through Normal to arrive at the Protecting failure state. [LS] Thanks for referring me to the comments resolution. I have looked into= row#80 which talks of a different scenario but talks on the same lines as = the one I have mentioned.=20 When you state that R1 returns to Normal and will immediately receive the S= F and go into Protecting Failure state, it depends on what you mean by "imm= ediate" here. Unless you mean an "atomic" operation that happens either bas= ed on storing of the previous failure state or by some sort of 2-pass throu= gh the state machine (which is some form of re-assertion as I had stated), = this will, for sure, cause a "traffic glitch" even though it may be momenta= ry. Any scenario that could result in an unnecessary traffic glitch is high= ly undesirable and would defeat the purpose of having such a detailed proto= col and state machine for protecting switching. =20 This was done in order to simplify the protocol and the state machine - as = you can see from the LC comments there are several other of these scenarios= and if we wanted to cover every possible scenario it would greatly complic= ate the state machine with different levels of conditions that would need t= o be checked. What you are suggesting is an optimization that you could im= plement, but we (after discussing this and other scenarios) opted for the s= implicity of the protocol. =20 [LS] I do not believe the suggestion to be an optimization, rather a fool-p= roof method that results in correct expected behaviour and does not leave i= t up to implementations to figure this out. If it is to be an "atomic opera= tion" or "2-pass logic", or to pass through an "intermediate state", then t= his needs to be mentioned clearly. As a standard mechanism being proposed f= or protecting switching, I feel that it is imperative for such recommendati= ons to be made in the draft for all such possible scenarios in order to ens= ure correctness and a high-level of interoperability amongst vendors implem= enting this solution under all situations/scenarios. It may not be too comp= lex actually, considering the fact that Ethernet linear protection switchin= g state machines provide solutions for such scenarios, so taking a similar = strategy for MPLS should be relatively easy I guess! However, even if it is= , I still think we would have to go ahead and make these recommendations in= the draft for completeness and correctness. =20 =20 [Suggested Solution]=20 In Section 4.3.3.3, the 2nd last bullet item under remote messages needs to= be modified as - "A remote NR(0,0) message SHALL be ignored if in local Pr= otecting administrative state. If in remote Protecting administrative stat= e then the LER SHALL go to Normal state and begin transmitting a NR(0,0) me= ssage OR shall go to the local Protecting Failure state if local Signal Fai= lure is still reasserted and begin transmitting SF(1,1). =20 Scenario 2 Assume that there is a non-revertive protection switching set up between ro= uters R1 and R5 for working LSP1 and protection LSP2. =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 SF clear on R1 =E0 FS on R1= =E0 FS clear on R1 [Result]=20 Both R1 and R5 going to Normal state with NR(0,0) [Problem]=20 Upon clearing the Forced Switch at R1, it is expected to go local Do-Not-Re= vert state again and begin transmitting DNR(0,1). Upon receiving this R5 is= expected to go to remote Do-Not-Revert state. =20 yw> I do not agree that the domain should transition back to DNR state once= the operator did a Forced Switch he means to go back to Normal. In a prev= ious version of the draft we presented two possibilities of reverting to No= rmal from DNR state (either use an explicit Clear command or use FS) and th= e use of FS was chosen. So this is the very scenario that allows the opera= tor to revert back to Normal from DNR state. =20 [LS] If this has been a conscious decision to switch back to working for a = non-revertive protection, then fine, I agree. =20 [Suggested Solution]=20 In Section 4.3.3.3, the 1st bullet item under local input needs to be modif= ied as - "A local Clear SHOULD be ignored if in remote Protecting administr= ative state. If in local Protecting administrative state then this input S= HALL cause the LER to go into Normal state and begin transmitting a NR(0,0)= message if in revertive mode or go into Do-Not-Revert state and begin tran= smitting DNR(0,1) if in non-revertive mode. =20 Scenario 3 Assume that there is a protection switching set up between routers R1 and R= 5 for working LSP1 and protection LSP2 where R1 is operating in the reverti= ve mode and R5 is operating in the non-revertive mode. =20 yw> There is a problem already at this point in your description - referri= ng to section 4.2.4 of the draft - it states clearly that this misconfigura= tion should be reported to the management system as an error situation. =20 [LS] Section 4.2.4 only mentions that if there is an inconsistency between = the two ends with regards to revertive/non-revertive, then the management s= ystem SHOULD be notified. Based on your response, this is the suggestion from my side - Rephrase the = 2nd sentence in Section 4.2.4 as follows - "If there is an inconsistency be= tween the two end points, i.e. one end point is configured for revertive ac= tion and the second end point is in non-revertive mode, then this should be= treated as a mis-configuration and the management system MUST be notified,= and any received PSC packets with the revertive (R) field different from w= hat is supported on the local node should be discarded." BTW, just curious - one end being revertive and the other end being non-rev= ertive is a scenario that can interwork in ethernet linear protection switc= hing. Any specific reason as to why this is considered non-interworking for= MPLS paths? =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 SF clear on R1 [Result]=20 R5 moves to Wait-to-restore state and begins transmitting NR(0,1) [Problem]=20 R5 is in non-revertive mode and as such does not have a Wait-to-restore sta= te.=20 [Suggested Solution]=20 In Section 4.3.3.4, the 4th bullet under remote messages needs to be modifi= ed as - "If in remote Protecting failure state, a remote Wait-to-Restore me= ssage SHALL cause the LER to go into remote Wait-to-Restore state if in rev= ertive mode and into remote Do-Not-Revert state if in non-revertive mode an= d continue transmission of the current message. =20 =20 I have worked out the exact sequence details of the state machine for the s= cenarios above, which I have listed below. =20 - Lavanya =20 =20 DETAILED SEQUENCE =20 Scenario 1 Assume that there is a revertive protection switching group set up between = routers R1 and R5 for working LSP1 and protection LSP2. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now issue a Forced Switch command on R5. R5 will now move to the local Protecting Administrative state and start tra= nsmitting FS(1,1). R1, on receiving FS(1,1), now moves to remote Protecting Adminstrative stat= e and since it was earlier in local Protecting Failure state, it will now t= ransmit SF(1,1) to R5. R5, on receiving SF(1,1) from R1, will ignore the message since there is an= active Local Forced Switch command. Now issue a Clear command on R5 for clearing the Forced Switch. R5 will now move to the Normal state since it was in local Protecting Admin= strative state and start transmitting NR(0,0). R1, on receiving NR(0,0), will go to Normal state since it was in remote Pr= otecting Adminstrative state and begin transmitting NR(0,0). =20 =20 Scenario 2 Assume that there is a non-revertive protection switching set up between ro= uters R1 and R5 for working LSP1 and protection LSP2. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now SF clears on R1. R1 will go to Do-Not-Revert state and start transmitting DNR(0,1). R5, on receving DNR(0,1) moves to the remote Do-Not-Revert state and contin= ues transmitting current message of NR(0,1). R1, on receiving NR(0,1), will ignore this message. Now issue a Forced Switch command on R1. R1 will go the local Protecting Administrative state and begins transmittin= g FS(1,1) to R5. R5, on receiving FS(1,1), moves to the remote Protecting Administrative sta= te and begins transmitting NR(0,1). R1, on receiving NR(0,1) will ignore this message. Now issue a Clear Forced Switch command on R1. R1 moves to the Normal state and begins transmitting NR(0,0). R5, on receiving NR(0,0), moves to the Normal state and begins transmitting= NR(0,0). =20 =20 Scenario 3 Assume that there is a protection switching set up between routers R1 and R= 5 for working LSP1 and protection LSP2 where R1 is operating in the reverti= ve mode and R5 is operating in the non-revertive mode. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now SF clears on R1. R1 will go to Wait-To-Restore state, start the WTR timer and start transmit= ting WTR(0,1). R5, on receiving WTR(0,1), moves to the remote Wait-To-Restore state and co= ntinues transmission of current message NR(0,1). =20 =20 ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From eric.gray@ericsson.com Tue Apr 12 03:36:11 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A1B54E0770 for ; Tue, 12 Apr 2011 03:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VLyimxYqFbz for ; Tue, 12 Apr 2011 03:36:09 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 3D447E0777 for ; Tue, 12 Apr 2011 03:36:09 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3CAa8fP001450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Apr 2011 05:36:08 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 12 Apr 2011 06:36:07 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 12 Apr 2011 06:36:06 -0400 Thread-Topic: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt Thread-Index: AcvkeK8hutvfRZeXSZymrltxfoQJoAACOzwgAAZzYNADsf3Q8AFmf1lw Message-ID: 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 Subject: [mpls] FW: Comments on draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 10:36:11 -0000 =20 Resending in plain text (too big) ________________________________ From: Lavanya Srivatsa [mailto:lavanya.srivatsa@aricent.com]=20 Sent: Tuesday, April 05, 2011 5:55 AM To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); MPLS TP; mpls@ietf.org Cc: Lavanya Srivatsa Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt Hi Yaacov, =20 Thanks for your prompt response. I apologize for my delayed response.=20 Please see my comments inlined with [LS]. =20 Thanks Lavanya =20 ________________________________ From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:yaacov.weingarten@= nsn.com]=20 Sent: Thursday, March 17, 2011 6:44 PM To: Lavanya Srivatsa; MPLS TP; mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt =20 Lavanya, hi =20 See my comments below =20 Hope this helps BR, yaacov =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Lavanya Srivatsa Sent: Thursday, March 17, 2011 11:16 AM To: MPLS TP; mpls@ietf.org Subject: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt =20 To the authors, =20 I have a list of protection switching scenarios that do not seem to result = in expected behaviour if operating as per this draft. I have proposed solut= ions/alternate text. I would appreciate your comments/confirmation on the s= ame. =20 Scenario 1 Assume that there is a revertive protection switching group set up between = routers R1 and R5 for working LSP1 and protection LSP2=20 =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 FS on R5 =E0 FS clear on R5 [Result]=20 Both R1 and R5 going to Normal state with NR(0,0) [Problem]=20 The above is an incorrect state on R1 since the local Signal Fail still exi= sts and has not been cleared. So R1 should have moved back to the local Pro= tecting Failure state transmitting SF(1,1) instead of going to the NR(0,0) = state. =20 yw> First off see in the comment resolution, row#80. =20 To explain more fully - you just stopped your scenario one step too soon - = When R1 returns to Normal state it will then immediately receive the SF ind= ication and go into Protecting Failure. In essence, as pointed out in the = comment in row #80 of the LC comments the state machine dictates that you t= ransition through Normal to arrive at the Protecting failure state. [LS] Thanks for referring me to the comments resolution. I have looked into= row#80 which talks of a different scenario but talks on the same lines as = the one I have mentioned.=20 When you state that R1 returns to Normal and will immediately receive the S= F and go into Protecting Failure state, it depends on what you mean by "imm= ediate" here. Unless you mean an "atomic" operation that happens either bas= ed on storing of the previous failure state or by some sort of 2-pass throu= gh the state machine (which is some form of re-assertion as I had stated), = this will, for sure, cause a "traffic glitch" even though it may be momenta= ry. Any scenario that could result in an unnecessary traffic glitch is high= ly undesirable and would defeat the purpose of having such a detailed proto= col and state machine for protecting switching. =20 This was done in order to simplify the protocol and the state machine - as = you can see from the LC comments there are several other of these scenarios= and if we wanted to cover every possible scenario it would greatly complic= ate the state machine with different levels of conditions that would need t= o be checked. What you are suggesting is an optimization that you could im= plement, but we (after discussing this and other scenarios) opted for the s= implicity of the protocol. =20 [LS] I do not believe the suggestion to be an optimization, rather a fool-p= roof method that results in correct expected behaviour and does not leave i= t up to implementations to figure this out. If it is to be an "atomic opera= tion" or "2-pass logic", or to pass through an "intermediate state", then t= his needs to be mentioned clearly. As a standard mechanism being proposed f= or protecting switching, I feel that it is imperative for such recommendati= ons to be made in the draft for all such possible scenarios in order to ens= ure correctness and a high-level of interoperability amongst vendors implem= enting this solution under all situations/scenarios. It may not be too comp= lex actually, considering the fact that Ethernet linear protection switchin= g state machines provide solutions for such scenarios, so taking a similar = strategy for MPLS should be relatively easy I guess! However, even if it is= , I still think we would have to go ahead and make these recommendations in= the draft for completeness and correctness. =20 =20 [Suggested Solution]=20 In Section 4.3.3.3, the 2nd last bullet item under remote messages needs to= be modified as - "A remote NR(0,0) message SHALL be ignored if in local Pr= otecting administrative state. If in remote Protecting administrative stat= e then the LER SHALL go to Normal state and begin transmitting a NR(0,0) me= ssage OR shall go to the local Protecting Failure state if local Signal Fai= lure is still reasserted and begin transmitting SF(1,1). =20 Scenario 2 Assume that there is a non-revertive protection switching set up between ro= uters R1 and R5 for working LSP1 and protection LSP2. =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 SF clear on R1 =E0 FS on R1= =E0 FS clear on R1 [Result]=20 Both R1 and R5 going to Normal state with NR(0,0) [Problem]=20 Upon clearing the Forced Switch at R1, it is expected to go local Do-Not-Re= vert state again and begin transmitting DNR(0,1). Upon receiving this R5 is= expected to go to remote Do-Not-Revert state. =20 yw> I do not agree that the domain should transition back to DNR state once= the operator did a Forced Switch he means to go back to Normal. In a prev= ious version of the draft we presented two possibilities of reverting to No= rmal from DNR state (either use an explicit Clear command or use FS) and th= e use of FS was chosen. So this is the very scenario that allows the opera= tor to revert back to Normal from DNR state. =20 [LS] If this has been a conscious decision to switch back to working for a = non-revertive protection, then fine, I agree. =20 [Suggested Solution]=20 In Section 4.3.3.3, the 1st bullet item under local input needs to be modif= ied as - "A local Clear SHOULD be ignored if in remote Protecting administr= ative state. If in local Protecting administrative state then this input S= HALL cause the LER to go into Normal state and begin transmitting a NR(0,0)= message if in revertive mode or go into Do-Not-Revert state and begin tran= smitting DNR(0,1) if in non-revertive mode. =20 Scenario 3 Assume that there is a protection switching set up between routers R1 and R= 5 for working LSP1 and protection LSP2 where R1 is operating in the reverti= ve mode and R5 is operating in the non-revertive mode. =20 yw> There is a problem already at this point in your description - referri= ng to section 4.2.4 of the draft - it states clearly that this misconfigura= tion should be reported to the management system as an error situation. =20 [LS] Section 4.2.4 only mentions that if there is an inconsistency between = the two ends with regards to revertive/non-revertive, then the management s= ystem SHOULD be notified. Based on your response, this is the suggestion from my side - Rephrase the = 2nd sentence in Section 4.2.4 as follows - "If there is an inconsistency be= tween the two end points, i.e. one end point is configured for revertive ac= tion and the second end point is in non-revertive mode, then this should be= treated as a mis-configuration and the management system MUST be notified,= and any received PSC packets with the revertive (R) field different from w= hat is supported on the local node should be discarded." BTW, just curious - one end being revertive and the other end being non-rev= ertive is a scenario that can interwork in ethernet linear protection switc= hing. Any specific reason as to why this is considered non-interworking for= MPLS paths? =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 SF clear on R1 [Result]=20 R5 moves to Wait-to-restore state and begins transmitting NR(0,1) [Problem]=20 R5 is in non-revertive mode and as such does not have a Wait-to-restore sta= te.=20 [Suggested Solution]=20 In Section 4.3.3.4, the 4th bullet under remote messages needs to be modifi= ed as - "If in remote Protecting failure state, a remote Wait-to-Restore me= ssage SHALL cause the LER to go into remote Wait-to-Restore state if in rev= ertive mode and into remote Do-Not-Revert state if in non-revertive mode an= d continue transmission of the current message. =20 =20 I have worked out the exact sequence details of the state machine for the s= cenarios above, which I have listed below. =20 - Lavanya =20 =20 DETAILED SEQUENCE =20 Scenario 1 Assume that there is a revertive protection switching group set up between = routers R1 and R5 for working LSP1 and protection LSP2. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now issue a Forced Switch command on R5. R5 will now move to the local Protecting Administrative state and start tra= nsmitting FS(1,1). R1, on receiving FS(1,1), now moves to remote Protecting Adminstrative stat= e and since it was earlier in local Protecting Failure state, it will now t= ransmit SF(1,1) to R5. R5, on receiving SF(1,1) from R1, will ignore the message since there is an= active Local Forced Switch command. Now issue a Clear command on R5 for clearing the Forced Switch. R5 will now move to the Normal state since it was in local Protecting Admin= strative state and start transmitting NR(0,0). R1, on receiving NR(0,0), will go to Normal state since it was in remote Pr= otecting Adminstrative state and begin transmitting NR(0,0). =20 =20 Scenario 2 Assume that there is a non-revertive protection switching set up between ro= uters R1 and R5 for working LSP1 and protection LSP2. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now SF clears on R1. R1 will go to Do-Not-Revert state and start transmitting DNR(0,1). R5, on receving DNR(0,1) moves to the remote Do-Not-Revert state and contin= ues transmitting current message of NR(0,1). R1, on receiving NR(0,1), will ignore this message. Now issue a Forced Switch command on R1. R1 will go the local Protecting Administrative state and begins transmittin= g FS(1,1) to R5. R5, on receiving FS(1,1), moves to the remote Protecting Administrative sta= te and begins transmitting NR(0,1). R1, on receiving NR(0,1) will ignore this message. Now issue a Clear Forced Switch command on R1. R1 moves to the Normal state and begins transmitting NR(0,0). R5, on receiving NR(0,0), moves to the Normal state and begins transmitting= NR(0,0). =20 =20 Scenario 3 Assume that there is a protection switching set up between routers R1 and R= 5 for working LSP1 and protection LSP2 where R1 is operating in the reverti= ve mode and R5 is operating in the non-revertive mode. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now SF clears on R1. R1 will go to Wait-To-Restore state, start the WTR timer and start transmit= ting WTR(0,1). R5, on receiving WTR(0,1), moves to the remote Wait-To-Restore state and co= ntinues transmission of current message NR(0,1). =20 =20 ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From loa@pi.nu Tue Apr 12 04:00:23 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 88522E079A for ; Tue, 12 Apr 2011 04:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYAcDFRPGwTS for ; Tue, 12 Apr 2011 04:00:22 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfc.amsl.com (Postfix) with ESMTP id B8B84E0796 for ; Tue, 12 Apr 2011 04:00:22 -0700 (PDT) Received: from [192.168.1.68] (unknown [58.69.139.171]) (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 7B20A2A8001; Tue, 12 Apr 2011 13:00:20 +0200 (CEST) Message-ID: <4DA430BF.7030106@pi.nu> Date: Tue, 12 Apr 2011 19:00:15 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mpls@ietf.org References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> In-Reply-To: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MPLS-TP ad hoc team Subject: [mpls] Closing: Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 11:00:23 -0000 All, this working group last call is closed. There has been comments, could the authors please resolve the comments, publish a new version of the draft and share the resolution on the working group mailing list! Loa on behalf of the mpls working group chairs. On 2011-03-16 07:26, loa@pi.nu wrote: > Working Group, > > this is to start a 3 week working group last call on > > draft-ietf-mpls-tp-on-demand-cv-03 > > Please send comments to the working group mailing list > mpls@ietf.org > > The working group last call ends on April 8, 2011. > > /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 david.i.allan@ericsson.com Tue Apr 12 07:17:13 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B431E07C7 for ; Tue, 12 Apr 2011 07:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.409 X-Spam-Level: X-Spam-Status: No, score=-4.409 tagged_above=-999 required=5 tests=[AWL=2.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYwFUg1o5Utb for ; Tue, 12 Apr 2011 07:17:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id C47F3E07C1 for ; Tue, 12 Apr 2011 07:17:12 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3CEHAVC021687; Tue, 12 Apr 2011 09:17:12 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 12 Apr 2011 10:17:10 -0400 From: David Allan I To: "curtis@occnc.com" Date: Tue, 12 Apr 2011 10:17:08 -0400 Thread-Topic: [mpls] MPLS-TP CC-CV-RDI Thread-Index: Acv4wZ4e5uohAEM9SYK+veD0+8TCYAAWljAQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> References: Your message of "Mon, 11 Apr 2011 18:08:16 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> In-Reply-To: <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.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 Cc: "mpls@ietf.org" , David Ward , "Schink, Helmut \(NSN - DE/Munich\)" Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:17:13 -0000 Agreed, but that would require redesigning BFD. The other alternative would= be to use the version number. As we had a simultaneous change of encapsultion with the GAL/G-ACh as well = as the need for additional features, the code point seemed to make sense. Thanks Dave=20 -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com]=20 Sent: Monday, April 11, 2011 8:28 PM To: David Allan I Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; Niti= n Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) Subject: Re: [mpls] MPLS-TP CC-CV-RDI=20 In message <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.e= ricsson.se> David Allan I writes: > =20 > Hi Nurit > =20 > It is backwards compatible in the sense that the new code points allow=20 > the additional behaviors specified for MPLS TP to be disambiguated=20 > from existing RFC 5884/5 behaviors > =20 > - this is the addition of the GAL, the source MEP TLV, > interleaving of CC and CV PDUs, and accepting the TP-FAULT > inputs as valid state machine inputs. > =20 > It is not perfectly backwards compatible in that the addition of the=20 > GAL and new code points means deployed implementations will not=20 > support the new encap and TLV without an upgrade .... RFC 5885 is=20 > close but not an exact match due to the addition of the Source MEP ID=20 > TLV. Some implementation tweaks are required. The usual way to handle an extension to an existing protocol is to use a ca= pability negotiation, not assign a new code point. > hope this helps > Dave > =20 > ________________________________ > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > [mailto:nurit.sprecher@nsn.com] > Sent: Monday, April 11, 2011 9:51 AM > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink,=20 > Helmut (NSN - DE/Munich) > Subject: MPLS-TP CC-CV-RDI > =20 > Dear authors, > =20 > Slide 14 of the attached, says that "This document an enhancement to=20 > RFC 5884/5885....But it still requires two new code points as it will=20 > not be perfectly backwards compatible...." > =20 > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > It is my understanding that the extension done to BFD is completely=20 > compatible with BFD. > Can you please clarify this point? Is the solution being defined in=20 > draft cc-cv-rdi is compatible with BFD? > Is it also possible for CC-CV-RDI and existing BFD to be compatible=20 > today given only the proper configuration? > Best regards, > Nurit From Alexander.Vainshtein@ecitele.com Tue Apr 12 07:20:00 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 30F7BE07C1 for ; Tue, 12 Apr 2011 07:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbWqWcxz30Is for ; Tue, 12 Apr 2011 07:19:59 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id 14B0AE07BE for ; Tue, 12 Apr 2011 07:19:58 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-be-4da45f283441 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 06.A6.02691.82F54AD4; Tue, 12 Apr 2011 17:18:16 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 12 Apr 2011 17:19:55 +0300 From: Alexander Vainshtein To: David Allan I Date: Tue, 12 Apr 2011 17:19:53 +0300 Thread-Topic: [mpls] MPLS-TP CC-CV-RDI Thread-Index: Acv4wZ4e5uohAEM9SYK+veD0+8TCYAAWljAQAAAcDZA= Message-ID: References: Your message of "Mon, 11 Apr 2011 18:08:16 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@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 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZ/OrTF12N+CW+Bnfn8lkcPjCd3eLh+e3M Fkf/drBYLLr3l9Hi1tKVrA6sHr++XmXzWLLkJ5PH9aar7B4/1wOJxV/8AlijuGxSUnMyy1KL 9O0SuDJmbqwv2CpV0b/4OmsDY7toFyMnh4SAicS13pOsELaYxIV769m6GLk4hAR2M0o877nJ BOFMY5S4t3IjE0gVm4CtxKbVd9lAbBEBPYk1F3+zghQxC6xilHj99AMLSIJFQFXi46wZYA3C QPbZb9MZIRrUJHp2L2aBsK0kdu/ezw5i8wr4S2x6cB5sqJDARCaJT2eTQGxOgQiJ3tbTYOcx Ap33/dQasJnMAuISt57MZ4I4W0BiyZ7zzBC2qMTLx/+g6kUl7rSvZ4So15FYsPsTG4StLbFs 4WtmiL2CEidnPmGB6JWUOLjiBssERvFZSFbMQtI+C0n7LCTtCxhZVjGKZuYUlCTlphsY6aUm Z5ak5qTqJefnbmKExOSLHYy3z2geYpTmYFES511xdIqvkEB6YklqdmpqQWpRfFFpTmrxIUYm Dk6pBsauuIh4M2GjfKPHFffFLhzimG1yxT75sUGLUbeSurOYkF2XxZw89sKDiezz9E+rqPFo zT425+yxhNf37aItrm/if2d68lANz4stBQzdwRtCtttbvBL5+Ks327X20/W05PrTZt7nJydd cfgQm6m+ePvHmVO002v+Cc9R82w7duBLff1NlifJHUosxRmJhlrMRcWJAMcacKmXAgAA Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:20:00 -0000 Dave, Raw BFD encapsulation over G-ACh has been already defined in RFC 5885. GAL does not really add anything to this encapsulation IMO, simply allows t= o use G-ACh on top of LSPs and not just PWs. Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Tuesday, April 12, 2011 5:17 PM > To: curtis@occnc.com > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich) > Subject: Re: [mpls] MPLS-TP CC-CV-RDI >=20 > Agreed, but that would require redesigning BFD. The other alternative > would be to use the version number. >=20 > As we had a simultaneous change of encapsultion with the GAL/G-ACh as > well as the need for additional features, the code point seemed to make > sense. >=20 > Thanks > Dave >=20 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Monday, April 11, 2011 8:28 PM > To: David Allan I > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; > Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > Subject: Re: [mpls] MPLS-TP CC-CV-RDI >=20 >=20 > In message > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson > .se> > David Allan I writes: > > > > Hi Nurit > > > > It is backwards compatible in the sense that the new code points > allow > > the additional behaviors specified for MPLS TP to be disambiguated > > from existing RFC 5884/5 behaviors > > > > - this is the addition of the GAL, the source MEP TLV, > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > inputs as valid state machine inputs. > > > > It is not perfectly backwards compatible in that the addition of the > > GAL and new code points means deployed implementations will not > > support the new encap and TLV without an upgrade .... RFC 5885 is > > close but not an exact match due to the addition of the Source MEP ID > > TLV. Some implementation tweaks are required. >=20 > The usual way to handle an extension to an existing protocol is to use > a capability negotiation, not assign a new code point. >=20 > > hope this helps > > Dave > > > > ________________________________ > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > [mailto:nurit.sprecher@nsn.com] > > Sent: Monday, April 11, 2011 9:51 AM > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, > > Helmut (NSN - DE/Munich) > > Subject: MPLS-TP CC-CV-RDI > > > > Dear authors, > > > > Slide 14 of the attached, says that "This document an enhancement to > > RFC 5884/5885....But it still requires two new code points as it will > > not be perfectly backwards compatible...." > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > It is my understanding that the extension done to BFD is completely > > compatible with BFD. > > Can you please clarify this point? Is the solution being defined in > > draft cc-cv-rdi is compatible with BFD? > > Is it also possible for CC-CV-RDI and existing BFD to be compatible > > today given only the proper configuration? > > Best regards, > > Nurit > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Tue Apr 12 07:25:53 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6B09DE07DB for ; Tue, 12 Apr 2011 07:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.722 X-Spam-Level: X-Spam-Status: No, score=-4.722 tagged_above=-999 required=5 tests=[AWL=1.877, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+vVGU56dXX6 for ; Tue, 12 Apr 2011 07:25:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 888EDE07C9 for ; Tue, 12 Apr 2011 07:25:52 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3CEPkZt023504; Tue, 12 Apr 2011 09:25:49 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 12 Apr 2011 10:25:42 -0400 From: David Allan I To: Alexander Vainshtein Date: Tue, 12 Apr 2011 10:25:40 -0400 Thread-Topic: [mpls] MPLS-TP CC-CV-RDI Thread-Index: Acv4wZ4e5uohAEM9SYK+veD0+8TCYAAWljAQAAAcDZAAABvNEA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@EUSAACMS0703.eamcs.ericsson.se> References: Your message of "Mon, 11 Apr 2011 18:08:16 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:25:53 -0000 There is a few semantic differences over 5885 unique to MPLS-TP.... 1) Interleave of CC and CV. 2) The additional mis-connectivity logic implied by CV=20 3) The additional transactions in TP-FAULT are valid inputs. And a couple of other things meant that BFD for TP could not be supported b= y a vanilla 5885 implementation. Hope this helps Dave =20 -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Tuesday, April 12, 2011 7:20 AM To: David Allan I Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); curtis@occ= nc.com Subject: RE: [mpls] MPLS-TP CC-CV-RDI Dave, Raw BFD encapsulation over G-ACh has been already defined in RFC 5885. GAL does not really add anything to this encapsulation IMO, simply allows t= o use G-ACh on top of LSPs and not just PWs. Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of David Allan I > Sent: Tuesday, April 12, 2011 5:17 PM > To: curtis@occnc.com > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich) > Subject: Re: [mpls] MPLS-TP CC-CV-RDI >=20 > Agreed, but that would require redesigning BFD. The other alternative=20 > would be to use the version number. >=20 > As we had a simultaneous change of encapsultion with the GAL/G-ACh as=20 > well as the need for additional features, the code point seemed to=20 > make sense. >=20 > Thanks > Dave >=20 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Monday, April 11, 2011 8:28 PM > To: David Allan I > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake;=20 > Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > Subject: Re: [mpls] MPLS-TP CC-CV-RDI >=20 >=20 > In message > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsso > n > .se> > David Allan I writes: > > > > Hi Nurit > > > > It is backwards compatible in the sense that the new code points > allow > > the additional behaviors specified for MPLS TP to be disambiguated=20 > > from existing RFC 5884/5 behaviors > > > > - this is the addition of the GAL, the source MEP TLV, > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > inputs as valid state machine inputs. > > > > It is not perfectly backwards compatible in that the addition of the=20 > > GAL and new code points means deployed implementations will not=20 > > support the new encap and TLV without an upgrade .... RFC 5885 is=20 > > close but not an exact match due to the addition of the Source MEP=20 > > ID TLV. Some implementation tweaks are required. >=20 > The usual way to handle an extension to an existing protocol is to use=20 > a capability negotiation, not assign a new code point. >=20 > > hope this helps > > Dave > > > > ________________________________ > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > > [mailto:nurit.sprecher@nsn.com] > > Sent: Monday, April 11, 2011 9:51 AM > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink,=20 > > Helmut (NSN - DE/Munich) > > Subject: MPLS-TP CC-CV-RDI > > > > Dear authors, > > > > Slide 14 of the attached, says that "This document an enhancement to=20 > > RFC 5884/5885....But it still requires two new code points as it=20 > > will not be perfectly backwards compatible...." > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > It is my understanding that the extension done to BFD is completely=20 > > compatible with BFD. > > Can you please clarify this point? Is the solution being defined in=20 > > draft cc-cv-rdi is compatible with BFD? > > Is it also possible for CC-CV-RDI and existing BFD to be compatible=20 > > today given only the proper configuration? > > Best regards, > > Nurit > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Tue Apr 12 07:39:16 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 866D1E079E for ; Tue, 12 Apr 2011 07:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZlRqNVUDfyk for ; Tue, 12 Apr 2011 07:39:15 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id 1F383E0798 for ; Tue, 12 Apr 2011 07:39:14 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-3a-4da463aeb4ee Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id E3.D6.02691.EA364AD4; Tue, 12 Apr 2011 17:37:34 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 12 Apr 2011 17:39:13 +0300 From: Alexander Vainshtein To: David Allan I Date: Tue, 12 Apr 2011 17:39:12 +0300 Thread-Topic: [mpls] MPLS-TP CC-CV-RDI Thread-Index: Acv4wZ4e5uohAEM9SYK+veD0+8TCYAAWljAQAAAcDZAAABvNEAAAMFPQ Message-ID: References: Your message of "Mon, 11 Apr 2011 18:08:16 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@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 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUy+dWnL7rrkpf4Giz5L25x+MB0douH57cz Wxz928FisejeX0aLW0tXsjqwevz6epXNY8mSn0we15uusnv8XA8kFn/xC2CNamC0SczLyy9J LElVSEktTrZVCijKLEtMrlRSyEyxVTJUUijISUxOzU3NK7FVSiwoSM1LUbLjUsAANkBlmXkK qXnJ+SmZeem2Sp7B/roWFqaWuoZKdmrKhsbWXCEZmcUKqbq5iZk5CrmpxcWJ6akKQJGELcwZ Z4+bFXzTqbg9bxNLA+Mu5S5GTg4JAROJzuMLmSBsMYkL99azgdhCArsZJboee3YxcgHZ0xgl ri5cBZZgE7CV2LT6LpgtIqAnsebib1aQImaBVYwSr59+YAFJsAioSnw+08gIYgsD2We/TWeE aFCT6Nm9mAXCdpM48aaDHcTmFfCX+LOzjwVi21JmiclNN8CKOAUiJJ7O7QMrYgQ67/upNWCn MguIS9x6Mh/qbAGJJXvOM0PYohIvH/9jhagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvmSEWC0qc nPmEBaJXUuLgihssExjFZyFZMQtJ+ywk7bOQtC9gZFnFKJqZU1CSlJtuYKSXmpxZkpqTqpec n7uJEZKCXuxgvH1G8xCjBTBwJjJLcSfnA1NYXkm8sYEBCkdJnPddwhJfIYF0YFrJTk0tSC2K LyrNSS0+xMjEwSnVwDgzTbZl7V3rC3ZeE7lbxdTWSob39DPV9RaqX3Z9p7E1MO9OmZ8mm20o W94eXvGoyrOfc/2iBW+knxRZfc21/tQeiydHJm1vfeKh8r5JZrc0k3jxDr/Uir78R//5bhzb /9dIo9vytdaFfT3fH14zmxbOc6sjLetR+nGLbIP1EyyXvondxG5epMRSnJFoqMVcVJwIAORr 5S4sAwAA Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:39:16 -0000 Dave, Lots of thanks for a prompt solution. The question that comes to my mind is: do we really want to put all the tool= s in the same bag? Vanilla 5885 implementation will provide the required CC/RDI functionality w= ithout any changes. Is this correct? If you want to add proactive CV to that you have several options: 1. Run an additional "slow" CV-only BFD session using a new code point (no i= nterleave). 2. Combine CC/RDI and CV into a single session with interleave and bear the= price of increased implementation complexity There are probably other practical options for CV. E.g., one could use the s= imple password authentication option and use Source MEP ID as the password.= Persistent misconnection could be detected as loss of connectivity, but onc= e it happens, it would be (hopefully) pretty simple to define the underlying= reason... (Not sure the security people would approve:-) Insisting on one size to fit all (CC/RDI and proactive CV) seems not practic= al to me. We may provide a solution for that, but should we really require f= rom everybody to stick with this complicated combined solution? Regards, Sasha > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Tuesday, April 12, 2011 5:26 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); > curtis@occnc.com > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > There is a few semantic differences over 5885 unique to MPLS-TP.... > > 1) Interleave of CC and CV. > 2) The additional mis-connectivity logic implied by CV > 3) The additional transactions in TP-FAULT are valid inputs. > > And a couple of other things meant that BFD for TP could not be > supported by a vanilla 5885 implementation. > > Hope this helps > Dave > > > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, April 12, 2011 7:20 AM > To: David Allan I > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); > curtis@occnc.com > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > Dave, > Raw BFD encapsulation over G-ACh has been already defined in RFC 5885. > GAL does not really add anything to this encapsulation IMO, simply > allows to use G-ACh on top of LSPs and not just PWs. > > > Regards, > Sasha > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of David Allan I > > Sent: Tuesday, April 12, 2011 5:17 PM > > To: curtis@occnc.com > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich) > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > Agreed, but that would require redesigning BFD. The other alternative > > would be to use the version number. > > > > As we had a simultaneous change of encapsultion with the GAL/G-ACh as > > well as the need for additional features, the code point seemed to > > make sense. > > > > Thanks > > Dave > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Monday, April 11, 2011 8:28 PM > > To: David Allan I > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E > Drake; > > Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > > > In message > > > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsso > > n > > .se> > > David Allan I writes: > > > > > > Hi Nurit > > > > > > It is backwards compatible in the sense that the new code points > > allow > > > the additional behaviors specified for MPLS TP to be disambiguated > > > from existing RFC 5884/5 behaviors > > > > > > - this is the addition of the GAL, the source MEP TLV, > > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > > inputs as valid state machine inputs. > > > > > > It is not perfectly backwards compatible in that the addition of > the > > > GAL and new code points means deployed implementations will not > > > support the new encap and TLV without an upgrade .... RFC 5885 is > > > close but not an exact match due to the addition of the Source MEP > > > ID TLV. Some implementation tweaks are required. > > > > The usual way to handle an extension to an existing protocol is to > use > > a capability negotiation, not assign a new code point. > > > > > hope this helps > > > Dave > > > > > > ________________________________ > > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > > [mailto:nurit.sprecher@nsn.com] > > > Sent: Monday, April 11, 2011 9:51 AM > > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, > > > Helmut (NSN - DE/Munich) > > > Subject: MPLS-TP CC-CV-RDI > > > > > > Dear authors, > > > > > > Slide 14 of the attached, says that "This document an enhancement > to > > > RFC 5884/5885....But it still requires two new code points as it > > > will not be perfectly backwards compatible...." > > > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > > It is my understanding that the extension done to BFD is completely > > > compatible with BFD. > > > Can you please clarify this point? Is the solution being defined in > > > draft cc-cv-rdi is compatible with BFD? > > > Is it also possible for CC-CV-RDI and existing BFD to be compatible > > > today given only the proper configuration? > > > Best regards, > > > Nurit > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From nurit.sprecher@nsn.com Tue Apr 12 07:51:01 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 12D22E07DE for ; Tue, 12 Apr 2011 07:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.604 X-Spam-Level: X-Spam-Status: No, score=-4.604 tagged_above=-999 required=5 tests=[AWL=1.995, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB9SnXehmLvP for ; Tue, 12 Apr 2011 07:51:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfc.amsl.com (Postfix) with ESMTP id 02887E07DA for ; Tue, 12 Apr 2011 07:50:59 -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 p3CEovIb025973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 16:50:57 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3CEorAw028916; Tue, 12 Apr 2011 16:50:57 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 16:50:55 +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: Tue, 12 Apr 2011 16:50:53 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403A62D0C@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] MPLS-TP CC-CV-RDI Thread-Index: Acv4wZ4e5uohAEM9SYK+veD0+8TCYAAWljAQAAAcDZAAASamMA== References: Your message of "Mon, 11 Apr 2011 18:08:16 EDT."<60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se><201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com><60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Alexander Vainshtein" , "David Allan I" X-OriginalArrivalTime: 12 Apr 2011 14:50:55.0894 (UTC) FILETIME=[071F9B60:01CBF921] Cc: mpls@ietf.org, "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:51:01 -0000 That is correct! -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Tuesday, April 12, 2011 5:20 PM To: David Allan I Cc: mpls@ietf.org; Schink, Helmut (NSN - DE/Munich); David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI Dave, Raw BFD encapsulation over G-ACh has been already defined in RFC 5885. GAL does not really add anything to this encapsulation IMO, simply allows to use G-ACh on top of LSPs and not just PWs. Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Tuesday, April 12, 2011 5:17 PM > To: curtis@occnc.com > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich) > Subject: Re: [mpls] MPLS-TP CC-CV-RDI >=20 > Agreed, but that would require redesigning BFD. The other alternative > would be to use the version number. >=20 > As we had a simultaneous change of encapsultion with the GAL/G-ACh as > well as the need for additional features, the code point seemed to make > sense. >=20 > Thanks > Dave >=20 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Monday, April 11, 2011 8:28 PM > To: David Allan I > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; > Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > Subject: Re: [mpls] MPLS-TP CC-CV-RDI >=20 >=20 > In message > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson > .se> > David Allan I writes: > > > > Hi Nurit > > > > It is backwards compatible in the sense that the new code points > allow > > the additional behaviors specified for MPLS TP to be disambiguated > > from existing RFC 5884/5 behaviors > > > > - this is the addition of the GAL, the source MEP TLV, > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > inputs as valid state machine inputs. > > > > It is not perfectly backwards compatible in that the addition of the > > GAL and new code points means deployed implementations will not > > support the new encap and TLV without an upgrade .... RFC 5885 is > > close but not an exact match due to the addition of the Source MEP ID > > TLV. Some implementation tweaks are required. >=20 > The usual way to handle an extension to an existing protocol is to use > a capability negotiation, not assign a new code point. >=20 > > hope this helps > > Dave > > > > ________________________________ > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > [mailto:nurit.sprecher@nsn.com] > > Sent: Monday, April 11, 2011 9:51 AM > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, > > Helmut (NSN - DE/Munich) > > Subject: MPLS-TP CC-CV-RDI > > > > Dear authors, > > > > Slide 14 of the attached, says that "This document an enhancement to > > RFC 5884/5885....But it still requires two new code points as it will > > not be perfectly backwards compatible...." > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > It is my understanding that the extension done to BFD is completely > > compatible with BFD. > > Can you please clarify this point? Is the solution being defined in > > draft cc-cv-rdi is compatible with BFD? > > Is it also possible for CC-CV-RDI and existing BFD to be compatible > > today given only the proper configuration? > > Best regards, > > Nurit > _______________________________________________ > 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 david.i.allan@ericsson.com Tue Apr 12 08:08:07 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 010F5E0705 for ; Tue, 12 Apr 2011 08:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.956 X-Spam-Level: X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[AWL=1.643, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hVifoSuaUGI for ; Tue, 12 Apr 2011 08:08:05 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id C976BE07DA for ; Tue, 12 Apr 2011 08:08:05 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3CF820X017782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Apr 2011 10:08:03 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 12 Apr 2011 11:08:02 -0400 From: David Allan I To: Alexander Vainshtein Date: Tue, 12 Apr 2011 11:08:00 -0400 Thread-Topic: [mpls] MPLS-TP CC-CV-RDI Thread-Index: Acv4wZ4e5uohAEM9SYK+veD0+8TCYAAWljAQAAAcDZAAABvNEAAAMFPQAAErXMA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD51D548E564@EUSAACMS0703.eamcs.ericsson.se> References: Your message of "Mon, 11 Apr 2011 18:08:16 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:08:07 -0000 We had a bunch of motivations in simplifiying it to one tool. 1) Less configuration as there would be fewer modes of operation. 2) CC by itself is of limited utility and compromises the rest of the netwo= rk if CV functionality is desired. A CC monitored LSP can leak into another= LSP undetected. IMO calling CC out as a separate requirement has only been= a source of confusion. Feedback was that running CV ALL the time was considered onerous, so we wen= t with the interleaved solution to reduce the processing load while still p= roviding complete fault coverage in the network. We did set a minimum CV ra= te so that there could be an exit criteria from a mis-connectivity fault. Running an extra session so that CC and CV were distinct sessions would be = a possible solution, and would have the desirable trait of self identifying= the CV periodicity as well as the CC periodicity, but would impact scaling= as it would be an extra session. At least that was the thinking... Dave -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Tuesday, April 12, 2011 7:39 AM To: David Allan I Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); curtis@occ= nc.com Subject: RE: [mpls] MPLS-TP CC-CV-RDI Dave, Lots of thanks for a prompt solution. The question that comes to my mind is: do we really want to put all the too= ls in the same bag? Vanilla 5885 implementation will provide the required CC/RDI functionality = without any changes. Is this correct?=20 If you want to add proactive CV to that you have several options: 1. Run an additional "slow" CV-only BFD session using a new code point (no = interleave).=20 2. Combine CC/RDI and CV into a single session with interleave and bear the= price of increased implementation complexity There are probably other practical options for CV. E.g., one could use the = simple password authentication option and use Source MEP ID as the password= . Persistent misconnection could be detected as loss of connectivity, but o= nce it happens, it would be (hopefully) pretty simple to define the underly= ing reason... (Not sure the security people would approve:-) Insisting on one size to fit all (CC/RDI and proactive CV) seems not practi= cal to me. We may provide a solution for that, but should we really require= from everybody to stick with this complicated combined solution? Regards, Sasha > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Tuesday, April 12, 2011 5:26 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich);=20 > curtis@occnc.com > Subject: RE: [mpls] MPLS-TP CC-CV-RDI >=20 > There is a few semantic differences over 5885 unique to MPLS-TP.... >=20 > 1) Interleave of CC and CV. > 2) The additional mis-connectivity logic implied by CV > 3) The additional transactions in TP-FAULT are valid inputs. >=20 > And a couple of other things meant that BFD for TP could not be=20 > supported by a vanilla 5885 implementation. >=20 > Hope this helps > Dave >=20 >=20 >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, April 12, 2011 7:20 AM > To: David Allan I > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich);=20 > curtis@occnc.com > Subject: RE: [mpls] MPLS-TP CC-CV-RDI >=20 > Dave, > Raw BFD encapsulation over G-ACh has been already defined in RFC 5885. > GAL does not really add anything to this encapsulation IMO, simply=20 > allows to use G-ACh on top of LSPs and not just PWs. >=20 >=20 > Regards, > Sasha >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > > Of David Allan I > > Sent: Tuesday, April 12, 2011 5:17 PM > > To: curtis@occnc.com > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich) > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > Agreed, but that would require redesigning BFD. The other=20 > > alternative would be to use the version number. > > > > As we had a simultaneous change of encapsultion with the GAL/G-ACh=20 > > as well as the need for additional features, the code point seemed=20 > > to make sense. > > > > Thanks > > Dave > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Monday, April 11, 2011 8:28 PM > > To: David Allan I > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E > Drake; > > Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > > > In message > > > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsso > > n > > .se> > > David Allan I writes: > > > > > > Hi Nurit > > > > > > It is backwards compatible in the sense that the new code points > > allow > > > the additional behaviors specified for MPLS TP to be=20 > > > disambiguated from existing RFC 5884/5 behaviors > > > > > > - this is the addition of the GAL, the source MEP TLV, > > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > > inputs as valid state machine inputs. > > > > > > It is not perfectly backwards compatible in that the addition of > the > > > GAL and new code points means deployed implementations will not=20 > > > support the new encap and TLV without an upgrade .... RFC 5885 is=20 > > > close but not an exact match due to the addition of the Source MEP=20 > > > ID TLV. Some implementation tweaks are required. > > > > The usual way to handle an extension to an existing protocol is to > use > > a capability negotiation, not assign a new code point. > > > > > hope this helps > > > Dave > > > > > > ________________________________ > > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)=20 > > > [mailto:nurit.sprecher@nsn.com] > > > Sent: Monday, April 11, 2011 9:51 AM > > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org;=20 > > > Schink, Helmut (NSN - DE/Munich) > > > Subject: MPLS-TP CC-CV-RDI > > > > > > Dear authors, > > > > > > Slide 14 of the attached, says that "This document an enhancement > to > > > RFC 5884/5885....But it still requires two new code points as it=20 > > > will not be perfectly backwards compatible...." > > > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > > It is my understanding that the extension done to BFD is=20 > > > completely compatible with BFD. > > > Can you please clarify this point? Is the solution being defined=20 > > > in draft cc-cv-rdi is compatible with BFD? > > > Is it also possible for CC-CV-RDI and existing BFD to be=20 > > > compatible today given only the proper configuration? > > > Best regards, > > > Nurit > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From Internet-Drafts@ietf.org Tue Apr 12 08:15:03 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25E20E079A; Tue, 12 Apr 2011 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJpeMm+C2CAD; Tue, 12 Apr 2011 08:15:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 40A29E0811; Tue, 12 Apr 2011 08:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110412151502.12196.90674.idtracker@ietfc.amsl.com> Date: Tue, 12 Apr 2011 08:15:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-rsvp-te-no-php-oob-mapping-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:15:03 -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 : Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs Author(s) : Z. Ali, G. Swallow Filename : draft-ietf-mpls-rsvp-te-no-php-oob-mapping-06.txt Pages : 9 Date : 2011-04-12 There are many deployment scenarios which require Egress Label Switching Router (LSR) to receive binding of the Resource ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched Path (LSP) to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document proposes protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-no-php-oob-mapping-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-rsvp-te-no-php-oob-mapping-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-12081010.I-D@ietf.org> --NextPart-- From Alexander.Vainshtein@ecitele.com Tue Apr 12 09:20:14 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A668AE083E for ; Tue, 12 Apr 2011 09:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzBnyzSR3uYF for ; Tue, 12 Apr 2011 09:20:13 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id 07BB1E07E9 for ; Tue, 12 Apr 2011 09:20:12 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-0a-4da47b58a9a9 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id E1.38.02691.85B74AD4; Tue, 12 Apr 2011 19:18:32 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 12 Apr 2011 19:20:11 +0300 From: Alexander Vainshtein To: David Allan I Date: Tue, 12 Apr 2011 19:20:10 +0300 Thread-Topic: [mpls] MPLS-TP CC-CV-RDI Thread-Index: Acv4wZ4e5uohAEM9SYK+veD0+8TCYAAWljAQAAAcDZAAABvNEAAAMFPQAAErXMAAAnK2YA== Message-ID: References: Your message of "Mon, 11 Apr 2011 18:08:16 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51D548E564@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51D548E564@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 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUy+dWnL7oR1Ut8DXY0ClocPjCd3eLh+e3M Fkf/drBYLLr3l9Hi1tKVrA6sHr++XmXzWLLkJ5PH9aar7B4/1wOJxV/8AlijGhhtEvPy8ksS S1IVUlKLk22VAooyyxKTK5UUMlNslQyVFApyEpNTc1PzSmyVEgsKUvNSlOy4FDCADVBZZp5C al5yfkpmXrqtkmewv66FhamlrqGSnZqyobE1V0hGZrFCqm5uYmaOQm5qcXFieqoCUCRhC3PG ihVGBetcKm6/PcfYwHjItIuRk0NCwERiasc8VghbTOLCvfVsXYxcHEICOxklFnYvZYRwpjBK PNizhx2kik3AVmLT6rtsILaIgJ7Emou/WUGKmAVWMUq8fvqBBSTBIqAqMfdxN1iRMJB99tt0 RogGNYme3YtZIOwwiZ7DJ5lBbF4Bf4lfN/5BbdvJIjFx/RSgqRwcnAIREjuX24PUMAKd9/3U GiYQm1lAXOLWk/lMEGcLSCzZc54ZwhaVePn4HytEvajEnfb1jBD1OhILdn9ig7C1JZYtfA21 V1Di5MwnLBC9khIHV9xgmcAoPgvJillI2mchaZ+FpH0BI8sqRtHMnIKSpNx0AyO91OTMktSc VL3k/NxNjJAU9GIH4+0zmocYLYBhM5FZijs5H5jC8krijQ0MUDhK4rzvEpb4CgmkA9NKdmpq QWpRfFFpTmrxIUYmDk6pBkZ+vv4J3CFLC4z8nPazpnZ3eAVzfdQtYPjSlM7GfTBE+6TVQ+mU Xsl7k/Z/WRxz+u7R3ZUJy2fXuZnGGXHmf42q58u+WLaTWfxQ5sTLUbPtTx++Mv3h0kML8xat Xv9ujoqUxbm5c/hyjrz31JZ/V3mN8aLf7k2/Xgd5LJ948qEhp0jPCyfFOGslluKMREMt5qLi RAD27Qk3LAMAAA== Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 16:20:14 -0000 Dave, Lots of thanks for a prompt response and sharing your motivation. Please see a couple of comments inline below. Regards, Sasha > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Tuesday, April 12, 2011 6:08 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); > curtis@occnc.com > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > We had a bunch of motivations in simplifiying it to one tool. > > 1) Less configuration as there would be fewer modes of operation. [[[Sasha]] I suspect that carrying CC and CV in the same session would effe= ctively result in approximately the amount of configuration - at least, as long as you do not want to config= ure the BFD discriminators (vanilla BFD does not require that). > 2) CC by itself is of limited utility and compromises the rest of the > network if CV functionality is desired. [[[Sasha]]] Is it always desired? Or is it an option? > A CC monitored LSP can leak into another LSP undetected. [[[Sasha]]] IMO you can use one of the BFD authentication mechanisms to prev= ent these effects. Note also that with interleaved CC and CV only semi-permanent leakage would= be detected. > IMO calling CC out as a separate requirement has only been a source of con= fusion. > > Feedback was that running CV ALL the time was considered onerous, so we > went with the interleaved solution to reduce the processing load while > still providing complete fault coverage in the network. We did set a > minimum CV rate so that there could be an exit criteria from a mis- > connectivity fault. > > Running an extra session so that CC and CV were distinct sessions would > be a possible solution, and would have the desirable trait of self > identifying the CV periodicity as well as the CC periodicity, but would > impact scaling as it would be an extra session. > [[[Sasha]]] Only if all LSPs require CV all the time... > At least that was the thinking... > Dave > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, April 12, 2011 7:39 AM > To: David Allan I > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); > curtis@occnc.com > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > Dave, > Lots of thanks for a prompt solution. > > The question that comes to my mind is: do we really want to put all the > tools in the same bag? > > Vanilla 5885 implementation will provide the required CC/RDI > functionality without any changes. > Is this correct? > > If you want to add proactive CV to that you have several options: > > 1. Run an additional "slow" CV-only BFD session using a new code point > (no interleave). > 2. Combine CC/RDI and CV into a single session with interleave and bear > the price of increased implementation complexity > > There are probably other practical options for CV. E.g., one could use > the simple password authentication option and use Source MEP ID as the > password. Persistent misconnection could be detected as loss of > connectivity, but once it happens, it would be (hopefully) pretty > simple to define the underlying reason... (Not sure the security people > would approve:-) > > Insisting on one size to fit all (CC/RDI and proactive CV) seems not > practical to me. We may provide a solution for that, but should we > really require from everybody to stick with this complicated combined > solution? > > Regards, > Sasha > > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > Sent: Tuesday, April 12, 2011 5:26 PM > > To: Alexander Vainshtein > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); > > curtis@occnc.com > > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > > > There is a few semantic differences over 5885 unique to MPLS-TP.... > > > > 1) Interleave of CC and CV. > > 2) The additional mis-connectivity logic implied by CV > > 3) The additional transactions in TP-FAULT are valid inputs. > > > > And a couple of other things meant that BFD for TP could not be > > supported by a vanilla 5885 implementation. > > > > Hope this helps > > Dave > > > > > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Tuesday, April 12, 2011 7:20 AM > > To: David Allan I > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); > > curtis@occnc.com > > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > > > Dave, > > Raw BFD encapsulation over G-ACh has been already defined in RFC > 5885. > > GAL does not really add anything to this encapsulation IMO, simply > > allows to use G-ACh on top of LSPs and not just PWs. > > > > > > Regards, > > Sasha > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of David Allan I > > > Sent: Tuesday, April 12, 2011 5:17 PM > > > To: curtis@occnc.com > > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich) > > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > > > Agreed, but that would require redesigning BFD. The other > > > alternative would be to use the version number. > > > > > > As we had a simultaneous change of encapsultion with the GAL/G-ACh > > > as well as the need for additional features, the code point seemed > > > to make sense. > > > > > > Thanks > > > Dave > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Monday, April 11, 2011 8:28 PM > > > To: David Allan I > > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E > > Drake; > > > Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > > > > > > In message > > > > > > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsso > > > n > > > .se> > > > David Allan I writes: > > > > > > > > Hi Nurit > > > > > > > > It is backwards compatible in the sense that the new code points > > > allow > > > > the additional behaviors specified for MPLS TP to be > > > > disambiguated from existing RFC 5884/5 behaviors > > > > > > > > - this is the addition of the GAL, the source MEP TLV, > > > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > > > inputs as valid state machine inputs. > > > > > > > > It is not perfectly backwards compatible in that the addition of > > the > > > > GAL and new code points means deployed implementations will not > > > > support the new encap and TLV without an upgrade .... RFC 5885 is > > > > close but not an exact match due to the addition of the Source > MEP > > > > ID TLV. Some implementation tweaks are required. > > > > > > The usual way to handle an extension to an existing protocol is to > > use > > > a capability negotiation, not assign a new code point. > > > > > > > hope this helps > > > > Dave > > > > > > > > ________________________________ > > > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > > > [mailto:nurit.sprecher@nsn.com] > > > > Sent: Monday, April 11, 2011 9:51 AM > > > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; > > > > Schink, Helmut (NSN - DE/Munich) > > > > Subject: MPLS-TP CC-CV-RDI > > > > > > > > Dear authors, > > > > > > > > Slide 14 of the attached, says that "This document an enhancement > > to > > > > RFC 5884/5885....But it still requires two new code points as it > > > > will not be perfectly backwards compatible...." > > > > > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > > > It is my understanding that the extension done to BFD is > > > > completely compatible with BFD. > > > > Can you please clarify this point? Is the solution being defined > > > > in draft cc-cv-rdi is compatible with BFD? > > > > Is it also possible for CC-CV-RDI and existing BFD to be > > > > compatible today given only the proper configuration? > > > > Best regards, > > > > Nurit > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From david.i.allan@ericsson.com Tue Apr 12 09:39:26 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 077D4E07DE for ; Tue, 12 Apr 2011 09:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.139 X-Spam-Level: X-Spam-Status: No, score=-5.139 tagged_above=-999 required=5 tests=[AWL=1.460, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTtrakGzpDV9 for ; Tue, 12 Apr 2011 09:39:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id C985BE07A5 for ; Tue, 12 Apr 2011 09:39:24 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3CGdIQR018288; Tue, 12 Apr 2011 11:39:22 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 12 Apr 2011 12:39:14 -0400 From: David Allan I To: Alexander Vainshtein Date: Tue, 12 Apr 2011 12:39:13 -0400 Thread-Topic: [mpls] MPLS-TP CC-CV-RDI Thread-Index: Acv4wZ4e5uohAEM9SYK+veD0+8TCYAAWljAQAAAcDZAAABvNEAAAMFPQAAErXMAAAnK2YAAAwK0g Message-ID: <60C093A41B5E45409A19D42CF7786DFD51D548E65F@EUSAACMS0703.eamcs.ericsson.se> References: Your message of "Mon, 11 Apr 2011 18:08:16 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51D548E564@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 16:39:26 -0000 HI Sasha: =20 > We had a bunch of motivations in simplifiying it to one tool. >=20 > 1) Less configuration as there would be fewer modes of operation. [[[Sasha]] I suspect that carrying CC and CV in the same session would eff= ectively result in approximately the amount of configuration - at least, as= long as you do not want to configure the BFD discriminators (vanilla BFD d= oes not require that). [Dave: We're adding a configuration section to the draft as a result of las= t comments, combining the tools and setting explicit defatuls does reduce t= he number of knobs.] > 2) CC by itself is of limited utility and compromises the rest of the=20 > network if CV functionality is desired. [[[Sasha]]] Is it always desired? Or is it an option? [Dave: I'm not sure why one would expend the heat of using CC alone when pr= ocessing the occasional information token is far more robust] > A CC monitored LSP can leak into another LSP undetected.=20 [[[Sasha]]] IMO you can use one of the BFD authentication mechanisms to pre= vent these effects. Note also that with interleaved CC and CV only semi-permanent leakage would= be detected. [Dave: True, but very intermittent leakage is problematic anyway as the def= ect condition would flap, and the leak needs to correspond to the axchange = of a CV PDU. And I have trouble envisioning a fault that was not a hard tra= sh of the LIB, and had the characteristics of only leaking into one other L= SP sproadically. Use of the authentication techniques was a possibility, but then that would= require the administration of a whole other class of identifiers/tokens, h= ence would be operationally undesirable] > IMO calling CC out as a separate requirement has only been a source of co= nfusion. >=20 > Feedback was that running CV ALL the time was considered onerous, so=20 > we went with the interleaved solution to reduce the processing load=20 > while still providing complete fault coverage in the network. We did=20 > set a minimum CV rate so that there could be an exit criteria from a=20 > mis- connectivity fault. >=20 > Running an extra session so that CC and CV were distinct sessions=20 > would be a possible solution, and would have the desirable trait of=20 > self identifying the CV periodicity as well as the CC periodicity, but=20 > would impact scaling as it would be an extra session. >=20 [[[Sasha]]] Only if all LSPs require CV all the time...=20 [Dave: Hence the interleave to minimize the penalty... Cheers D] From fjjc@tid.es Tue Apr 12 10:02:48 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AECD7E086C for ; Tue, 12 Apr 2011 10:02:48 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdqJORC1fGr7 for ; Tue, 12 Apr 2011 10:02:47 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfc.amsl.com (Postfix) with ESMTP id 57C19E086D for ; Tue, 12 Apr 2011 10:02:47 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJJ00KV1U0J07@tid.hi.inet> for mpls@ietf.org; Tue, 12 Apr 2011 19:02:43 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 04.DB.02936.EDE74AD4; Tue, 12 Apr 2011 18:33:34 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LJJ00005U0JQ3@tid.hi.inet> for mpls@ietf.org; Tue, 12 Apr 2011 19:02:43 +0200 (MEST) Received: from [10.95.50.27] (10.95.67.43) by htcasmad1.hi.inet (10.95.67.73) with Microsoft SMTP Server id 8.3.83.0; Tue, 12 Apr 2011 19:02:43 +0200 Date: Tue, 12 Apr 2011 19:02:41 +0200 From: Javier Jimenez In-reply-to: <580BEA5E3B99744AB1F5BFF5E9A3C67D0184E73823@HE111648.emea1.cds.t-internal.com> To: "Thomas.Beckhaus@telekom.de" Message-id: <4DA485B1.5050008@tid.es> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 X-AuditID: 0a5f4068-b7c9eae000000b78-86-4da47eded527 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsXCFe/ApXuvbomvQfsiWYtbS1eyOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+Ka38wF240rVi35wdrAeEWzi5GDQ0hASuLUx9IuRk4OCQET ieWfHzBC2GISF+6tZwOxhQQ2Mkp8/sXSxcgFZP9glDj2ZgI7hDOdUaLl72uwDhYBVYlve44y g9hsAkoSjxpvsoLYwgJ6EqtedrOCLOMUiJXobgIrERGwlZgz7QZYCbNAnkTv+h1gy3iBxpzd t4oRwhaU+DH5HgtEjbXEqW8rmSFsbYkn7y6AjRQVyJFo+a4NcWc7k8S816kTGIVmIemehaR7 FpLuBYzMqxjFipOKMtMzSnITM3PSDQz1MjL1MvNSSzYxQgI2Ywfj8p0qhxgFOBiVeHgLxBf7 CrEmlhVX5h5ilORgUhLlbWpZ4ivEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPdEFVCONyWxsiq1 KB8mJcPBoSTB+wOkTbAoNT21Ii0zBxiXMGkmDk6Qdh6g9kaQGt7igsTc4sx0iPwpRkkpcV6+ VqCEAEgiozQPrvcVozjQkcK8b0HaeIAJBK7rFdBAJqCBUTFgA0sSEVJSDYwHI1bab448E7j7 /MWDWqc/ZK7fZqm6aX3H6dMStQ/uOK/gna3t2MasYahq7vrn9GJOhnd5if9SDHZ3aNhs64n4 Men0jc8pz4ILavUEGn/4vn9TedolV/xIkMgt8bUWYSo3tAW7HnL5mpgtu9ux8evpA5Zbq2Wt K6vDf+9gPJL32vMB7ys5gy9KLMUZiYZazEXFiQAmN0j33QIAAA== References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> <4D95D999.604@tid.es> <14C7F4F06DB5814AB0DE29716C4F6D67182EA529@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0184E73823@HE111648.emea1.cds.t-internal.com> Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions on seamless MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 17:02:48 -0000 Hi Thomas, Wim, Thanks for your responses. Some additional thoughts: WH> when you perform NH self you will install a LBL entry for every LBL pr= efix and would result in a bigger LFIB. Right, but that only makes a difference if a small set of inter-domain LSPs is expected (which may be true). As this number grows, the difference in scalability will eventually dissapear, right? Anyway, it might be interesting for operators that are already running metro MPLS networks to keep separated IGP / LDP instances in different domains. In this case either we allow next hop self in both directions or we need to redistribute routes among IGPs, etc. If the intention is to make a generalistic recommendation, wouldn't it make sense to show the different options and then leave the final decision to the operator? On the other side, after reading the draft, I'm not sure why it is claimed that only those labels needed to support the actual services in place need to be installed in the AGN nodes. Is this the default behaviour? I would assume that all the labels distributed in BGP would be installed in all the AGNs automatically, but I may be wrong. I'm not sure it is explained in the text why this happens. I agree with the fact that VPLS is an orthogonal problem, but I noticed that is was not mentioned in the draft (while point to point business services are indeed) and I was wondering if it was intentional. Otherwise, I would include this service as part of the reference scenarios, so that any potential implication may arise more easily. Finally, and regarding the OAM, the question is: does the seamless MPLS architecture consider MPLS-TP OAM to any extent? If so, it should be stated in the text. Kind regards, Javier El 03/04/2011 21:36, Thomas.Beckhaus@telekom.de escribi=F3: > Javier, > > see in line (TB) > > Thomas > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Henderickx, Wim (Wim) >> Sent: Saturday, April 02, 2011 1:06 PM >> To: Javier Jimenez >> Cc: mpls@ietf.org >> Subject: Re: [mpls] Questions on seamless MPLS >> >> In-line >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Javier Jimenez >> Sent: vrijdag 1 april 2011 15:57 >> Cc: mpls@ietf.org >> Subject: [mpls] Questions on seamless MPLS >> >> Hi all, >> >> Here in Telef=F3nica we are pushing for MPLS E2E solutions, and it seems >> the seamless MPLS draft respresents a great starting point. >> Congratulations to the authors for this nice piece of work. >> >> I have two questions, not being involved in the draft so far: >> 1.- The draft proposes to use the next-hop-self in the outwards >> direction (with respect to an specific regional area) and to leave >> next-hop-unchanged for the incoming traffic. This approach >> requires that >> some routing information is flooded from the core area to the regional >> ones (specificallly, reachability to the ABRs). I'm sure this design >> increases the scalability of the solution, but two concerns >> come to my mind: >> - Wouldn't it be cleaner to perform the next-hop-self in both >> directions? I come from the transport world, where things tend to be >> symetrical (and easier to understand for humans). >> >> WH> when you perform NH self you will install a LBL entry for >> every LBL prefix and would result in a bigger LFIB. >> >> - More specifically, when migrating to a seamless architecture, it may >> be the case that the IGPs are already different in the core and in the >> regions (also the label distribution protocols), and it could not be >> possible to flood external IGP information into the regional areas or >> the operator would prefer to keep IGP clear from external >> influece (for >> that reason you have BGP). >> In summary, would there be room for two options (and which >> are the pros >> & cons) or just the one recommended in the draft? >> >> WH> the reason of the current architecture is due to >> scalability as outlined above >> >> > TB> we had exaclty this discussion regarding a next hop self (NHS) for i= ncomming traffic. In an single IGP scenario, the NHS is not required (in ou= r discussion, symmetry was also a topic - but we are neigher physicists nor= transport people). So we decided to avoid it because of scalability reason= s as Wim explained. But there are certain scenarios, where a NHS for incomm= ing traffic is preferred or required. > > >> 2.- Right now, VPLS services are typically offered only on a regional >> basis due to scalability issues. How would a VPLS service scale on top >> of a seamless MPLS architecture? Is this requirement part of the >> architecture or has been intentionally removed? >> >> WH> VPLS scale is orthogonal of the seamless MPLS >> architecture and it depends on the MAC@, replication/P2MP LSP >> architecture, end-points, use of H-VPLS, etc. Seamless MPLS >> is not changing these parameters for VPLS services, VPLS will >> just use the seamless MPLS architecture >> > TB> With the Seamless-MPLS approach, we consider different VPLS scenario= s: H-VPLS, flat VPLS or also a combination of PW based backhaul to a VSI on= a central PE (section 10.1.3 of rfc4762). This does not fix the scalabilit= y problem of Ethernet, but provide some possible solutions (e.g. easy backh= auling to a high scaling PE). > > >> Kind regards, >> Javier Jimenez >> Telef=F3nica Research >> >> Este mensaje se dirige exclusivamente a su destinatario. >> Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de >> correo electr=F3nico en el enlace situado m=E1s abajo. >> This message is intended exclusively for its addressee. We >> only send and receive email on the basis of the terms set out at. >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> _______________________________________________ >> 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 >> >> > . > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From gregimirsky@gmail.com Tue Apr 12 10:28:07 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B1D0E0881 for ; Tue, 12 Apr 2011 10:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u25ZeZoky4uo for ; Tue, 12 Apr 2011 10:28:05 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 48153E087E for ; Tue, 12 Apr 2011 10:28:05 -0700 (PDT) Received: by vws12 with SMTP id 12so6529684vws.31 for ; Tue, 12 Apr 2011 10:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H3q/ZhSXWQ+QqL8lzcg3lslgGNI1nSgVOatyvT4q7lk=; b=gbtrBTSbGYwAOl3h0omye0TMciULDBWakyLgCa+e5tD/y2FP8clek8AtbjTlfzp7gr 5NHgwZpkS8iD8lPYbLqWyhKUzCGenldUsBhXkWICiraHEJaXxuBhCJ+NFwkGMea8bq6p z1MOfIj5fOSMKGsXBAosKJnXfWRO0ahgQs8qw= 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=KSIYB0fPZ/fDipj/Z7kJ+s5LvaglkgMn5xvWMgr5cwrZCuiUc0GB0D7FqNIOy8kT7N MFHGr87GLWt+noDOHmuwqJYUWo04oWHj/gU9EGDsP1PD9fDxAVL2/4eiLNx5V8WDEv++ LH4xpGrYxsYEICoRvXZD2El2QgJp1Pcuwre3Q= MIME-Version: 1.0 Received: by 10.52.95.15 with SMTP id dg15mr1519322vdb.228.1302629284656; Tue, 12 Apr 2011 10:28:04 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Tue, 12 Apr 2011 10:28:04 -0700 (PDT) In-Reply-To: References: <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> <201104120327.p3C3Rp0Q023230@harbor.orleans.occnc.com> <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 12 Apr 2011 10:28:04 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=20cf307f32e4c9373e04a0bc0362 Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 17:28:07 -0000 --20cf307f32e4c9373e04a0bc0362 Content-Type: text/plain; charset=ISO-8859-1 Dear Sasha, thank you for the great comparative analysis of RFC 5885 and draft-ietf-mpls-tp-cc-cv-rdi. I have couple notes: - when refer to RFC 5885 are we imply use of GAL/G-ACh encapsulation with procedures described in RFC 5884? - RFC 5885 does not address independent mode introduced for bi-directional associated p2p LSP. - the scope of draft-ietf-mpls-tp-cc-cv-rdi is limited to bi-directional p2p LSPs, section and PWs. It is my understanding that at some point we'll address CC/CV monitoring over unidirectional p2p and p2mp LSP. It might be easier to expand OAM by using the draft rather then generalized BFD mechanism. Regards, Greg On Tue, Apr 12, 2011 at 7:39 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Dave, > Lots of thanks for a prompt solution. > > The question that comes to my mind is: do we really want to put all the > tools in the same bag? > > Vanilla 5885 implementation will provide the required CC/RDI functionality > without any changes. > Is this correct? > > If you want to add proactive CV to that you have several options: > > 1. Run an additional "slow" CV-only BFD session using a new code point (no > interleave). > 2. Combine CC/RDI and CV into a single session with interleave and bear the > price of increased implementation complexity > > There are probably other practical options for CV. E.g., one could use the > simple password authentication option and use Source MEP ID as the password. > Persistent misconnection could be detected as loss of connectivity, but once > it happens, it would be (hopefully) pretty simple to define the underlying > reason... (Not sure the security people would approve:-) > > Insisting on one size to fit all (CC/RDI and proactive CV) seems not > practical to me. We may provide a solution for that, but should we really > require from everybody to stick with this complicated combined solution? > > Regards, > Sasha > > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > Sent: Tuesday, April 12, 2011 5:26 PM > > To: Alexander Vainshtein > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); > > curtis@occnc.com > > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > > > There is a few semantic differences over 5885 unique to MPLS-TP.... > > > > 1) Interleave of CC and CV. > > 2) The additional mis-connectivity logic implied by CV > > 3) The additional transactions in TP-FAULT are valid inputs. > > > > And a couple of other things meant that BFD for TP could not be > > supported by a vanilla 5885 implementation. > > > > Hope this helps > > Dave > > > > > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Tuesday, April 12, 2011 7:20 AM > > To: David Allan I > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); > > curtis@occnc.com > > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > > > Dave, > > Raw BFD encapsulation over G-ACh has been already defined in RFC 5885. > > GAL does not really add anything to this encapsulation IMO, simply > > allows to use G-ACh on top of LSPs and not just PWs. > > > > > > Regards, > > Sasha > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > > Of David Allan I > > > Sent: Tuesday, April 12, 2011 5:17 PM > > > To: curtis@occnc.com > > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich) > > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > > > Agreed, but that would require redesigning BFD. The other alternative > > > would be to use the version number. > > > > > > As we had a simultaneous change of encapsultion with the GAL/G-ACh as > > > well as the need for additional features, the code point seemed to > > > make sense. > > > > > > Thanks > > > Dave > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Monday, April 11, 2011 8:28 PM > > > To: David Allan I > > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E > > Drake; > > > Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > > > > > > In message > > > > > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsso > > > n > > > .se> > > > David Allan I writes: > > > > > > > > Hi Nurit > > > > > > > > It is backwards compatible in the sense that the new code points > > > allow > > > > the additional behaviors specified for MPLS TP to be disambiguated > > > > from existing RFC 5884/5 behaviors > > > > > > > > - this is the addition of the GAL, the source MEP TLV, > > > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > > > inputs as valid state machine inputs. > > > > > > > > It is not perfectly backwards compatible in that the addition of > > the > > > > GAL and new code points means deployed implementations will not > > > > support the new encap and TLV without an upgrade .... RFC 5885 is > > > > close but not an exact match due to the addition of the Source MEP > > > > ID TLV. Some implementation tweaks are required. > > > > > > The usual way to handle an extension to an existing protocol is to > > use > > > a capability negotiation, not assign a new code point. > > > > > > > hope this helps > > > > Dave > > > > > > > > ________________________________ > > > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > > > [mailto:nurit.sprecher@nsn.com] > > > > Sent: Monday, April 11, 2011 9:51 AM > > > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, > > > > Helmut (NSN - DE/Munich) > > > > Subject: MPLS-TP CC-CV-RDI > > > > > > > > Dear authors, > > > > > > > > Slide 14 of the attached, says that "This document an enhancement > > to > > > > RFC 5884/5885....But it still requires two new code points as it > > > > will not be perfectly backwards compatible...." > > > > > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > > > It is my understanding that the extension done to BFD is completely > > > > compatible with BFD. > > > > Can you please clarify this point? Is the solution being defined in > > > > draft cc-cv-rdi is compatible with BFD? > > > > Is it also possible for CC-CV-RDI and existing BFD to be compatible > > > > today given only the proper configuration? > > > > Best regards, > > > > Nurit > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf307f32e4c9373e04a0bc0362 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sasha,
    thank you for the great comparative analysis of RFC 5885 and= draft-ietf-mpls-tp-cc-cv-rdi. I have couple notes:
    • when refer t= o RFC 5885 are we imply use of GAL/G-ACh encapsulation with procedures desc= ribed in RFC 5884?
    • RFC 5885 does not address independent mode introduced for bi-directiona= l associated p2p LSP.
    • the scope of draft-ietf-mpls-tp-cc-cv-rdi= is limited to bi-directional p2p LSPs, section and PWs. It is my understan= ding that at some point we'll address CC/CV monitoring over unidirectio= nal p2p and p2mp LSP. It might be easier to expand OAM by using the draft r= ather then generalized BFD mechanism.
    Regards,
    Greg

    On Tue, Apr 12, 201= 1 at 7:39 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com><= /span> wrote:
    Dave,
    Lots of thanks for a prompt solution.

    The question that comes to my mind is: do we really want to put all the too= ls in the same bag?

    Vanilla 5885 implementation will provide the required CC/RDI functionality = without any changes.
    Is this correct?

    If you want to add proactive CV to that you have several options:

    1. Run an additional "slow" CV-only BFD session using a new code = point (no interleave).
    2. Combine CC/RDI and CV into a single session with interleave and bear the= price of increased implementation complexity

    There are probably other practical options for CV. E.g., one could use the = simple password authentication option and use Source MEP ID as the password= . Persistent misconnection could be detected as loss of connectivity, but o= nce it happens, it would be (hopefully) pretty simple to define the underly= ing reason... (Not sure the security people would approve:-)

    Insisting on one size to fit all (CC/RDI and proactive CV) seems not practi= cal to me. We may provide a solution for that, but should we really require= from =A0everybody to stick with this complicated combined solution?

    Regards,
    =A0 =A0 Sasha


    > -----Original Message-----
    > From: David Allan I [mailto:david.i.allan@ericsson.com]
    > Sent: Tuesday, April 12, 2011 5:26 PM
    > To: Alexander Vainshtein
    > Cc: mpls@ietf.org; David Ward; Sc= hink, Helmut (NSN - DE/Munich);
    > curtis@occnc.com
    > Subject: RE: [mpls] MPLS-TP CC-CV-RDI
    >
    > There is a few semantic differences over 5885 unique to MPLS-TP.... >
    > 1) Interleave of CC and CV.
    > 2) The additional mis-connectivity logic implied by CV
    > 3) The additional transactions in TP-FAULT are valid inputs.
    >
    > And a couple of other things meant that BFD for TP could not be
    > supported by a vanilla 5885 implementation.
    >
    > Hope this helps
    > Dave
    >
    >
    >
    > -----Original Message-----
    > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
    > Sent: Tuesday, April 12, 2011 7:20 AM
    > To: David Allan I
    > Cc: mpls@ietf.org; David Ward; Sc= hink, Helmut (NSN - DE/Munich);
    > curtis@occnc.com
    > Subject: RE: [mpls] MPLS-TP CC-CV-RDI
    >
    > Dave,
    > Raw BFD encapsulation over G-ACh has been already defined in RFC 5885.=
    > GAL does not really add anything to this encapsulation IMO, simply
    > allows to use G-ACh on top of LSPs and not just PWs.
    >
    >
    > Regards,
    > =A0 =A0 =A0Sasha
    >
    > > -----Original Message-----
    > > From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.= org] On Behalf
    > > Of David Allan I
    > > Sent: Tuesday, April 12, 2011 5:17 PM
    > > To: curtis@occnc.com
    > > Cc: mpls@ietf.org; David War= d; Schink, Helmut (NSN - DE/Munich)
    > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI
    > >
    > > Agreed, but that would require redesigning BFD. The other alterna= tive
    > > would be to use the version number.
    > >
    > > As we had a simultaneous change of encapsultion with the GAL/G-AC= h as
    > > well as the need for additional features, the code point seemed t= o
    > > make sense.
    > >
    > > Thanks
    > > Dave
    > >
    > > -----Original Message-----
    > > From: curtis@occnc.com [m= ailto:curtis@occnc.com]
    > > Sent: Monday, April 11, 2011 8:28 PM
    > > To: David Allan I
    > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E > Drake;
    > > Nitin Bahadur; mpls@ietf.org= ; Schink, Helmut (NSN - DE/Munich)
    > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI
    > >
    > >
    > > In message
    > >
    > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.eric= sso
    > > n
    > > .se>
    > > David Allan I writes:
    > > >
    > > > Hi Nurit
    > > >
    > > > It is backwards compatible in the sense that the new code po= ints
    > > allow
    > > > the additional =A0behaviors specified for MPLS TP to be disa= mbiguated
    > > > from existing RFC 5884/5 behaviors
    > > >
    > > > =A0 =A0 - this is the addition of the GAL, the source MEP TL= V,
    > > > =A0 =A0 =A0 interleaving of CC and CV PDUs, and accepting th= e TP-FAULT
    > > > =A0 =A0 =A0 inputs as valid state machine inputs.
    > > >
    > > > It is not perfectly backwards compatible in that the additio= n of
    > the
    > > > GAL and new code points means deployed implementations will = not
    > > > support the new encap and TLV without an upgrade .... RFC 58= 85 is
    > > > close but not an exact match due to the addition of the Sour= ce MEP
    > > > ID TLV. Some implementation tweaks are required.
    > >
    > > The usual way to handle an extension to an existing protocol is t= o
    > use
    > > a capability negotiation, not assign a new code point.
    > >
    > > > hope this helps
    > > > Dave
    > > >
    > > > ________________________________
    > > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
    > > > [mailto:nurit.spre= cher@nsn.com]
    > > > Sent: Monday, April 11, 2011 9:51 AM
    > > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink,
    > > > Helmut (NSN - DE/Munich)
    > > > Subject: MPLS-TP CC-CV-RDI
    > > >
    > > > Dear authors,
    > > >
    > > > Slide 14 of the attached, says that "This document an e= nhancement
    > to
    > > > RFC 5884/5885....But it still requires two new code points a= s it
    > > > will not be perfectly backwards compatible...."
    > > >
    > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > > It is my understanding that the extension done to BFD is com= pletely
    > > > compatible with BFD.
    > > > Can you please clarify this point? Is the solution being def= ined in
    > > > draft cc-cv-rdi is compatible with BFD?
    > > > Is it also possible for CC-CV-RDI and existing BFD to be com= patible
    > > > today given only the proper configuration?
    > > > Best regards,
    > > > Nurit
    > > _______________________________________________
    > > mpls mailing list
    > > mpls@ietf.org
    > > https://www.ietf.org/mailman/listinfo/mpls


    This e-mail message is intended for the recipient only and cont= ains information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform us = by e-mail, phone or fax, and then delete the original and all copies thereo= f.

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

    --20cf307f32e4c9373e04a0bc0362-- From curtis@occnc.com Tue Apr 12 13:24:19 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EA8A2E090C for ; Tue, 12 Apr 2011 13:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uJj2gQtYc1n for ; Tue, 12 Apr 2011 13:24:19 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id DA914E0870 for ; Tue, 12 Apr 2011 13:24:18 -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 p3CKOG4O005733; Tue, 12 Apr 2011 16:24:16 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104122024.p3CKOG4O005733@harbor.orleans.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Tue, 12 Apr 2011 10:17:08 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 12 Apr 2011 16:24:16 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , David Ward , "Schink, Helmut \(NSN - DE/Munich\)" Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 12 Apr 2011 20:24:20 -0000 In message <60C093A41B5E45409A19D42CF7786DFD51D548E4AF@EUSAACMS0703.eamcs.ericsson.se> David Allan I writes: > > Agreed, but that would require redesigning BFD. The other alternative > would be to use the version number. The version number seems to make sense. We need to make sure to extend BFD in such a way that we don't throw away capability that exists today. > As we had a simultaneous change of encapsultion with the GAL/G-ACh as > well as the need for additional features, the code point seemed to > make sense. I don't think this is a good idea. It is creating to BFDs. > Thanks > Dave > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Monday, April 11, 2011 8:28 PM > To: David Allan I > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > In message <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsson.se> > David Allan I writes: > > > > Hi Nurit > > > > It is backwards compatible in the sense that the new code points allow > > the additional behaviors specified for MPLS TP to be disambiguated > > from existing RFC 5884/5 behaviors > > > > - this is the addition of the GAL, the source MEP TLV, > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > inputs as valid state machine inputs. > > > > It is not perfectly backwards compatible in that the addition of the > > GAL and new code points means deployed implementations will not > > support the new encap and TLV without an upgrade .... RFC 5885 is > > close but not an exact match due to the addition of the Source MEP ID > > TLV. Some implementation tweaks are required. > > The usual way to handle an extension to an existing protocol is to use a capability negotiation, not assign a new code point. > > > hope this helps > > Dave > > > > ________________________________ > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > [mailto:nurit.sprecher@nsn.com] > > Sent: Monday, April 11, 2011 9:51 AM > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, > > Helmut (NSN - DE/Munich) > > Subject: MPLS-TP CC-CV-RDI > > > > Dear authors, > > > > Slide 14 of the attached, says that "This document an enhancement to > > RFC 5884/5885....But it still requires two new code points as it will > > not be perfectly backwards compatible...." > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > It is my understanding that the extension done to BFD is completely > > compatible with BFD. > > Can you please clarify this point? Is the solution being defined in > > draft cc-cv-rdi is compatible with BFD? > > Is it also possible for CC-CV-RDI and existing BFD to be compatible > > today given only the proper configuration? > > Best regards, > > Nurit From curtis@occnc.com Tue Apr 12 15:35:56 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3039FE093F for ; Tue, 12 Apr 2011 15:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR4n1feGIw3k for ; Tue, 12 Apr 2011 15:35:55 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 16682E091B for ; Tue, 12 Apr 2011 15:35:54 -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 p3CMZmFI065638; Tue, 12 Apr 2011 18:35:48 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104122235.p3CMZmFI065638@harbor.orleans.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Tue, 12 Apr 2011 10:25:40 EDT." <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 12 Apr 2011 18:35:48 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "Schink, Helmut \(NSN - DE/Munich\)" , David Ward Subject: Re: [mpls] MPLS-TP CC-CV-RDI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 12 Apr 2011 22:35:56 -0000 In message <60C093A41B5E45409A19D42CF7786DFD51D548E4C8@EUSAACMS0703.eamcs.ericsson.se> David Allan I writes: > > There is a few semantic differences over 5885 unique to MPLS-TP.... > > 1) Interleave of CC and CV. > 2) The additional mis-connectivity logic implied by CV > 3) The additional transactions in TP-FAULT are valid inputs. > > And a couple of other things meant that BFD for TP could not be > supported by a vanilla 5885 implementation. > > Hope this helps > Dave Sounds like a version update at most. Curtis > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, April 12, 2011 7:20 AM > To: David Allan I > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich); curtis@occnc.com > Subject: RE: [mpls] MPLS-TP CC-CV-RDI > > Dave, > Raw BFD encapsulation over G-ACh has been already defined in RFC 5885. > GAL does not really add anything to this encapsulation IMO, simply allows to use G-ACh on top of LSPs and not just PWs. > > > Regards, > Sasha > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of David Allan I > > Sent: Tuesday, April 12, 2011 5:17 PM > > To: curtis@occnc.com > > Cc: mpls@ietf.org; David Ward; Schink, Helmut (NSN - DE/Munich) > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > Agreed, but that would require redesigning BFD. The other alternative > > would be to use the version number. > > > > As we had a simultaneous change of encapsultion with the GAL/G-ACh as > > well as the need for additional features, the code point seemed to > > make sense. > > > > Thanks > > Dave > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Monday, April 11, 2011 8:28 PM > > To: David Allan I > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); David Ward; John E Drake; > > Nitin Bahadur; mpls@ietf.org; Schink, Helmut (NSN - DE/Munich) > > Subject: Re: [mpls] MPLS-TP CC-CV-RDI > > > > > > In message > > <60C093A41B5E45409A19D42CF7786DFD51D548E241@EUSAACMS0703.eamcs.ericsso > > n > > .se> > > David Allan I writes: > > > > > > Hi Nurit > > > > > > It is backwards compatible in the sense that the new code points > > allow > > > the additional behaviors specified for MPLS TP to be disambiguated > > > from existing RFC 5884/5 behaviors > > > > > > - this is the addition of the GAL, the source MEP TLV, > > > interleaving of CC and CV PDUs, and accepting the TP-FAULT > > > inputs as valid state machine inputs. > > > > > > It is not perfectly backwards compatible in that the addition of the > > > GAL and new code points means deployed implementations will not > > > support the new encap and TLV without an upgrade .... RFC 5885 is > > > close but not an exact match due to the addition of the Source MEP > > > ID TLV. Some implementation tweaks are required. > > > > The usual way to handle an extension to an existing protocol is to use > > a capability negotiation, not assign a new code point. > > > > > hope this helps > > > Dave > > > > > > ________________________________ > > > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > > > [mailto:nurit.sprecher@nsn.com] > > > Sent: Monday, April 11, 2011 9:51 AM > > > To: David Ward; David Allan I; John E Drake; Nitin Bahadur > > > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; Schink, > > > Helmut (NSN - DE/Munich) > > > Subject: MPLS-TP CC-CV-RDI > > > > > > Dear authors, > > > > > > Slide 14 of the attached, says that "This document an enhancement to > > > RFC 5884/5885....But it still requires two new code points as it > > > will not be perfectly backwards compatible...." > > > > > > http://tools.ietf.org/agenda/80/slides/mpls-9.pdf > > > It is my understanding that the extension done to BFD is completely > > > compatible with BFD. > > > Can you please clarify this point? Is the solution being defined in > > > draft cc-cv-rdi is compatible with BFD? > > > Is it also possible for CC-CV-RDI and existing BFD to be compatible > > > today given only the proper configuration? > > > Best regards, > > > Nurit > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Wed Apr 13 00:24:26 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 649C8E0711 for ; Wed, 13 Apr 2011 00:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bprMpMAQPHhZ for ; Wed, 13 Apr 2011 00:24:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 86F5AE06D0 for ; Wed, 13 Apr 2011 00:24:25 -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 <0LJK00LEHXR6NB@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 13 Apr 2011 15:21:06 +0800 (CST) Received: from szxeml205-edg.china.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 <0LJK000AXXR51Q@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 13 Apr 2011 15:21:06 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 13 Apr 2011 15:20:52 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 13 Apr 2011 15:21:05 +0800 Date: Wed, 13 Apr 2011 07:20:52 +0000 From: Mach Chen X-Originating-IP: [10.110.98.37] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Question about MEG numbers for an associated bi-directional LSP Thread-index: Acv5q1ioTC08tdFtRfSbCvUxRFU7XQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [mpls] Question about MEG numbers for an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 07:24:26 -0000 Hi, In Section 3.1. of "http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11", it says: "An MPLS-TP Maintenance Entity Group may be defined to monitor the transport path for fault and/or performance management." and "In case of associated bi-directional point-to-point transport paths, two independent unidirectional Maintenance Entities are defined to independently monitor each direction. This has implications for transactions that terminate at or query a MIP, as a return path from MIP to originating MEP does not necessarily exist in the MEG." Could someone clarify that how many MEGs should be there for an associated bidirectional LSP? Many thanks, Mach From wim.henderickx@alcatel-lucent.com Wed Apr 13 06:44:07 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E39FCE0709 for ; Wed, 13 Apr 2011 06:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBtq4ugTanft for ; Wed, 13 Apr 2011 06:44:06 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfc.amsl.com (Postfix) with ESMTP id 602C1E0690 for ; Wed, 13 Apr 2011 06:44:05 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3DDhoaM029546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 15:44:02 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 13 Apr 2011 15:43:48 +0200 From: "Henderickx, Wim (Wim)" To: Javier Jimenez , "Thomas.Beckhaus@telekom.de" Date: Wed, 13 Apr 2011 15:43:46 +0200 Thread-Topic: [mpls] Questions on seamless MPLS Thread-Index: Acv5M3Z0yrMRhQmYRtKwf7zoJZ8FiwArLz1w Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6718445D5E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> <4D95D999.604@tid.es> <14C7F4F06DB5814AB0DE29716C4F6D67182EA529@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0184E73823@HE111648.emea1.cds.t-internal.com> <4DA485B1.5050008@tid.es> In-Reply-To: <4DA485B1.5050008@tid.es> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "mpls@ietf.org" Subject: Re: [mpls] Questions on seamless MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 13:44:08 -0000 Javier, in-line with WH2 -----Original Message----- From: Javier Jimenez [mailto:fjjc@tid.es]=20 Sent: dinsdag 12 april 2011 19:03 To: Thomas.Beckhaus@telekom.de Cc: mpls@ietf.org; Henderickx, Wim (Wim) Subject: Re: [mpls] Questions on seamless MPLS Hi Thomas, Wim, Thanks for your responses. Some additional thoughts: WH> when you perform NH self you will install a LBL entry for every LBL pr= efix and would result in a bigger LFIB. Right, but that only makes a difference if a small set of inter-domain LSPs is expected (which may be true). As this number grows, the difference in scalability will eventually dissapear, right? Anyway, it might be interesting for operators that are already running metro MPLS networks to keep separated IGP / LDP instances in different domains. In this case either we allow next hop self in both directions or we need to redistribute routes among IGPs, etc. If the intention is to make a generalistic recommendation, wouldn't it make sense to show the different options and then leave the final decision to the operator? WH2> we will include some text on the consequences of one or the other arch= itecture On the other side, after reading the draft, I'm not sure why it is claimed that only those labels needed to support the actual services in place need to be installed in the AGN nodes. Is this the default behaviour? I would assume that all the labels distributed in BGP would be installed in all the AGNs automatically, but I may be wrong. I'm not sure it is explained in the text why this happens. I agree with the fact that VPLS is an orthogonal problem, but I noticed that is was not mentioned in the draft (while point to point business services are indeed) and I was wondering if it was intentional. Otherwise, I would include this service as part of the reference scenarios, so that any potential implication may arise more easily. Finally, and regarding the OAM, the question is: does the seamless MPLS architecture consider MPLS-TP OAM to any extent? If so, it should be stated in the text. WH2> there is no intention to include MPLS-TP OAM in the draft Kind regards, Javier El 03/04/2011 21:36, Thomas.Beckhaus@telekom.de escribi=F3: > Javier, > > see in line (TB) > > Thomas > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Henderickx, Wim (Wim) >> Sent: Saturday, April 02, 2011 1:06 PM >> To: Javier Jimenez >> Cc: mpls@ietf.org >> Subject: Re: [mpls] Questions on seamless MPLS >> >> In-line >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Javier Jimenez >> Sent: vrijdag 1 april 2011 15:57 >> Cc: mpls@ietf.org >> Subject: [mpls] Questions on seamless MPLS >> >> Hi all, >> >> Here in Telef=F3nica we are pushing for MPLS E2E solutions, and it seems >> the seamless MPLS draft respresents a great starting point. >> Congratulations to the authors for this nice piece of work. >> >> I have two questions, not being involved in the draft so far: >> 1.- The draft proposes to use the next-hop-self in the outwards >> direction (with respect to an specific regional area) and to leave >> next-hop-unchanged for the incoming traffic. This approach >> requires that >> some routing information is flooded from the core area to the regional >> ones (specificallly, reachability to the ABRs). I'm sure this design >> increases the scalability of the solution, but two concerns >> come to my mind: >> - Wouldn't it be cleaner to perform the next-hop-self in both >> directions? I come from the transport world, where things tend to be >> symetrical (and easier to understand for humans). >> >> WH> when you perform NH self you will install a LBL entry for >> every LBL prefix and would result in a bigger LFIB. >> >> - More specifically, when migrating to a seamless architecture, it may >> be the case that the IGPs are already different in the core and in the >> regions (also the label distribution protocols), and it could not be >> possible to flood external IGP information into the regional areas or >> the operator would prefer to keep IGP clear from external >> influece (for >> that reason you have BGP). >> In summary, would there be room for two options (and which >> are the pros >> & cons) or just the one recommended in the draft? >> >> WH> the reason of the current architecture is due to >> scalability as outlined above >> >> > TB> we had exaclty this discussion regarding a next hop self (NHS) for i= ncomming traffic. In an single IGP scenario, the NHS is not required (in ou= r discussion, symmetry was also a topic - but we are neigher physicists nor= transport people). So we decided to avoid it because of scalability reason= s as Wim explained. But there are certain scenarios, where a NHS for incomm= ing traffic is preferred or required. > > >> 2.- Right now, VPLS services are typically offered only on a regional >> basis due to scalability issues. How would a VPLS service scale on top >> of a seamless MPLS architecture? Is this requirement part of the >> architecture or has been intentionally removed? >> >> WH> VPLS scale is orthogonal of the seamless MPLS >> architecture and it depends on the MAC@, replication/P2MP LSP >> architecture, end-points, use of H-VPLS, etc. Seamless MPLS >> is not changing these parameters for VPLS services, VPLS will >> just use the seamless MPLS architecture >> > TB> With the Seamless-MPLS approach, we consider different VPLS scenario= s: H-VPLS, flat VPLS or also a combination of PW based backhaul to a VSI on= a central PE (section 10.1.3 of rfc4762). This does not fix the scalabilit= y problem of Ethernet, but provide some possible solutions (e.g. easy backh= auling to a high scaling PE). > > >> Kind regards, >> Javier Jimenez >> Telef=F3nica Research >> >> Este mensaje se dirige exclusivamente a su destinatario. >> Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de >> correo electr=F3nico en el enlace situado m=E1s abajo. >> This message is intended exclusively for its addressee. We >> only send and receive email on the basis of the terms set out at. >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> _______________________________________________ >> 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 >> >> > . > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From gregimirsky@gmail.com Wed Apr 13 10:12:32 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C3E81E07CD for ; Wed, 13 Apr 2011 10:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwYrdqV5UjJT for ; Wed, 13 Apr 2011 10:12:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 929DDE07C5 for ; Wed, 13 Apr 2011 10:12:31 -0700 (PDT) Received: by vws12 with SMTP id 12so789172vws.31 for ; Wed, 13 Apr 2011 10:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UveUe2oj9lnsC8qGetWsuv13VmMIj9q35cdBJXQsE9k=; b=uDk2GfaI4pND5TdNObZQnXispruUmZsH4EXgQ4Dr8GCTgj/097XnJk+UYS9qUahxkp 3qrbdsi9YtQ1mYOORJ97VxYoXilDARtAjjXyzK91OCvManK7mpDaBTDmkIBc8CYXXZYS wUJc6qtQfXXP/vrtHtLfP36+NSnsg1DUQJLVE= 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=tibeY977d7YidkAPsgq8SUUZeYYzfq2333ejVf7YWmIGMa9u34kaeSnajmNr//bQSP X4TtvGXPFjzFRD8TpnC8c8peJOR9oKovjoKOU7WDrvsKek9pBJFjNFMAoYiNSSd4eiVt OAssFQYTNZ9m0ZKVQULcyQ97JB3LrzPpbmVPA= MIME-Version: 1.0 Received: by 10.52.0.66 with SMTP id 2mr6839245vdc.308.1302714751059; Wed, 13 Apr 2011 10:12:31 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Wed, 13 Apr 2011 10:12:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Apr 2011 10:12:30 -0700 Message-ID: From: Greg Mirsky To: Mach Chen Content-Type: multipart/alternative; boundary=20cf3054a11bfb0b2204a0cfe98b Cc: "mpls@ietf.org" Subject: Re: [mpls] Question about MEG numbers for an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:12:32 -0000 --20cf3054a11bfb0b2204a0cfe98b Content-Type: text/plain; charset=ISO-8859-1 Hi Mach, I'll offer my opinion. If bi-directional associated LSP is monitored in coordinated fashion, then one MEG exists. If bi-directional associated LSP is monitored in independent fashion - two MEGs defined. Regards, Greg On Wed, Apr 13, 2011 at 12:20 AM, Mach Chen wrote: > Hi, > > In Section 3.1. of " > http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11", it says: > > "An MPLS-TP Maintenance Entity Group may be defined to monitor the > transport path for fault and/or performance management." > > and > > "In case of associated bi-directional point-to-point transport paths, two > independent unidirectional Maintenance Entities are defined to independently > monitor each direction. This has implications for transactions that > terminate at or query a MIP, as a return path from MIP to originating MEP > does not necessarily exist in the MEG." > > Could someone clarify that how many MEGs should be there for an associated > bidirectional LSP? > > Many thanks, > Mach > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf3054a11bfb0b2204a0cfe98b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mach,
    I'll offer my opinion.
    If bi-directional associated LSP = is monitored in coordinated fashion, then one MEG exists.
    If bi-directio= nal associated LSP is monitored in independent fashion - two MEGs defined.<= br>
    Regards,
    Greg

    On Wed, Apr 13, 2011= at 12:20 AM, Mach Chen <mach.chen@huawei.com> wrote:
    Hi,

    In Section 3.1. of "http://tools.ietf.org/html/draft= -ietf-mpls-tp-oam-framework-11", it says:

    "An MPLS-TP Maintenance Entity Group may be defined to monitor the tra= nsport path for fault and/or performance management."

    and

    "In case of associated bi-directional point-to-point transport paths, = two independent unidirectional Maintenance Entities are defined to independ= ently monitor each direction. This has implications for transactions that t= erminate at or query a MIP, as a return path from MIP to originating MEP do= es not necessarily exist in the MEG."

    Could someone clarify that how many MEGs should be there for an associated = bidirectional LSP?

    Many thanks,
    Mach

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

    --20cf3054a11bfb0b2204a0cfe98b-- From Internet-Drafts@ietf.org Wed Apr 13 10:15:03 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D06CE0808; Wed, 13 Apr 2011 10:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLsVBPZNykex; Wed, 13 Apr 2011 10:15:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 460F8E0806; Wed, 13 Apr 2011 10:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110413171502.9335.98344.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 10:15:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:15:03 -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 : Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs Author(s) : Z. Ali, G. Swallow Filename : draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07.txt Pages : 9 Date : 2011-04-13 There are many deployment scenarios which require Egress Label Switching Router (LSR) to receive binding of the Resource ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched Path (LSP) to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document proposes protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to- point (P2P) and point-to-multipoint (P2MP) LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13100034.I-D@ietf.org> --NextPart-- From aldrin.ietf@gmail.com Wed Apr 13 10:40:38 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A3A7DE0863 for ; Wed, 13 Apr 2011 10:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvGB7QllWbpm for ; Wed, 13 Apr 2011 10:40:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id CD0F6E0853 for ; Wed, 13 Apr 2011 10:40:37 -0700 (PDT) Received: by iwn39 with SMTP id 39so988380iwn.31 for ; Wed, 13 Apr 2011 10:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id:cc:x-mailer:from :subject:date:to; bh=DcQchbV0OzQT2DoVmuHlXk3HgtGO/xuPg2xbw5BWlKY=; b=sRCQa9i8Zm64w+rlv5cx1rsI7IYVXWdTkt2Hdz8S5EIZHDVFCX1Mf5xlTvainHSOMI 84GVs9gTN2jF4y702I2eDSqmKWKCCaj8+GHhkypMjhwcBoEate/7iNeqh31TrswarWVR xGLzGKNyE28XTfoA7Y09naR+DvpBKGxY0rX94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; b=TXCOknP/doPUToOdF81WxuU5F1G0WN1oxqxXqplOysSQp/4G6yvz1KNgTv5r2M922O h3QzIkUWSpuW9cSHl8WeOFaU8qlFpoJ4/tkLILLS2VR5UB1dQOupYrb8ArD2VlvcUyTV w/GOD/EtzIlHBG4aZjmKdvfKivCXQwVZy12JY= Received: by 10.43.63.196 with SMTP id xf4mr455139icb.172.1302716437327; Wed, 13 Apr 2011 10:40:37 -0700 (PDT) Received: from [192.168.1.127] ([12.133.183.34]) by mx.google.com with ESMTPS id y10sm564463iba.63.2011.04.13.10.40.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 10:40:36 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8G4) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <150C472B-AAA3-48AC-9F53-D034FC96C039@gmail.com> X-Mailer: iPad Mail (8G4) From: Sam Aldrin Date: Wed, 13 Apr 2011 10:40:53 -0700 To: Mach Chen Cc: "mpls@ietf.org" Subject: Re: [mpls] Question about MEG numbers for an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:40:38 -0000 Mach, IMHO, If the associated bi-dir lsp's are monitored in a coordinated fashion,= then one MEG ID is required. Else two MEG ID's are needed, in order to moni= tor them independently. Cheers Sam Sent from my iPad On Apr 13, 2011, at 12:20 AM, Mach Chen wrote: > Hi, >=20 > In Section 3.1. of "http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-fram= ework-11", it says: >=20 > "An MPLS-TP Maintenance Entity Group may be defined to monitor the transpo= rt path for fault and/or performance management." >=20 > and=20 >=20 > "In case of associated bi-directional point-to-point transport paths, two i= ndependent unidirectional Maintenance Entities are defined to independently m= onitor each direction. This has implications for transactions that terminate= at or query a MIP, as a return path from MIP to originating MEP does not ne= cessarily exist in the MEG." >=20 > Could someone clarify that how many MEGs should be there for an associated= bidirectional LSP? >=20 > Many thanks, > Mach=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Wed Apr 13 16:48:03 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 799F9E06EA for ; Wed, 13 Apr 2011 16:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vwcwxP5ZKDx for ; Wed, 13 Apr 2011 16:48:02 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 776C3E06E8 for ; Wed, 13 Apr 2011 16:48:02 -0700 (PDT) Received: by vws12 with SMTP id 12so1119413vws.31 for ; Wed, 13 Apr 2011 16:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OZpPDX2KZuqMOl/Eokyfs1J70YdoQQbGhWG1C59R0Go=; b=oMj44R5eSpR6KgrczCa/vx4LTISHxZbWpzRWenr0BQNZW5sBVRPfZ67IWZmmlbSLqr sYNT+/UCP45jH6CUUCGU748Qf/4k/978u1ZyykCq0j4ZO4c+VmYaMiGNDTZvtCXnCPNT jb6i4rdwbQtiGnzeNuDUSXoE1IsnGall3dfRw= 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=h1hPQoa8VijjChYi8FtVPC94kV+Ay1Tw8kXh31T9p1mMvUzkWx2mAo3JIePWY7GLpn JMpA//kdWjSDkYzEsx3DdgHening4Je5tgpWrqxCrWbmej8hkOvJNfVOvGMdCbFLlsMw drks6Rin2+4QifjSkePgPtFJ1xCMf3OBQTSzo= MIME-Version: 1.0 Received: by 10.52.90.116 with SMTP id bv20mr129255vdb.108.1302738482046; Wed, 13 Apr 2011 16:48:02 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Wed, 13 Apr 2011 16:48:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Apr 2011 16:48:02 -0700 Message-ID: From: Greg Mirsky To: Eric Gray Content-Type: multipart/alternative; boundary=20cf307f38d47526fb04a0d57001 Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 23:48:03 -0000 --20cf307f38d47526fb04a0d57001 Content-Type: text/plain; charset=ISO-8859-1 I haven't noticed that it's so long. Clipped ... Dear Eric, I think that Section 4.1 might be the place. With wording that "Reply via specified path" can be requested and then Reply Path TLV (draft-ietf-mpls-return-path-specified-lsp-ping-02) used to define the path. Regards, Greg On Tue, Apr 12, 2011 at 3:31 AM, Eric Gray wrote: > > Resending this message in plain text (too big)... > ________________________________ > > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Friday, April 01, 2011 6:41 AM > To: Greg Mirsky; Alexander Vainshtein > Cc: hideki.endo.es@hitachi.com; mpls@ietf.org; Manuel.Paul@telekom.de; > Rolf.Winter@neclab.eu > Subject: RE: [mpls] Working Group Last Call on > draft-ietf-mpls-tp-on-demand-cv- > > > Out of curiosity, where would you expand it (i.e. - where would you suggest > we > say this)? > > ________________________________ > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Thursday, March 31, 2011 3:10 AM > To: Alexander Vainshtein > Cc: hideki.endo.es@hitachi.com; Eric Gray; mpls@ietf.org; > Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu > Subject: Re: [mpls] Working Group Last Call on > draft-ietf-mpls-tp-on-demand-cv- > > > Dear Sasha and All, > considering that LSP ping can specify the return path for the LSP Echo > Reply, I'd expand capability to LSP ping MEP-to-MIP to all MPLS-TP > constructs, bi-directional as well as unidirectional. The return path might > be directed over an LSP which is in reverse direction that is not > necessarily is associated with LSP that been tested by LSP Echo Request. > > Regards, > Greg > > > On Wed, Mar 30, 2011 at 11:43 PM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote: > > > Hideki, Eric, and all, > I believe that ability to do ping MEP-to-MIP should not be precluded > (at least for co-routed bidirectional LSPs). > > > Regards, > Sasha > > > --20cf307f38d47526fb04a0d57001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I haven't noticed that it's so long. Clipped ...

    Dear Eric,<= br>I think that Section 4.1 might be the place. With wording that "Rep= ly via specified path" can be requested and then Reply Path TLV (draft= -ietf-mpls-return-path-specified-lsp-ping-02) used to define the path.

    Regards,
    Greg

    On Tue, Apr 12, 2011= at 3:31 AM, Eric Gray <eric.gray@ericsson.com> wrote:

    Resending this message in plain text (too big)...
    ________________________________

    From: Eric Gray [mailto:eric.gray= @ericsson.com]
    Sent: Friday, April 01, 2011 6:41 AM
    To: Greg Mirsky; Alexander Vainshtein
    Cc: hideki.endo.es@= hitachi.com; mpls@ietf.org; Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu
    Subject: RE: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand= -cv-


    Out of curiosity, where would you expand it (i.e. - where would you suggest= we
    say this)?

    ________________________________

    From: Greg Mirsky [mailto:gregimir= sky@gmail.com]
    Sent: Thursday, March 31, 2011 3:10 AM
    To: Alexander Vainshtein
    Cc: hideki.endo.es@= hitachi.com; Eric Gray= ; mpls@ietf.org; Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu
    Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand= -cv-


    Dear Sasha and All,
    considering that LSP ping can specify the return path for the LSP Echo Repl= y, I'd expand capability to LSP ping MEP-to-MIP to all MPLS-TP construc= ts, bi-directional as well as unidirectional. The return path might be dire= cted over an LSP which is in reverse direction that is not necessarily is a= ssociated with LSP that been tested by LSP Echo Request.

    Regards,
    Greg


    On Wed, Mar 30, 2011 at 11:43 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>= ; wrote:


    =A0 =A0 =A0 =A0Hideki, Eric, and all,
    =A0 =A0 =A0 =A0I believe that ability to do ping MEP-to-MIP should not be = precluded (at least for co-routed bidirectional LSPs).


    =A0 =A0 =A0 =A0Regards,
    =A0 =A0 =A0 =A0 =A0 =A0Sasha



    --20cf307f38d47526fb04a0d57001-- From mach.chen@huawei.com Wed Apr 13 18:35:09 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BDB24E07B2 for ; Wed, 13 Apr 2011 18:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea4MBPdYPMan for ; Wed, 13 Apr 2011 18:35:09 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 31DFFE05F5 for ; Wed, 13 Apr 2011 18:35:08 -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 <0LJM003ICCEI3F@szxga03-in.huawei.com> for mpls@ietf.org; Thu, 14 Apr 2011 09:35:07 +0800 (CST) Received: from szxeml204-edg.china.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 <0LJM00GTJCEIW6@szxga03-in.huawei.com> for mpls@ietf.org; Thu, 14 Apr 2011 09:35:06 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Apr 2011 09:34:51 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 09:35:06 +0800 Date: Thu, 14 Apr 2011 01:34:50 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.37] To: Greg Mirsky , Sam Aldrin Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_I85iMK8n9/tFQK61DHHuWA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [mpls] Question about MEG numbers for an associated bi-directional LSP Thread-index: Acv5q1ioTC08tdFtRfSbCvUxRFU7XQAD5GcAACHFejA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "mpls@ietf.org" Subject: Re: [mpls] Question about MEG numbers for an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 01:35:09 -0000 --Boundary_(ID_I85iMK8n9/tFQK61DHHuWA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thanks Greg and Sam, So, from the view of implementation, does it mean that both ways should be supported? Best regards, Mach From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Thursday, April 14, 2011 1:12 AM To: Mach Chen Cc: mpls@ietf.org Subject: Re: [mpls] Question about MEG numbers for an associated bi-directional LSP Hi Mach, I'll offer my opinion. If bi-directional associated LSP is monitored in coordinated fashion, then one MEG exists. If bi-directional associated LSP is monitored in independent fashion - two MEGs defined. Regards, Greg On Wed, Apr 13, 2011 at 12:20 AM, Mach Chen > wrote: Hi, In Section 3.1. of "http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11", it says: "An MPLS-TP Maintenance Entity Group may be defined to monitor the transport path for fault and/or performance management." and "In case of associated bi-directional point-to-point transport paths, two independent unidirectional Maintenance Entities are defined to independently monitor each direction. This has implications for transactions that terminate at or query a MIP, as a return path from MIP to originating MEP does not necessarily exist in the MEG." Could someone clarify that how many MEGs should be there for an associated bidirectional LSP? Many thanks, Mach _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --Boundary_(ID_I85iMK8n9/tFQK61DHHuWA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

    Thanks Greg and Sam,

     

    So, from the view of implementation, does it mean that both ways should be supported?

     

    Best regards,

    Mach

     

    From: Greg Mirsky [mailto:gregimirsky@gmail.com]
    Sent: Thursday, April 14, 2011 1:12 AM
    To: Mach Chen
    Cc: mpls@ietf.org
    Subject: Re: [mpls] Question about MEG numbers for an associated bi-directional LSP

     

    Hi Mach,
    I'll offer my opinion.
    If bi-directional associated LSP is monitored in coordinated fashion, then one MEG exists.
    If bi-directional associated LSP is monitored in independent fashion - two MEGs defined.

    Regards,
    Greg

    On Wed, Apr 13, 2011 at 12:20 AM, Mach Chen <mach.chen@huawei.com> wrote:

    Hi,

    In Section 3.1. of "http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11", it says:

    "An MPLS-TP Maintenance Entity Group may be defined to monitor the transport path for fault and/or performance management."

    and

    "In case of associated bi-directional point-to-point transport paths, two independent unidirectional Maintenance Entities are defined to independently monitor each direction. This has implications for transactions that terminate at or query a MIP, as a return path from MIP to originating MEP does not necessarily exist in the MEG."

    Could someone clarify that how many MEGs should be there for an associated bidirectional LSP?

    Many thanks,
    Mach

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

     

    --Boundary_(ID_I85iMK8n9/tFQK61DHHuWA)-- From aldrin.ietf@gmail.com Wed Apr 13 19:08:05 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1F14FE06C9 for ; Wed, 13 Apr 2011 19:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFtpCfsZ4PQS for ; Wed, 13 Apr 2011 19:08:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 48EB5E068B for ; Wed, 13 Apr 2011 19:08:04 -0700 (PDT) Received: by iwn39 with SMTP id 39so1362557iwn.31 for ; Wed, 13 Apr 2011 19:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=tsw5viUBi1gvzj1D1gSYM8ocFwSAG90Ue4I9Hya4jY4=; b=m+AWSi7uh3Q/bTACcUIP4VKAA0y1jOdui0xdgBkPvtNtmTtIW0h5BuN//Bi7YNW9+v HXxLRiGgTdPddSdF4TAAjSiqpz/uZciTMxod2M+Vvld5qvusBzR8QRDc7hgsLY2bYX7d pHh55qN0kdOsZyQGFUR0+6sTUhjUehJ3c9T5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=Y8Wv+ChIIDbBURbF7kGE8n2tr52gyrOs80sVSwpsn8+eLzWpdg0YlkfU4hZaYJO7/2 5kdDwaED6DLAOiWenCTVej9YFYszulivE2pw941OvCCt5PDGuLPBYjv+EE95fedaKCS5 BfBmSrN5Lz3+tJ2iqhGlhAQ49VtihZBWD/YD8= Received: by 10.42.197.197 with SMTP id el5mr232986icb.484.1302746883783; Wed, 13 Apr 2011 19:08:03 -0700 (PDT) Received: from [10.109.162.59] ([166.205.139.220]) by mx.google.com with ESMTPS id i3sm823492iby.23.2011.04.13.19.08.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 19:08:02 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-169649472 Message-Id: <33F97AE6-7FF8-449E-B0FB-2B4A65B0FBAD@gmail.com> X-Mailer: iPhone Mail (8G4) From: Sam Aldrin Date: Wed, 13 Apr 2011 19:07:49 -0700 To: Mach Chen Cc: "mpls@ietf.org" Subject: Re: [mpls] Question about MEG numbers for an associated bi-directional LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 02:08:05 -0000 --Apple-Mail-1-169649472 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mach, Yes. Sam Sent from my iPhone On Apr 13, 2011, at 6:34 PM, Mach Chen wrote: > Thanks Greg and Sam, >=20 > =20 >=20 > So, from the view of implementation, does it mean that both ways should be= supported? >=20 > =20 >=20 > Best regards, >=20 > Mach >=20 > =20 >=20 > From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 > Sent: Thursday, April 14, 2011 1:12 AM > To: Mach Chen > Cc: mpls@ietf.org > Subject: Re: [mpls] Question about MEG numbers for an associated bi-direct= ional LSP >=20 > =20 >=20 > Hi Mach, > I'll offer my opinion. > If bi-directional associated LSP is monitored in coordinated fashion, then= one MEG exists. > If bi-directional associated LSP is monitored in independent fashion - two= MEGs defined. >=20 > Regards, > Greg >=20 > On Wed, Apr 13, 2011 at 12:20 AM, Mach Chen wrote: >=20 > Hi, >=20 > In Section 3.1. of "http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-fram= ework-11", it says: >=20 > "An MPLS-TP Maintenance Entity Group may be defined to monitor the transpo= rt path for fault and/or performance management." >=20 > and >=20 > "In case of associated bi-directional point-to-point transport paths, two i= ndependent unidirectional Maintenance Entities are defined to independently m= onitor each direction. This has implications for transactions that terminate= at or query a MIP, as a return path from MIP to originating MEP does not ne= cessarily exist in the MEG." >=20 > Could someone clarify that how many MEGs should be there for an associated= bidirectional LSP? >=20 > Many thanks, > Mach >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > =20 --Apple-Mail-1-169649472 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
    Mach,

    Yes.

    Sam

    Sent from my iPhone

    On Apr 13, 2011, at 6:34 PM, Mach Chen <mach.chen@huawei.com> wrote:

    Thanks Greg and Sam,

     

    So, from the view of implementation, does it mean that both ways should be supported?

     

    Best regards,

    Mach

     

    From: Greg Mirsky [mailto:gregimirsky@gmail.com]
    Sent: Thursday, April 14, 2011 1:12 AM
    To: Mach Chen
    Cc: mpls@ietf.org
    Subject: Re: [mpls] Question about MEG numbers for an associated bi-directional LSP

     

    Hi Mach,
    I'll offer my opinion.
    If bi-directional associated LSP is monitored in coordinated fashion, then one MEG exists.
    If bi-directional associated LSP is monitored in independent fashion - two MEGs defined.

    Regards,
    Greg

    On Wed, Apr 13, 2011 at 12:20 AM, Mach Chen <mach.chen@huawei.com> wrote:

    Hi,

    In Section 3.1. of "http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11", it says:

    "An MPLS-TP Maintenance Entity Group may be defined to monitor the transport path for fault and/or performance management."

    and

    "In case of associated bi-directional point-to-point transport paths, two independent unidirectional Maintenance Entities are defined to independently monitor each direction. This has implications for transactions that terminate at or query a MIP, as a return path from MIP to originating MEP does not necessarily exist in the MEG."

    Could someone clarify that how many MEGs should be there for an associated bidirectional LSP?

    Many thanks,
    Mach

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

     

    --Apple-Mail-1-169649472-- From mach.chen@huawei.com Thu Apr 14 19:35:55 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55844E075D; Thu, 14 Apr 2011 19:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FBUUo8rgKdn; Thu, 14 Apr 2011 19:35:54 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 702E9E065C; Thu, 14 Apr 2011 19:35:54 -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 <0LJO00F039VGSV@szxga04-in.huawei.com>; Fri, 15 Apr 2011 10:35:41 +0800 (CST) Received: from szxeml205-edg.china.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 <0LJO00ION9VGSW@szxga04-in.huawei.com>; Fri, 15 Apr 2011 10:35:40 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 10:35:25 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 10:35:40 +0800 Date: Fri, 15 Apr 2011 02:35:17 +0000 From: Mach Chen In-reply-to: <4DA738A4.8010904@cisco.com> X-Originating-IP: [10.110.98.37] To: Luca Martini , Greg Mirsky Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Whether T-LDP is part of the MPLS-TP control plane Thread-index: AQHL+xXOuBRay31Jh0yRN2bvU9H63Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: [mpls] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 02:35:55 -0000 Hi Luca, You said T-LDP is not part of the MPLS-TP control plane. IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is figure about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP layer. In addition, in the abstract of MPLS-TP control plane (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says: "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs)..." Best regards, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Friday, April 15, 2011 2:11 AM > To: Greg Mirsky > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > On 04/14/11 00:09, Greg Mirsky wrote: > > Luca, > > you've asked > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > but isn't T-LDP part of MPLS-TP control plane? Control plane assumes > > IP addressing thus use of T-LDP is plausible. > > > No T-LDP is not part of the MPLS-TP control plane. > It could be , but i think folks are more leaning toward GMPLS instead. > > Note that the problem described in this document exists for MPLS. So in > that case LDP is certainly used. But the document appears to only care > about MPLS-TP. > > Luca > > > > > Regards, > > Greg > > From Alexander.Vainshtein@ecitele.com Thu Apr 14 21:45:44 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DE054E0720; Thu, 14 Apr 2011 21:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk+t39hlc2Lo; Thu, 14 Apr 2011 21:45:44 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id 74D43E06E1; Thu, 14 Apr 2011 21:45:43 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-82-4da7cd12ba25 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 29.50.02691.21DC7AD4; Fri, 15 Apr 2011 07:44:02 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 15 Apr 2011 07:45:42 +0300 From: Alexander Vainshtein To: Mach Chen , Luca Martini , Greg Mirsky Date: Fri, 15 Apr 2011 07:45:10 +0300 Thread-Topic: Whether T-LDP is part of the MPLS-TP control plane Thread-Index: AQHL+xXOuBRay31Jh0yRN2bvU9H63ZReWaFt Message-ID: References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.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 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTbWxLURjO6b23vet2ubpVj0WkOTIJ02WbkYp1JvyYxGJii/GHqz3aG7e3 Te815o8RIZlYjG2oz0U3xsRHfA1pWIgYYxJZfOzDooaOkRKCUPf2xkycX8953+d5n/ecvC9N mH7p02lelHFA5ASkN5J7orHPNlPn8eLs0PAs+5eGV5T9dc9Pg73rdKr9WVMLZa+JXSALqaK6 H+eoorZgr6Fo6633VFEo9E1XQq6oAvmcKPpkTsZWF5acDlQS4Cs4ZyWy8i4HykFWv8A5sReL sgNxfj8WXajAaP3v5Cs0XrRi0elz8aLbgRYuXWyz22fOtuWggimTc2bMMZZ6eMmKbV6OF6xe LEmcG1uVyKoLhOdu+IDePzx2w0DrbVAFoinVIImGbB7cebiG0vB42NV3Rl8NjLSJbQOw8Ucd 0C51AD7Y1mtQWXrWAc+f6tWrOI0V4dmbg6SKCXYB7HvdkeCQbAbc9fF6omoqOxc+HKjXafxC GGmMERrOhUOXYgktwy6Gt09uM2hmPwG8+mhzgpTElsKavsEEBkp7XztadZqZBT6LHNFpbbMw dP0hoWEzfPvyF6XxzbBn+xmg8afDo9dieg1nwubGIUIzHgfv7o+QmnYCvHniCbkLWIKjLIKj 5MFR8uAo+VFAngRmXvDLq73u7Nws7ORlLOAsp897HmjT8+YKeH5/ajtgaYBSmCsZx4tNFFch VXrbwQRah8zMwD0lNGa1z1Xp4STPysA6AUvtANIESmN2RpuLTYyLq9yIA74/KbvyzbVEerLT p8ypKK+ckZ39zwVZmOFVoWIT61bGbi3Gfhz4I51I0wgy3fcVx3EB7MYb1vCC/Deto5NU5xTF +Y3aFSP5Oa/Eu7V8B7DR4cEPYWAiRZ+I0y3MC7UQq5I868SROurabIrH41FgUd6cyvSrrBRl qUYqRRUTnWLytCphoqzHSCq9CpRdHrqYuUTXcOPlqc6CZUL8+51Fke4t/Y+7UiPT6vdOXbGm rmWHuXwff+x9oaEeHXp7sMuR1pw3i/pk7Ky9Zk6uaIjO42ozm4R33e3r95X3EOXLM8Lzdx+5 NFDeRuVn5R370FxddiKyoH95xPctfqskOVr2OFragsIFk+YnO3PlVkRKHi5nGhGQuN86k4LV EQQAAA== Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 04:45:45 -0000 Mach, Luca, Greg and all, I concur with Mach on this point. Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Mach Chen [= mach.chen@huawei.com] Sent: Friday, April 15, 2011 5:35 AM To: Luca Martini; Greg Mirsky Cc: mpls@ietf.org; pwe3@ietf.org Subject: [PWE3] Whether T-LDP is part of the MPLS-TP control plane Hi Luca, You said T-LDP is not part of the MPLS-TP control plane. IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is fig= ure about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP laye= r. In addition, in the abstract of MPLS-TP control plane (http://tools.ietf.org= /html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says: "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths= (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires= (PWs)..." Best regards, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Friday, April 15, 2011 2:11 AM > To: Greg Mirsky > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 working group poll for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > On 04/14/11 00:09, Greg Mirsky wrote: > > Luca, > > you've asked > > How would LDP , which is IP based , even run on an MPLS-TP network ? > > but isn't T-LDP part of MPLS-TP control plane? Control plane assumes > > IP addressing thus use of T-LDP is plausible. > > > No T-LDP is not part of the MPLS-TP control plane. > It could be , but i think folks are more leaning toward GMPLS instead. > > Note that the problem described in this document exists for MPLS. So in > that case LDP is certainly used. But the document appears to only care > about MPLS-TP. > > Luca > > > > > Regards, > > Greg > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From neil.2.harrison@bt.com Fri Apr 15 00:13:05 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 41AAFE06F1; Fri, 15 Apr 2011 00:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMrqd6eLsTKg; Fri, 15 Apr 2011 00:13:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfc.amsl.com (Postfix) with ESMTP id E2B58E06C8; Fri, 15 Apr 2011 00:13:03 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 15 Apr 2011 08:13:03 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.163]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 15 Apr 2011 08:13:02 +0100 From: To: , , , Date: Fri, 15 Apr 2011 08:12:59 +0100 Thread-Topic: Whether T-LDP is part of the MPLS-TP control plane Thread-Index: AQHL+xXOuBRay31Jh0yRN2bvU9H63ZReWaFtgAAk8JA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4401FD04381@EMV62-UKRD.domain1.systemhost.net> References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [mpls] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:13:05 -0000 Luca is actually correct in that PWs are NOT part of the MPLS-TP CP. This = follows from the simple (obvious?) observation that MS PWs represent a diff= erent layer network to MPLS-TP. The fact PWs should not exist in MPLS-TP i= s a different issue...but given they do then their functional layer network= specification has to be addressed. Aside=3D> I asked Stewart (Bryant) many months ago on a call (in the early = ITU/IETF discussion days) as to why we don't simply use the same GMPLS-base= d signalling protocol for setting up PW connections as we do for MPLS-TP co= nnections, ie why reinvent the wheel? I also had a secondary point that th= e PW layer CP/MP also needs to be logically OOB like the MPLS-TP CP/MP. I = was told for the 1st point that it was because RSVP-TE does not support the= specific type of addressing that PWs use. [Note that access point address= ing is probably THE most definitive component of defining a layer network a= nd one has to take great care with it. Get it wrong or do it badly at the = outset (I can think of some examples ;-)) and it is very hard to change lat= er.] Wrt to the 2nd point Stewart had already realised there was also an O= OB issue for the PW layer network CP/MP, but had no answer at that time. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: 15 April 2011 05:45 > To: Mach Chen; Luca Martini; Greg Mirsky > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: Re: [PWE3] Whether T-LDP is part of the MPLS-TP control plane >=20 > Mach, Luca, Greg and all, > I concur with Mach on this point. >=20 > Regards, > Sasha >=20 > ________________________________________ > From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Mach > Chen [mach.chen@huawei.com] > Sent: Friday, April 15, 2011 5:35 AM > To: Luca Martini; Greg Mirsky > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: [PWE3] Whether T-LDP is part of the MPLS-TP control plane >=20 > Hi Luca, >=20 > You said T-LDP is not part of the MPLS-TP control plane. >=20 > IMHO, this is not right, according to Section 4.4.1 of RFC5921, there > is figure about "MPLS-TP layer boundary", it shows that PW belongs to > MPLS-TP layer. >=20 > In addition, in the abstract of MPLS-TP control plane > (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), > it says: > "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched > Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for > Pseudowires (PWs)..." >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > > Luca Martini > > Sent: Friday, April 15, 2011 2:11 AM > > To: Greg Mirsky > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] PWE3 working group poll for > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > > > > On 04/14/11 00:09, Greg Mirsky wrote: > > > Luca, > > > you've asked > > > How would LDP , which is IP based , even run on an MPLS-TP network > ? > > > but isn't T-LDP part of MPLS-TP control plane? Control plane > assumes > > > IP addressing thus use of T-LDP is plausible. > > > > > No T-LDP is not part of the MPLS-TP control plane. > > It could be , but i think folks are more leaning toward GMPLS > instead. > > > > Note that the problem described in this document exists for MPLS. So > in > > that case LDP is certainly used. But the document appears to only > care > > about MPLS-TP. > > > > Luca > > > > > > > > > Regards, > > > Greg > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From manavbhatia@gmail.com Fri Apr 15 10:03:17 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3D32130067 for ; Fri, 15 Apr 2011 10:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42qkyc134OcF for ; Fri, 15 Apr 2011 10:03:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 5DCFA130061 for ; Fri, 15 Apr 2011 10:03:14 -0700 (PDT) Received: by wyb29 with SMTP id 29so2714447wyb.31 for ; Fri, 15 Apr 2011 10:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=73yTej62SMz4HT1ZL0mD7aBau5nbzquYHNQQuXfPGYw=; b=R2haW3G00Ge9Bk3TuG543xrz+xVsm4IHsl4X+/cmo18r4YYK1whP+IL3nTp7yq8Vy7 zAuDHDXV8LsKrYQ9oEJ4OaUvAyHkQOyZN9dchHAz75nD2NC0uXVE5Eza7nCpPAxeHcAI dOg6NQ/oNt2Ob/AX2zgZdAnc6zq3vvPWtHHyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rKVISKM/umhJqhFT9P88F4iZBh80m172w/BZ3I5R3/nFs1jYX+zOg5v2jjEzWBx45X 1V3sBnxbhsxtgLQ6YrDltssZ46iH6MN12ZWxd9aXGk9zflKqiZxLX/RLllCDqBGCXD2C n0nxMq49wCD+oXLMUgPEN6TJtSlXzmEnCnKnU= MIME-Version: 1.0 Received: by 10.227.177.69 with SMTP id bh5mr282131wbb.155.1302886993610; Fri, 15 Apr 2011 10:03:13 -0700 (PDT) Received: by 10.227.142.140 with HTTP; Fri, 15 Apr 2011 10:03:12 -0700 (PDT) Date: Fri, 15 Apr 2011 22:33:12 +0530 Message-ID: From: Manav Bhatia To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:03:17 -0000 Hi, I have posted a new draft: http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00.txt Abstract There are several applications that require symmetric Multiprotocol Label Switching (MPLS) path between two points. This cannot be achieved with regular MPLS as the LSPs are unidirectional. If symmetry is required, a separate LSP in each direction is required for bidirectional traffic flow. Generalized MPLS on the other hand, has provisions for setting up a bidirectional LSP. This document uses the extensions introduced for GMPLS and applies it to regular MPLS for establishing bidirectional LSPs. Additionally, it also describes how bi-directional symmetrical Fast Reroute using both one-to-one and facility backup can be achieved. Would be great if the WG can provide some feedback on this. Cheers, Manav From wwwrun@rfc-editor.org Mon Apr 18 01:59:05 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 06899E06CD for ; Mon, 18 Apr 2011 01:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hJk9ukldLu5 for ; Mon, 18 Apr 2011 01:59:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id 6F686E065C for ; Mon, 18 Apr 2011 01:59:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8C91DE0733; Mon, 18 Apr 2011 01:58:59 -0700 (PDT) To: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, stbryant@cisco.com, adrian@olddog.co.uk, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu From: RFC Errata System Message-Id: <20110418085859.8C91DE0733@rfc-editor.org> Date: Mon, 18 Apr 2011 01:58:59 -0700 (PDT) Cc: mpls@ietf.org, valeriaelisabetta.mattavelli@ericsson.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3031 (2782) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 08:59:05 -0000 The following errata report has been submitted for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=2782 -------------------------------------- Type: Editorial Reported by: Valeria Elisabetta Mattavelli Section: 2.2 Original Text ------------- layer 3 the protocol layer at which IP and its associated routing protocols operate link layer synonymous with layer 2 Corrected Text -------------- layer 3 the protocol layer at which IP and its associated routing protocols operate link layer synonymous with layer 2 Notes ----- Wrong text indentation 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. -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From rcallon@juniper.net Mon Apr 18 08:21:14 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 44720E06DD for ; Mon, 18 Apr 2011 08:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.699 X-Spam-Level: X-Spam-Status: No, score=-106.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGzTRcNrd933 for ; Mon, 18 Apr 2011 08:21:13 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfc.amsl.com (Postfix) with ESMTP id 5A51DE06A2 for ; Mon, 18 Apr 2011 08:21:13 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTaxW6LcYyfVZZRPMkQ5QDwv6os9mfGwB@postini.com; Mon, 18 Apr 2011 08:21:13 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 18 Apr 2011 08:17:09 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 18 Apr 2011 11:19:13 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Mon, 18 Apr 2011 11:15:55 -0400 Thread-Topic: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQ Message-ID: 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: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:21:14 -0000 All, this is to start a two week working group poll on whether to make draft-kompella-mpls-entropy-label an mpls wg document. Please send your comments to the mpls@ietf.org mailing list. The poll ends on May 3rd.=20 thanks Ross (as WG co-chair) From wim.henderickx@alcatel-lucent.com Mon Apr 18 08:38:50 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4AC44E0776 for ; Mon, 18 Apr 2011 08:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.031 X-Spam-Level: X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyfmgrz5Mh3H for ; Mon, 18 Apr 2011 08:38:49 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfc.amsl.com (Postfix) with ESMTP id 63F5EE06A2 for ; Mon, 18 Apr 2011 08:38:48 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3IFciJk002448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Apr 2011 17:38:47 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 18 Apr 2011 17:38:44 +0200 From: "Henderickx, Wim (Wim)" To: Ross Callon , "mpls@ietf.org" Date: Mon, 18 Apr 2011 17:38:43 +0200 Thread-Topic: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQAADxFeA= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67185180C5@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:38:50 -0000 support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: maandag 18 april 2011 17:16 To: mpls@ietf.org Subject: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG docume= nt All, this is to start a two week working group poll on whether to make draft-kompella-mpls-entropy-label an mpls wg document. Please send your comments to the mpls@ietf.org mailing list. The poll ends on May 3rd.=20 thanks Ross (as WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From dave.mcdysan@verizon.com Mon Apr 18 08:39:05 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D3805E080C for ; Mon, 18 Apr 2011 08:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+dwuumgfNu1 for ; Mon, 18 Apr 2011 08:39:05 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by ietfc.amsl.com (Postfix) with ESMTP id 08901E080D for ; Mon, 18 Apr 2011 08:39:04 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p3IFcrd8011140 for ; Mon, 18 Apr 2011 11:38:54 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.64,232,1301875200"; d="scan'208";a="32518133" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 18 Apr 2011 15:38:38 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.15]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Mon, 18 Apr 2011 11:38:37 -0400 To: Ross Callon , Mpls Date: Mon, 18 Apr 2011 11:38:36 -0400 Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acv93q+DEGXrW/KISdKKhYlfS6SKlw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:39:06 -0000 I support making this a MPLS wg document. It appears to be a viable solution direction to meet (at least partially) a number of requirements stated in the rtgwg draft that recently passed the last call stage: http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-04.txt In particular, the relevant requirements from this draft are at least FR#3, FR#5, FR#11, FR#14, FR#19, and FR#21. Thanks, Dave On Monday4/18/11 11:15 AM, "Ross Callon" wrote: >All, > >this is to start a two week working group poll on whether to make >draft-kompella-mpls-entropy-label an mpls wg document. > >Please send your comments to the mpls@ietf.org mailing list. > >The poll ends on May 3rd. > >thanks Ross (as WG co-chair) >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From prvs=108960e7ba=edwin.mallette@bhnis.com Mon Apr 18 09:35:38 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0341EE06D9 for ; Mon, 18 Apr 2011 09:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9OUY2hzUJOc for ; Mon, 18 Apr 2011 09:35:37 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by ietfc.amsl.com (Postfix) with ESMTP id 68B65E0685 for ; Mon, 18 Apr 2011 09:35:37 -0700 (PDT) Received: from pps.filterd (mx2 [127.0.0.1]) by mx2.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p3IGZFcA007189; Mon, 18 Apr 2011 12:35:36 -0400 Received: from cntpaowa2.corp.local ([10.225.4.6]) by mx2.mybrighthouse.com with ESMTP id vrrgyr4en-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Apr 2011 12:35:36 -0400 Received: from CNEMAIL.corp.local ([10.225.1.130]) by cntpaowa2.corp.local ([10.225.4.6]) with mapi; Mon, 18 Apr 2011 12:35:36 -0400 From: "Mallette, Edwin" To: Ross Callon , "mpls@ietf.org" Date: Mon, 18 Apr 2011 12:35:34 -0400 Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acv95qUSU0A079fiS5e5I4y4GlhzdA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104180104 Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:35:38 -0000 /Support On 4/18/11 11:15 AM, "Ross Callon" wrote: >All, > >this is to start a two week working group poll on whether to make >draft-kompella-mpls-entropy-label an mpls wg document. > >Please send your comments to the mpls@ietf.org mailing list. > >The poll ends on May 3rd. > >thanks Ross (as WG co-chair) >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. From lberger@labn.net Mon Apr 18 12:23:46 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 88118E07FF for ; Mon, 18 Apr 2011 12:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iWq9Lwla8yc for ; Mon, 18 Apr 2011 12:23:45 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by ietfc.amsl.com (Postfix) with SMTP id 642FBE0694 for ; Mon, 18 Apr 2011 12:23:45 -0700 (PDT) Received: (qmail 22461 invoked by uid 0); 18 Apr 2011 19:23:44 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 18 Apr 2011 19:23:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=c1b99aOCyQh/mUfnGhSQ3wB4EbgeCEIyMT7YDinPDB7NtS5+LVdoRvAD2UJMWDl0nkK5oC5XxvI80P1srtzjYPrDoZ9BWiWsFGUQVoJJa5MEEDct5VQk8dTir2IK899V; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QBu2y-0002mP-CA; Mon, 18 Apr 2011 13:23:44 -0600 Message-ID: <4DAC8FB7.2080603@labn.net> Date: Mon, 18 Apr 2011 15:23:35 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: mpls@ietf.org, ospf@ietf.org, isis-wg@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [mpls] Fwd: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:23:46 -0000 The enclosed last call is taking place in CCAMP. Please send any comments to ccamp@ietf.org. Thank you, Lou -------- Original Message -------- Subject: 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib Date: Mon, 18 Apr 2011 15:19:27 -0400 From: Lou Berger To: CCAMP This mail begins a 2nd WG last call on: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08 The draft has been updated after the earlier working group primarily based on MIB Dr. review and discussion on the ccamp list. This working group last call ends on May 2nd. This LC will be announced on the MPLS, OSPF, and ISIS WG lists. Please send comments to the CCAMP mailing list. Lou (and Deborah) From ning.so@verizonbusiness.com Mon Apr 18 12:26:32 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68F48E070C for ; Mon, 18 Apr 2011 12:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPK-9e4p8Ydt for ; Mon, 18 Apr 2011 12:26:31 -0700 (PDT) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by ietfc.amsl.com (Postfix) with ESMTP id CA0A5E06A0 for ; Mon, 18 Apr 2011 12:26:31 -0700 (PDT) Received: from omzismtp02.vzbi.com ([unknown] [165.122.46.167]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LJV006974NRVC80@firewall.verizonbusiness.com> for mpls@ietf.org; Mon, 18 Apr 2011 19:26:16 +0000 (GMT) Received: from omzismtp02.vzbi.com ([unknown] [127.0.0.1]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LJV0043D4NRVZ00@omzismtp02.vzbi.com> for mpls@ietf.org; Mon, 18 Apr 2011 19:26:15 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([unknown] [153.39.68.166]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LJV0041F4NRW300@omzismtp02.vzbi.com> for mpls@ietf.org; Mon, 18 Apr 2011 19:26:15 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 19:26:15 +0000 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_01CBFDFE.7B93E41E" Date: Mon, 18 Apr 2011 19:26:14 +0000 Message-id: <14584D6EE26B314187A4F68BA20606000729D349@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG Thread-index: Acv9/mzR4JmnF5nqTxe8+jVTzK8YfA== From: "So, Ning" To: mpls@ietf.org X-OriginalArrivalTime: 18 Apr 2011 19:26:15.0455 (UTC) FILETIME=[7C0712F0:01CBFDFE] Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:26:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFDFE.7B93E41E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support. =20 =20 Best regards, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 =20 All, =20 this is to start a two week working group poll on whether to make draft-kompella-mpls-entropy-label an mpls wg document. =20 Please send your comments to the mpls@ietf.org mailing list. =20 The poll ends on May 3rd.=20 =20 thanks Ross (as WG co-chair) =20 ------_=_NextPart_001_01CBFDFE.7B93E41E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Yes/support.

     

     

    Best = regards,

     

    Ning = So

    Network = Evolution Planning

    Verizon, = Inc.

    (office) = 972-729-7905

    (Cell) = 972-955-0914

     

     

    All,

     

    this = is to start a two week working group poll on whether to make = draft-kompella-mpls-entropy-label an mpls wg document.

     

    Please = send your comments to the mpls@ietf.org mailing = list.

     

    The poll ends on May 3rd.

     

    thanks = Ross (as WG co-chair)

     

    ------_=_NextPart_001_01CBFDFE.7B93E41E-- From akatlas@gmail.com Mon Apr 18 12:59:33 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE791E0877 for ; Mon, 18 Apr 2011 12:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETp95hsKW3Wc for ; Mon, 18 Apr 2011 12:59:33 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 2C593E081F for ; Mon, 18 Apr 2011 12:59:33 -0700 (PDT) Received: by iwn39 with SMTP id 39so5532096iwn.31 for ; Mon, 18 Apr 2011 12:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U9xxHDqgHMLrERIBk77irIpz0IJZBgZubIHIVOVJJ4c=; b=g7pkJqGUNp9Ef/k5mNFl3UZYxoyiQnEU/alkRZ1a5qHKc/V30CjLYLMez24JUiD+65 P4qoMEbHJBF5qktBzpM++QcLl/52KbRwp8SabcohDZQozPZ1dnjx6zakB88svSnoFC9U j0sCXHr4QvLRRY8OYbEaiNFwG/OKUiN1C8IX0= 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=io8P5HkMPtsYt/cfZeksOwifjK0lph+hF5gATY8cJgfiOxfydwa1OKmNBIt2C5Wl7z 9kc9PU/1Pl9Xz8SybujZwoCe6tSR6qFo64hfY4aj3Iz3vnCHbBWqQC3Tq7dg7Rkj4tyo xtmHFxg5hOSGF/rsr52dGDRsuVM9GwUQrQfcs= MIME-Version: 1.0 Received: by 10.43.55.141 with SMTP id vy13mr4161366icb.477.1303156772661; Mon, 18 Apr 2011 12:59:32 -0700 (PDT) Received: by 10.42.3.67 with HTTP; Mon, 18 Apr 2011 12:59:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2011 15:59:32 -0400 Message-ID: From: Alia Atlas To: Ross Callon Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:59:33 -0000 I support. It's a nice solution to a real problem. Alia On Mon, Apr 18, 2011 at 11:15 AM, Ross Callon wrote: > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From ping@pingpan.org Mon Apr 18 15:03:18 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4CB43E0821 for ; Mon, 18 Apr 2011 15:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz-F4DwRvV0s for ; Mon, 18 Apr 2011 15:03:17 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfc.amsl.com (Postfix) with SMTP id 9F64EE067C for ; Mon, 18 Apr 2011 15:03:16 -0700 (PDT) Received: from mail-vx0-f174.google.com ([209.85.220.174]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTay1JNRldVhJkaxcJUYQQovtb52r1vho@postini.com; Mon, 18 Apr 2011 15:03:16 PDT Received: by mail-vx0-f174.google.com with SMTP id 39so5551686vxi.5 for ; Mon, 18 Apr 2011 15:03:16 -0700 (PDT) Received: by 10.52.71.148 with SMTP id v20mr2623995vdu.266.1303164196117; Mon, 18 Apr 2011 15:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.169.2 with HTTP; Mon, 18 Apr 2011 15:02:36 -0700 (PDT) In-Reply-To: References: From: Ping Pan Date: Mon, 18 Apr 2011 15:02:36 -0700 Message-ID: To: Ross Callon Content-Type: multipart/alternative; boundary=20cf307cfcfcfe5e5b04a1388e16 Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:03:18 -0000 --20cf307cfcfcfe5e5b04a1388e16 Content-Type: text/plain; charset=ISO-8859-1 Support. - Ping On Mon, Apr 18, 2011 at 8:15 AM, Ross Callon wrote: > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf307cfcfcfe5e5b04a1388e16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support.

    - Ping


    On Mon, Apr 18, 2011 at 8:15 AM, Ross Ca= llon <rcallon@j= uniper.net> wrote:
    All,

    this is to start a two week working group poll on whether to make
    draft-kompella-mpls-entropy-label an mpls wg document.

    Please send your comments to the mpls@ietf= .org mailing list.

    The poll ends on May 3rd.

    thanks Ross (as WG co-chair)
    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls

    --20cf307cfcfcfe5e5b04a1388e16-- From jiangyuanlong@huawei.com Mon Apr 18 18:10:39 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9FDEDE06ED for ; Mon, 18 Apr 2011 18:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.943 X-Spam-Level: * X-Spam-Status: No, score=1.943 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7uNEWqg8D3D for ; Mon, 18 Apr 2011 18:10:39 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 00752E0679 for ; Mon, 18 Apr 2011 18:10:39 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV00FV3KLORX@szxga05-in.huawei.com> for mpls@ietf.org; Tue, 19 Apr 2011 09:10:36 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV007CDKLOWK@szxga05-in.huawei.com> for mpls@ietf.org; Tue, 19 Apr 2011 09:10:36 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 09:10:32 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.159]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 09:10:35 +0800 Date: Tue, 19 Apr 2011 01:10:34 +0000 From: Jiangyuanlong In-reply-to: X-Originating-IP: [10.70.40.77] To: Ross Callon , "mpls@ietf.org" Message-id: <3B0A1BED22CAD649A1B3E97BE5DDD68B037291D9@SZXEML514-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQABTlY7A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 01:10:39 -0000 U3VwcG9ydC4NCg0KWXVhbmxvbmcNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb3Nz IENhbGxvbg0Kt6LLzcqxvOQ6IDIwMTHE6jTUwjE4yNUgMjM6MTYNCsrVvP7IyzogbXBsc0BpZXRm Lm9yZw0K1vfM4jogW21wbHNdIHBvbGwgb24gZHJhZnQta29tcGVsbGEtbXBscy1lbnRyb3B5LWxh YmVsIGFzIE1QTFMgV0cgZG9jdW1lbnQNCg0KQWxsLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdv IHdlZWsgd29ya2luZyBncm91cCBwb2xsIG9uIHdoZXRoZXIgdG8gbWFrZQ0KZHJhZnQta29tcGVs bGEtbXBscy1lbnRyb3B5LWxhYmVsIGFuIG1wbHMgd2cgZG9jdW1lbnQuDQoNClBsZWFzZSBzZW5k IHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHNAaWV0Zi5vcmcgbWFpbGluZyBsaXN0Lg0KDQpUaGUg cG9sbCBlbmRzIG9uIE1heSAzcmQuIA0KDQp0aGFua3MgUm9zcyAoYXMgV0cgY28tY2hhaXIpDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWls aW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0K From venkatflex@gmail.com Mon Apr 18 18:42:08 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 564F2E0694 for ; Mon, 18 Apr 2011 18:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWV0NMvQZI+S for ; Mon, 18 Apr 2011 18:42:07 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id C36A7E0692 for ; Mon, 18 Apr 2011 18:42:07 -0700 (PDT) Received: by vxg33 with SMTP id 33so4949115vxg.31 for ; Mon, 18 Apr 2011 18:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=weVfZK/niKZ8Vv1hx0sWJolDltBcft8IYq46c3poqvs=; b=waiy5YhSBlXrdiJGXMUGre53PFvtiMfNiDRFKn04jNryBjSGG8+6djQeaxSkZ0zR6d 2wCWv5EhaIJNQxKe1uQDbmss/fa/nqlBceEExV4yOBBeKhvhXjcaxPWEQScTwiFLdF8r Ftw4y9KMOJO6e0piQ/AK2i+wHVs1lIhCxp+1U= 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=Nnb/t/MkMgnPignoiTwtGpFT5L1Y8JUnH5qE9usRFjt/1H1uCEm5p95vIJUh5xertx 4Mfez1pXCFjClX6hlBa0+13k+7fwEHx4H1YjSllR7FtDMdpjf6PusT44YOrX8nGZmeJq hJn0TmySr3FmgQ2esbWkRFk1QH/ecQxR1B1ww= MIME-Version: 1.0 Received: by 10.52.100.70 with SMTP id ew6mr3321470vdb.95.1303176677078; Mon, 18 Apr 2011 18:31:17 -0700 (PDT) Received: by 10.52.158.97 with HTTP; Mon, 18 Apr 2011 18:31:17 -0700 (PDT) In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B037291D9@SZXEML514-MBS.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B037291D9@SZXEML514-MBS.china.huawei.com> Date: Mon, 18 Apr 2011 21:31:17 -0400 Message-ID: From: venkatesan mahalingam To: mpls , Ross Callon Content-Type: multipart/alternative; boundary=20cf3071c6d2eab6db04a13b76e7 Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 01:42:08 -0000 --20cf3071c6d2eab6db04a13b76e7 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Yes/Support. Cheers, Venkat. 2011/4/18 Jiangyuanlong > Support. > > Yuanlong > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] = =B4=FA=B1=ED Ross Callon > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C218=C8=D5 23:16 > =CA=D5=BC=FE=C8=CB: mpls@ietf.org > =D6=F7=CC=E2: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG= document > > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > 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 > --20cf3071c6d2eab6db04a13b76e7 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Yes/Support.

    Cheers,
    Venkat.

    2011/4/18 Jiangyuanlong <jiangyuanlong@huawei.com>
    =
    Support.

    Yuanlong

    -----=D3=CA=BC=FE=D4=AD=BC=FE-----
    =B7=A2=BC=FE=C8=CB: mpls-bounces@i= etf.org [mailto:mpls-bounces@i= etf.org] =B4=FA=B1=ED Ross Callon
    =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C218=C8=D5 23:16
    =CA=D5=BC=FE=C8=CB: mpls@ietf.org
    =D6=F7=CC=E2: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG d= ocument

    All,

    this is to start a two week working group poll on whether to make
    draft-kompella-mpls-entropy-label an mpls wg document.

    Please send your comments to the mpls@ietf= .org mailing list.

    The poll ends on May 3rd.

    thanks Ross (as WG co-chair)
    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls
    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls

    --20cf3071c6d2eab6db04a13b76e7-- From shane@castlepoint.net Mon Apr 18 19:14:35 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B6EC7E0684 for ; Mon, 18 Apr 2011 19:14:35 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF2Il0bg5bDJ for ; Mon, 18 Apr 2011 19:14:35 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfc.amsl.com (Postfix) with ESMTP id 47C2EE0674 for ; Mon, 18 Apr 2011 19:14:35 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id B4766268037; Mon, 18 Apr 2011 20:14:34 -0600 (MDT) Received: from mbp.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 18 Apr 2011 20:14:34 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=62232; syn-fingerprint=65535:56:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Mon, 18 Apr 2011 20:14:19 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: To: Ross Callon X-Mailer: Apple Mail (2.1084) Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:14:35 -0000 On Apr 18, 2011, at 9:15 AM, Ross Callon wrote: > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) This is probably not a surprise, but I support this becoming a WG doc. :-) -shane From mach.chen@huawei.com Mon Apr 18 19:27:35 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CCA85E06FE for ; Mon, 18 Apr 2011 19:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.694 X-Spam-Level: X-Spam-Status: No, score=-3.694 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P09HcQva6hur for ; Mon, 18 Apr 2011 19:27:35 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 12982E06E3 for ; Mon, 18 Apr 2011 19:27:35 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV00J5GO5WEI@szxga05-in.huawei.com> for mpls@ietf.org; Tue, 19 Apr 2011 10:27:32 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV00JP6O5WFG@szxga05-in.huawei.com> for mpls@ietf.org; Tue, 19 Apr 2011 10:27:32 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 10:27:28 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 10:27:31 +0800 Date: Tue, 19 Apr 2011 02:26:43 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.38] To: Ross Callon , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQABVCp8A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:27:35 -0000 Yes/Support. One comments: Section 7 says: "Since MPLS-TP does not use ECMP, entropy labels are not applicable to an MPLS-TP deployment.", but there are two application scenarios mentioned in the draft: LAG and ECMP. MPLS-TP does not use ECMP, but LAG may be used IMHO. So, entropy label may be applicable to an MPLS-TP deployment when LAG is used. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Ross Callon > Sent: Monday, April 18, 2011 11:16 PM > To: mpls@ietf.org > Subject: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG > document > > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Ian.B.Stanley@team.telstra.com Mon Apr 18 19:28:15 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ACDCFE067E for ; Mon, 18 Apr 2011 19:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko13c-4vD-jx for ; Mon, 18 Apr 2011 19:28:15 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfc.amsl.com (Postfix) with ESMTP id 980AEE06CA for ; Mon, 18 Apr 2011 19:28:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,236,1301839200"; d="scan'208";a="32791851" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 19 Apr 2011 12:28:13 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6320"; a="24023126" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdvi.tcif.telstra.com.au with ESMTP; 19 Apr 2011 12:28:10 +1000 Received: from WSMSG3152V.srv.dir.telstra.com ([172.49.40.155]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 19 Apr 2011 12:28:12 +1000 From: "Stanley, Ian B" To: Shane Amante , Ross Callon Date: Tue, 19 Apr 2011 12:28:09 +1000 Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acv+OW3+ROqBgZF1Q9eU4db0EOlDNg== Message-ID: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:28:15 -0000 Support ian =20 Regards, Ian Stanley Transport & Routing Architecture | AOM 02 9396 8508 0419 257221 This communication may contain CONFIDENTIAL or copyright information of Telstra Corporation Limited (ABN 33 051 775 556). If you are not an intended recipient, you MUST NOT keep, forward, copy, use, save or rely on this communication, and any such action is unauthorised and prohibited. If you have received this communication in error, please reply to this email to notify the sender of its incorrect delivery, and then delete both it and your reply. Thank you. =20 On 19/04/11 12:14 PM, "Shane Amante" wrote: > >On Apr 18, 2011, at 9:15 AM, Ross Callon wrote: >> All, >>=20 >> this is to start a two week working group poll on whether to make >> draft-kompella-mpls-entropy-label an mpls wg document. >>=20 >> Please send your comments to the mpls@ietf.org mailing list. >>=20 >> The poll ends on May 3rd. >>=20 >> thanks Ross (as WG co-chair) > >This is probably not a surprise, but I support this becoming a WG doc. >:-) > >-shane > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From thomas.morin@orange-ftgroup.com Tue Apr 19 00:30:51 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BAD49E068B for ; Tue, 19 Apr 2011 00:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdPpeqRvE+UR for ; Tue, 19 Apr 2011 00:30:51 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfc.amsl.com (Postfix) with ESMTP id DBE56E0674 for ; Tue, 19 Apr 2011 00:30:50 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C5E546C0003 for ; Tue, 19 Apr 2011 09:31:24 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id BDBBD6C0002 for ; Tue, 19 Apr 2011 09:31:24 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 09:30:49 +0200 Received: from [10.193.71.121] ([10.193.71.121]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 09:30:48 +0200 Message-ID: <4DAD3A28.8010400@orange-ftgroup.com> Date: Tue, 19 Apr 2011 09:30:48 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: X-TagToolbar-Keys: D20110419093048732 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Apr 2011 07:30:48.0130 (UTC) FILETIME=[B3C2DA20:01CBFE63] Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 07:30:51 -0000 Support. -Thomas Ross Callon a écrit : > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From zhang.fei3@zte.com.cn Tue Apr 19 04:12:41 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B4EAE072B; Tue, 19 Apr 2011 04:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.812 X-Spam-Level: X-Spam-Status: No, score=-98.812 tagged_above=-999 required=5 tests=[AWL=-1.177, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XtMV0n-ziGk; Tue, 19 Apr 2011 04:12:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfc.amsl.com (Postfix) with ESMTP id A938FE06C8; Tue, 19 Apr 2011 04:12:37 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 125203246204556; Tue, 19 Apr 2011 19:11:39 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4886.4317891712; Tue, 19 Apr 2011 19:12:29 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3JBCPXe047096; Tue, 19 Apr 2011 19:12:25 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <6477E10CC7D76444A479B9AC31F262A9DDDB4723@ESESSCMS0365.eemea.ericsson.se> To: Attila Takacs MIME-Version: 1.0 X-KeepSent: 35B01643:99EC0612-48257877:00390B84; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 19 Apr 2011 19:12:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-19 19:12:24, Serialize complete at 2011-04-19 19:12:24 Content-Type: multipart/alternative; boundary="=_alternative 003D8DBF48257877_=" X-MAIL: mse01.zte.com.cn p3JBCPXe047096 Cc: "mpls@ietf.org" , "ccamp@ietf.org" , mpls-bounces@ietf.org, ccamp-bounces@ietf.org Subject: Re: [mpls] [CCAMP] Requirement for singled ended provisioning of associated bidirectional LSPs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:12:41 -0000 This is a multipart message in MIME format. --=_alternative 003D8DBF48257877_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQXR0aWxhLCANCg0Kc2VlIGlubGluZSBbRmVpXQ0KDQpCZXN0IHJlZ2FyZHMNCg0KRmVpDQoN Cg0KDQpBdHRpbGEgVGFrYWNzIDxBdHRpbGEuVGFrYWNzQGVyaWNzc29uLmNvbT4gDQq3orz+yMs6 ICBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQoyMDExLTA0LTE5IDE3OjM4DQoNCsrVvP7Iyw0KTG91 IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4sICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYu b3JnPg0Ks63LzQ0KDQrW98ziDQpSZTogW0NDQU1QXSBSZXF1aXJlbWVudCBmb3Igc2luZ2xlZCBl bmRlZCBwcm92aXNpb25pbmcgb2YgYXNzb2NpYXRlZCANCmJpZGlyZWN0aW9uYWwgTFNQcw0KDQoN Cg0KDQoNCg0KSGkgYWxsLCANClBsZWFzZSBzZWUgaW5saW5lIFthdF0uDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4u bmV0XSANClNlbnQ6IEZyaWRheSwgQXByaWwgMTUsIDIwMTEgMzo1MCBQTQ0KVG86IEF0dGlsYSBU YWthY3MNCkNjOiBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUmVxdWlyZW1lbnQgZm9yIHNpbmds ZWQgZW5kZWQgcHJvdmlzaW9uaW5nIG9mIGFzc29jaWF0ZWQgDQpiaWRpcmVjdGlvbmFsIExTUHMN Cg0KW1N1YmplY3Q6IFdhcyBSZTogW0NDQU1QXSBwb2xsIG9uIG1ha2luZw0KZHJhZnQtemhhbmct bXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0IGEgV0cgZG9jdW1lbnRdDQoNCj4g MikgUG9pbnQgcmVsYXRlZCB0byB0aGUgY29udGVudHMgb2YgdGhlIGRyYWZ0Lg0KPg0KPiBBcyB0 aGlzIGlzIGEgdGVjaG5pY2FsIHBvaW50LCBhbmQgaW5kZXBlbmRlbnQgb2YgdGhlIHBvbGwuICBJ J2xsIHN0YXJ0IA0KPiBhIG5ldyB0aHJlYWQgb24gdGhpcyBpbiBhIHNlcGFyYXRlIG1haWwuDQo+ DQoNCkFzIEkgKGFzIFdHIG1lbWJlciwgbm90IGNoYWlyKSB1bmRlcnN0YW5kIGl0LCB5b3UgYXJl IHF1ZXN0aW9uaW5nIHRoZSANCnJlcXVpcmVtZW50IGZvciB0aGUgInNpbmdsZSBzaWRlZCBtb2Rl Ii4gIEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgcXVlc3Rpb24uIA0KIEFzIHlvdSBwb2ludGVkIG91 dCwgSSBiZWxpZXZlIEkgc3VnZ2VzdCB0aGF0IHRoaXMgcXVlc3Rpb24gYmUgcmFpc2VkLCBieSAN CnRoZSBhdXRob3JzLCBvbiB0aGUgVFAgbGlzdC4NCg0KW2F0XSBGZWksIGlzL3dhcyB0aGVyZSBh bnkgY29uY2x1c2lvbiBvbiB0aGUgVFAgbGlzdD8NCg0KW0ZlaV1BbHRob3VnaCBJIHB1dCBpdCBv biB0aGUgVFAgbGlzdCwgdGhlcmUgd2FzIG5vIGRpc2N1c3Npb24gb24gdGhpcyANCnRvcGljLiBT ZWUgdGhlIG9sZCBsaW5rIDogDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bXBscy10cC9jdXJyZW50L21zZzA1Mjc3Lmh0bWwNCiAgICAgSSBmb3J3YXJkIHRoZSBkaXNjdXNz aW9uIHRvIHRoZSBNUExTIGxpc3QgdGhpcyB0aW1lLCBob3BlIHdlIGNhbiBnZXQgDQptb3JlIGZl ZWRiYWNrLg0KDQoNClJGQzU2NDUgc2VlbXMgdG8gYWxsb3cgZm9yIGluZGVwZW5kZW50IHByb3Zp c2lvbmluZyBvZiBhc3NvY2lhdGVkLCBidXQgaXQgDQpkb2Vzbid0IHByZWNsdWRlIHRoZSAic2lu Z2xlIHNpZGVkIG1vZGUiLiAgSXQgYWxzbyBoYXMgcmVxdWlyZW1lbnRzDQoxMSBhbmQgMTIgd2hp Y2ggYXJlIGNlcnRhaW5seSBmYWNpbGl0YXRlZCBieSAic2luZ2xlIHNpZGVkIG1vZGUiLg0KDQpb YXRdIEkgdGhpbmsgcmVxdWlyZW1lbnRzIDExIGFuZCAxMiBjYW4gYmUgZnVsZmlsbGVkIGJ5IHVz aW5nIGFuIA0KYXNzb2NpYXRpb24gaWQgb24gYm90aCBMU1BzIHdpdGggImRvdWJsZS1zaWRlZCBt b2RlIiBhdCBMU1AgZXN0YWJsaXNobWVudCANCm9yIGF0IGEgbGF0ZXIgcG9pbnQgZm9yIGFzc29j aWF0aW9uLiANCg0KW0ZlaV0gQWdyZWUsIGJ1dCB0aGUgY29tcGxleGl0eSBvZiAiZG91YmxlLXNp ZGVkIG1vZGUiIGlzIGFsbW9zdCB0aGUgc2FtZSANCmFzIGNvbXBhcmVkIHRvICJzaW5nbGUtc2lk ZWQgbW9kZSIgYXQgTFNQIGVzdGFibGlzaG1lbnQuDQoNCiAgICAgQXNzdW1lIHRoYXQgdGhlIHRp bWUgY29zdHMgZm9yIHBhdGggYW5kIHJlc3YgbWVzc2FnZSBhcmUgdGhlIHNhbWUgDQp2bGF1ZSAi VEMiIA0KDQogICAgICBGb3IgInNpbmdsZS1zaWRlZCBtb2RlIiwgdGhlIHRpbWUgY29zdHMgYXJl IDNUQ3MoMlRDcyBmb3IgTFNQMSBmcm9tIA0Kd2VzdCB0byBlYXN0IHBsdXMgMVRDIGZvciBMU1Ay IGZyb20gZWFzdCB0byB3ZXN0KS4NCiAgICAgIEFzIGZvciAiZG91YmxlLXNpZGVkIG1vZGUiLCB0 aGUgYmluZGluZyBoYXBwZW5zIHdoZW4gdGhlIHBhdGggDQpyZWZyZXNoIG1lc3NhZ2UgYXJlIHNl bnQgb3V0IGJhc2VkIG9uIHRoZSBzb2x1dGlvbiBkZXNjcmliZWQgaW4gdGhlIA0KZG9jdW1lbnQs IHNvIHRoZSB0aW1lIGNvc3QgaXMgZ2VuZXJhbGx5IHRoZSBzYW1lIDpvbmUgcGF0aC1yZXN2IGNp cmNsZSANCnBsdXMgb25lIHBhdGggbWVzc2FnZSBwcm9jZXNzaW5nLiANCg0KSW4gdGhlIGNhc2Ug TFNQcyBzaG91bGQgYmUgYXNzb2NpYXRlZCBsYXRlciBvbiwgYWZ0ZXIgZXN0YWJsaXNobWVudCwg YSANCnNpbXBsZSAic2luZ2xlIHNpZGVkIiBzb2x1dGlvbiBtaWdodCBiZSB1c2VkIHRvIGFsbG93 IHNpbmdsZS10b3VjaCANCmFzc29jaWF0aW9uLCB0aGlzIGlzIG1haW5seSBhbiBvcHRpbWl6YXRp b24gbm90IGEgcmVxdWlyZWQgZmVhdHVyZSBJIA0KZ3Vlc3MuIEluIHRoaXMgY2FzZSBiZXNpZGVz IHRoZSBhc3NvY2lhdGlvbiBpZCBvbmUgbWF5IGFsc28gc2VuZCB0aGUgTFNQIA0KaWQgb2YgdGhl IHJldmVyc2UgZGlyZWN0aW9uIHRvIHdoaWNoIHRoZSBhc3NvY2lhdGlvbiBzaG91bGQgYmUgDQpl c3RhYmxpc2hlZCwgd2hpY2ggaW4gdHVybiB3b3VsZCByZXN1bHQgaW4gdGhlIHJlc2lnbmFsbGlu ZyBvZiB0aGF0IExTUCANCndpdGggdGhlIGFzc29jaWF0aW9uIGlkLiBEb2luZyBtb3JlIGVsYWJv cmF0ZSAic2luZ2xlLXNpZGVkIiBzaWduYWxpbmcsIA0KZS5nLCBpbmNsdWRpbmcgcmV2ZXJzZSBi dyBhbmQgcW9zIHBhcmFtZXRlcnMgc2VlbXMgdG8gbWUgdG8gYWRkIA0KdW5uZWNlc3NhcnkgY29t cGxleGl0eS4gDQoNCltGZWldIEluIHRoaXMgY2FzZSwgdGhlIGFzc29jaWF0aW9uIGlkIGlzIHRo ZSBMU1AgaWQgb2YgdGhlIHJldmVyc2UgDQpkaXJlY3Rpb24gKCJpZiBrbm93biwgaXQgTUFZIGJl IHNldCB0byB0aGUgTFNQIElEIG9mIHRoZSBhc3NvY2lhdGVkIA0KcmV2ZXJzZSBMU1AiKSwgdGhl cmUgaXMgbm8gbmVlZCB0byBjYXJyeSByZXZlcnNlIGJ3IGFuZCBxb3MgcGFyYW1ldGVycy4gDQpU aGV5IGFyZSBvbmx5IGNhcnJpZWQgd2hlbiB0aGUgcmV2ZXJzZSBMU1AgZG9lcyBub3QgZXhpc3Qu IEkgd2lsbCBjbGFyaWZ5IA0KaXQgaW4gbmV4dCB2ZXJzaW9uLg0KDQogSXQgaXMgbW9yZSBjb21w bGV4IGZvciBkb3VibGUgc2lkZWQgcHJvdmlzaW9uZyBtb2RlIGluIHRoaXMgY2FzZSB0aGF0IHRo ZSANCkxTUHMgYXJlIGFzc29jaWF0ZWQgYWZ0ZXIgZXN0YWJsaXNobWVudCwgYW5kIHRoZSBjb3N0 IGlzIG9uZSBwYXRoLXJlc3YgDQpyZWZyZXNoIGNpcmNsZSBwbHVzIG9uZSBwYXRoIHJlZnJlc2gg bWVzc2FnZSBwcm9jZXNzaW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQpBdHRpbGENCg0KDQoNCg0KDQpJ IGJlbGlldmUgeW91IGFsc28gcmFpc2Ugc29tZSB2YWxpZCBpc3N1ZXMgd2l0aCB0aGUgY3VycmVu dCBkZWZpbml0aW9uIG9mIA0KdGhlIHByb2Nlc3NpbmcgcnVsZXMuIEknbGwgZGVmZXIgbXkgY29t bWVudHMgb24gdGhpcyBmb3Igbm93Lg0KDQpMb3UNCg0KQlRXIFRoaXMgaXNuJ3QgdGhlIGZpcnN0 IHRpbWUgdGhhdCAic2luZ2xlIHNpZGVkIG1vZGUiIGhhcyBiZWVuIHN1Z2dlc3QuDQpJIHNlZW0g dG8gcmVtZW1iZXIgZGlzY3Vzc2luZyBhIHByb3Bvc2FsIG9uIHRoaXMgZnJvbSBKdWhhIEhlaW5h bmVuIGF0IHRoZSANCkFkZWxhaWRlIElFVEYuICBJIGFsc28ga25vdyBvZiBvbmUgdmVuZG9yLXNw ZWNpZmljIGltcGxlbWVudGF0aW9uIHRoYXQgDQpuZXZlciBtYWRlIGl0IHRvIHRoZSBmaWVsZCBv ciB0aGUgV0cuDQoNCk9uIDQvMTUvMjAxMSA5OjQyIEFNLCBMb3UgQmVyZ2VyIHdyb3RlOg0KPiBB dHRpbGEsDQo+ICAgICAgICAgICAgICAgIFNvIHdlIGhhdmUgdHdvIHBvaW50cyBoZXJlOg0KPiAx KSBXRyBwcm9jZWR1cmUgcmVsYXRlZA0KPiANCj4gU28gdGhpcyBtYWlsIGlzIGluIHJlc3BvbnNl IHRvIGEgcG9sbC4gQXMgeW91ciBhbnN3ZXIgaXMgKGEpLiAgSSAoYXMNCj4gY2hhaXIpIGtub3cg aG93IHRvIGludGVycHJldCB5b3UgcG9zaXRpb24sIGkuZS4sICJZZXMvU3VwcG9ydCIuDQo+IA0K PiAyKSBQb2ludCByZWxhdGVkIHRvIHRoZSBjb250ZW50cyBvZiB0aGUgZHJhZnQuDQo+IA0KPiBB cyB0aGlzIGlzIGEgdGVjaG5pY2FsIHBvaW50LCBhbmQgaW5kZXBlbmRlbnQgb2YgdGhlIHBvbGwu ICBJJ2xsIHN0YXJ0IA0KPiBhIG5ldyB0aHJlYWQgb24gdGhpcyBpbiBhIHNlcGFyYXRlIG1haWwu DQo+IA0KPiBUaGFua3MsDQo+IExvdQ0KPiANCj4gT24gNC8xNC8yMDExIDE6MDYgUE0sIEF0dGls YSBUYWthY3Mgd3JvdGU6DQo+PiBIaSBMb3UsIGFsbCwNCj4+IEl0IHdvdWxkIGJlIG5pY2UgdG8g Y2xhcmlmeSB0aGUgc2NvcGUgb2YgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbi4gDQo+PiBJIHdvdWxk IHNheSAoYSkgaWYgdGhhdCBkb2VzIG5vdCBpbmNsdWRlIGNvbW1pdG1lbnQgdG8gd29yayBvbiB0 aGUgDQoic2luZ2xlIHNpZGVkIG1vZGUiLiBUbyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgdGhh dCBvcGVyYXRpb24gbW9kZSBpcyANCm5vdCByZXF1aXJlZCBmb3IgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIExTUHMuIFRoZXJlIGlzIG5vIGRpc2N1c3Npb24gaW4gDQp0aGUgZG9jdW1lbnQgYWJv dXQgd2hpY2ggb3BlcmF0aW9uIG1vZGUgaXMgcmVhbGx5IG5lZWRlZCwgaWYgSSdtIG5vdCANCm1p c3Rha2VuIHNpbWlsYXIgY29tbWVudHMgd2VyZSByYWlzZWQgaW4gQmVpamluZywgYnV0IHRoaXMg aXMgbm90IA0KYWRkcmVzc2VkIGluIHRoZSBkb2N1bWVudC4gSGVuY2UgbXkgY29uZnVzaW9uLg0K Pj4gVGhhbmtzLA0KPj4gQXR0aWxhDQo+PiANCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+PiBT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDEzLCAyMDExIDI6NDMgUE0NCj4+IFRvOiBBdHRpbGEgVGFr YWNzDQo+PiBDYzogY2NhbXBAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIHBvbGwg b24gbWFraW5nIA0KPj4gZHJhZnQtemhhbmctbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQt bHNwLTA0IGEgV0cgZG9jdW1lbnQNCj4+DQo+PiBBdHRpbGEsDQo+PiAgICAgICAgICAgICAgIFNv IEkgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnQsIGFuZCB3b3VsZCBsaWtlIHRvIGhhdmUgdGhpcyAN CmRpc2N1c3Npb24sIGJ1dCBJIHRoaW5rIEkgbmVlZCBzb21lIGNsYXJpZmljYXRpb24gZnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgDQp0aGUgcG9sbC4NCj4+ICBJJ20gdW5zdXJlIGlmIHlvdSdyZSBz YXlpbmc6DQo+PiAoYSkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IGJlY29taW5nIGEgV0cgZG9jdW1l bnQgYW5kIHdvdWxkIGxpa2UNCj4+ICAgICBkaXNjdXNzIHRoZSBwb2ludCByYWlzZWQgYmVsb3cg aW4gdGhlIGNvbnRleHQgb2YgYSBXRyBkb2N1bWVudCBvcg0KPj4gKGIpIGRvIE5PVCBzdXBwb3J0 IHRoaXMgZG9jdW1lbnQgYmVjb21pbmcgYSBXRyBkb2N1bWVudCB1bnRpbCB0aGUNCj4+ICAgICBw b2ludCB5b3UgcmFpc2UgYmVjb21lcyBhIFdHIGRvY3VtZW50DQo+Pg0KPj4gQ2FuIHlvdSBjbGFy aWZ5IGlmIHlvdSBtZWFuIChhKSBvciAoYik/DQo+Pg0KPj4gTG91DQo+Pg0KPj4gT24gNC8xMi8y MDExIDQ6MjcgUE0sIEF0dGlsYSBUYWthY3Mgd3JvdGU6DQo+Pj4gSGkgYXV0aG9ycywNCj4+Pg0K Pj4+IFlvdSB0YWxrIGFib3V0IHR3byBwcm92aXNpb25pbmcgbW9kZWxzOiAic2luZ2xlIiBhbmQg ImRvdWJsZSIgc2lkZWQgDQptb2Rlcy4gDQo+Pj4NCj4+PiBEb3VibGUgc2lkZWQgaXMgY2xlYXIs IGl0IHVzZXMgaW5kZXBlbmRlbnQgc2lnbmFsaW5nIGZvciB0aGUgdHdvIExTUHMuIA0KDQo+Pj4N Cj4+PiBTaW5nbGUgc2lkZWQsIGlmIEkgdW5kZXJzdG9vZCBjb3JyZWN0bHksIHNvbWVob3cgYmlu ZHMgdGhlIHR3byBMU1AgDQpzaWduYWxpbmcgcGhhc2VzIHRvZ2V0aGVyLiBJIGhhdmUgc29tZSBk b3VidHMgdGhhdCB0aGlzIG1vZGVsIGlzIG5lZWRlZC4gDQpJdCBzZWVtcyB0byBjb21wbGljYXRl IG9wZXJhdGlvbiBhbmQgaXQgYWxzbyBiZWdzIHRoZSBxdWVzdGlvbiB3aHkgbm90IHVzZSANCmJp ZGlyZWN0aW9uYWwgTFNQcyBpbnN0ZWFkLiANCj4+Pg0KPj4+IEkgdGhpbmsgdHdvIGluZGVwZW5k ZW50bHkgc2lnbmFsZWQgTFNQcyB3aXRoIHRoZSBhZGRpdGlvbiBvZiB0aGUgDQpwcm9wb3NlZCBB c3NvY2lhdGlvbiBvYmplY3Qgd291bGQgZG8gdGhlIGpvYiBhZGRyZXNzaW5nIHRoZSBhc3NvY2lh dGVkIA0KYmlkaXJlY3Rpb25hbCBMU1AgcmVxdWlyZW1lbnRzLCBzbyB0aGF0IHRyYW5zaXQgbm9k ZXMgYXJlIGFsc28gYXdhcmUgb2YgDQp0aGUgYmluZGluZy4NCj4+Pg0KPj4+IEJlc3QgcmVnYXJk cywNCj4+PiBBdHRpbGENCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4g RnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5v cmddIE9uIA0KPj4+IEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQo+Pj4gU2VudDogRnJpZGF5LCBBcHJp bCAwMSwgMjAxMSAxMToyNCBBTQ0KPj4+IFRvOiBjY2FtcEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6 IFtDQ0FNUF0gcG9sbCBvbiBtYWtpbmcNCj4+PiBkcmFmdC16aGFuZy1tcGxzLXRwLXJzdnB0ZS1l eHQtYXNzb2NpYXRlZC1sc3AtMDQgYSBXRyBkb2N1bWVudA0KPj4+DQo+Pj4gQWxsLA0KPj4+DQo+ Pj4gVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQo+Pj4gZHJhZnQt emhhbmctbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0IGEgY2NhbXAgd29ya2lu ZyBncm91cCANCmRvY3VtZW50LiBQbGVhc2Ugc2VuZCBtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRp bmcgInllcy9zdXBwb3J0Ig0KPj4+IG9yICJuby9kbyBub3Qgc3VwcG9ydCIuICBJZiBpbmRpY2F0 aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwgDQpyZXNlcnZhdGlvbnMgd2l0aCB0 aGUgZG9jdW1lbnQuDQo+Pj4NCj4+PiBUaGUgcG9sbCBlbmRzIEZyaWRheSBBcHJpbCAxNS4NCj4+ Pg0KPj4+IE11Y2ggdGhhbmtzLA0KPj4+IExvdSAoYW5kIERlYm9yYWgpDQo+Pj4NCj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IENDQU1QIG1h aWxpbmcgbGlzdA0KPj4+IENDQU1QQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4gQ0NBTVBAaWV0 Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+DQo+Pg0KPj4NCj4+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg0K --=_alternative 003D8DBF48257877_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEF0dGlsYSwgPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zZWUgaW5saW5lIDwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5bRmVpXTwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+QXR0aWxhIFRh a2FjcyAmbHQ7QXR0aWxhLlRha2Fjc0Blcmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO2NjYW1wLWJvdW5j ZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAx MS0wNC0xOSAxNzozODwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5Mb3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OywNCiZxdW90 O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbQ0NBTVBd IFJlcXVpcmVtZW50IGZvciBzaW5nbGVkDQplbmRlZCBwcm92aXNpb25pbmcgb2YgYXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIExTUHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhpIGFsbCwgPGJyPg0KUGxlYXNlIHNlZSBpbmxpbmUgW2F0 XS48YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSA8YnI+DQpTZW50OiBGcmlkYXks IEFwcmlsIDE1LCAyMDExIDM6NTAgUE08YnI+DQpUbzogQXR0aWxhIFRha2Fjczxicj4NCkNjOiBj Y2FtcEBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFJlcXVpcmVtZW50IGZvciBzaW5nbGVkIGVuZGVk IHByb3Zpc2lvbmluZyBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCkxTUHM8YnI+DQo8YnI+ DQpbU3ViamVjdDogV2FzIFJlOiBbQ0NBTVBdIHBvbGwgb24gbWFraW5nPGJyPg0KZHJhZnQtemhh bmctbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0IGEgV0cgZG9jdW1lbnRdPGJy Pg0KPGJyPg0KJmd0OyAyKSBQb2ludCByZWxhdGVkIHRvIHRoZSBjb250ZW50cyBvZiB0aGUgZHJh ZnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgdGhpcyBpcyBhIHRlY2huaWNhbCBwb2ludCwgYW5k IGluZGVwZW5kZW50IG9mIHRoZSBwb2xsLiAmbmJzcDtJJ2xsDQpzdGFydCA8YnI+DQomZ3Q7IGEg bmV3IHRocmVhZCBvbiB0aGlzIGluIGEgc2VwYXJhdGUgbWFpbC48YnI+DQomZ3Q7PGJyPg0KPGJy Pg0KQXMgSSAoYXMgV0cgbWVtYmVyLCBub3QgY2hhaXIpIHVuZGVyc3RhbmQgaXQsIHlvdSBhcmUg cXVlc3Rpb25pbmcgdGhlIHJlcXVpcmVtZW50DQpmb3IgdGhlICZxdW90O3NpbmdsZSBzaWRlZCBt b2RlJnF1b3Q7LiAmbmJzcDtJIHRoaW5rIHRoaXMgaXMgYSBnb29kIHF1ZXN0aW9uLg0KJm5ic3A7 QXMgeW91IHBvaW50ZWQgb3V0LCBJIGJlbGlldmUgSSBzdWdnZXN0IHRoYXQgdGhpcyBxdWVzdGlv biBiZSByYWlzZWQsDQpieSB0aGUgYXV0aG9ycywgb24gdGhlIFRQIGxpc3QuPGJyPg0KPGJyPg0K W2F0XSBGZWksIGlzL3dhcyB0aGVyZSBhbnkgY29uY2x1c2lvbiBvbiB0aGUgVFAgbGlzdD88L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pjx0dD48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZT5bRmVpXUFsdGhvdWdoIEkgcHV0IGl0IG9uIHRoZSBUUA0KbGlz dCwgdGhlcmUgd2FzIG5vIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4gU2VlIHRoZSBvbGQgbGlu ayA6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzLXRwL2N1cnJlbnQv bXNnMDUyNzcuaHRtbDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZT4mbmJzcDsgJm5ic3A7ICZuYnNwO0kgZm9yd2FyZCB0aGUgZGlzY3Vzc2lvbg0KdG8gdGhlIE1Q TFMgbGlzdCB0aGlzIHRpbWUsIGhvcGUgd2UgY2FuIGdldCBtb3JlIGZlZWRiYWNrLjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0KUkZDNTY0NSBzZWVtcyB0byBh bGxvdyBmb3IgaW5kZXBlbmRlbnQgcHJvdmlzaW9uaW5nIG9mIGFzc29jaWF0ZWQsIGJ1dA0KaXQg ZG9lc24ndCBwcmVjbHVkZSB0aGUgJnF1b3Q7c2luZ2xlIHNpZGVkIG1vZGUmcXVvdDsuICZuYnNw O0l0IGFsc28gaGFzDQpyZXF1aXJlbWVudHM8YnI+DQoxMSBhbmQgMTIgd2hpY2ggYXJlIGNlcnRh aW5seSBmYWNpbGl0YXRlZCBieSAmcXVvdDtzaW5nbGUgc2lkZWQgbW9kZSZxdW90Oy48YnI+DQo8 YnI+DQpbYXRdIEkgdGhpbmsgcmVxdWlyZW1lbnRzIDExIGFuZCAxMiBjYW4gYmUgZnVsZmlsbGVk IGJ5IHVzaW5nIGFuIGFzc29jaWF0aW9uDQppZCBvbiBib3RoIExTUHMgd2l0aCAmcXVvdDtkb3Vi bGUtc2lkZWQgbW9kZSZxdW90OyBhdCBMU1AgZXN0YWJsaXNobWVudA0Kb3IgYXQgYSBsYXRlciBw b2ludCBmb3IgYXNzb2NpYXRpb24uIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZT5bRmVpXSBBZ3JlZSwgYnV0IHRoZSBjb21wbGV4aXR5IG9mICZxdW90 O2RvdWJsZS1zaWRlZA0KbW9kZSZxdW90OyBpcyBhbG1vc3QgdGhlIHNhbWUgYXMgY29tcGFyZWQg dG8gJnF1b3Q7c2luZ2xlLXNpZGVkIG1vZGUmcXVvdDsNCmF0IExTUCBlc3RhYmxpc2htZW50Ljwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT4mbmJzcDsg Jm5ic3A7ICZuYnNwO0Fzc3VtZSB0aGF0IHRoZSB0aW1lDQpjb3N0cyBmb3IgcGF0aCBhbmQgcmVz diBtZXNzYWdlIGFyZSB0aGUgc2FtZSB2bGF1ZSAmcXVvdDtUQyZxdW90OyA8L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgRm9yICZxdW90O3NpbmdsZS1zaWRlZA0KbW9kZSZxdW90OywgdGhlIHRpbWUgY29zdHMgYXJl IDNUQ3MoMlRDcyBmb3IgTFNQMSBmcm9tIHdlc3QgdG8gZWFzdCBwbHVzDQoxVEMgZm9yIExTUDIg ZnJvbSBlYXN0IHRvIHdlc3QpLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZT4mbmJzcDsgJm5ic3A7ICZuYnNwOyBBcyBmb3IgJnF1b3Q7ZG91YmxlLXNpZGVkDQpt b2RlJnF1b3Q7LCB0aGUgYmluZGluZyBoYXBwZW5zIHdoZW4gdGhlIHBhdGggcmVmcmVzaCBtZXNz YWdlIGFyZSBzZW50DQpvdXQgYmFzZWQgb24gdGhlIHNvbHV0aW9uIGRlc2NyaWJlZCBpbiB0aGUg ZG9jdW1lbnQsIHNvIHRoZSB0aW1lIGNvc3QgaXMNCmdlbmVyYWxseSB0aGUgc2FtZSA6b25lIHBh dGgtcmVzdiBjaXJjbGUgcGx1cyBvbmUgcGF0aCBtZXNzYWdlIHByb2Nlc3NpbmcuDQo8L2ZvbnQ+ PC90dD48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCkluIHRoZSBjYXNlIExTUHMgc2hvdWxk IGJlIGFzc29jaWF0ZWQgbGF0ZXIgb24sIGFmdGVyIGVzdGFibGlzaG1lbnQsIGENCnNpbXBsZSAm cXVvdDtzaW5nbGUgc2lkZWQmcXVvdDsgc29sdXRpb24gbWlnaHQgYmUgdXNlZCB0byBhbGxvdyBz aW5nbGUtdG91Y2gNCmFzc29jaWF0aW9uLCB0aGlzIGlzIG1haW5seSBhbiBvcHRpbWl6YXRpb24g bm90IGEgcmVxdWlyZWQgZmVhdHVyZSBJIGd1ZXNzLg0KSW4gdGhpcyBjYXNlIGJlc2lkZXMgdGhl IGFzc29jaWF0aW9uIGlkIG9uZSBtYXkgYWxzbyBzZW5kIHRoZSBMU1AgaWQgb2YNCnRoZSByZXZl cnNlIGRpcmVjdGlvbiB0byB3aGljaCB0aGUgYXNzb2NpYXRpb24gc2hvdWxkIGJlIGVzdGFibGlz aGVkLCB3aGljaA0KaW4gdHVybiB3b3VsZCByZXN1bHQgaW4gdGhlIHJlc2lnbmFsbGluZyBvZiB0 aGF0IExTUCB3aXRoIHRoZSBhc3NvY2lhdGlvbg0KaWQuIERvaW5nIG1vcmUgZWxhYm9yYXRlICZx dW90O3NpbmdsZS1zaWRlZCZxdW90OyBzaWduYWxpbmcsIGUuZywgaW5jbHVkaW5nDQpyZXZlcnNl IGJ3IGFuZCBxb3MgcGFyYW1ldGVycyBzZWVtcyB0byBtZSB0byBhZGQgdW5uZWNlc3NhcnkgY29t cGxleGl0eS4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZT5bRmVpXSBJbiB0aGlzIGNhc2UsIHRoZSBhc3NvY2lhdGlvbiBpZA0KaXMgdGhlIExTUCBp ZCBvZiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24gKCZxdW90O2lmIGtub3duLCBpdCBNQVkgYmUgc2V0 IHRvDQp0aGUgTFNQIElEIG9mIHRoZSBhc3NvY2lhdGVkIHJldmVyc2UgTFNQJnF1b3Q7KSwgdGhl cmUgaXMgbm8gbmVlZCB0byBjYXJyeQ0KcmV2ZXJzZSBidyBhbmQgcW9zIHBhcmFtZXRlcnMuIFRo ZXkgYXJlIG9ubHkgY2FycmllZCB3aGVuIHRoZSByZXZlcnNlIExTUA0KZG9lcyBub3QgZXhpc3Qu IEkgd2lsbCBjbGFyaWZ5IGl0IGluIG5leHQgdmVyc2lvbi48L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+Jm5ic3A7SXQgaXMgbW9yZSBjb21wbGV4IGZv ciBkb3VibGUgc2lkZWQNCnByb3Zpc2lvbmcgbW9kZSBpbiB0aGlzIGNhc2UgdGhhdCB0aGUgTFNQ cyBhcmUgYXNzb2NpYXRlZCBhZnRlciBlc3RhYmxpc2htZW50LA0KYW5kIHRoZSBjb3N0IGlzIG9u ZSBwYXRoLXJlc3YgcmVmcmVzaCBjaXJjbGUgcGx1cyBvbmUgcGF0aCByZWZyZXNoIG1lc3NhZ2UN CnByb2Nlc3NpbmcuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpCZXN0 IHJlZ2FyZHMsPGJyPg0KQXR0aWxhPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K SSBiZWxpZXZlIHlvdSBhbHNvIHJhaXNlIHNvbWUgdmFsaWQgaXNzdWVzIHdpdGggdGhlIGN1cnJl bnQgZGVmaW5pdGlvbg0Kb2YgdGhlIHByb2Nlc3NpbmcgcnVsZXMuIEknbGwgZGVmZXIgbXkgY29t bWVudHMgb24gdGhpcyBmb3Igbm93Ljxicj4NCjxicj4NCkxvdTxicj4NCjxicj4NCkJUVyBUaGlz IGlzbid0IHRoZSBmaXJzdCB0aW1lIHRoYXQgJnF1b3Q7c2luZ2xlIHNpZGVkIG1vZGUmcXVvdDsg aGFzIGJlZW4NCnN1Z2dlc3QuPGJyPg0KSSBzZWVtIHRvIHJlbWVtYmVyIGRpc2N1c3NpbmcgYSBw cm9wb3NhbCBvbiB0aGlzIGZyb20gSnVoYSBIZWluYW5lbiBhdA0KdGhlIEFkZWxhaWRlIElFVEYu ICZuYnNwO0kgYWxzbyBrbm93IG9mIG9uZSB2ZW5kb3Itc3BlY2lmaWMgaW1wbGVtZW50YXRpb24N CnRoYXQgbmV2ZXIgbWFkZSBpdCB0byB0aGUgZmllbGQgb3IgdGhlIFdHLjxicj4NCjxicj4NCk9u IDQvMTUvMjAxMSA5OjQyIEFNLCBMb3UgQmVyZ2VyIHdyb3RlOjxicj4NCiZndDsgQXR0aWxhLDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtTbw0Kd2UgaGF2ZSB0d28gcG9pbnRzIGhlcmU6PGJyPg0KJmd0OyAxKSBX RyBwcm9jZWR1cmUgcmVsYXRlZDxicj4NCiZndDsgPGJyPg0KJmd0OyBTbyB0aGlzIG1haWwgaXMg aW4gcmVzcG9uc2UgdG8gYSBwb2xsLiBBcyB5b3VyIGFuc3dlciBpcyAoYSkuICZuYnNwO0kNCihh czxicj4NCiZndDsgY2hhaXIpIGtub3cgaG93IHRvIGludGVycHJldCB5b3UgcG9zaXRpb24sIGku ZS4sICZxdW90O1llcy9TdXBwb3J0JnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAyKSBQb2lu dCByZWxhdGVkIHRvIHRoZSBjb250ZW50cyBvZiB0aGUgZHJhZnQuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEFzIHRoaXMgaXMgYSB0ZWNobmljYWwgcG9pbnQsIGFuZCBpbmRlcGVuZGVudCBvZiB0aGUg cG9sbC4gJm5ic3A7SSdsbA0Kc3RhcnQgPGJyPg0KJmd0OyBhIG5ldyB0aHJlYWQgb24gdGhpcyBp biBhIHNlcGFyYXRlIG1haWwuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7 IExvdTxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiA0LzE0LzIwMTEgMTowNiBQTSwgQXR0aWxhIFRh a2FjcyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBIaSBMb3UsIGFsbCw8YnI+DQomZ3Q7Jmd0OyBJdCB3 b3VsZCBiZSBuaWNlIHRvIGNsYXJpZnkgdGhlIHNjb3BlIG9mIHRoZSBwcm9wb3NlZCBleHRlbnNp b24uDQo8YnI+DQomZ3Q7Jmd0OyBJIHdvdWxkIHNheSAoYSkgaWYgdGhhdCBkb2VzIG5vdCBpbmNs dWRlIGNvbW1pdG1lbnQgdG8gd29yayBvbg0KdGhlICZxdW90O3NpbmdsZSBzaWRlZCBtb2RlJnF1 b3Q7LiBUbyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgdGhhdCBvcGVyYXRpb24NCm1vZGUgaXMg bm90IHJlcXVpcmVkIGZvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4gVGhlcmUgaXMg bm8gZGlzY3Vzc2lvbg0KaW4gdGhlIGRvY3VtZW50IGFib3V0IHdoaWNoIG9wZXJhdGlvbiBtb2Rl IGlzIHJlYWxseSBuZWVkZWQsIGlmIEknbSBub3QNCm1pc3Rha2VuIHNpbWlsYXIgY29tbWVudHMg d2VyZSByYWlzZWQgaW4gQmVpamluZywgYnV0IHRoaXMgaXMgbm90IGFkZHJlc3NlZA0KaW4gdGhl IGRvY3VtZW50LiBIZW5jZSBteSBjb25mdXNpb24uPGJyPg0KJmd0OyZndDsgVGhhbmtzLDxicj4N CiZndDsmZ3Q7IEF0dGlsYTxicj4NCiZndDsmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTog TG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdPGJyPg0KJmd0OyZndDsgU2VudDog V2VkbmVzZGF5LCBBcHJpbCAxMywgMjAxMSAyOjQzIFBNPGJyPg0KJmd0OyZndDsgVG86IEF0dGls YSBUYWthY3M8YnI+DQomZ3Q7Jmd0OyBDYzogY2NhbXBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBT dWJqZWN0OiBSZTogW0NDQU1QXSBwb2xsIG9uIG1ha2luZyA8YnI+DQomZ3Q7Jmd0OyBkcmFmdC16 aGFuZy1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQgYSBXRyBkb2N1bWVudDxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQXR0aWxhLDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO1Nv IEkgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnQsIGFuZCB3b3VsZCBsaWtlIHRvIGhhdmUgdGhpcw0K ZGlzY3Vzc2lvbiwgYnV0IEkgdGhpbmsgSSBuZWVkIHNvbWUgY2xhcmlmaWNhdGlvbiBmcm9tIHRo ZSBwZXJzcGVjdGl2ZQ0Kb2YgdGhlIHBvbGwuPGJyPg0KJmd0OyZndDsgJm5ic3A7SSdtIHVuc3Vy ZSBpZiB5b3UncmUgc2F5aW5nOjxicj4NCiZndDsmZ3Q7IChhKSBzdXBwb3J0IHRoaXMgZG9jdW1l bnQgYmVjb21pbmcgYSBXRyBkb2N1bWVudCBhbmQgd291bGQgbGlrZTxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDsgZGlzY3VzcyB0aGUgcG9pbnQgcmFpc2VkIGJlbG93IGluIHRoZSBjb250ZXh0 IG9mDQphIFdHIGRvY3VtZW50IG9yPGJyPg0KJmd0OyZndDsgKGIpIGRvIE5PVCBzdXBwb3J0IHRo aXMgZG9jdW1lbnQgYmVjb21pbmcgYSBXRyBkb2N1bWVudCB1bnRpbA0KdGhlPGJyPg0KJmd0OyZn dDsgJm5ic3A7ICZuYnNwOyBwb2ludCB5b3UgcmFpc2UgYmVjb21lcyBhIFdHIGRvY3VtZW50PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBDYW4geW91IGNsYXJpZnkgaWYgeW91IG1lYW4gKGEp IG9yIChiKT88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IExvdTxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgT24gNC8xMi8yMDExIDQ6MjcgUE0sIEF0dGlsYSBUYWthY3Mgd3JvdGU6PGJy Pg0KJmd0OyZndDsmZ3Q7IEhpIGF1dGhvcnMsPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IFlvdSB0YWxrIGFib3V0IHR3byBwcm92aXNpb25pbmcgbW9kZWxzOiAmcXVvdDtzaW5n bGUmcXVvdDsNCmFuZCAmcXVvdDtkb3VibGUmcXVvdDsgc2lkZWQgbW9kZXMuIDxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBEb3VibGUgc2lkZWQgaXMgY2xlYXIsIGl0IHVzZXMg aW5kZXBlbmRlbnQgc2lnbmFsaW5nIGZvciB0aGUNCnR3byBMU1BzLiA8YnI+DQomZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsgU2luZ2xlIHNpZGVkLCBpZiBJIHVuZGVyc3Rvb2QgY29ycmVj dGx5LCBzb21laG93IGJpbmRzIHRoZQ0KdHdvIExTUCBzaWduYWxpbmcgcGhhc2VzIHRvZ2V0aGVy LiBJIGhhdmUgc29tZSBkb3VidHMgdGhhdCB0aGlzIG1vZGVsIGlzDQpuZWVkZWQuIEl0IHNlZW1z IHRvIGNvbXBsaWNhdGUgb3BlcmF0aW9uIGFuZCBpdCBhbHNvIGJlZ3MgdGhlIHF1ZXN0aW9uDQp3 aHkgbm90IHVzZSBiaWRpcmVjdGlvbmFsIExTUHMgaW5zdGVhZC4gPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IEkgdGhpbmsgdHdvIGluZGVwZW5kZW50bHkgc2lnbmFsZWQgTFNQ cyB3aXRoIHRoZSBhZGRpdGlvbg0Kb2YgdGhlIHByb3Bvc2VkIEFzc29jaWF0aW9uIG9iamVjdCB3 b3VsZCBkbyB0aGUgam9iIGFkZHJlc3NpbmcgdGhlIGFzc29jaWF0ZWQNCmJpZGlyZWN0aW9uYWwg TFNQIHJlcXVpcmVtZW50cywgc28gdGhhdCB0cmFuc2l0IG5vZGVzIGFyZSBhbHNvIGF3YXJlIG9m DQp0aGUgYmluZGluZy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQmVzdCBy ZWdhcmRzLDxicj4NCiZndDsmZ3Q7Jmd0OyBBdHRpbGE8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsg RnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5v cmddDQpPbiA8YnI+DQomZ3Q7Jmd0OyZndDsgQmVoYWxmIE9mIExvdSBCZXJnZXI8YnI+DQomZ3Q7 Jmd0OyZndDsgU2VudDogRnJpZGF5LCBBcHJpbCAwMSwgMjAxMSAxMToyNCBBTTxicj4NCiZndDsm Z3Q7Jmd0OyBUbzogY2NhbXBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsgU3ViamVjdDogW0ND QU1QXSBwb2xsIG9uIG1ha2luZzxicj4NCiZndDsmZ3Q7Jmd0OyBkcmFmdC16aGFuZy1tcGxzLXRw LXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQgYSBXRyBkb2N1bWVudDxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBbGwsPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IFRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZzxicj4NCiZn dDsmZ3Q7Jmd0OyBkcmFmdC16aGFuZy1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3At MDQgYSBjY2FtcCB3b3JraW5nDQpncm91cCBkb2N1bWVudC4gUGxlYXNlIHNlbmQgbWFpbCB0byB0 aGUgbGlzdCBpbmRpY2F0aW5nICZxdW90O3llcy9zdXBwb3J0JnF1b3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IG9yICZxdW90O25vL2RvIG5vdCBzdXBwb3J0JnF1b3Q7LiAmbmJzcDtJZiBpbmRpY2F0aW5n IG5vLA0KcGxlYXNlIHN0YXRlIHlvdXIgdGVjaG5pY2FsIHJlc2VydmF0aW9ucyB3aXRoIHRoZSBk b2N1bWVudC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhlIHBvbGwgZW5k cyBGcmlkYXkgQXByaWwgMTUuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE11 Y2ggdGhhbmtzLDxicj4NCiZndDsmZ3Q7Jmd0OyBMb3UgKGFuZCBEZWJvcmFoKTxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7Jmd0OyZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsmZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 Jmd0OyBDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsgQ0NBTVBAaWV0Zi5vcmc8 YnI+DQomZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j Y2FtcDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FNUEBpZXRmLm9y Zzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQo8 YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 003D8DBF48257877_=-- From linda.dunbar@huawei.com Tue Apr 19 08:47:41 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 62568E0774 for ; Tue, 19 Apr 2011 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNgMAgb84tCK for ; Tue, 19 Apr 2011 08:47:40 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfc.amsl.com (Postfix) with ESMTP id C987AE0773 for ; Tue, 19 Apr 2011 08:47:40 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJW004CQP7FXG@usaga04-in.huawei.com> for mpls@ietf.org; Tue, 19 Apr 2011 10:47:39 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LJW00MNHP7EZZ@usaga04-in.huawei.com> for mpls@ietf.org; Tue, 19 Apr 2011 10:47:39 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 08:47:39 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.75]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 08:47:38 -0700 Date: Tue, 19 Apr 2011 15:47:37 +0000 From: Linda Dunbar In-reply-to: <14584D6EE26B314187A4F68BA20606000729D349@ASHEVS008.mcilink.com> X-Originating-IP: [10.192.11.188] To: "mpls@ietf.org" Message-id: <4A95BA014132FF49AE685FAB4B9F17F60513E16F@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_QOoc8IPk8u84WDJ+ljtZbA)" Content-language: en-US Accept-Language: en-US Thread-topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG Thread-index: Acv9/mzR4JmnF5nqTxe8+jVTzK8YfAAnUAZQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <14584D6EE26B314187A4F68BA20606000729D349@ASHEVS008.mcilink.com> Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:47:41 -0000 --Boundary_(ID_QOoc8IPk8u84WDJ+ljtZbA) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT Yes/support. Best regards, Linda Dunbar All, this is to start a two week working group poll on whether to make draft-kompella-mpls-entropy-label an mpls wg document. Please send your comments to the mpls@ietf.org mailing list. The poll ends on May 3rd. thanks Ross (as WG co-chair) --Boundary_(ID_QOoc8IPk8u84WDJ+ljtZbA) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: 7BIT

     

     

    Yes/support.

     

     

    Best regards,

     

    Linda Dunbar

     

     

    All,

     

    this is to start a two week working group poll on whether to make draft-kompella-mpls-entropy-label an mpls wg document.

     

    Please send your comments to the mpls@ietf.org mailing list.

     

    The poll ends on May 3rd.

     

    thanks Ross (as WG co-chair)

     

    --Boundary_(ID_QOoc8IPk8u84WDJ+ljtZbA)-- From curtis@occnc.com Tue Apr 19 10:01:31 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75E7DE079F for ; Tue, 19 Apr 2011 10:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWFroPZe38Zp for ; Tue, 19 Apr 2011 10:01:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id B3508E079D for ; Tue, 19 Apr 2011 10:01:30 -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 p3JH1Qjd048842; Tue, 19 Apr 2011 13:01:26 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104191701.p3JH1Qjd048842@harbor.orleans.occnc.com> To: Manav Bhatia From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Apr 2011 22:33:12 +0530." Date: Tue, 19 Apr 2011 13:01:26 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 19 Apr 2011 17:01:31 -0000 In message Manav Bhatia writes: > > Hi, > > I have posted a new draft: > http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00.txt > > Abstract > > There are several applications that require symmetric Multiprotocol > Label Switching (MPLS) path between two points. This cannot be > achieved with regular MPLS as the LSPs are unidirectional. If > symmetry is required, a separate LSP in each direction is required for > bidirectional traffic flow. Generalized MPLS on the other hand, has > provisions for setting up a bidirectional LSP. This document uses the > extensions introduced for GMPLS and applies it to regular MPLS for > establishing bidirectional LSPs. Additionally, it also describes how > bi-directional symmetrical Fast Reroute using both one-to-one and > facility backup can be achieved. > > Would be great if the WG can provide some feedback on this. > > Cheers, Manav Manav, In practice, FRR provides a fast temporary protection after which a reroute should occur. The existing mechanism makes use of a merge point which is very often further down the working path than the other side of the repair, as it would be for a transport style segment protection. This provides a more efficient use of bandwidth during the temporary protection for the common case where zero signaled bandwidth is reserved on the protect path and diffserv marking is used. As a result FRR is not symetric but instead results in lower congestion for the lowest priority service carried (BE, often used for plain old Internet service). If the path were symetric, then a different FRR backup would be needed depending on whether the far end node failed or the link to that node failed. If node failure is assumed, then the backup paths are not symetric. For example, in A-B-C-D-E-F, where link C-D fails, C sends to E and D sends to B. If using FRR it is better to just live with the existing behavior where protection makes efficient use of capacity, not trying to loop back to the other side of the fault, is assymetric, and is temporary. Curtis From rrao@infinera.com Tue Apr 19 10:59:40 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8959E0702 for ; Tue, 19 Apr 2011 10:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84qSuhCcVDIV for ; Tue, 19 Apr 2011 10:59:40 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by ietfc.amsl.com (Postfix) with ESMTP id 42016E0675 for ; Tue, 19 Apr 2011 10:59:40 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Tue, 19 Apr 2011 10:59:39 -0700 From: Rajan Rao To: Ross Callon , "mpls@ietf.org" Date: Tue, 19 Apr 2011 10:59:38 -0700 Thread-Topic: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQADgh7UA= Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA7DAC3FDD54@SV-EXDB1.infinera.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:59:41 -0000 Support Rajan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Monday, April 18, 2011 8:16 AM To: mpls@ietf.org Subject: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG docume= nt All, this is to start a two week working group poll on whether to make draft-kompella-mpls-entropy-label an mpls wg document. Please send your comments to the mpls@ietf.org mailing list. The poll ends on May 3rd.=20 thanks Ross (as WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Tue Apr 19 11:26:34 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 592EFE085A for ; Tue, 19 Apr 2011 11:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi+GGEAQxIkk for ; Tue, 19 Apr 2011 11:26:33 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id A33EDE0685 for ; Tue, 19 Apr 2011 11:26:33 -0700 (PDT) Received: by pxi20 with SMTP id 20so4280352pxi.27 for ; Tue, 19 Apr 2011 11:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=oQ0xYsZ+iFfYVIAmMJUkJ9ZK0z+2QChZ1IXkV67EKsg=; b=q6E1CBcBEXMJMbok311oAw6cq+rOrMO7zy+NAeIgzXRASbCsYGe6KIaUs/jQrOeuSi gAq30kZe+x63So1BmBnyhk2RzWXmE2jYvzLR3z96bTXN/gOeYtokh4l/sFppepgWROuL IqAlTtFOJhjtFxQupiA3w6TH5SeWns+UMGwxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=QM69lyZ909dxC0N4COim1omFfNSMHSaLCmpypnuMMnw1T8QanWUNw6LEazfVj8Rz1h ett3Fz1E3DHTZXQWAMLLaLOgcoLfgzC0XakIw028zcuNGxS6e+pMAyrHi1h5/tNCeWVW QTxH4/aZf0fFzjyLfwYX5uxWApYIAZnUrvWl0= Received: by 10.68.57.72 with SMTP id g8mr1239986pbq.446.1303237593071; Tue, 19 Apr 2011 11:26:33 -0700 (PDT) Received: from [192.168.1.127] ([12.133.183.34]) by mx.google.com with ESMTPS id p2sm94201pbq.6.2011.04.19.11.26.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 11:26:32 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8H7) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <51F2BF8B-B339-442F-B546-4AD0752B47AD@gmail.com> X-Mailer: iPad Mail (8H7) From: Sam Aldrin Date: Tue, 19 Apr 2011 11:26:53 -0700 To: Ross Callon Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:26:34 -0000 Support. -sam Sent from my iPad On Apr 18, 2011, at 8:15 AM, Ross Callon wrote: > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@occnc.com Tue Apr 19 13:46:22 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8DE96E0776 for ; Tue, 19 Apr 2011 13:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzD7N0UyYXgl for ; Tue, 19 Apr 2011 13:46:22 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id A1103E076A for ; Tue, 19 Apr 2011 13:46:21 -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 p3JKkKcF051622; Tue, 19 Apr 2011 16:46:20 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104192046.p3JKkKcF051622@harbor.orleans.occnc.com> To: Ross Callon From: Curtis Villamizar In-reply-to: Your message of "Mon, 18 Apr 2011 11:15:55 EDT." Date: Tue, 19 Apr 2011 16:46:20 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 19 Apr 2011 20:46:22 -0000 In message Ross Callon writes: > > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) yes/support Curtis From manavbhatia@gmail.com Tue Apr 19 18:03:26 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D901AE076E for ; Tue, 19 Apr 2011 18:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v40eXezwTcpI for ; Tue, 19 Apr 2011 18:03:26 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfc.amsl.com (Postfix) with ESMTP id F2A38E0670 for ; Tue, 19 Apr 2011 18:03:25 -0700 (PDT) Received: by wwk4 with SMTP id 4so3554177wwk.1 for ; Tue, 19 Apr 2011 18:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wlGxF/GoCt0Uas7NBSl04A1MGjzzS00cdhYOKogl5Ak=; b=eG3qbT9Z8KMCghUwgXpi9kVC0Uadk5mXQ7xxeNuXUkiatOkpYbXMGwsUtXTIJVOx2E JHXkvE3lENGLYicFg144NHuo6sFMk5U/3l7tW5uV1riudZbwIME3Q/yLFP7ResAp8JEt 7/jAPk9j5NObKXMLKuvNYKwpvU4yMjg4nKfcY= 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=UzunNKWzrhMZizL4V04bKsyX6zcIZ0bvaBfoGsUGA6A2zeCjTjtiEl17AGVgPDoIUk VWa5i8QG1Jg+3O2maQF3DU0UEXcFf7RmO7x51JYpKAZxAxcbAzgpevu5ujRnQ2WqIDKP tYfPPTsqehJ4k++/Z1Ig0ijkQe4YXEzTxxWhY= MIME-Version: 1.0 Received: by 10.227.0.152 with SMTP id 24mr6858501wbb.126.1303261405065; Tue, 19 Apr 2011 18:03:25 -0700 (PDT) Received: by 10.227.142.140 with HTTP; Tue, 19 Apr 2011 18:03:25 -0700 (PDT) In-Reply-To: <201104191701.p3JH1Qjd048842@harbor.orleans.occnc.com> References: <201104191701.p3JH1Qjd048842@harbor.orleans.occnc.com> Date: Wed, 20 Apr 2011 06:33:25 +0530 Message-ID: From: Manav Bhatia To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:03:27 -0000 Hi Curtis, > > As a result FRR is not symetric but instead results in lower > congestion for the lowest priority service carried (BE, often used for > plain old Internet service). =A0If the path were symetric, then a > different FRR backup would be needed depending on whether the far end > node failed or the link to that node failed. =A0If node failure is > assumed, then the backup paths are not symetric. =A0For example, in > A-B-C-D-E-F, where link C-D fails, C sends to E and D sends to B. With the mechanism described in this draft when link C-D fails, C will set up a bi-directional FRR tunnel from C to E. Thus all traffic arriving from E will get switched to C.Its only the nodes upstream to the fault that set up the protection tunnel. I should have mentioned this explicitly in the draft. > > If using FRR it is better to just live with the existing behavior > where protection makes efficient use of capacity, not trying to loop > back to the other side of the fault, is assymetric, and is temporary. What lead me to this work was 1588 or PTP (precision time protocol) that requires symmetric paths for precise delay measurement and is used to distribute highly accurate time and frequency information over IP/MPLS networks. In case of a failure, however temporary, the paths because of the existing FRR mechanisms would be assymetrical, which will break 1588 as packets in one direction will follow one path, while the packets in reverse will follow the other. I wanted to provide a bidirectional LSP where the FRR would also be bidirectional. This may result in some non-optimization, buts that probably the cost of achieving complete symmetry. Cheers, Manav From jsmith4112003@yahoo.co.uk Tue Apr 19 18:10:35 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 59932E07EF for ; Tue, 19 Apr 2011 18:10:35 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ycXwqd7NVcV for ; Tue, 19 Apr 2011 18:10:34 -0700 (PDT) Received: from nm4-vm0.bullet.mail.ukl.yahoo.com (nm4-vm0.bullet.mail.ukl.yahoo.com [217.146.183.230]) by ietfc.amsl.com (Postfix) with SMTP id 5B7DBE072C for ; Tue, 19 Apr 2011 18:10:34 -0700 (PDT) Received: from [217.146.183.216] by nm4.bullet.mail.ukl.yahoo.com with NNFMP; 20 Apr 2011 01:10:29 -0000 Received: from [217.146.183.162] by tm9.bullet.mail.ukl.yahoo.com with NNFMP; 20 Apr 2011 01:10:29 -0000 Received: from [127.0.0.1] by omp1003.mail.ukl.yahoo.com with NNFMP; 20 Apr 2011 01:10:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 879542.21013.bm@omp1003.mail.ukl.yahoo.com Received: (qmail 24393 invoked by uid 60001); 20 Apr 2011 01:10:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1303261829; bh=qDkJ9m4YSOAbikShTxI9Lev/3o4rrWZunyy/j1kvuBM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0U5iGnmNzXv4jtQ4MUhGLUG+8/K4ve+dUS3i9oWoE6TVmbqgFg2aF0nDH7C9+wyQuC73lGfa01AFKS4Ynit5X5SAyL0tVIdy197VtYAVoVBC5qzYlFJDKsq4jSGxpAEurbN1Sg3MwVOKMDzOnc++51asH+x/GmFgACZUBsLCmWk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=G0ZT3w1TWI1BVLDOYoRW3uOBrLT29MJWqOE0PcRXloV4gpSwdeCuNdavzp1YPL3B0WLQf5hlMDEP9KrMZLlvX10Hk/iEjwiWKxliMAJO8tRQj99Z+Wg0GxVqIFQIMK5WyFj7CPNBgsmJmHQvSJLcviROXg81wU3tSdxppEyLXtg=; Message-ID: <765290.61662.qm@web27208.mail.ukl.yahoo.com> X-YMail-OSG: MWbtsg4VM1lOxwNt_1QbtV332RxIDu8rSWrWI0K6HbdzxO9 uZuiiFRkQ7YdeD5l9kkDzlwL9A1z8_c8m8wtT0xC5okNwmkruep965YkVC0z SEmNdBsrUWrst3kAFCAdHMTqYmVyCRvEjZYP9B.wJOMSMvrNfJxr4cj9FC7g Olpn4m.lSvQoPotrpVcBxU60Hin9Ysr9R7Mzt9MP9nnZJ8tIQchOVi6aGMNF y4Q9_7JTu0rKyI_WL62Whl5Dd2JIYI6kk0n2VO3S7hgBrIts2QgFl8.Zplm1 q6l4O7G.5JVgjCQSsx4r5e.A4SK17uOIBf01.uq.30vAPQDAMvWHlxl7C9_M bgcfqZ0ffaBU78rGGeAZ4ADE4nNU- Received: from [135.245.168.37] by web27208.mail.ukl.yahoo.com via HTTP; Wed, 20 Apr 2011 02:10:29 BST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <201104191701.p3JH1Qjd048842@harbor.orleans.occnc.com> Date: Wed, 20 Apr 2011 02:10:29 +0100 (BST) From: John Smith To: curtis@occnc.com, Manav Bhatia In-Reply-To: <201104191701.p3JH1Qjd048842@harbor.orleans.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:10:35 -0000 =0A=0A=0A=0A----- Original Message ----=0AFrom: Curtis Villamizar =0ATo: Manav Bhatia =0ACc: mpls@ietf.org=0A= Sent: Tue, 19 April, 2011 22:31:26=0ASubject: Re: [mpls] draft-bhatia-mpls-= rsvp-te-bidirectional-lsp=0A=0A=0AIn message =0AManav Bhatia writes:=0A> =0A> Hi,=0A> =0A> I h= ave posted a new draft:=0A> http://www.ietf.org/id/draft-bhatia-mpls-rsvp-t= e-bidirectional-lsp-00.txt=0A> =0A> Abstract=0A> =0A> There are several a= pplications that require symmetric Multiprotocol=0A> Label Switching (MPLS)= path between two points. This cannot be=0A> achieved with regular MPLS as= the LSPs are unidirectional. If=0A> symmetry is required, a separate LSP = in each direction is required for=0A> bidirectional traffic flow. Generali= zed MPLS on the other hand, has=0A> provisions for setting up a bidirection= al LSP. This document uses the=0A> extensions introduced for GMPLS and app= lies it to regular MPLS for=0A> establishing bidirectional LSPs. Additiona= lly, it also describes how=0A> bi-directional symmetrical Fast Reroute usin= g both one-to-one and=0A> facility backup can be achieved.=0A> =0A> Would = be great if the WG can provide some feedback on this.=0A> =0A> Cheers, Man= av=0A=0A=0AManav,=0A=0AIn practice, FRR provides a fast temporary protectio= n after which a=0Areroute should occur. The existing mechanism makes use o= f a merge=0Apoint which is very often further down the working path than th= e other=0Aside of the repair, as it would be for a transport style segment= =0Aprotection. This provides a more efficient use of bandwidth during=0Ath= e temporary protection for the common case where zero signaled=0Abandwidth = is reserved on the protect path and diffserv marking is=0Aused.=0A=0AAs a r= esult FRR is not symetric but instead results in lower=0Acongestion for the= lowest priority service carried (BE, often used for=0Aplain old Internet s= ervice). If the path were symetric, then a=0Adifferent FRR backup would be= needed depending on whether the far end=0Anode failed or the link to that = node failed. If node failure is=0Aassumed, then the backup paths are not s= ymetric. For example, in=0AA-B-C-D-E-F, where link C-D fails, C sends to E= and D sends to B.=0A=0AIf using FRR it is better to just live with the exi= sting behavior=0Awhere protection makes efficient use of capacity, not tryi= ng to loop=0Aback to the other side of the fault, is assymetric, and is tem= porary.=0A=0ACurtis=0A=0A_______________________________________________=0A= mpls mailing list=0Ampls@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/m= pls=0A From jsmith4112003@yahoo.co.uk Tue Apr 19 18:15:19 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 49342E07EF for ; Tue, 19 Apr 2011 18:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKKnGEbC-YHK for ; Tue, 19 Apr 2011 18:15:18 -0700 (PDT) Received: from nm10.bullet.mail.ukl.yahoo.com (nm10.bullet.mail.ukl.yahoo.com [217.146.182.251]) by ietfc.amsl.com (Postfix) with SMTP id 404CEE07E8 for ; Tue, 19 Apr 2011 18:15:18 -0700 (PDT) Received: from [217.146.183.208] by nm10.bullet.mail.ukl.yahoo.com with NNFMP; 20 Apr 2011 01:15:14 -0000 Received: from [217.146.183.33] by tm1.bullet.mail.ukl.yahoo.com with NNFMP; 20 Apr 2011 01:15:14 -0000 Received: from [127.0.0.1] by omp1022.mail.ukl.yahoo.com with NNFMP; 20 Apr 2011 01:15:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 619086.62714.bm@omp1022.mail.ukl.yahoo.com Received: (qmail 89876 invoked by uid 60001); 20 Apr 2011 01:15:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1303262114; bh=nGU6scqWN/y/KtN88Jwfuvcm0yc1F1i79bdqFLyIhfA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C+zshMz8vpxJE0ZG+Tmn7AWOHU4+vKEJilWBnSzZWSNX1bhwzmRLcZTKWV2/blBNIbnNPhUZAec8LgEhkvVaAtRpBdlusIdrQ1TB4AeAVZ2QcaCSh5iuRtsN6/2/8qSXlVRqWYJ04Qa1RrYiBgS68GDYuMMJrgJU2YZz0K/7xN8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zSRCipx9c9U3OymZRdVWIKLEaPqBKwng4nDoScCG/KMabduW6+NiNDPcqZAo+a+yoZYyY8LCEKp7nNEQTBHV3egSr3wG7e3PHtNl3w8lKVpaPAvPgi4Sns5S7xHkFFfUM0gpRpB3WK/X+ZDxTKKBSBA3gH0wEDah8gLvxlA2liw=; Message-ID: <425552.79274.qm@web27205.mail.ukl.yahoo.com> X-YMail-OSG: 2m88ZUIVM1nj2jXu7zslwvkZTM5Np0am6DxVZo6bvKbvYNx O1kfqmylW5DrY4oQVZanhJ2NGgD5M65VhrI66En2N2NRPt6JFzyqlgxf70NR RjhkzIMEt.HaSajIDVQRQui.4VRtj4rat2PYa9G_ChmceQWYE.nXgGt5Y89I 8yvdh8QpPaPiq6.vpY8KCyOrQWUSHPRh_gALCBf8v3T.5SoXkWiDjAm9QUDA G.g_OT.92UnklweA9J5woPHrWSU6KrYI1byY6Hz1NRGN7rS4ZKtGndwyP6_p gQOc5YWXLMLA9z0ClcRDUa84tmLEK6QQj6g.2jSg3pHQ2oZIECXcX2JbO7Gn aNH1d5Zo0qcQXvvHYV2AB_OfhVxk- Received: from [135.245.168.37] by web27205.mail.ukl.yahoo.com via HTTP; Wed, 20 Apr 2011 02:15:14 BST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <201104191701.p3JH1Qjd048842@harbor.orleans.occnc.com> Date: Wed, 20 Apr 2011 02:15:14 +0100 (BST) From: John Smith To: curtis@occnc.com In-Reply-To: <201104191701.p3JH1Qjd048842@harbor.orleans.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:15:19 -0000 Manav,=0A=0AIf you remove FRR as Curtis suggests then you will have a very = simple draft =0A(basically just your section 2) that will explain how bidir= ectional LSPs can be =0Aset up for regular MPLS (as opposed to GMPLS). You = could have a small section =0Athat says bidirectional FRR is not required.= =0A=0AI support having a draft that explicitly says how regular MPLS can se= t up =0Abidirectional LSPs - even if it uses the same mechanism as defined = for GMPLS.=0A=0ARegards,=0AJohn=0A=0A=0A----- Original Message ----=0AFrom:= Curtis Villamizar =0ATo: Manav Bhatia =0ACc: mpls@ietf.org=0ASent: Tue, 19 April, 2011 22:31:26=0ASubject: R= e: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp=0A=0A=0AIn message =0AManav Bhatia writes:= =0A> =0A> Hi,=0A> =0A> I have posted a new draft:=0A> http://www.ietf.org= /id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00.txt=0A> =0A> Abstract= =0A> =0A> There are several applications that require symmetric Multiproto= col=0A> Label Switching (MPLS) path between two points. This cannot be=0A>= achieved with regular MPLS as the LSPs are unidirectional. If=0A> symmetr= y is required, a separate LSP in each direction is required for=0A> bidirec= tional traffic flow. Generalized MPLS on the other hand, has=0A> provision= s for setting up a bidirectional LSP. This document uses the=0A> extension= s introduced for GMPLS and applies it to regular MPLS for=0A> establishing = bidirectional LSPs. Additionally, it also describes how=0A> bi-directional= symmetrical Fast Reroute using both one-to-one and=0A> facility backup can= be achieved.=0A> =0A> Would be great if the WG can provide some feedback = on this.=0A> =0A> Cheers, Manav=0A=0A=0AManav,=0A=0AIn practice, FRR provi= des a fast temporary protection after which a=0Areroute should occur. The = existing mechanism makes use of a merge=0Apoint which is very often further= down the working path than the other=0Aside of the repair, as it would be = for a transport style segment=0Aprotection. This provides a more efficient= use of bandwidth during=0Athe temporary protection for the common case whe= re zero signaled=0Abandwidth is reserved on the protect path and diffserv m= arking is=0Aused.=0A=0AAs a result FRR is not symetric but instead results = in lower=0Acongestion for the lowest priority service carried (BE, often us= ed for=0Aplain old Internet service). If the path were symetric, then a++= =0Adifferent FRR backup would be needed depending on whether the far end=0A= node failed or the link to that node failed. If node failure is=0Aassumed,= then the backup paths are not symetric. For example, in=0AA-B-C-D-E-F, wh= ere link C-D fails, C sends to E and D sends to B.=0A=0AIf using FRR it is = better to just live with the existing behavior=0Awhere protection makes eff= icient use of capacity, not trying to loop=0Aback to the other side of the = fault, is assymetric, and is temporary.=0A=0ACurtis=0A=0A__________________= _____________________________=0Ampls mailing list=0Ampls@ietf.org=0Ahttps:/= /www.ietf.org/mailman/listinfo/mpls=0A From zhang.fei3@zte.com.cn Tue Apr 19 19:12:49 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5B29EE0814; Tue, 19 Apr 2011 19:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.437 X-Spam-Level: X-Spam-Status: No, score=-97.437 tagged_above=-999 required=5 tests=[AWL=-2.216, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yufGRmqY5DI; Tue, 19 Apr 2011 19:12:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfc.amsl.com (Postfix) with ESMTP id D088DE06F5; Tue, 19 Apr 2011 19:12:47 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 125201784411434; Wed, 20 Apr 2011 10:11:52 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 41939.1937000543; Wed, 20 Apr 2011 10:01:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3K2CXYv088131; Wed, 20 Apr 2011 10:12:33 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Ross Callon MIME-Version: 1.0 X-KeepSent: 65482FDD:D569249F-48257878:000C163C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 20 Apr 2011 10:12:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-20 10:12:32, Serialize complete at 2011-04-20 10:12:32 Content-Type: multipart/alternative; boundary="=_alternative 000C20AB48257878_=" X-MAIL: mse02.zte.com.cn p3K2CXYv088131 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:12:49 -0000 This is a multipart message in MIME format. --=_alternative 000C20AB48257878_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVhaC9zdXBwb3J0DQoNCkZlaQ0KDQoNCg0KUm9zcyBDYWxsb24gPHJjYWxsb25AanVuaXBlci5u ZXQ+IA0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoyMDExLTA0LTE4IDIzOjE1DQoN CsrVvP7Iyw0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpb bXBsc10gcG9sbCBvbiBkcmFmdC1rb21wZWxsYS1tcGxzLWVudHJvcHktbGFiZWwgYXMgTVBMUyBX RyBkb2N1bWVudA0KDQoNCg0KDQoNCg0KQWxsLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdl ZWsgd29ya2luZyBncm91cCBwb2xsIG9uIHdoZXRoZXIgdG8gbWFrZQ0KZHJhZnQta29tcGVsbGEt bXBscy1lbnRyb3B5LWxhYmVsIGFuIG1wbHMgd2cgZG9jdW1lbnQuDQoNClBsZWFzZSBzZW5kIHlv dXIgY29tbWVudHMgdG8gdGhlIG1wbHNAaWV0Zi5vcmcgbWFpbGluZyBsaXN0Lg0KDQpUaGUgcG9s bCBlbmRzIG9uIE1heSAzcmQuIA0KDQp0aGFua3MgUm9zcyAoYXMgV0cgY28tY2hhaXIpDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5n IGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KDQoNCg0K --=_alternative 000C20AB48257878_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllYWgvc3VwcG9ydDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlJvc3MgQ2FsbG9uICZs dDtyY2FsbG9uQGp1bmlwZXIubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNC0xOCAyMzoxNTwv Zm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m cXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W21wbHNdIHBv bGwgb24gZHJhZnQta29tcGVsbGEtbXBscy1lbnRyb3B5LWxhYmVsDQphcyBNUExTIFdHIGRvY3Vt ZW50PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N Cjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5BbGwsPGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcg Z3JvdXAgcG9sbCBvbiB3aGV0aGVyIHRvIG1ha2U8YnI+DQpkcmFmdC1rb21wZWxsYS1tcGxzLWVu dHJvcHktbGFiZWwgYW4gbXBscyB3ZyBkb2N1bWVudC48YnI+DQo8YnI+DQpQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzQGlldGYub3JnIG1haWxpbmcgbGlzdC48YnI+DQo8YnI+ DQpUaGUgcG9sbCBlbmRzIG9uIE1heSAzcmQuIDxicj4NCjxicj4NCnRoYW5rcyBSb3NzIChhcyBX RyBjby1jaGFpcik8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjxicj4NCjwvZm9u dD48L3R0Pg0KPGJyPg0K --=_alternative 000C20AB48257878_=-- From curtis@occnc.com Tue Apr 19 20:58:08 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 808DFE0660 for ; Tue, 19 Apr 2011 20:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4kc9H3-1dca for ; Tue, 19 Apr 2011 20:58:07 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id C83B0E0670 for ; Tue, 19 Apr 2011 20:58:07 -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 p3K3w5Xd074952; Tue, 19 Apr 2011 23:58:05 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104200358.p3K3w5Xd074952@harbor.orleans.occnc.com> To: Manav Bhatia From: Curtis Villamizar In-reply-to: Your message of "Wed, 20 Apr 2011 06:33:25 +0530." Date: Tue, 19 Apr 2011 23:58:05 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 20 Apr 2011 03:58:08 -0000 In message Manav Bhatia writes: > > Hi Curtis, > > > > As a result FRR is not symetric but instead results in lower > > congestion for the lowest priority service carried (BE, often used for > > plain old Internet service).  If the path were symetric, then a > > different FRR backup would be needed depending on whether the far end > > node failed or the link to that node failed.  If node failure is > > assumed, then the backup paths are not symetric.  For example, in > > A-B-C-D-E-F, where link C-D fails, C sends to E and D sends to B. > > With the mechanism described in this draft when link C-D fails, C will > set up a bi-directional FRR tunnel from C to E. Thus all traffic > arriving from E will get switched to C.Its only the nodes upstream to > the fault that set up the protection tunnel. I should have mentioned > this explicitly in the draft. FRR today requires no signaling at the time of failure. > > If using FRR it is better to just live with the existing behavior > > where protection makes efficient use of capacity, not trying to loop > > back to the other side of the fault, is assymetric, and is temporary. > > What lead me to this work was 1588 or PTP (precision time protocol) > that requires symmetric paths for precise delay measurement and is > used to distribute highly accurate time and frequency information over > IP/MPLS networks. In case of a failure, however temporary, the paths > because of the existing FRR mechanisms would be assymetrical, which > will break 1588 as packets in one direction will follow one path, > while the packets in reverse will follow the other. I wanted to > provide a bidirectional LSP where the FRR would also be bidirectional. > This may result in some non-optimization, buts that probably the cost > of achieving complete symmetry. > > Cheers, Manav So for under a second, PTP with get bad information and should be able to figure out that it is bad. End-to-end PTP with multiple LSR in the middle is no more accurate than a purely software based NTP. In fact, it is less accurate. This IMHO is clearly not worth the cost. Curtis From curtis@occnc.com Tue Apr 19 21:06:00 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6EB76E06BB for ; Tue, 19 Apr 2011 21:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxAvJ4B8vgpL for ; Tue, 19 Apr 2011 21:05:59 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 9F7DFE0689 for ; Tue, 19 Apr 2011 21:05:59 -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 p3K45x6p076818; Wed, 20 Apr 2011 00:05:59 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104200405.p3K45x6p076818@harbor.orleans.occnc.com> To: John Smith From: Curtis Villamizar In-reply-to: Your message of "Wed, 20 Apr 2011 02:15:14 BST." <425552.79274.qm@web27205.mail.ukl.yahoo.com> Date: Wed, 20 Apr 2011 00:05:59 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 20 Apr 2011 04:06:00 -0000 In message <425552.79274.qm@web27205.mail.ukl.yahoo.com> John Smith writes: > > Manav, > > If you remove FRR as Curtis suggests then you will have a very simple > draft (basically just your section 2) that will explain how > bidirectional LSPs can be set up for regular MPLS (as opposed to > GMPLS). You could have a small section that says bidirectional FRR is > not required. > > I support having a draft that explicitly says how regular MPLS can set > up bidirectional LSPs - even if it uses the same mechanism as defined > for GMPLS. Nothing prevents you from doing this now so this draft is not needed. > Regards, > John > > > ----- Original Message ---- > From: Curtis Villamizar > To: Manav Bhatia > Cc: mpls@ietf.org > Sent: Tue, 19 April, 2011 22:31:26 > Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp > > > In message > Manav Bhatia writes: > > > > Hi, > > > > I have posted a new draft: > > http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00.txt > > > > Abstract > > > > There are several applications that require symmetric Multiprotocol > > Label Switching (MPLS) path between two points. This cannot be > > achieved with regular MPLS as the LSPs are unidirectional. If > > symmetry is required, a separate LSP in each direction is required for > > bidirectional traffic flow. Generalized MPLS on the other hand, has > > provisions for setting up a bidirectional LSP. This document uses the > > extensions introduced for GMPLS and applies it to regular MPLS for > > establishing bidirectional LSPs. Additionally, it also describes how > > bi-directional symmetrical Fast Reroute using both one-to-one and > > facility backup can be achieved. > > > > Would be great if the WG can provide some feedback on this. > > > > Cheers, Manav > > > Manav, > > In practice, FRR provides a fast temporary protection after which a > reroute should occur. The existing mechanism makes use of a merge > point which is very often further down the working path than the other > side of the repair, as it would be for a transport style segment > protection. This provides a more efficient use of bandwidth during > the temporary protection for the common case where zero signaled > bandwidth is reserved on the protect path and diffserv marking is > used. > > As a result FRR is not symetric but instead results in lower > congestion for the lowest priority service carried (BE, often used for > plain old Internet service). If the path were symetric, then a++ > different FRR backup would be needed depending on whether the far end > node failed or the link to that node failed. If node failure is > assumed, then the backup paths are not symetric. For example, in > A-B-C-D-E-F, where link C-D fails, C sends to E and D sends to B. > > If using FRR it is better to just live with the existing behavior > where protection makes efficient use of capacity, not trying to loop > back to the other side of the fault, is assymetric, and is temporary. > > Curtis From rjs@rob.sh Tue Apr 19 22:04:54 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C0941E0689 for ; Tue, 19 Apr 2011 22:04:54 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZlAJHpatb9w for ; Tue, 19 Apr 2011 22:04:54 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfc.amsl.com (Postfix) with ESMTP id 392C3E067C for ; Tue, 19 Apr 2011 22:04:53 -0700 (PDT) Received: from [93.97.180.64] (helo=[192.168.1.89]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1QCPam-000250-6e; Wed, 20 Apr 2011 06:04:44 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: Date: Wed, 20 Apr 2011 06:04:42 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1B131BEC-337A-4773-9371-ECDECD0D78F4@rob.sh> References: To: Ross Callon X-Mailer: Apple Mail (2.1082) Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 05:04:54 -0000 On 18 Apr 2011, at 16:15, Ross Callon wrote: > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. Support - this is a neat solution. Cheers, r. From yaakov_s@rad.com Wed Apr 20 02:55:04 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFD11E06A3 for ; Wed, 20 Apr 2011 02:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb3sBXcuJ42K for ; Wed, 20 Apr 2011 02:55:04 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by ietfc.amsl.com (Postfix) with ESMTP id B7E3CE0670 for ; Wed, 20 Apr 2011 02:55:02 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 20 Apr 2011 12:54:57 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 20 Apr 2011 12:53:03 +0300 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Wed, 20 Apr 2011 12:53:03 +0300 From: Yaakov Stein To: Ross Callon , "mpls@ietf.org" Thread-Topic: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQAFkiMxA= Date: Wed, 20 Apr 2011 09:53:02 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E0A90F@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:55:05 -0000 Support. I do question the wording in section 3 : Entropy labels MUST be at the bottom of the label stack, and thus the 'Bottom of Stack' (S) bit ([RFC3032]) in the label should be set. <> be set ? Not only does this contradict the wording in section 4.1 EL is a 'regular' 32-bit label whose S bit MUST be 1 it also begs the question "when is the bottom-of-stack label NOT set ?" . Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Monday, April 18, 2011 18:16 To: mpls@ietf.org Subject: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG docume= nt All, this is to start a two week working group poll on whether to make draft-kompella-mpls-entropy-label an mpls wg document. Please send your comments to the mpls@ietf.org mailing list. The poll ends on May 3rd.=20 thanks Ross (as WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Wed Apr 20 08:29:59 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 20D9EE0766 for ; Wed, 20 Apr 2011 08:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PERlvPsvZsjN for ; Wed, 20 Apr 2011 08:29:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id F1E30E06FE for ; Wed, 20 Apr 2011 08:29:57 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3KFTsH7019383; Wed, 20 Apr 2011 10:29:56 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.159]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 20 Apr 2011 11:29:51 -0400 From: David Allan I To: "mpls@ietf.org" Date: Wed, 20 Apr 2011 11:29:50 -0400 Thread-Topic: Poll / Final in draft-cc-cv-rdi Thread-Index: Acv+tvS4BEK+rt17R96WWlGBJIq3WgAuHfsA Message-ID: <60C093A41B5E45409A19D42CF7786DFD521A20DDDF@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0082_01CBFF35.1D53C590" MIME-Version: 1.0 Cc: Ross Callon Subject: [mpls] FW: Poll / Final in draft-cc-cv-rdi X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:29:59 -0000 ------=_NextPart_000_0082_01CBFF35.1D53C590 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Folks: We've received a number of comments both formally and informally that the current draft has deviated too far from the base BFD spec and thus loses backward compatibility with existing code bases. Further, discussions with the BFD WG have indicated we have a potential race condition in the current startup procedures described in draft-cc-cv-rdi. The issue is the transition to UP state requires confirmation by the peer MEP prior to changing the detection time to the rx-interval x detect mult in order to avoid potential flapping. This can result in an implementation effectively needing two UP states (UP forward, UP reverse direction). Otherwise the MEP may time out the reverse direction before seeing an UP state from the peer MEP. So we can make this implicit in the specification and require BFD changes or we can use poll/final discipline on startup as defined in the base specification and make the transition to fully UP and the desired rate both explicit and exposed in the protocol exchange. This would reduce the deltas between the base spec (RFC 5880) and draft CC-CV-RDI. We would also observe that it is permissable in the specification to respond to a poll with a final reply with the session parameters unchanged. So once a session is up a compliant implementation does not actually have to implement on the fly changes to session paramters. The processing of the poll bit can simply be reduced to setting the final bit in the next message. This would permit implementations to optimize the UP processing loop. This is a change of direction from what has been in the draft to date, hence we'd look to the WG for comment on this change... the editors Dave, John and George... ------=_NextPart_000_0082_01CBFF35.1D53C590 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQUTCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIELjCCAxagAwIBAgIRALblbh/SK1c9Ljnzou72C4UwDQYJKoZIhvcNAQEFBQAw OTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Ew MTAeFw0wOTEwMjgxMzAwMzVaFw0xMjEwMjgxMzAwMzJaMGYxETAPBgNVBAoMCEVyaWNzc29uMRQw EgYDVQQDDAtEYXZpZCBBbGxhbjEQMA4GA1UEBRMHZWFsbGRhdjEpMCcGCSqGSIb3DQEJARYaZGF2 aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALcxmDlr O4lawMYgUOZdbfo3ZCBNOKIDfrOeZg5dmU0kgGrSkFPw5BK5I4bR13PMlTy5yEMSKlSeR8Q1E6nc mYJRQEHYQlrNzItpoTC73kANBEYoI3oAqkcJxj1CZJv+9jvWAaEpajxg9l8WuSe/XAfjS79BI/Y6 DXtgOsZKdwTxAgMBAAGjggGGMIIBgjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3Js LnRydXN0LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRh cC50cnVzdC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89 RXJpY3Nzb24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAlBgNVHREEHjAc gRpkYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbTBGBgNVHSAEPzA9MDsGBiqFcGsBATAxMC8GCCsG AQUFBwIBFiNodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9sZWdhbC5zaHRtbDAdBgNVHQ4EFgQUayrt IThpu38nwwrhT4GDR/+dIWAwHwYDVR0jBBgwFoAUlifDuN6lX11EPjlS5UWxdl9jMJswDgYDVR0P AQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4IBAQBzF4/vMotGcoPjCyuIUptzrYoQ8VhJe5/ufZNv 78ulVpc0LBaBjDx4r7xnPiM8wKKSY+GAzeWneeh6fK5epbDih7uB78kcziHeZGar6g8PHk/NZAKb A/MHOpHQZc72zzQC/eQJl3sFtctDVX5dLnrTwL/2nHp1genPDl7Ff0yvUkobDD/3oIWKIrGV0ayw jMrpCkpn+F5/3UxymJQ/8961F4GWivcUuYgbNmIBZMdaR+LoDZHD7p2268LwuYPFj6LHsHE/dIVY ZYzVRKP3+jbzMuipOv3wB0zIG5Vr9diGCKzUmyVK6HA2f0HAmWOGV3oHg1BdIWulvx1+MmetnK/L MIIERTCCAy2gAwIBAgIQE8nq/94mrancpMojgYNH4zANBgkqhkiG9w0BAQUFADBEMRowGAYDVQQK DBFUZWxpYVNvbmVyYSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0Eg djEwHhcNMDYxMDA2MTAwMDUzWhcNMTYxMDAyMDUwNDE3WjA5MREwDwYDVQQKDAhFcmljc3NvbjEk MCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAthB35DUe64fEPI0YWUQ/MLG488U7lbbHKv6eoJWc0nhBgV7UcAKpq+o0vBQY iogTIe/Wsud+5v0sFzt1ClEeOX92CCKfQ404UnfqdsYRt8eMsnPYHM5a/CXzhJz4XHT0isNT9JlJ YVJ+GpO7dNPf2Hv1usd1GR08FSAFiCyIUquIcjROM/kbzrbwfbsEPOpSnMYtJhaC3r+2nC44fmVx 818dYxwJhdGWhu/QqW7yXEblqZaoCeqsfoQI7JglNFsdOxpMhk4fL1DD/R5c+6MpPu1TnHFIjZJ1 x4mrNRsDPagVFDo/Hv8bJ2kz9GX6pigY9xq4dQvVpJ5UlmoMWpwgXQIDAQABo4IBPDCCATgwEgYD VR0TAQH/BAgwBgEB/wIBADBGBgNVHSAEPzA9MDsGByqFcCMCAQEwMDAuBggrBgEFBQcCARYiaHR0 cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTCBiQYDVR0fBIGBMH8wfaB7oHmGd2xkYXA6 Ly9sZGFwLnRydXN0LnRlbGlhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFB1YmxpYyUyMFJvb3QlMjBD QSUyMHYxLG89VGVsaWFTb25lcmElMjBHcm91cD9hdXRob3JpdHlyZXZvY2F0aW9ubGlzdD9iYXNl MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUlifDuN6lX11EPjlS5UWxdl9jMJswHwYDVR0jBBgw FoAURdvwj7gaYqGoIxtjiDij2+AaYvEwDQYJKoZIhvcNAQEFBQADggEBAHYASipDP4zdFr1qWSmf 9ifCFci/q0+OFS9K42zTQ2F3RP1eGUhTdrrkJoH9QpKqdrITS3tDRCrev7H8YreKf+aKTyL88rb+ rwe63NgVLPPo2nO2mjYkbsAQo4k9Vp55uOeDjmbq80LtEh/NT2wbYsFH+F7BLyzp0UWfvTDv3nFT AkFZnrs7MgpeshVW8dM5iltYD4wRIoBfAWGdU42s5NaVXCsxSLgduI9ak6T7FBuB6EISLua7dxex pTVereQxe6I24LtUqihvyYU72j1FP52WKsPa5FfA2m8K7du63orKG7T6e/LaJcYqN2XGVZOx0PK6 VdjP45gIxn2UVZHMwg8wggRtMIIDVaADAgECAhEAnLCMBJrLlyJ4Y2K2G4ZaPTANBgkqhkiG9w0B AQUFADA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkg MjA0OCBWMzAeFw0wNjEwMzEyMDQyMjdaFw0xNjExMDExNTQyMjVaMEQxGjAYBgNVBAoMEVRlbGlh U29uZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMpPEANqkICreamVfhHiA235Zl7lAoadpURBLJju UgIoXkO5V1Y8wscOPOHDkjMN3zrRlnH/RWuEYHcOY/hIMhYIqjY/G9jk1yR0FY9an9Pa5pB04DCC oek3Sl7Vfv+N6Xn1axZhcoaD/zVa2Hvdkr+B4TsbP0++PUtTo3hiEsyCijEqcJL5mMHmJxYCD5B3 VClCEXjofWJunouwFYOnnow+mDwXlfrLswZVwpgt2cs4+zzi7FFb2qzWQGinNAGPqzlLJWHwD6Pm WIMGOCFdinD/6loYR2oc95IVjFkp4lq2aMQotiXFxlZEp/jfoq9AD2MGEwSbK0w1saJxHWZEfq0C AwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk+v8kLDPQsZ2MMB0GA1UdDgQWBBRF 2/CPuBpioagjG2OIOKPb4Bpi8TASBgNVHRMBAf8ECDAGAQH/AgEEMIGFBgNVHSAEfjB8MD0GCSqG SIb3DQUGATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29t MDsGByqFcCMCAQEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh LmNvbTBwBgNVHR8EaTBnMGWgY6Bhhl9odHRwOi8vd3d3LnJzYXNlY3VyaXR5LmNvbS9wcm9kdWN0 cy9rZW9uL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVfc3RhdHVzL1JTQV9TZWN1cml0eV8yMDQ4X3Yz LkNSTDAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAARemizYKcibv/zvbK1KsQdZ mC+E5QSRSbbk9Z/9eRaSjjVNov28hLVLoB1YKE2paadiJLsZ9oiIMz2zUPoruGJ1YEM6bjps10zd nCEzIMJ+QMlKB4nTD7tiaO8KG7uBaoNkKxu1nmADWLEJN0Oe5kHrskZI8ZbqvvdyitoM/x2I6mJC i4y8zpsq5M8Ef/WmgtxyxTGwqCtDbckL0tYJFvxxgeRmNcUfUrjhOwiXkud7ahPQkjenB0Da/qM7 in84see0/6emPA9t50w9RmQNgKR3ctLGPxzclPG0DxKU8K0gcTWGHrnGKGDUlEiWJKmGuqv2Rt/A d15XE904jka0Ng8xggJ+MIICegIBATBOMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQC25W4f0itXPS4586Lu9guFMAkGBSsOAwIaBQCg ggGGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQyMDE1Mjk1 MFowIwYJKoZIhvcNAQkEMRYEFHg9RIvwRV/BXULbYOvoPmqRuK34MF0GCSsGAQQBgjcQBDFQME4w OTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Ew MQIRALblbh/SK1c9Ljnzou72C4UwXwYLKoZIhvcNAQkQAgsxUKBOMDkxETAPBgNVBAoMCEVyaWNz c29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQC25W4f0itXPS4586Lu 9guFMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqG SIb3DQEBAQUABIGANEKQJ0p/o2z5q2kZ/9VIY+2iS1d5wwBHrtqIy2gP3OhbuY8PdWMPyOT77Mza POgj6QjbeyiAir3sCTIjLT79TMGGUokL3EIVkT48/W0ZCEqcqg9XZoF2LtGw2E6AeT1iOHP4Ht5y EVLe2evHva6EBemHl/ZRW/TnsXmleiMZ+C0AAAAAAAA= ------=_NextPart_000_0082_01CBFF35.1D53C590-- From gregimirsky@gmail.com Wed Apr 20 13:23:33 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8E175E073F for ; Wed, 20 Apr 2011 13:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN0K9YIX7h21 for ; Wed, 20 Apr 2011 13:23:32 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id D801CE0669 for ; Wed, 20 Apr 2011 13:23:32 -0700 (PDT) Received: by vxg33 with SMTP id 33so1013900vxg.31 for ; Wed, 20 Apr 2011 13:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=x/Xz1Z2X0ssWhRfjE95QysvctUENg3GoneF6IBUK6PI=; b=k+TcjZtCeyx/KhWtv2B8jxpCFKW9erlEFJIRPNhqfGzziIWHgbMoGbSm58HbaykpfV sjcDJwC9E/2tdBde5bbjfqqhbHlZ8XjmBhOQnvkXdOJuus1dtmiz/02PPZqox5Sg8zA/ PANmSEjUt2V6hH8pkFdf+lh9JZBUwee4YaHjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SFeMbnh++XTcxZYUesvBVYg8xc4EC+WHLP1CJK8pYSmB5BkYQaOEKOzp+BvcdQWt1h 8UnWV5NYK6ocFzGxB3i/oFygtpbRhP3bfrp02Mz1EZivbcEKrPx/ylHHi2Nx/KkNUYsD KkEK9WBvjfbvWt82lEsHD8ohOzDEg25GI0oeI= MIME-Version: 1.0 Received: by 10.52.0.66 with SMTP id 2mr32519vdc.308.1303331012500; Wed, 20 Apr 2011 13:23:32 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Wed, 20 Apr 2011 13:23:32 -0700 (PDT) Date: Wed, 20 Apr 2011 13:23:32 -0700 Message-ID: From: Greg Mirsky To: David Allan I , John E Drake , swallow@cisco.com, Annamaria Fulignoli , Sami Boutros , martin.vigoureux@alcatel-lucent.com, "Siva Sivabalan(msiva)" , David Ward , mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf3054a11b065e1004a15f6681 Subject: [mpls] Mis-connectivity defect #4 in draft-ietf-mpls-tp-cc-cv-rdi X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 20:23:33 -0000 --20cf3054a11b065e1004a15f6681 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, I think that question of FRR applicability in MPLS-TP networks was discussed but I couldn't find if the conclusion was reached. I think that FRR is applicable to unidirectional p2p and p2mp LSPs and bi-directional associated LSP if it's monitored, protected in independent mode. I assume that both FRR methods, one-to-one and facility, are equally applicable in MPLS-TP networks. Hence my question: In Section 3.5.2: Receipt of an expected session discriminator with an unexpected label (mis-connectivity defect). but with one-to-one backup FRR, LER being MP, local protection being in use ingress label will be different from one of protected LSP. In order not to generate false positive it must be associated with the session discriminator. Hence my question: If my assumptions regarding FRR in MPLS-TP accurate is there a gap in associating one-to-one backup LSP with CC/CV/RDI session? Regards, Greg --20cf3054a11b065e1004a15f6681 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
    I think that question of FRR applicability in MPLS-TP netw= orks was discussed but I couldn't find if the conclusion was reached. <= br>I think that FRR is applicable to unidirectional p2p and p2mp LSPs and b= i-directional associated LSP if it's monitored, protected in independen= t mode. I assume that both FRR methods, one-to-one and facility, are equall= y applicable in MPLS-TP networks. Hence my question:
    In Section 3.5.2:
    Receipt of an expected s= ession discriminator with an unexpected label (mis-connectivity defect).
    but with one-to-one backup FRR, LER being MP, local protection bein= g in use ingress label will be different from one of protected LSP. In orde= r not to generate false positive it must be associated with the session dis= criminator.
    Hence my question:
    If my assumptions regarding FRR in MPLS-TP accurate i= s there a gap in associating one-to-one backup LSP with CC/CV/RDI session?<= br>

    Regards,
    Greg
    --20cf3054a11b065e1004a15f6681-- From lmartini@cisco.com Wed Apr 20 15:19:35 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72324E0796; Wed, 20 Apr 2011 15:19:35 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH4yZl4H4tYE; Wed, 20 Apr 2011 15:19:34 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfc.amsl.com (Postfix) with ESMTP id 9D96AE0791; Wed, 20 Apr 2011 15:19:34 -0700 (PDT) Received: from seven.monoski.com ([65.114.195.189]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p3KMISmx020321 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 16:18:29 -0600 (MDT) Message-ID: <4DAF5BB3.9030607@cisco.com> Date: Wed, 20 Apr 2011 16:18:27 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mach Chen References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:19:35 -0000 On 04/14/2011 08:35 PM, Mach Chen wrote: > Hi Luca, > > You said T-LDP is not part of the MPLS-TP control plane. > > IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is figure about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP layer. > > In addition, in the abstract of MPLS-TP control plane (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says: > "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs)..." > Mach, The point is not about running LDP over an MPLS-TP LSP. Today you simply cannot control or provision an MPLS-TP LSP using LDP. You can Provision a PW using LDP, but not an MPLS-TP LSP. There are several ways to run LDP over an MPLS -TP LSP, as well, but I cannot find an explicit indication of a standard way. In any case the problem you are proposing is not specific to MPLS-TP, so solution must be general enough to apply to MPLS. Luca > Best regards, > Mach > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Luca Martini >> Sent: Friday, April 15, 2011 2:11 AM >> To: Greg Mirsky >> Cc: pwe3@ietf.org >> Subject: Re: [PWE3] PWE3 working group poll for >> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt >> >> On 04/14/11 00:09, Greg Mirsky wrote: >>> Luca, >>> you've asked >>> How would LDP , which is IP based , even run on an MPLS-TP network ? >>> but isn't T-LDP part of MPLS-TP control plane? Control plane assumes >>> IP addressing thus use of T-LDP is plausible. >>> >> No T-LDP is not part of the MPLS-TP control plane. >> It could be , but i think folks are more leaning toward GMPLS instead. >> >> Note that the problem described in this document exists for MPLS. So in >> that case LDP is certainly used. But the document appears to only care >> about MPLS-TP. >> >> Luca >> >> >> >>> Regards, >>> Greg >>> From mach.chen@huawei.com Wed Apr 20 19:19:20 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D33B6E0819; Wed, 20 Apr 2011 19:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.638 X-Spam-Level: X-Spam-Status: No, score=-5.638 tagged_above=-999 required=5 tests=[AWL=0.961, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUoQR+jC+YZ3; Wed, 20 Apr 2011 19:19:20 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id BB35DE080F; Wed, 20 Apr 2011 19:19:19 -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 <0LJZ00J5ZD46V0@szxga04-in.huawei.com>; Thu, 21 Apr 2011 10:19:18 +0800 (CST) Received: from szxeml208-edg.china.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 <0LJZ009G0D46FE@szxga04-in.huawei.com>; Thu, 21 Apr 2011 10:19:18 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Apr 2011 10:19:11 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 21 Apr 2011 10:19:18 +0800 Date: Thu, 21 Apr 2011 02:18:17 +0000 From: Mach Chen In-reply-to: <4DAF5BB3.9030607@cisco.com> X-Originating-IP: [10.110.98.38] To: Luca Martini Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] Whether T-LDP is part of the MPLS-TP control plane Thread-index: AQHL+xXOuBRay31Jh0yRN2bvU9H63ZRm1XWAgADHm5A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DA685B4.9080804@cisco.com> <4DA738A4.8010904@cisco.com> <4DAF5BB3.9030607@cisco.com> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] Whether T-LDP is part of the MPLS-TP control plane X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 02:19:21 -0000 Hi Luca, > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Luca Martini > Sent: Thursday, April 21, 2011 6:18 AM > To: Mach Chen > Cc: pwe3@ietf.org; mpls@ietf.org > Subject: Re: [mpls] Whether T-LDP is part of the MPLS-TP control plane > > > On 04/14/2011 08:35 PM, Mach Chen wrote: > > Hi Luca, > > > > You said T-LDP is not part of the MPLS-TP control plane. > > > > IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is figure > about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP layer. > > > > In addition, in the abstract of MPLS-TP control plane > (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says: > > "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched > Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for > Pseudowires (PWs)..." > > > Mach, > The point is not about running LDP over an MPLS-TP LSP. Today you simply > cannot control or provision an MPLS-TP LSP using LDP. You can Provision > a PW using LDP, but not an MPLS-TP LSP. But noting that we are talking about whether LDP is "PART" of the MPLS-TP control plane :-) > > There are several ways to run LDP over an MPLS -TP LSP, as well, but I > cannot find an explicit indication of a standard way. > > In any case the problem you are proposing is not specific to MPLS-TP, so > solution must be general enough to apply to MPLS. Agree! Best regards, Mach > > Luca > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > >> Luca Martini > >> Sent: Friday, April 15, 2011 2:11 AM > >> To: Greg Mirsky > >> Cc: pwe3@ietf.org > >> Subject: Re: [PWE3] PWE3 working group poll for > >> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt > >> > >> On 04/14/11 00:09, Greg Mirsky wrote: > >>> Luca, > >>> you've asked > >>> How would LDP , which is IP based , even run on an MPLS-TP network ? > >>> but isn't T-LDP part of MPLS-TP control plane? Control plane assumes > >>> IP addressing thus use of T-LDP is plausible. > >>> > >> No T-LDP is not part of the MPLS-TP control plane. > >> It could be , but i think folks are more leaning toward GMPLS instead. > >> > >> Note that the problem described in this document exists for MPLS. So in > >> that case LDP is certainly used. But the document appears to only care > >> about MPLS-TP. > >> > >> Luca > >> > >> > >> > >>> Regards, > >>> Greg > >>> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From dai.xuehui@zte.com.cn Wed Apr 20 22:51:17 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94EABE0706; Wed, 20 Apr 2011 22:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.035 X-Spam-Level: X-Spam-Status: No, score=-97.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY03vsjxxGIx; Wed, 20 Apr 2011 22:51:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by ietfc.amsl.com (Postfix) with ESMTP id 6AB18E06FB; Wed, 20 Apr 2011 22:51:14 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101784411434; Thu, 21 Apr 2011 13:48:38 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 95720.1895989657; Thu, 21 Apr 2011 13:39:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3L5p11F063927; Thu, 21 Apr 2011 13:51:01 +0800 (GMT-8) (envelope-from dai.xuehui@zte.com.cn) In-Reply-To: To: Manav Bhatia MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: dai.xuehui@zte.com.cn Date: Thu, 21 Apr 2011 13:50:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-21 13:51:01, Serialize complete at 2011-04-21 13:51:01 Content-Type: multipart/alternative; boundary="=_alternative 002023F648257879_=" X-MAIL: mse01.zte.com.cn p3L5p11F063927 Cc: mpls@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 05:51:17 -0000 This is a multipart message in MIME format. --=_alternative 002023F648257879_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTWFuYXajrA0KDQpJbiB0aGUgYWJzdHJhY3Qgb2YgeW91ciBkcmFmdCwgeW91IHNhaWQgIiBB ZGRpdGlvbmFsbHksIGl0IGFsc28gZGVzY3JpYmVzIA0KaG93DQpiaS1kaXJlY3Rpb25hbCBzeW1t ZXRyaWNhbCBGYXN0IFJlcm91dGUgdXNpbmcgYm90aCBvbmUtdG8tb25lIGFuZA0KZmFjaWxpdHkg YmFja3VwIGNhbiBiZSBhY2hpZXZlZC4iDQoNCkkgaGF2ZSB0d28gcXVlc3Rpb25zIG5lZWRzIHlv dXIgY2xhcmlmaWNhdGlvbiwgdGhleSBhcmUgYm90aCBhYm91dCB0aGUgDQpiaWRpcmVjdGlvbmFs IEZSUjoNCg0KRmlyc3QsIHVuZGVyIHRoZSBub2RlIHByb3RlY3Rpb24gY29uZGl0aW9uLCBpZiBh IGZhbGl1cmUgb2NjdXJzIG9uIHRoZSANCmxpbmsgYmV0d2VlbiB0aGUgdXBzdHJlYW0gUExSIGFu ZCB0aGUgcHJvdGVjdGVkIG5vZGUsIHN1Y2ggYXMgbGluayBCLS1DIGluIA0KZmlndXJlIDMsIHRo ZW4gdGhlIHVwc3RyZWFtIFBMUiBjYW4gZGVyZWN0IHRoaXMgZmFsaXVyZSBhbmQgZG8gcHJvdGVj dGlvbiwgDQpidXQgaG93IGNhbiB0aGUgZG93bnN0cmVhbSBQTFIga25vdyBpdCBhbHNvIG5lZWRz IHRvIHN3aXRjaCB0byB0aGUgZGV0b3VyIA0KbHNwPw0KDQpzZWNvbmQsIGluIGJ5cGFzcyBtZXRo b2QsIGhvdyBjYW4gdGhlIGRvd25zdHJlYW0gTVAob3IgZG93bnN0cmVhbSBQTFIpIA0KYmluZHMg dGhlIHByb3RlY3RlZCBMU1Agd2l0aCB0aGUgYnlwYXNzIHR1bm5lbD8NCg0KDQpiZXN0IHJlZ2Fy ZHMsDQoNCnh1ZWh1aQ0KDQoNCg0KDQoNCk1hbmF2IEJoYXRpYSA8bWFuYXZiaGF0aWFAZ21haWwu Y29tPiANCreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0wNC0xNiAwMTowMw0K DQrK1bz+yMsNCm1wbHNAaWV0Zi5vcmcNCrOty80NCg0K1vfM4g0KW21wbHNdIGRyYWZ0LWJoYXRp YS1tcGxzLXJzdnAtdGUtYmlkaXJlY3Rpb25hbC1sc3ANCg0KDQoNCg0KDQoNCkhpLA0KDQpJIGhh dmUgcG9zdGVkIGEgbmV3IGRyYWZ0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1iaGF0 aWEtbXBscy1yc3ZwLXRlLWJpZGlyZWN0aW9uYWwtbHNwLTAwLnR4dA0KDQpBYnN0cmFjdA0KDQpU aGVyZSBhcmUgc2V2ZXJhbCBhcHBsaWNhdGlvbnMgdGhhdCByZXF1aXJlIHN5bW1ldHJpYyBNdWx0 aXByb3RvY29sDQpMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIHBhdGggYmV0d2VlbiB0d28gcG9pbnRz LiAgVGhpcyBjYW5ub3QgYmUNCmFjaGlldmVkIHdpdGggcmVndWxhciBNUExTIGFzIHRoZSBMU1Bz IGFyZSB1bmlkaXJlY3Rpb25hbC4gIElmDQpzeW1tZXRyeSBpcyByZXF1aXJlZCwgYSBzZXBhcmF0 ZSBMU1AgaW4gZWFjaCBkaXJlY3Rpb24gaXMgcmVxdWlyZWQgZm9yDQpiaWRpcmVjdGlvbmFsIHRy YWZmaWMgZmxvdy4gIEdlbmVyYWxpemVkIE1QTFMgb24gdGhlIG90aGVyIGhhbmQsIGhhcw0KcHJv dmlzaW9ucyBmb3Igc2V0dGluZyB1cCBhIGJpZGlyZWN0aW9uYWwgTFNQLiAgVGhpcyBkb2N1bWVu dCB1c2VzIHRoZQ0KZXh0ZW5zaW9ucyBpbnRyb2R1Y2VkIGZvciBHTVBMUyBhbmQgYXBwbGllcyBp dCB0byByZWd1bGFyIE1QTFMgZm9yDQplc3RhYmxpc2hpbmcgYmlkaXJlY3Rpb25hbCBMU1BzLiAg QWRkaXRpb25hbGx5LCBpdCBhbHNvIGRlc2NyaWJlcyBob3cNCmJpLWRpcmVjdGlvbmFsIHN5bW1l dHJpY2FsIEZhc3QgUmVyb3V0ZSB1c2luZyBib3RoIG9uZS10by1vbmUgYW5kDQpmYWNpbGl0eSBi YWNrdXAgY2FuIGJlIGFjaGlldmVkLg0KDQpXb3VsZCBiZSBncmVhdCBpZiB0aGUgV0cgY2FuIHBy b3ZpZGUgc29tZSBmZWVkYmFjayBvbiB0aGlzLg0KDQpDaGVlcnMsIE1hbmF2DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QN Cm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KDQoNCg0K --=_alternative 002023F648257879_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE1hbmF2o6w8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIHRoZSBhYnN0cmFjdCBv ZiB5b3VyIGRyYWZ0LCB5b3Ugc2FpZA0KJnF1b3Q7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+IEFk ZGl0aW9uYWxseSwgaXQgYWxzbyBkZXNjcmliZXMgaG93PGJyPg0KYmktZGlyZWN0aW9uYWwgc3lt bWV0cmljYWwgRmFzdCBSZXJvdXRlIHVzaW5nIGJvdGggb25lLXRvLW9uZSBhbmQ8YnI+DQpmYWNp bGl0eSBiYWNrdXAgY2FuIGJlIGFjaGlldmVkLjwvZm9udD48L3R0Pjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkkgaGF2ZSB0d28gcXVlc3Rpb25zIG5lZWRzIHlvdXIgY2xhcmlmaWNhdGlv biwNCnRoZXkgYXJlIGJvdGggYWJvdXQgdGhlIGJpZGlyZWN0aW9uYWwgRlJSOjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Rmlyc3QsIHVuZGVyIHRoZSBu b2RlIHByb3RlY3Rpb24gY29uZGl0aW9uLA0KaWYgYSBmYWxpdXJlIG9jY3VycyBvbiB0aGUgbGlu ayBiZXR3ZWVuIHRoZSB1cHN0cmVhbSBQTFIgYW5kIHRoZSBwcm90ZWN0ZWQNCm5vZGUsIHN1Y2gg YXMgbGluayBCLS1DIGluIGZpZ3VyZSAzLCB0aGVuIHRoZSB1cHN0cmVhbSBQTFIgY2FuIGRlcmVj dCB0aGlzDQpmYWxpdXJlIGFuZCBkbyBwcm90ZWN0aW9uLCBidXQgaG93IGNhbiB0aGUgZG93bnN0 cmVhbSBQTFIga25vdyBpdCBhbHNvDQpuZWVkcyB0byBzd2l0Y2ggdG8gdGhlIGRldG91ciBsc3A/ PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zZWNvbmQs IGluIGJ5cGFzcyBtZXRob2QsIGhvdyBjYW4gdGhlDQpkb3duc3RyZWFtIE1QKG9yIGRvd25zdHJl YW0gUExSKSBiaW5kcyB0aGUgcHJvdGVjdGVkIExTUCB3aXRoIHRoZSBieXBhc3MNCnR1bm5lbD88 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJl c3QgcmVnYXJkcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPnh1ZWh1aTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5NYW5hdiBCaGF0aWEgJmx0O21hbmF2YmhhdGlhQGdtYWlsLmNv bSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrei vP7IyzogJm5ic3A7bXBscy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDQtMTYgMDE6MDM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQl Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+bXBsc0BpZXRmLm9yZzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W21wbHNd IGRyYWZ0LWJoYXRpYS1tcGxzLXJzdnAtdGUtYmlkaXJlY3Rpb25hbC1sc3A8L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhpLDxicj4NCjxi cj4NCkkgaGF2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQ6PGJyPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1iaGF0aWEtbXBscy1yc3ZwLXRlLWJpZGlyZWN0aW9uYWwtbHNwLTAwLnR4dDxicj4N Cjxicj4NCkFic3RyYWN0PGJyPg0KPGJyPg0KVGhlcmUgYXJlIHNldmVyYWwgYXBwbGljYXRpb25z IHRoYXQgcmVxdWlyZSBzeW1tZXRyaWMgTXVsdGlwcm90b2NvbDxicj4NCkxhYmVsIFN3aXRjaGlu ZyAoTVBMUykgcGF0aCBiZXR3ZWVuIHR3byBwb2ludHMuICZuYnNwO1RoaXMgY2Fubm90IGJlPGJy Pg0KYWNoaWV2ZWQgd2l0aCByZWd1bGFyIE1QTFMgYXMgdGhlIExTUHMgYXJlIHVuaWRpcmVjdGlv bmFsLiAmbmJzcDtJZjxicj4NCnN5bW1ldHJ5IGlzIHJlcXVpcmVkLCBhIHNlcGFyYXRlIExTUCBp biBlYWNoIGRpcmVjdGlvbiBpcyByZXF1aXJlZCBmb3I8YnI+DQpiaWRpcmVjdGlvbmFsIHRyYWZm aWMgZmxvdy4gJm5ic3A7R2VuZXJhbGl6ZWQgTVBMUyBvbiB0aGUgb3RoZXIgaGFuZCwgaGFzPGJy Pg0KcHJvdmlzaW9ucyBmb3Igc2V0dGluZyB1cCBhIGJpZGlyZWN0aW9uYWwgTFNQLiAmbmJzcDtU aGlzIGRvY3VtZW50IHVzZXMNCnRoZTxicj4NCmV4dGVuc2lvbnMgaW50cm9kdWNlZCBmb3IgR01Q TFMgYW5kIGFwcGxpZXMgaXQgdG8gcmVndWxhciBNUExTIGZvcjxicj4NCmVzdGFibGlzaGluZyBi aWRpcmVjdGlvbmFsIExTUHMuICZuYnNwO0FkZGl0aW9uYWxseSwgaXQgYWxzbyBkZXNjcmliZXMN Cmhvdzxicj4NCmJpLWRpcmVjdGlvbmFsIHN5bW1ldHJpY2FsIEZhc3QgUmVyb3V0ZSB1c2luZyBi b3RoIG9uZS10by1vbmUgYW5kPGJyPg0KZmFjaWxpdHkgYmFja3VwIGNhbiBiZSBhY2hpZXZlZC48 YnI+DQo8YnI+DQpXb3VsZCBiZSBncmVhdCBpZiB0aGUgV0cgY2FuIHByb3ZpZGUgc29tZSBmZWVk YmFjayBvbiB0aGlzLjxicj4NCjxicj4NCkNoZWVycywgTWFuYXY8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0 PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBsczxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 002023F648257879_=-- From manavbhatia@gmail.com Thu Apr 21 02:01:55 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 24187E0759 for ; Thu, 21 Apr 2011 02:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-1.526, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K+mBmv4z2bS for ; Thu, 21 Apr 2011 02:01:54 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfc.amsl.com (Postfix) with ESMTP id 1CD63E0752 for ; Thu, 21 Apr 2011 02:01:54 -0700 (PDT) Received: by gwb20 with SMTP id 20so512785gwb.31 for ; Thu, 21 Apr 2011 02:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SeMN1hxx/g3AgE38A5YQjlLDx5fm12tmtEL8sY9L3E0=; b=sAKha57kgbe+eM28EaWvBabdePMXk/40uVGjUzKy+Nt6gHv7IUZcVSfy8DjQ1kuYIS OWJtqeLowLltnH/sLG4EuS6J9SLwnMHhqlvXHTfCBAv9O7MQTtnYou2cZzSToFFvDu8a cq4Ezx8uB35oFZXAhTL0bbzNuyO5z+1/vixAg= 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=p/rvGVPFbg0TJpkfxJ71cJ0EOArpzmD9fcptjLR7GKrHUGO5wz/RUMMA1Gb/uHeNUc WgdtxypCjTktFcC5DAwNNuqmtch8zPYOi9OGe3ugLi+Y8Arskh8ubvw5dTEGiq188i7B I/E8w1XFdD/3M+7/cBhnlnbiYQiRbvUin/kUc= MIME-Version: 1.0 Received: by 10.236.170.225 with SMTP id p61mr7204367yhl.231.1303376512336; Thu, 21 Apr 2011 02:01:52 -0700 (PDT) Received: by 10.236.155.72 with HTTP; Thu, 21 Apr 2011 02:01:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Apr 2011 14:31:52 +0530 Message-ID: From: Manav Bhatia To: dai.xuehui@zte.com.cn Content-Type: multipart/alternative; boundary=20cf305b131806c2b604a169fe62 Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 09:01:55 -0000 --20cf305b131806c2b604a169fe62 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Xuehui, I should have added text to cover this. During the failure, the PLR must keep sending Path messages in order for th= e protected LSP to keep refreshing the PSB of the MP router for the protected tunnel. This prevents the protected tunnel from a refresh time-out. In the case of a facility bypass tunnel, the PLR sends the Path message for the protected tunnel towards the MP router (NHop or NNHop router) through the bypass tunnel. This path message is encapsulated with the bypass tunnel label (like the traffic that is being protected). In addition to this, the PLR must also modify the first IPv4 sub-object of the ERO. This is because the original ERO on the egress Path message for the protected tunnel will contain the IP address of the failed interface. If th= e PLR does not replace that IP address with an active IP address of its own, the MP will reject the refresh as the MP router will consider the IP addres= s in the failed interface as invalid. Can we consider a change in the ERO as a trigger for FRR on the downstream MP? Alternatively, we could explore using BFD between the PLR-MP (suggested by Lizhong in an offline discussion). Cheers, Manav 2011/4/21 > > Hi Manav=A3=AC > > In the abstract of your draft, you said " Additionally, it also describes > how > > bi-directional symmetrical Fast Reroute using both one-to-one and > facility backup can be achieved. > " > > I have two questions needs your clarification, they are both about the > bidirectional FRR: > > First, under the node protection condition, if a faliure occurs on the li= nk > between the upstream PLR and the protected node, such as link B--C in fig= ure > 3, then the upstream PLR can derect this faliure and do protection, but h= ow > can the downstream PLR know it also needs to switch to the detour lsp? > > second, in bypass method, how can the downstream MP(or downstream PLR) > binds the protected LSP with the bypass tunnel? > > > best regards, > > xuehui > > > > > *Manav Bhatia * > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org > > 2011-04-16 01:03 > =CA=D5=BC=FE=C8=CB > mpls@ietf.org > =B3=AD=CB=CD > =D6=F7=CC=E2 > [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp > > > > > Hi, > > I have posted a new draft: > http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00.txt > > Abstract > > There are several applications that require symmetric Multiprotocol > Label Switching (MPLS) path between two points. This cannot be > achieved with regular MPLS as the LSPs are unidirectional. If > symmetry is required, a separate LSP in each direction is required for > bidirectional traffic flow. Generalized MPLS on the other hand, has > provisions for setting up a bidirectional LSP. This document uses the > extensions introduced for GMPLS and applies it to regular MPLS for > establishing bidirectional LSPs. Additionally, it also describes how > bi-directional symmetrical Fast Reroute using both one-to-one and > facility backup can be achieved. > > Would be great if the WG can provide some feedback on this. > > Cheers, Manav > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > --20cf305b131806c2b604a169fe62 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
    Hi Xuehui,

    I should have added text to cover = this.

    During the failure, the PLR must keep s= ending Path messages in order for the protected LSP to keep refreshing= the PSB of the MP router for the protected tunnel. This prevents the = protected tunnel from a refresh time-out. In the case of a facility by= pass tunnel, the PLR sends the Path message for the protected tunnel t= owards the MP router (NHop or NNHop router) through the bypass tunnel.= This path message is encapsulated with the bypass tunnel label (like = the traffic that is being protected). In addition to this, the PLR mus= t also modify the first IPv4 sub-object of the ERO. This is because th= e original ERO on the egress Path message for the protected tunnel wil= l contain the IP address of the failed interface. If the PLR does not = replace that IP address with an active IP address of its own, the MP w= ill reject the refresh as the MP router will consider the IP address i= n the failed interface as invalid.

    Can we consider a change in the ERO as a trigger for FR= R on the downstream MP? 

    Alternatively, we co= uld explore using BFD between the PLR-MP (suggested by Lizhong in an offlin= e discussion).

    Cheers, Manav

    2011/= 4/21 <dai.xu= ehui@zte.com.cn>

    Hi Manav=A3=AC

    In the abstract of your draft, you= said " Additionally, it also describes how

    bi-directional symmetrical Fast Reroute using both one-to-one and
    facility backup can be achieved.
    "

    I have two questions needs your cl= arification, they are both about the bidirectional FRR:

    First, under the node protection c= ondition, if a faliure occurs on the link between the upstream PLR and the protected node, such as link B--C in figure 3, then the upstream PLR can derect this faliure and do protection, but how can the downstream PLR know it also needs to switch to the detour lsp?

    second, in bypass method, how can = the downstream MP(or downstream PLR) binds the protected LSP with the bypass tunnel?


    best regards,

    xuehui




    Manav Bhatia <manavbhatia@gmail.com>
    =B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.= org

    2011-04-16 01:03

    =CA=D5=BC=FE=C8= =CB
    		mpls@ietf.org
    =B3=AD=CB=CD
    =D6=F7=CC=E2
    		[mpls] draft-bhatia-mpls-rsvp= -te-bidirectional-lsp





    Hi,

    I have posted a new draft:
    http://www.ietf.org/id/draft-bhatia-mpls-rsvp-= te-bidirectional-lsp-00.txt

    Abstract

    There are several applications that require symmetric Multiprotocol
    Label Switching (MPLS) path between two points.  This cannot be
    achieved with regular MPLS as the LSPs are unidirectional.  If
    symmetry is required, a separate LSP in each direction is required for
    bidirectional traffic flow.  Generalized MPLS on the other hand, has provisions for setting up a bidirectional LSP.  This document uses the
    extensions introduced for GMPLS and applies it to regular MPLS for
    establishing bidirectional LSPs.  Additionally, it also describes how
    bi-directional symmetrical Fast Reroute using both one-to-one and
    facility backup can be achieved.

    Would be great if the WG can provide some feedback on this.

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

    --20cf305b131806c2b604a169fe62-- From autumn.liu@ericsson.com Thu Apr 21 10:14:56 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8889E065F for ; Thu, 21 Apr 2011 10:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OCJfIF2YxjH for ; Thu, 21 Apr 2011 10:14:55 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 9120AE06A8 for ; Thu, 21 Apr 2011 10:14:55 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3LHEoae022087; Thu, 21 Apr 2011 12:14:52 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.159]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 21 Apr 2011 13:14:47 -0400 From: Autumn Liu To: Manav Bhatia , "dai.xuehui@zte.com.cn" Date: Thu, 21 Apr 2011 13:14:46 -0400 Thread-Topic: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp Thread-Index: AcwAAwPk05iPDAAuT/CWXSAWqxLXQQAQvv6g Message-ID: <60C093A41B5E45409A19D42CF7786DFD521A20E488@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD521A20E488EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 17:14:57 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD521A20E488EUSAACMS0703e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TWFuYXYsDQoNClRoZSBmYWN0IHRoYXQgUEFUSCBtZXNzYWdlIG9mIHRoZSBwcm90ZWN0ZWQgTFNQ IGlzIHJlY2VpdmVkIG9uIG5ldyBpbnRlcmZhY2Ugb24gdGhlIE1QIGluZGljYXRlcyB0aGF0IEZS UiBpcyBpbiB1c2Ugb24gdGhlIGZvcndhcmQgZGlyZWN0aW9uIGFuZCB0aGlzIGNhbiBiZSB1c2Vk IGFzIGEgdHJpZ2dlciB0byBzd2l0Y2ggb3ZlciBvbiB0aGUgTVAgZm9yIGJhY2t3YXJkIGRpcmVj dGlvbi4gSG93ZXZlciB0aGlzIG1ldGhvZCBvciBvdGhlciBtZXRob2Qgd2l0aCBjb250cm9sIG1l c3NhZ2Ugbm90aWZpY2F0aW9uIGFyZSBtb3N0IGxpa2VseSBub3QgYWJsZSB0byBhY2hpZXZlIDUw IG1zIHN3aXRjaCBvdmVyIHRpbWUuDQpIb3cgYWJvdXQgcnVubmluZyBCRkQgb24gdGhlIGJ5cGFz cyB0dW5uZWwgd2l0aCBuZXcgbm90aWZpY2F0aW9uIHRvIHRyaWdnZXIgdGhlIHN3aXRjaCBvdmVy IG9uIG90aGVyIGVuZCB3aGVuIG9uZSBlbmQgaGFzIEZSUiBmYWlsdXJlIHN3aXRjaCBvdmVyLg0K DQpSZWdhcmRzLA0KQXV0dW1uDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1hbmF2IEJoYXRpYQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIxLCAy MDExIDI6MDIgQU0NClRvOiBkYWkueHVlaHVpQHp0ZS5jb20uY24NCkNjOiBtcGxzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW21wbHNdIGRyYWZ0LWJoYXRpYS1tcGxzLXJzdnAtdGUtYmlkaXJlY3Rp b25hbC1sc3ANCg0KSGkgWHVlaHVpLA0KDQpJIHNob3VsZCBoYXZlIGFkZGVkIHRleHQgdG8gY292 ZXIgdGhpcy4NCg0KRHVyaW5nIHRoZSBmYWlsdXJlLCB0aGUgUExSIG11c3Qga2VlcCBzZW5kaW5n IFBhdGggbWVzc2FnZXMgaW4gb3JkZXIgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQIHRvIGtlZXAgcmVm cmVzaGluZyB0aGUgUFNCIG9mIHRoZSBNUCByb3V0ZXIgZm9yIHRoZSBwcm90ZWN0ZWQgdHVubmVs LiBUaGlzIHByZXZlbnRzIHRoZSBwcm90ZWN0ZWQgdHVubmVsIGZyb20gYSByZWZyZXNoIHRpbWUt b3V0LiBJbiB0aGUgY2FzZSBvZiBhIGZhY2lsaXR5IGJ5cGFzcyB0dW5uZWwsIHRoZSBQTFIgc2Vu ZHMgdGhlIFBhdGggbWVzc2FnZSBmb3IgdGhlIHByb3RlY3RlZCB0dW5uZWwgdG93YXJkcyB0aGUg TVAgcm91dGVyIChOSG9wIG9yIE5OSG9wIHJvdXRlcikgdGhyb3VnaCB0aGUgYnlwYXNzIHR1bm5l bC4gVGhpcyBwYXRoIG1lc3NhZ2UgaXMgZW5jYXBzdWxhdGVkIHdpdGggdGhlIGJ5cGFzcyB0dW5u ZWwgbGFiZWwgKGxpa2UgdGhlIHRyYWZmaWMgdGhhdCBpcyBiZWluZyBwcm90ZWN0ZWQpLiBJbiBh ZGRpdGlvbiB0byB0aGlzLCB0aGUgUExSIG11c3QgYWxzbyBtb2RpZnkgdGhlIGZpcnN0IElQdjQg c3ViLW9iamVjdCBvZiB0aGUgRVJPLiBUaGlzIGlzIGJlY2F1c2UgdGhlIG9yaWdpbmFsIEVSTyBv biB0aGUgZWdyZXNzIFBhdGggbWVzc2FnZSBmb3IgdGhlIHByb3RlY3RlZCB0dW5uZWwgd2lsbCBj b250YWluIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBmYWlsZWQgaW50ZXJmYWNlLiBJZiB0aGUgUExS IGRvZXMgbm90IHJlcGxhY2UgdGhhdCBJUCBhZGRyZXNzIHdpdGggYW4gYWN0aXZlIElQIGFkZHJl c3Mgb2YgaXRzIG93biwgdGhlIE1QIHdpbGwgcmVqZWN0IHRoZSByZWZyZXNoIGFzIHRoZSBNUCBy b3V0ZXIgd2lsbCBjb25zaWRlciB0aGUgSVAgYWRkcmVzcyBpbiB0aGUgZmFpbGVkIGludGVyZmFj ZSBhcyBpbnZhbGlkLg0KDQpDYW4gd2UgY29uc2lkZXIgYSBjaGFuZ2UgaW4gdGhlIEVSTyBhcyBh IHRyaWdnZXIgZm9yIEZSUiBvbiB0aGUgZG93bnN0cmVhbSBNUD8NCg0KQWx0ZXJuYXRpdmVseSwg d2UgY291bGQgZXhwbG9yZSB1c2luZyBCRkQgYmV0d2VlbiB0aGUgUExSLU1QIChzdWdnZXN0ZWQg YnkgTGl6aG9uZyBpbiBhbiBvZmZsaW5lIGRpc2N1c3Npb24pLg0KDQpDaGVlcnMsIE1hbmF2DQoN CjIwMTEvNC8yMSA8ZGFpLnh1ZWh1aUB6dGUuY29tLmNuPG1haWx0bzpkYWkueHVlaHVpQHp0ZS5j b20uY24+Pg0KDQpIaSBNYW5hdqOsDQoNCkluIHRoZSBhYnN0cmFjdCBvZiB5b3VyIGRyYWZ0LCB5 b3Ugc2FpZCAiIEFkZGl0aW9uYWxseSwgaXQgYWxzbyBkZXNjcmliZXMgaG93DQoNCmJpLWRpcmVj dGlvbmFsIHN5bW1ldHJpY2FsIEZhc3QgUmVyb3V0ZSB1c2luZyBib3RoIG9uZS10by1vbmUgYW5k DQpmYWNpbGl0eSBiYWNrdXAgY2FuIGJlIGFjaGlldmVkLg0KIg0KDQpJIGhhdmUgdHdvIHF1ZXN0 aW9ucyBuZWVkcyB5b3VyIGNsYXJpZmljYXRpb24sIHRoZXkgYXJlIGJvdGggYWJvdXQgdGhlIGJp ZGlyZWN0aW9uYWwgRlJSOg0KDQpGaXJzdCwgdW5kZXIgdGhlIG5vZGUgcHJvdGVjdGlvbiBjb25k aXRpb24sIGlmIGEgZmFsaXVyZSBvY2N1cnMgb24gdGhlIGxpbmsgYmV0d2VlbiB0aGUgdXBzdHJl YW0gUExSIGFuZCB0aGUgcHJvdGVjdGVkIG5vZGUsIHN1Y2ggYXMgbGluayBCLS1DIGluIGZpZ3Vy ZSAzLCB0aGVuIHRoZSB1cHN0cmVhbSBQTFIgY2FuIGRlcmVjdCB0aGlzIGZhbGl1cmUgYW5kIGRv IHByb3RlY3Rpb24sIGJ1dCBob3cgY2FuIHRoZSBkb3duc3RyZWFtIFBMUiBrbm93IGl0IGFsc28g bmVlZHMgdG8gc3dpdGNoIHRvIHRoZSBkZXRvdXIgbHNwPw0KDQpzZWNvbmQsIGluIGJ5cGFzcyBt ZXRob2QsIGhvdyBjYW4gdGhlIGRvd25zdHJlYW0gTVAob3IgZG93bnN0cmVhbSBQTFIpIGJpbmRz IHRoZSBwcm90ZWN0ZWQgTFNQIHdpdGggdGhlIGJ5cGFzcyB0dW5uZWw/DQoNCg0KYmVzdCByZWdh cmRzLA0KDQp4dWVodWkNCg0KDQoNCg0KDQpNYW5hdiBCaGF0aWEgPG1hbmF2YmhhdGlhQGdtYWls LmNvbTxtYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tPj4NCreivP7IyzogIG1wbHMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPg0KDQoyMDExLTA0LTE2IDAx OjAzDQoNCg0KytW8/sjLDQogICAgICAgIG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+DQqzrcvNDQoNCtb3zOINCiAgICAgICAgW21wbHNdIGRyYWZ0LWJoYXRpYS1tcGxzLXJzdnAt dGUtYmlkaXJlY3Rpb25hbC1sc3ANCg0KDQoNCg0KDQoNCg0KSGksDQoNCkkgaGF2ZSBwb3N0ZWQg YSBuZXcgZHJhZnQ6DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJoYXRpYS1tcGxzLXJz dnAtdGUtYmlkaXJlY3Rpb25hbC1sc3AtMDAudHh0DQoNCkFic3RyYWN0DQoNClRoZXJlIGFyZSBz ZXZlcmFsIGFwcGxpY2F0aW9ucyB0aGF0IHJlcXVpcmUgc3ltbWV0cmljIE11bHRpcHJvdG9jb2wN CkxhYmVsIFN3aXRjaGluZyAoTVBMUykgcGF0aCBiZXR3ZWVuIHR3byBwb2ludHMuICBUaGlzIGNh bm5vdCBiZQ0KYWNoaWV2ZWQgd2l0aCByZWd1bGFyIE1QTFMgYXMgdGhlIExTUHMgYXJlIHVuaWRp cmVjdGlvbmFsLiAgSWYNCnN5bW1ldHJ5IGlzIHJlcXVpcmVkLCBhIHNlcGFyYXRlIExTUCBpbiBl YWNoIGRpcmVjdGlvbiBpcyByZXF1aXJlZCBmb3INCmJpZGlyZWN0aW9uYWwgdHJhZmZpYyBmbG93 LiAgR2VuZXJhbGl6ZWQgTVBMUyBvbiB0aGUgb3RoZXIgaGFuZCwgaGFzDQpwcm92aXNpb25zIGZv ciBzZXR0aW5nIHVwIGEgYmlkaXJlY3Rpb25hbCBMU1AuICBUaGlzIGRvY3VtZW50IHVzZXMgdGhl DQpleHRlbnNpb25zIGludHJvZHVjZWQgZm9yIEdNUExTIGFuZCBhcHBsaWVzIGl0IHRvIHJlZ3Vs YXIgTVBMUyBmb3INCmVzdGFibGlzaGluZyBiaWRpcmVjdGlvbmFsIExTUHMuICBBZGRpdGlvbmFs bHksIGl0IGFsc28gZGVzY3JpYmVzIGhvdw0KYmktZGlyZWN0aW9uYWwgc3ltbWV0cmljYWwgRmFz dCBSZXJvdXRlIHVzaW5nIGJvdGggb25lLXRvLW9uZSBhbmQNCmZhY2lsaXR5IGJhY2t1cCBjYW4g YmUgYWNoaWV2ZWQuDQoNCldvdWxkIGJlIGdyZWF0IGlmIHRoZSBXRyBjYW4gcHJvdmlkZSBzb21l IGZlZWRiYWNrIG9uIHRoaXMuDQoNCkNoZWVycywgTWFuYXYNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRm Lm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KDQoNCg0K --_000_60C093A41B5E45409A19D42CF7786DFD521A20E488EUSAACMS0703e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Manav,
     
    The fact that PATH message of the protected LSP = is=20 received on new interface on the MP indicates that FRR is in use on the for= ward=20 direction and this can be used as a trigger to switch over on the MP for=20 backward direction. However this method or other method with control messag= e=20 notification are most likely not able to achieve 50 ms switch over=20 time.
    How about running BFD on the bypass tunnel with = new=20 notification to trigger the switch over on other end when one end has FRR=20 failure switch over.
     
    Regards,
    Autumn
     

    From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Manav Bhatia
    Sent:= =20 Thursday, April 21, 2011 2:02 AM
    To:=20 dai.xuehui@zte.com.cn
    Cc: mpls@ietf.org
    Subject: Re: [m= pls]=20 draft-bhatia-mpls-rsvp-te-bidirectional-lsp

    Hi Xuehui,

    I should have added text to cover this.

    During the failure, the PLR must keep sending Path messages in or= der=20 for the protected LSP to keep refreshing the PSB of the MP router for = the=20 protected tunnel. This prevents the protected tunnel from a refresh=20 time-out. In the case of a facility bypass tunnel, the PLR sends the=20 Path message for the protected tunnel towards the MP router (NHop=20 or NNHop router) through the bypass tunnel. This path message=20 is encapsulated with the bypass tunnel label (like the traffic that=20 is being protected). In addition to this, the PLR must also modify=20 the first IPv4 sub-object of the ERO. This is because the original=20 ERO on the egress Path message for the protected tunnel will contain=20 the IP address of the failed interface. If the PLR does not replace=20 that IP address with an active IP address of its own, the MP will=20 reject the refresh as the MP router will consider the IP address in=20 the failed interface as invalid.

    Can we consider a change in the ERO as a trigger for FRR on the downst= ream=20 MP? 

    Alternatively, we could explore using BFD between the PLR-MP (suggeste= d by=20 Lizhong in an offline discussion).

    Cheers, Manav

    2011/4/21 <dai.xuehui@zte.com.cn><= BR>

    Hi Manav=A3=AC

    In the abstract of your draft, you said "=20 Additionally, it also describes how

    bi-directional symmetrical Fast Reroute using both=20 one-to-one and
    facility backup can be achieved.
    "

    I have=20 two questions needs your clarification, they are both about the bidirecti= onal=20 FRR:

    First, under the nod= e=20 protection condition, if a faliure occurs on the link between the upstrea= m PLR=20 and the protected node, such as link B--C in figure 3, then the upstream = PLR=20 can derect this faliure and do protection, but how can the downstream PLR= know=20 it also needs to switch to the detour lsp?

    second, in bypass method, how can the downstre= am MP(or=20 downstream PLR) binds the protected LSP with the bypass tunnel?    =20


    best regards,
    xuehui




    Manav Bhatia &l= t;manavbhatia@gmail.com>
    = =B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.org=20

    2011-04-16 01:03

    		<= /TBODY>
    =CA=D5=BC= =FE=C8=CB
    		 mpls@ietf.org
    =B3=AD=CB= =CD
    =D6=F7=CC= =E2
    		 [mpls]=20 draft-bhatia-mpls-rsvp-te-bidirectional-lsp




    Hi,

    I have posted a new draft:
    http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirect= ional-lsp-00.txt

    Abstract

    There=20 are several applications that require symmetric Multiprotocol
    Label=20 Switching (MPLS) path between two points.  This cannot be
    achieve= d=20 with regular MPLS as the LSPs are unidirectional.  If
    symmetry is= =20 required, a separate LSP in each direction is required for
    bidirection= al=20 traffic flow.  Generalized MPLS on the other hand, has
    provisions= for=20 setting up a bidirectional LSP.  This document uses the
    extension= s=20 introduced for GMPLS and applies it to regular MPLS for
    establishing=20 bidirectional LSPs.  Additionally, it also describes=20 how
    bi-directional symmetrical Fast Reroute using both one-to-one=20 and
    facility backup can be achieved.

    Would be great if the WG c= an=20 provide some feedback on this.

    Cheers, Manav
    _______________________________________________
    mpls m= ailing=20 list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls



    --_000_60C093A41B5E45409A19D42CF7786DFD521A20E488EUSAACMS0703e_-- From gregimirsky@gmail.com Thu Apr 21 11:10:35 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D743BE0701 for ; Thu, 21 Apr 2011 11:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly4mUuLngBki for ; Thu, 21 Apr 2011 11:10:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 99685E06F6 for ; Thu, 21 Apr 2011 11:10:34 -0700 (PDT) Received: by vws12 with SMTP id 12so1838128vws.31 for ; Thu, 21 Apr 2011 11:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4vF0qR/dNDEm1+EC6P+Vqbw+fvEEShIv0PIdmAGxE/k=; b=obE6zYbZGoX2AjEZCQP3+FrxexJQqQs86uvk2Scn+w0e+4X/0AI/wXOpOU2o8Kd8+7 ipYOo/fvw7ygv7Ho+8TQoei5mVua1lLwC7S+bF3f89jYZC++wcFh9KeSmzmfvzUB5nF8 jIluRoHs3l8EBvEY8Y5FKo+xk0Fr/Mg0S3da0= 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=XnajGkS3D2QG5ckSNg3dTv+7iBFZJvemEskeqCJbYWPFFUjjlrAyW/OR9pTPEqy5oQ RaThwxVCVctqHipogq6UvPuSrbacyUejLLb5I0gRxy3Plc+fqdXVV9khi0HcYx3bavzx 6PBl1HPbGlV/u/+uOhDOxu52sH+Z9XFqbRpxc= MIME-Version: 1.0 Received: by 10.52.100.5 with SMTP id eu5mr121978vdb.268.1303408822989; Thu, 21 Apr 2011 11:00:22 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Thu, 21 Apr 2011 11:00:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Apr 2011 11:00:22 -0700 Message-ID: From: Greg Mirsky To: Manav Bhatia Content-Type: multipart/alternative; boundary=20cf3071cf9ae4350604a1718372 Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:10:36 -0000 --20cf3071cf9ae4350604a1718372 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Manav, I'd point that using control plane as trigger for protection switchover wil= l make bi-directional FRR un-applicable to MPLS-TP networks, at least to thos= e TP networks that will not be using control plane. I think that trigger must be in the data plane if we want to make this mechanism applicable to MPLS, not limited to non-TP networks. Perhaps G-ACh based PSC solution is more suitable. Regards, Greg 2011/4/21 Manav Bhatia > Hi Xuehui, > > I should have added text to cover this. > > During the failure, the PLR must keep sending Path messages in order for > the protected LSP to keep refreshing the PSB of the MP router for the > protected tunnel. This prevents the protected tunnel from a refresh > time-out. In the case of a facility bypass tunnel, the PLR sends the > Path message for the protected tunnel towards the MP router (NHop or NNHo= p > router) through the bypass tunnel. This path message is encapsulated with > the bypass tunnel label (like the traffic that is being protected). In > addition to this, the PLR must also modify the first IPv4 sub-object of t= he > ERO. This is because the original ERO on the egress Path message for the > protected tunnel will contain the IP address of the failed interface. If = the > PLR does not replace that IP address with an active IP address of its own= , > the MP will reject the refresh as the MP router will consider the IP addr= ess > in the failed interface as invalid. > > Can we consider a change in the ERO as a trigger for FRR on the downstrea= m > MP? > > Alternatively, we could explore using BFD between the PLR-MP (suggested b= y > Lizhong in an offline discussion). > > Cheers, Manav > > 2011/4/21 > > >> Hi Manav=A3=AC >> >> In the abstract of your draft, you said " Additionally, it also describe= s >> how >> >> bi-directional symmetrical Fast Reroute using both one-to-one and >> facility backup can be achieved. >> " >> >> I have two questions needs your clarification, they are both about the >> bidirectional FRR: >> >> First, under the node protection condition, if a faliure occurs on the >> link between the upstream PLR and the protected node, such as link B--C = in >> figure 3, then the upstream PLR can derect this faliure and do protectio= n, >> but how can the downstream PLR know it also needs to switch to the detou= r >> lsp? >> >> second, in bypass method, how can the downstream MP(or downstream PLR) >> binds the protected LSP with the bypass tunnel? >> >> >> best regards, >> >> xuehui >> >> >> >> >> *Manav Bhatia * >> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org >> >> 2011-04-16 01:03 >> =CA=D5=BC=FE=C8=CB >> mpls@ietf.org >> =B3=AD=CB=CD >> =D6=F7=CC=E2 >> [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp >> >> >> >> >> Hi, >> >> I have posted a new draft: >> http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00.tx= t >> >> Abstract >> >> There are several applications that require symmetric Multiprotocol >> Label Switching (MPLS) path between two points. This cannot be >> achieved with regular MPLS as the LSPs are unidirectional. If >> symmetry is required, a separate LSP in each direction is required for >> bidirectional traffic flow. Generalized MPLS on the other hand, has >> provisions for setting up a bidirectional LSP. This document uses the >> extensions introduced for GMPLS and applies it to regular MPLS for >> establishing bidirectional LSPs. Additionally, it also describes how >> bi-directional symmetrical Fast Reroute using both one-to-one and >> facility backup can be achieved. >> >> Would be great if the WG can provide some feedback on this. >> >> Cheers, Manav >> _______________________________________________ >> 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 > > --20cf3071cf9ae4350604a1718372 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Manav,
    I'd point that using control plane as trigger for protec= tion switchover will make bi-directional FRR un-applicable to MPLS-TP netwo= rks, at least to those TP networks that will not be using control plane. I = think that trigger must be in the data plane if we want to make this mechan= ism applicable to MPLS, not limited to non-TP networks. Perhaps G-ACh based= PSC solution is more suitable.

    Regards,
    Greg

    2011/4/21 Manav Bhat= ia <manavbhat= ia@gmail.com>
    Hi Xuehui,

    I should have added text to cover = this.

    During the failure, the PLR must keep s= ending Path messages in order for the protected LSP to keep refreshing= the PSB of the MP router for the protected tunnel. This prevents the = protected tunnel from a refresh time-out. In the case of a facility by= pass tunnel, the PLR sends the Path message for the protected tunnel t= owards the MP router (NHop or NNHop router) through the bypass tunnel.= This path message is encapsulated with the bypass tunnel label (like = the traffic that is being protected). In addition to this, the PLR mus= t also modify the first IPv4 sub-object of the ERO. This is because th= e original ERO on the egress Path message for the protected tunnel wil= l contain the IP address of the failed interface. If the PLR does not = replace that IP address with an active IP address of its own, the MP w= ill reject the refresh as the MP router will consider the IP address i= n the failed interface as invalid.

    Can we consider a change in the ERO as a trigger for FR= R on the downstream MP? 

    Alternatively, we co= uld explore using BFD between the PLR-MP (suggested by Lizhong in an offlin= e discussion).

    Cheers, Manav

    2011/= 4/21 <dai.xuehui@zte.com.cn>


    Hi Manav=A3=AC

    In the abstract of your draft, you= said " Additionally, it also describes how
    =
    bi-directional symmetrical Fast Reroute using both one-to-one and
    facility backup can be achieved.
    "

    I have two questions needs your cl= arification, they are both about the bidirectional FRR:

    First, under the node protection c= ondition, if a faliure occurs on the link between the upstream PLR and the protected node, such as link B--C in figure 3, then the upstream PLR can derect this faliure and do protection, but how can the downstream PLR know it also needs to switch to the detour lsp?

    second, in bypass method, how can = the downstream MP(or downstream PLR) binds the protected LSP with the bypass tunnel?


    best regards,

    xuehui




    Manav Bhatia= <manavbhatia= @gmail.com>
    =B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.= org

    2011-04-16 01:03

    =CA=D5=BC=FE=C8= =CB
    		mpls@ietf.org
    =B3=AD=CB=CD
    =D6=F7=CC=E2
    		[mpls] draft-bhatia-mpls-rsvp= -te-bidirectional-lsp





    Hi,

    I have posted a new draft:
    http://www.ietf.org/id/draft-bhatia-mpls-rsvp-= te-bidirectional-lsp-00.txt

    Abstract

    There are several applications that require symmetric Multiprotocol
    Label Switching (MPLS) path between two points.  This cannot be
    achieved with regular MPLS as the LSPs are unidirectional.  If
    symmetry is required, a separate LSP in each direction is required for
    bidirectional traffic flow.  Generalized MPLS on the other hand, has provisions for setting up a bidirectional LSP.  This document uses the
    extensions introduced for GMPLS and applies it to regular MPLS for
    establishing bidirectional LSPs.  Additionally, it also describes how
    bi-directional symmetrical Fast Reroute using both one-to-one and
    facility backup can be achieved.

    Would be great if the WG can provide some feedback on this.

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


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


    --20cf3071cf9ae4350604a1718372-- From Robert.Rennison@ecitele.com Thu Apr 21 13:53:43 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9BCDFE06B9 for ; Thu, 21 Apr 2011 13:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbjhqql96kNz for ; Thu, 21 Apr 2011 13:53:42 -0700 (PDT) Received: from uspitbmg01.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfc.amsl.com (Postfix) with ESMTP id DE7E1E0722 for ; Thu, 21 Apr 2011 13:53:29 -0700 (PDT) X-AuditID: 3f5e7f87-b7b53ae000006a38-71-4db0c03de967 Received: from uspitexch02.ecitele.com ( [10.0.0.72]) by uspitbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 6B.60.27192.D30C0BD4; Thu, 21 Apr 2011 19:39:42 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by uspitexch02.ecitele.com ([10.0.0.72]) with mapi; Thu, 21 Apr 2011 16:53:28 -0400 From: Robert Rennison To: David Allan I , "mpls@ietf.org" Date: Thu, 21 Apr 2011 16:53:27 -0400 Thread-Topic: Poll / Final in draft-cc-cv-rdi Thread-Index: Acv+tvS4BEK+rt17R96WWlGBJIq3WgAuHfsAADkvD+A= Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE5466F24A667B@USPITMAIL01.ecitele.com> References: <60C093A41B5E45409A19D42CF7786DFD521A20DDDF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD521A20DDDF@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 X-Brightmail-Tracker: H4sIAAAAAAAAA2WTbUhTURjHd3bv5nW5vM6305C83LIP1mzLgmnO+lBg0VJLyEqy63bcLm13 Y3eGfojMoEQEJ4rYvqQ1Jd/QXlBLwVrRi2RaFNoaQTWC7A0MkYqsu90yo/Ppf87z+/+fw+E5 BKbqk6sJlnMjF8fYaLkCV0gkeZrcmwNGbYdXrn81OYTpAx1dMv2PS0/x7Vjet/ln8jyf76s0 b7rmWVQBdqga5DAc53AzbkSZEW8y0AUu9jhjqqIp1mygdTTltDEmZEec20AzTifizHSugvpv 5QgYy1GIMznMLGcx0Lv252v0+i1ZGh2du26NLnOrosjK8hTS2BnWRtkRzzMWRAknR69h1p4v c5gzlFPZ7nktrQbN2joQTUByM3xzeh4XdRKcetkvrwMKQkUOATgSmgDiph7AwKn6qDAlJzPh wNyELKwTyEI4/DIQcWNkGpy+d1oe1rigO+uvRvh4cgP0Pb8jrQOEwGvgzDtKtGbDWwvNEURJ FsAnj9siVhV5AN54MRWJjyaL4ZnRkYgGwuUWxnulYqtkGAidl4qXJqFvdBITdSJ892bxN58I g2f7gchvgG0jc3JRr4ed7e8xsW8cfHAuhHtAkndZrHeZxbvM4l1maQN4N0iq4J2su8xu0eoy kIl1IxvKMDnsV4AwItuOnDw7DBqa0/1gFSGlE5X5LQNG1coyh7nKyvDWUleFDfF+oBfeqhFT rzA5hPHi3KWZWu0/GzpZeb3WZ1SRFmF2jiHkRK4/1hSCoKEy2CrExrmQBVWWszb337KUiPYD SMTQCcp9YUbJOxk7z1rE+jhII77cbh0DKpxzcEidrBwMQ2QYslZwSzmzIJkAdLzyUbgaI/yB pYRZIVwqhHc87Q+HC7O9VFJXgxPkT337jpK9F2SNc29r2mc3dcxYXH14CfmVR70Hm956JB9X B2vLazb7PQYS44PZJty4x1s6WdYt2SiZ6rrb8v7i2pwe4wfZvO3zd1dqYdHhpsWe3UE0mH/f Ujz68EjIFlsWOz12uYH2pe6sTUkqNk94/M3lVXs+BTaNJn7LonHeyujSMRfP/AKrEKuCwAMA AA== Cc: Ross Callon Subject: Re: [mpls] Poll / Final in draft-cc-cv-rdi X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:53:43 -0000 Dave, John and George, Many thanks for listening to the comments regarding deviation from the base= spec and potential problems in doing so. I strongly support the approach of mandating support for the BFD baseline s= pecification along with the Poll/final mechanism. I've made the point in the BFD WG when this was first presented and on the l= ist regarding potential problems in deviating from the base spec. The more= I discuss and think through these the more I come to the conclusion that we= should leave the state machines alone and not make changes for perceived op= timizations of "issues". If the baseline spec was implementable in the past= it still is even if encapsulated in a different wrapper. In short whilst you could potentially get a BFD session to work without sup= porting P/F you may end up dumbing the speed down to the startup value which= many vendors begin with and thus the network operators will not be able to= get eh equipment they have paid for to operate at the rates they are capabl= e of merely because one vendors "letter of the law" implementation does not= support P/F. Some comments and expansion inline preceded by [[ [Rob Rennison] .... ]] Cheers Rob -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Davi= d Allan I Sent: Wednesday, April 20, 2011 11:30 AM To: mpls@ietf.org Cc: Ross Callon Subject: [mpls] FW: Poll / Final in draft-cc-cv-rdi Hi Folks: We've received a number of comments both formally and informally that the cu= rrent draft has deviated too far from the base BFD spec and thus loses backw= ard compatibility with existing code bases. Further, discussions with the B= FD WG have indicated we have a potential race condition in the current start= up procedures described in draft-cc-cv-rdi. The issue is the transition to UP state requires confirmation by the peer ME= P prior to changing the detection time to the rx-interval x detect mult in o= rder to avoid potential flapping. This can result in an implementation effec= tively needing two UP states (UP forward, UP reverse direction). Otherwise the MEP may time out the reverse direction before seeing an UP sta= te from the peer MEP. So we can make this implicit in the specification and require BFD changes or= we can use poll/final discipline on startup as defined in the base specific= ation and make the transition to fully UP and the desired rate both explicit= and exposed in the protocol exchange. This would reduce the deltas between= the base spec (RFC 5880) and draft CC-CV-RDI. [[ [Rob Rennison] Without a valid concrete reason to change the base spec we s= hould leave it alone, and I've yet to see any concrete rationale explained,= allusion to "issues" with having to keep a Tx and Rx state and possible op= timizations are not being concrete enough IMHO to have a productive discuss= ion about and to change what's already working. I will try to read between t= he lines and see where this takes us. The baseline specification has nume= rous interoperable implementations and should not be changed lightly. Also r= e your question of should we make things explicit or implicit in the spec; p= lease do not make things implicit in the specs, any variations are subtle e= nough without key points being implicit, so whatever is specified should be= explicit.] ]] > We would also observe that it is permissable in the specification to respo= nd to a poll with a final reply > with the session parameters unchanged. [[ [Rob Rennison] Agreed, if you do not wish to change what you are accepting f= rom the peer, then do not change the value of "_Required_ Min Rx interval" y= ou put in the BFD control packets you send to your peer, i.e. you can effec= tively ignore what he says he wants to send to you via the values he puts in= "_Desired_ Min TX Interval" he sends to you. _But_ You do need to interpret and act on the values your peer MEP is telling you= via the "Required Min Rx Interval" so you both have to go as slow as your p= eer wants you to go. So whatever optimizations of the "UP processing loop" y= ou wish to do, and I assume you mean you wish to do it all without reverting= to having the control plane i.e. slow path take part, these optimizations w= ill need to interpret the value in the "Required Min Rx interval" as sent by= the peer. You will also need to make sure you send the correct values in the State fie= ld to transmission from Down to Init to Up or perhaps your optimization will= constantly send Init state. One additional observation is that if you were to try to interoperate with a= peer MEP which was capable of running a session at a value X mS but started= off at Y mS where Y >> X then you would end up running at the slow rate of= YmS whereas if you were true to the BFD baseline spec you would have been a= ble to get the peer to play at the rate you desired. This is why many implementations start of slowly at say a few packets per se= cond or so rate and then once they have established a session they tell the= peer what the rate is they would like to send at, they do this using the= poll bit when they modify the value they are sending in the "Desired Tx in= terval" field, but do not modify the rate yet. The peer can then take his sw= eet time setting up the hardware to be prepared to receive some potentially= fast BFD control packets with a specific value of "My discriminator". When= the peer has got his hardware ready to receive, the peer responds with the= final bit set and you can then "blast way at the fast rate". This is all yo= u as a given MEP care about, "can I get this session speeded up so I can bla= st at him at the rate I would like to". Conversely the other end is responsi= ble for suggesting a new fast value to you and gives you the courtesy of the= P/F mechanism to allow you to get ready, whereupon you set the F bit when y= ou are ready. In this manner a pair of peers, for a specific session can in= an orderly manner progress from a software/ control plane mechanism to one= where a _simple_ hardware/fastpath/acceleration logic does the detection. The upshot of the existing mechanism is a fairly simple hardware implementat= ion involving some timers and pattern matching on discriminators, whereas th= e optimizations you allude to do not necessarily simply things for the hardw= are or the remote peer and would limit the interoperability. If your optimiz= ation looks to external devices like any other BFD peer then go ahead, but m= ake sure you obey the spirit of the law and not the letter, i.e. do not fail= to work with other vendors at a fast rate, which they are capable of, beca= use you do not support F/P. ]] >So once a session is up a compliant implementation does not actually have t= o implement on the fly changes to session paramters. The processing of the p= oll bit can simply be reduced to setting the final bit in the next message. This would permit implementations to optimize the UP processing loop. [[ [Rob Rennison] Agreed it does not have to allow for on the fly changes to se= ssion parameters i.e. requests it gets from the peer about the rate the pee= r wishes to send to it i.e. the values the peer puts into the "Desired Min T= x Interval" but it does need to interpret the values it receives from the p= eer in the "Required Min Rx Interval". ]] This is a change of direction from what has been in the draft to date, hence= we'd look to the WG for comment on this change... the editors Dave, John and George... This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From manavbhatia@gmail.com Thu Apr 21 17:41:06 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7AE68E074C for ; Thu, 21 Apr 2011 17:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO0sv7x7fHro for ; Thu, 21 Apr 2011 17:41:05 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id E9553E065C for ; Thu, 21 Apr 2011 17:41:04 -0700 (PDT) Received: by wwa36 with SMTP id 36so164269wwa.13 for ; Thu, 21 Apr 2011 17:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eW7njOTO/EJRsIuWi0r68liT7/il33CbTJOGWw4iBuk=; b=UBFNTg97j0ad/tkBY3akUAfd4CBq1YAqMEAK2bF4e3JpetRxSY2yE+e2ajUkHeaC36 VKwfno1sqbxSfX5tHo05+bwBpZOMhv2OFMQq0d0c9KduxBkwF3zAxPhcPDSRakCTA55I FDVgJMKAaBbMTuT+Zvtdh4fa6snPkSUZyl7kA= 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=DFmyLRZXFhQ5CFtOCuY2xlJ3V2XqJumYflDouprJ1cqAs1wMiYicklVQwjZ6qEif9a aqmYkVMTe4rgY3bF4THhkry5A9Hj3X4CMS+fw3sTrskBI+bRYBQ9CpkTJ9sqn77O3lwK LyoHQ6Dk7TpFjsX1l92aens+WBelNOaUFbGRk= MIME-Version: 1.0 Received: by 10.227.55.73 with SMTP id t9mr505208wbg.213.1303432864149; Thu, 21 Apr 2011 17:41:04 -0700 (PDT) Received: by 10.227.142.140 with HTTP; Thu, 21 Apr 2011 17:41:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Apr 2011 06:11:04 +0530 Message-ID: From: Manav Bhatia To: Greg Mirsky Content-Type: multipart/alternative; boundary=20cf30025e90db322c04a1771c6e Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 00:41:06 -0000 --20cf30025e90db322c04a1771c6e Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Greg and Autumn, I agree that a control plane mechanism to trigger FRR at the downstream PLR will not be sufficient to guarantee 50ms failover. Let me work on that and i'll update the draft to use a data plane mechanism like FRR to do this. Cheers, Manav 2011/4/21 Greg Mirsky > Dear Manav, > I'd point that using control plane as trigger for protection switchover > will make bi-directional FRR un-applicable to MPLS-TP networks, at least = to > those TP networks that will not be using control plane. I think that trig= ger > must be in the data plane if we want to make this mechanism applicable to > MPLS, not limited to non-TP networks. Perhaps G-ACh based PSC solution is > more suitable. > > Regards, > Greg > > > 2011/4/21 Manav Bhatia > >> Hi Xuehui, >> >> I should have added text to cover this. >> >> During the failure, the PLR must keep sending Path messages in order for >> the protected LSP to keep refreshing the PSB of the MP router for the >> protected tunnel. This prevents the protected tunnel from a refresh >> time-out. In the case of a facility bypass tunnel, the PLR sends the >> Path message for the protected tunnel towards the MP router (NHop or NNH= op >> router) through the bypass tunnel. This path message is encapsulated wit= h >> the bypass tunnel label (like the traffic that is being protected). In >> addition to this, the PLR must also modify the first IPv4 sub-object of = the >> ERO. This is because the original ERO on the egress Path message for the >> protected tunnel will contain the IP address of the failed interface. If= the >> PLR does not replace that IP address with an active IP address of its ow= n, >> the MP will reject the refresh as the MP router will consider the IP add= ress >> in the failed interface as invalid. >> >> Can we consider a change in the ERO as a trigger for FRR on the downstre= am >> MP? >> >> Alternatively, we could explore using BFD between the PLR-MP (suggested = by >> Lizhong in an offline discussion). >> >> Cheers, Manav >> >> 2011/4/21 >> >> >>> Hi Manav=A3=AC >>> >>> In the abstract of your draft, you said " Additionally, it also >>> describes how >>> >>> bi-directional symmetrical Fast Reroute using both one-to-one and >>> facility backup can be achieved. >>> " >>> >>> I have two questions needs your clarification, they are both about the >>> bidirectional FRR: >>> >>> First, under the node protection condition, if a faliure occurs on the >>> link between the upstream PLR and the protected node, such as link B--C= in >>> figure 3, then the upstream PLR can derect this faliure and do protecti= on, >>> but how can the downstream PLR know it also needs to switch to the deto= ur >>> lsp? >>> >>> second, in bypass method, how can the downstream MP(or downstream PLR) >>> binds the protected LSP with the bypass tunnel? >>> >>> >>> best regards, >>> >>> xuehui >>> >>> >>> >>> >>> *Manav Bhatia * >>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org >>> >>> 2011-04-16 01:03 >>> =CA=D5=BC=FE=C8=CB >>> mpls@ietf.org >>> =B3=AD=CB=CD >>> =D6=F7=CC=E2 >>> [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp >>> >>> >>> >>> >>> Hi, >>> >>> I have posted a new draft: >>> http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00.t= xt >>> >>> Abstract >>> >>> There are several applications that require symmetric Multiprotocol >>> Label Switching (MPLS) path between two points. This cannot be >>> achieved with regular MPLS as the LSPs are unidirectional. If >>> symmetry is required, a separate LSP in each direction is required for >>> bidirectional traffic flow. Generalized MPLS on the other hand, has >>> provisions for setting up a bidirectional LSP. This document uses the >>> extensions introduced for GMPLS and applies it to regular MPLS for >>> establishing bidirectional LSPs. Additionally, it also describes how >>> bi-directional symmetrical Fast Reroute using both one-to-one and >>> facility backup can be achieved. >>> >>> Would be great if the WG can provide some feedback on this. >>> >>> Cheers, Manav >>> _______________________________________________ >>> 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 >> >> > --20cf30025e90db322c04a1771c6e Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Greg and Autumn,

    I agree that a control plane mechani= sm to trigger FRR at the downstream PLR will not be sufficient to guarantee= 50ms failover. Let me work on that and i'll update the draft to use a = data plane mechanism like FRR to do this.

    Cheers, Manav

    2011/4/= 21 Greg Mirsky <gregimirsky@gmail.com>
    Dear Manav,
    I'd point that using control plane as trigger for protec= tion switchover will make bi-directional FRR un-applicable to MPLS-TP netwo= rks, at least to those TP networks that will not be using control plane. I = think that trigger must be in the data plane if we want to make this mechan= ism applicable to MPLS, not limited to non-TP networks. Perhaps G-ACh based= PSC solution is more suitable.

    Regards,
    Greg


    2011/4/21 Manav Bhatia <m= anavbhatia@gmail.com>
    Hi Xuehui,

    I should have added text to cover = this.

    During the failure, the PLR must keep s= ending Path messages in order for the protected LSP to keep refreshing= the PSB of the MP router for the protected tunnel. This prevents the = protected tunnel from a refresh time-out. In the case of a facility by= pass tunnel, the PLR sends the Path message for the protected tunnel t= owards the MP router (NHop or NNHop router) through the bypass tunnel.= This path message is encapsulated with the bypass tunnel label (like = the traffic that is being protected). In addition to this, the PLR mus= t also modify the first IPv4 sub-object of the ERO. This is because th= e original ERO on the egress Path message for the protected tunnel wil= l contain the IP address of the failed interface. If the PLR does not = replace that IP address with an active IP address of its own, the MP w= ill reject the refresh as the MP router will consider the IP address i= n the failed interface as invalid.

    Can we consider a change in the ERO as a trigger for FR= R on the downstream MP? 

    Alternatively, we co= uld explore using BFD between the PLR-MP (suggested by Lizhong in an offlin= e discussion).

    Cheers, Manav

    2011/= 4/21 <dai.xuehui@zte.com.cn>


    Hi Manav=A3=AC

    In the abstract of your draft, you= said " Additionally, it also describes how
    =
    bi-directional symmetrical Fast Reroute using both one-to-one and
    facility backup can be achieved.
    "

    I have two questions needs your cl= arification, they are both about the bidirectional FRR:

    First, under the node protection c= ondition, if a faliure occurs on the link between the upstream PLR and the protected node, such as link B--C in figure 3, then the upstream PLR can derect this faliure and do protection, but how can the downstream PLR know it also needs to switch to the detour lsp?

    second, in bypass method, how can = the downstream MP(or downstream PLR) binds the protected LSP with the bypass tunnel?


    best regards,

    xuehui




    Manav Bhatia= <manavbhatia= @gmail.com>
    =B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.= org

    2011-04-16 01:03

    =CA=D5=BC=FE=C8= =CB
    		mpls@ietf.org
    =B3=AD=CB=CD
    =D6=F7=CC=E2
    		[mpls] draft-bhatia-mpls-rsvp= -te-bidirectional-lsp





    Hi,

    I have posted a new draft:
    http://www.ietf.org/id/draft-bhatia-mpls-rsvp-= te-bidirectional-lsp-00.txt

    Abstract

    There are several applications that require symmetric Multiprotocol
    Label Switching (MPLS) path between two points.  This cannot be
    achieved with regular MPLS as the LSPs are unidirectional.  If
    symmetry is required, a separate LSP in each direction is required for
    bidirectional traffic flow.  Generalized MPLS on the other hand, has provisions for setting up a bidirectional LSP.  This document uses the
    extensions introduced for GMPLS and applies it to regular MPLS for
    establishing bidirectional LSPs.  Additionally, it also describes how
    bi-directional symmetrical Fast Reroute using both one-to-one and
    facility backup can be achieved.

    Would be great if the WG can provide some feedback on this.

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


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



    --20cf30025e90db322c04a1771c6e-- From manavbhatia@gmail.com Thu Apr 21 18:34:19 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38D81E074D for ; Thu, 21 Apr 2011 18:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06-OdrhoPwxc for ; Thu, 21 Apr 2011 18:34:18 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfc.amsl.com (Postfix) with ESMTP id DEC06E0718 for ; Thu, 21 Apr 2011 18:34:17 -0700 (PDT) Received: by wwk4 with SMTP id 4so292551wwk.1 for ; Thu, 21 Apr 2011 18:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LnVZdcmh3P3+n2/Lh1w7sdNJwyn/plnVQ6FNod/xWUE=; b=hKU1oWwqMNjxTbGOfVizc2Ipj0NFYXVv8zHh+eXbd9qgmMnWLO7TL+2NxFthNpm2nX Qjf/ISZwJMxnqUgTx/bclzUtG27U67FuVz7Gvg50qssQw3G8W2wMCBMsu16e8dlkaMZO hCe4ZgEWtSOU1JZGbd/gIJ3FO4t1FvAn1weHU= 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=TnN4TM4wDGkM4CIRnqcxK2aAuJW1vAk2Z8bVekUK/vjMRrw4vDW44Pnx2rkih/ZoVu MoPPva3mcn8wd9FVoXt7B+WmCkqs8Mcfr0MJDu4wJK6ThtSCeXKZbGvmnJwNqC1nn0Me QBQ+Pq/UXJjX9Z07Fj8LrZzjTnIGMei0cSymk= MIME-Version: 1.0 Received: by 10.227.177.69 with SMTP id bh5mr552977wbb.155.1303436057199; Thu, 21 Apr 2011 18:34:17 -0700 (PDT) Received: by 10.227.142.140 with HTTP; Thu, 21 Apr 2011 18:34:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Apr 2011 07:04:17 +0530 Message-ID: From: Manav Bhatia To: dai.xuehui@zte.com.cn Content-Type: multipart/alternative; boundary=00248c0ee66a2d460104a177db98 Cc: mpls@ietf.org Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:34:19 -0000 --00248c0ee66a2d460104a177db98 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Xuehui, > > : From my understanding, the ERO may is not suitable to be used a= s > a trigger for FRR, since when a node receives a path message containing a= n > ERO, it will check if this node is part of the abstract node described b= y > the first subobject, and finally will replace the first subobject with an= y > subobject that denotes an abstract node containing the next hop, for this > point, please see section 4.3.4.1 of RFC3209. so, the MP node will not kn= ow > the IP address changes of the PLR. Further, it can't acheive fast > switching, such as 50ms. > In case of a facility bypass tunnel, the PLR sends the PATH message for the protected LSP towards the MP through the bypass tunnel by encapsulating the PATH message with the bypass tunnel label (like the data traffic). In the PATH message the PLR must modify the first IPv4 subobject of the ERO since the original ERO will be containing the IP address of the interface that ha= s gone down. If the PLR doesnt change this address with an active interface o= f its own the MP will reject the refresh as it will find the interface addres= s to be invalid. The PLR, must thus modify the ERO before sending out the PAT= H message. I was initially thinking of using this change as the trigger for the MP to switch to the FRR path, but i agree that this will take more than 50ms, and something in the data plane should be used. I will work on this i= n the next revision. > Alternatively, we could explore using BFD between the PLR-MP (suggested b= y > Lizhong in an offline discussion). > where is the BFD running on=A3=BF the protected lsp or the bypas= s > tunnel? can you clarify it to me? thanks! > Between the MP and the PLR - needs some more thought. > > Besides, you haven't answer my second question, that is how can the MP > knows which is the bypass tunnel it should switch to? since, the bypass > tunnel is created by the upstream PLR, how can the MP bind with the same > bypass tunnel? > Since the bypass tunnel is itself a bi-directional tunnel the MP will know that it can use this tunnel to send the traffic back to the upstream PLR. Cheers, Manav --00248c0ee66a2d460104a177db98 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Xuehui,
    <= div class=3D"im">
    <xuehui>: From my understanding, the ERO may is not suitable to be used as a trigger for FRR, since when a node receives a path message containing an ERO, it will check  if this node is part of the abstract node described by the first subobject, and finally will replace the fir= st subobject with any subobject that denotes an abstract node containing the next hop, for this point, please see section 4.3.4.1 of RFC3209. so, the MP node will not know the IP address changes  of the PLR.  Further, it can't acheive fast switching, such as 50ms.

    In case of a facility bypass tunnel, t= he PLR sends the PATH message for the protected LSP towards the MP through = the bypass tunnel by encapsulating the PATH message with the bypass tunnel = label (like the data traffic). In the PATH message the PLR must modify the = first IPv4 subobject of the ERO since the original ERO will be containing t= he IP address of the interface that has gone down. If the PLR doesnt change= this address with an active interface of its own the MP will reject the re= fresh as it will find the interface address to be invalid. The PLR, must th= us modify the ERO before sending out the PATH message. I was initially thin= king of using this change as the trigger for the MP to switch to the FRR pa= th, but i agree that this will take more than 50ms, and something in the da= ta plane should be used. I will work on this in the next revision.


    Alternatively, we could explore us= ing BFD between the PLR-MP (suggested by Lizhong in an offline discussion).
    <xuehui>= ; where is the BFD running on=A3=BF the protected lsp or the bypass tunnel? can you clarif= y it to me? thanks!

    Between the MP and the PLR - needs som= e more thought.
     

    Besides, you haven&= #39;t answer my second question, that is how can the MP knows which is the bypass tunnel it should switch to? since, the bypass tunnel is created by the upstream PLR, how can the MP bind with the same bypass tunnel?

    Since the bypass tunnel is itself a bi= -directional tunnel the MP will know that it can use this tunnel to send th= e traffic back to the upstream PLR.

    Cheers, Manav<= /div>
    --00248c0ee66a2d460104a177db98-- From Internet-Drafts@ietf.org Fri Apr 22 02:45:02 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6FA5FE0829; Fri, 22 Apr 2011 02:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKHfhH8OmRtS; Fri, 22 Apr 2011 02:45:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFA25E0824; Fri, 22 Apr 2011 02:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110422094501.22703.43005.idtracker@ietfc.amsl.com> Date: Fri, 22 Apr 2011 02:45:01 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-p2mp-13.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 09: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 : 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-13.txt Pages : 39 Date : 2011-04-22 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 Multipoint LDP (mLDP). 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 LSPs 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-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-22024042.I-D@ietf.org> --NextPart-- From loa@pi.nu Fri Apr 22 05:11:32 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0ECC1E068A for ; Fri, 22 Apr 2011 05:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtN0+EWtMpAE for ; Fri, 22 Apr 2011 05:11:29 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfc.amsl.com (Postfix) with ESMTP id 954D0E0694 for ; Fri, 22 Apr 2011 05:11:29 -0700 (PDT) Received: from [120.28.9.177] (unknown [120.28.9.177]) (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 D395F2A8001; Fri, 22 Apr 2011 14:11:25 +0200 (CEST) Message-ID: <4DB1706B.3050602@pi.nu> Date: Fri, 22 Apr 2011 20:11:23 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:11:32 -0000 Working Group, this is to start a two week poll on making draft-asati-pignataro-mpls-ldp-iana-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 8th. /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 eosborne@cisco.com Fri Apr 22 06:18:19 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 769F3E05F5 for ; Fri, 22 Apr 2011 06:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5YBeetyEzgh for ; Fri, 22 Apr 2011 06:18:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 909E4E067C for ; Fri, 22 Apr 2011 06:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1490; q=dns/txt; s=iport; t=1303478297; x=1304687897; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DShHCldB2VcUT4GxQvlJGRdU8vd/eP/J7DNYtxV70qI=; b=ddTEgfywKp6ur340MCutjSG35aRmAbCoL1rsJDpwgRBEn6h17vFE3feC ZKo7UB6yFNVEo/owJUV6GtJV9q2Q5qUsUjhw1/1skXOhHQDOrWSkmzcYP s4HrZ9aw7pfJkq/okhRaLTWmL6UZ/O3edultkEfh/l9oT6dPvXL3hk0DO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIBAOF/sU2tJXG//2dsb2JhbACXU44Ld6ZjnF4ChXQEhXSMRw X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208";a="434836372" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2011 13:17:57 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3MDHvnN013769; Fri, 22 Apr 2011 13:17:57 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 08:17:56 -0500 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: Fri, 22 Apr 2011 08:17:56 -0500 Message-ID: In-Reply-To: <4DB1706B.3050602@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AcwA5nbFQpd6srWkS2SIlLqEz/HACwACTYzw References: <4DB1706B.3050602@pi.nu> From: "Eric Osborne (eosborne)" To: "Loa Andersson" , X-OriginalArrivalTime: 22 Apr 2011 13:17:56.0915 (UTC) FILETIME=[B1EC7830:01CC00EF] Cc: Ross Callon Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 13:18:19 -0000 yes/support eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Friday, April 22, 2011 8:11 AM > To: mpls@ietf.org > Cc: Ross Callon > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-asati-pignataro-mpls-ldp-iana-01 >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document please > respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group document > please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are not supporting > the document. >=20 > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing > list, but with another subject than what is on this mail. >=20 > The poll ends May 8th. >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tnadeau@lucidvision.com Fri Apr 22 06:26:57 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C65D2E0745 for ; Fri, 22 Apr 2011 06:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rZv1oOkyF6J for ; Fri, 22 Apr 2011 06:26:57 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfc.amsl.com (Postfix) with ESMTP id 1AF4BE06CC for ; Fri, 22 Apr 2011 06:26:57 -0700 (PDT) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4E53C1B0D089; Fri, 22 Apr 2011 09:26:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4DB1706B.3050602@pi.nu> Date: Fri, 22 Apr 2011 09:26:55 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4DB1706B.3050602@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1084) Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 13:26:57 -0000 Support. On Apr 22, 2011, at 8:11 AM, Loa Andersson wrote: > Working Group, > > this is to start a two week poll on making > > draft-asati-pignataro-mpls-ldp-iana-01 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 8th. > > /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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From prvs=1093e80d4a=edwin.mallette@bhnis.com Fri Apr 22 06:33:41 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 763E8E0740 for ; Fri, 22 Apr 2011 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGOI1-srU45B for ; Fri, 22 Apr 2011 06:33:40 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by ietfc.amsl.com (Postfix) with ESMTP id CC03FE0736 for ; Fri, 22 Apr 2011 06:33:40 -0700 (PDT) Received: from pps.filterd (mx2 [127.0.0.1]) by mx2.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p3MDV699016772; Fri, 22 Apr 2011 09:33:40 -0400 Received: from tbstpcas01.corp.local ([10.226.201.190]) by mx2.mybrighthouse.com with ESMTP id vuamm80kx-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Apr 2011 09:33:40 -0400 Received: from CNEMAIL.corp.local ([10.225.1.130]) by tbstpcas01.corp.local ([10.226.201.190]) with mapi; Fri, 22 Apr 2011 09:33:39 -0400 From: "Mallette, Edwin" To: Loa Andersson , "mpls@ietf.org" Date: Fri, 22 Apr 2011 09:33:39 -0400 Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AcwA8eOeqY5w3sEXR9muyVQis1/WDA== Message-ID: In-Reply-To: <4DB1706B.3050602@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104220068 Cc: Ross Callon Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 13:33:41 -0000 Yes/support. On 4/22/11 8:11 AM, "Loa Andersson" wrote: >Working Group, > >this is to start a two week poll on making > >draft-asati-pignataro-mpls-ldp-iana-01 > >an mpls working group document. > >If you support the document becoming a working group document >please respond to this poll with "yes/support" > >If you do not support the document becoming a working group >document please respond to this poll with "no/do not support" >and at the same time give the technical reasons why you are >not supporting the document. > >If you have technical comments or in any other way want to >discuss the document, please send these comments to the mpls >working group mailing list, but with another subject than what >is on this mail. > >The poll ends May 8th. > >/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 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. From Alexander.Vainshtein@ecitele.com Fri Apr 22 06:52:13 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3777CE0765 for ; Fri, 22 Apr 2011 06:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9PyTtgkKs5b for ; Fri, 22 Apr 2011 06:52:11 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id 6ED5EE076D for ; Fri, 22 Apr 2011 06:52:11 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-68-4db187a5ebb5 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id EB.84.02691.5A781BD4; Fri, 22 Apr 2011 16:50:29 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 22 Apr 2011 16:52:08 +0300 From: Alexander Vainshtein To: Robert Rennison , David Allan I , "mpls@ietf.org" Date: Fri, 22 Apr 2011 16:49:52 +0300 Thread-Topic: Poll / Final in draft-cc-cv-rdi Thread-Index: Acv+tvS4BEK+rt17R96WWlGBJIq3WgAuHfsAADkvD+AAJ/+rCw== Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD521A20DDDF@EUSAACMS0703.eamcs.ericsson.se>, <786AD2EC3D80A1428B921CDC9BE9EE5466F24A667B@USPITMAIL01.ecitele.com> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE5466F24A667B@USPITMAIL01.ecitele.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 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTfWwLYRzH8/Ru3W3ryalufTrEOSHxUlnNolhHDJlIM8JfQri1j/aivTZ3 R3QJiiwEEa/L1NtIy7xlOkIFWYwYIkG8lHlJRL2sYkQtWDDPOWbi/vo9v+/n9/v+nsvvoQhj Rl9ICaKCJJH3cfpccnv64ydrbF3cWdQVL7A/v3WWsLfFjmTZvzfcIycTFV2d9/UV0ehXXUVy zf3sWcS8MCjlRTGg8Api3Uh2ObhZkrCMd4U4VnA7OBvHBn28C/mRqDg4PhhEopsry2X/+0ox JogsEl0BtyB6HNyMOZVWu71kvNXGlQ0bYiuemDvXK8gssvp5wcf6kSzzHsTizKLThPdO6gER rC1ffuZ9eRgkSjaAHAoyY+Hr2FVCiwvg7WeN+g0glzIy5wAM7zydrR12AHhq/Tu9SukZB2w6 9vQXZWLCAD6oqydVgWCGwmTrWixQFInjrjCtpvsxo2D00RWdmjYxVviwnVXTJmYKfJNpBGpM M5Ww5vNLQvPag1tefJWl8jnMbJiorVIZgIf7fOO4TnMyw7bUfp02NAOjF279vkA+bH/xI0vj 8+GTdVp/Ao9Qf/6jXotHwkMH3hKab194fVeK1Got8FLDQ3ILMEd6WUR6lUd6lUd6ldcD8ijI F3xBpcrvKRozGrkEBfnQaFfA3wS0ZXmTAI9vDm8BDAU4A52oOek0ZvHL5JC/BVgoHZdPSzVx p7FPVcAd8vKyd6G01IfkFgApgjPRJ9ZgnHbzoWokBf5IdvyPtxKFea4AXktRWVhcVPTPgTPT HYuiTiPjwTu3BKEgkv6UDqAoDtKVeHuNfSXkQcsXCz7lr6yjclRnA3aeojK0HOT9suDR9Bug mMpcrmsGVPr87mZgJMWAiArNtF1FGRX1LhV7uqlvZVV3d3camPHN+9GDVMqAX1JPvzS20mGr 2L1G1Qq/kB6pMAyGvkaoXek4YUlmDCvJvIZ4fcHmwRHLu/55ZczGfeVtHZsmFoBvL6dXm/y7 jySlcmVujuFxa3bp3TicdLS59KDTFIglh5xsffG84dqX+ena1em9o+i2gSsuZZriqWlTDw2u uWbZ1tkyZpyz+nZJneFi04TOmQcXhGx3EoeNne8/pDhS9vK2EYQk8z8BX+eHMQYEAAA= Cc: Ross Callon Subject: Re: [mpls] Poll / Final in draft-cc-cv-rdi X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 13:52:13 -0000 Hi all, I concur with Rob: the session state machine should be compliant with t RFC 5880. My 2c, Sasha ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Robert Renn= ison [Robert.Rennison@ecitele.com] Sent: Thursday, April 21, 2011 11:53 PM To: David Allan I; mpls@ietf.org Cc: Ross Callon Subject: Re: [mpls] Poll / Final in draft-cc-cv-rdi Dave, John and George, Many thanks for listening to the comments regarding deviation from the base= spec and potential problems in doing so. I strongly support the approach of mandating support for the BFD baseline s= pecification along with the Poll/final mechanism. I've made the point in the BFD WG when this was first presented and on the l= ist regarding potential problems in deviating from the base spec. The more= I discuss and think through these the more I come to the conclusion that we= should leave the state machines alone and not make changes for perceived op= timizations of "issues". If the baseline spec was implementable in the past= it still is even if encapsulated in a different wrapper. In short whilst you could potentially get a BFD session to work without sup= porting P/F you may end up dumbing the speed down to the startup value which= many vendors begin with and thus the network operators will not be able to= get eh equipment they have paid for to operate at the rates they are capabl= e of merely because one vendors "letter of the law" implementation does not= support P/F. Some comments and expansion inline preceded by [[ [Rob Rennison] .... ]] Cheers Rob -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Davi= d Allan I Sent: Wednesday, April 20, 2011 11:30 AM To: mpls@ietf.org Cc: Ross Callon Subject: [mpls] FW: Poll / Final in draft-cc-cv-rdi Hi Folks: We've received a number of comments both formally and informally that the cu= rrent draft has deviated too far from the base BFD spec and thus loses backw= ard compatibility with existing code bases. Further, discussions with the B= FD WG have indicated we have a potential race condition in the current start= up procedures described in draft-cc-cv-rdi. The issue is the transition to UP state requires confirmation by the peer ME= P prior to changing the detection time to the rx-interval x detect mult in o= rder to avoid potential flapping. This can result in an implementation effec= tively needing two UP states (UP forward, UP reverse direction). Otherwise the MEP may time out the reverse direction before seeing an UP sta= te from the peer MEP. So we can make this implicit in the specification and require BFD changes or= we can use poll/final discipline on startup as defined in the base specific= ation and make the transition to fully UP and the desired rate both explicit= and exposed in the protocol exchange. This would reduce the deltas between= the base spec (RFC 5880) and draft CC-CV-RDI. [[ [Rob Rennison] Without a valid concrete reason to change the base spec we s= hould leave it alone, and I've yet to see any concrete rationale explained,= allusion to "issues" with having to keep a Tx and Rx state and possible op= timizations are not being concrete enough IMHO to have a productive discuss= ion about and to change what's already working. I will try to read between t= he lines and see where this takes us. The baseline specification has nume= rous interoperable implementations and should not be changed lightly. Also r= e your question of should we make things explicit or implicit in the spec; p= lease do not make things implicit in the specs, any variations are subtle e= nough without key points being implicit, so whatever is specified should be= explicit.] ]] > We would also observe that it is permissable in the specification to respo= nd to a poll with a final reply > with the session parameters unchanged. [[ [Rob Rennison] Agreed, if you do not wish to change what you are accepting f= rom the peer, then do not change the value of "_Required_ Min Rx interval" y= ou put in the BFD control packets you send to your peer, i.e. you can effec= tively ignore what he says he wants to send to you via the values he puts in= "_Desired_ Min TX Interval" he sends to you. _But_ You do need to interpret and act on the values your peer MEP is telling you= via the "Required Min Rx Interval" so you both have to go as slow as your p= eer wants you to go. So whatever optimizations of the "UP processing loop" y= ou wish to do, and I assume you mean you wish to do it all without reverting= to having the control plane i.e. slow path take part, these optimizations w= ill need to interpret the value in the "Required Min Rx interval" as sent by= the peer. You will also need to make sure you send the correct values in the State fie= ld to transmission from Down to Init to Up or perhaps your optimization will= constantly send Init state. One additional observation is that if you were to try to interoperate with a= peer MEP which was capable of running a session at a value X mS but started= off at Y mS where Y >> X then you would end up running at the slow rate of= YmS whereas if you were true to the BFD baseline spec you would have been a= ble to get the peer to play at the rate you desired. This is why many implementations start of slowly at say a few packets per se= cond or so rate and then once they have established a session they tell the= peer what the rate is they would like to send at, they do this using the= poll bit when they modify the value they are sending in the "Desired Tx in= terval" field, but do not modify the rate yet. The peer can then take his sw= eet time setting up the hardware to be prepared to receive some potentially= fast BFD control packets with a specific value of "My discriminator". When= the peer has got his hardware ready to receive, the peer responds with the= final bit set and you can then "blast way at the fast rate". This is all yo= u as a given MEP care about, "can I get this session speeded up so I can bla= st at him at the rate I would like to". Conversely the other end is responsi= ble for suggesting a new fast value to you and gives you the courtesy of the= P/F mechanism to allow you to get ready, whereupon you set the F bit when y= ou are ready. In this manner a pair of peers, for a specific session can in an o= rderly manner progress from a software/ control plane mechanism to one where= a _simple_ hardware/fastpath/acceleration logic does the detection. The upshot of the existing mechanism is a fairly simple hardware implementat= ion involving some timers and pattern matching on discriminators, whereas th= e optimizations you allude to do not necessarily simply things for the hardw= are or the remote peer and would limit the interoperability. If your optimiz= ation looks to external devices like any other BFD peer then go ahead, but m= ake sure you obey the spirit of the law and not the letter, i.e. do not fail= to work with other vendors at a fast rate, which they are capable of, beca= use you do not support F/P. ]] >So once a session is up a compliant implementation does not actually have t= o implement on the fly changes to session paramters. The processing of the p= oll bit can simply be reduced to setting the final bit in the next message. This would permit implementations to optimize the UP processing loop. [[ [Rob Rennison] Agreed it does not have to allow for on the fly changes to se= ssion parameters i.e. requests it gets from the peer about the rate the pee= r wishes to send to it i.e. the values the peer puts into the "Desired Min T= x Interval" but it does need to interpret the values it receives from the p= eer in the "Required Min Rx Interval". ]] This is a change of direction from what has been in the draft to date, hence= we'd look to the WG for comment on this change... the editors Dave, John and George... This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From rcallon@juniper.net Fri Apr 22 10:32:24 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 726F8E0808; Fri, 22 Apr 2011 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.695 X-Spam-Level: X-Spam-Status: No, score=-106.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbYTgY-HXcy8; Fri, 22 Apr 2011 10:32:20 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfc.amsl.com (Postfix) with ESMTP id 00A0DE07FE; Fri, 22 Apr 2011 10:32:19 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTbG7o6+6Bu7x5kaH3/OTjurk2vKi4KLz@postini.com; Fri, 22 Apr 2011 10:32:20 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Apr 2011 10:29:34 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 22 Apr 2011 13:29:34 -0400 From: Ross Callon To: "rtg-bfd@ietf.org" Date: Fri, 22 Apr 2011 13:29:34 -0400 Thread-Topic: Poll / Final in draft-cc-cv-rdi Thread-Index: Acv+tvS4BEK+rt17R96WWlGBJIq3WgAuHfsAAGi3yiA= Message-ID: 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" Subject: [mpls] FW: Poll / Final in draft-cc-cv-rdi X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:32:24 -0000 FYI. This discussion on the MPLS WG email list may be of interest to some B= FD folks.=20 Ross -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Wednesday, April 20, 2011 11:30 AM To: mpls@ietf.org Cc: Loa Andersson; Ross Callon; George Swallow; John E Drake Subject: FW: Poll / Final in draft-cc-cv-rdi Hi Folks: =20 We've received a number of comments both formally and informally that the current draft has deviated too far from the base BFD spec and thus loses backward compatibility with existing code bases. Further, discussions with the BFD WG have indicated we have a potential race condition in the current startup procedures described in draft-cc-cv-rdi. =20 The issue is the transition to UP state requires confirmation by the peer MEP prior to changing the detection time to the rx-interval x detect mult i= n order to avoid potential flapping. This can result in an implementation effectively needing two UP states (UP forward, UP reverse direction). Otherwise the MEP may time out the reverse direction before seeing an UP state from the peer MEP. =20 So we can make this implicit in the specification and require BFD changes o= r we can use poll/final discipline on startup as defined in the base specification and make the transition to fully UP and the desired rate both explicit and exposed in the protocol exchange. This would reduce the deltas between the base spec (RFC 5880) and draft CC-CV-RDI. =20 We would also observe that it is permissable in the specification to respon= d to a poll with a final reply with the session parameters unchanged. So once a session is up a compliant implementation does not actually have to implement on the fly changes to session paramters. The processing of the poll bit can simply be reduced to setting the final bit in the next message= . This would permit implementations to optimize the UP processing loop. =20 This is a change of direction from what has been in the draft to date, henc= e we'd look to the WG for comment on this change... =20 the editors Dave, John and George... From Adrian.Farrel@huawei.com Sat Apr 23 06:48:56 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A62A2E0706 for ; Sat, 23 Apr 2011 06:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.946 X-Spam-Level: X-Spam-Status: No, score=-104.946 tagged_above=-999 required=5 tests=[AWL=1.653, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bfOu57QmeUt for ; Sat, 23 Apr 2011 06:48:55 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfc.amsl.com (Postfix) with ESMTP id CFCA4E06FF for ; Sat, 23 Apr 2011 06:48:55 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LK300KI8YDIPV@usaga03-in.huawei.com> for mpls@ietf.org; Sat, 23 Apr 2011 08:48:54 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LK300ABBYDG40@usaga03-in.huawei.com> for mpls@ietf.org; Sat, 23 Apr 2011 08:48:54 -0500 (CDT) Date: Sat, 23 Apr 2011 14:48:51 +0100 From: Adrian Farrel To: draft-ietf-mpls-rsvp-te-no-php-oob-mapping@tools.ietf.org Message-id: <0c6d01cc01bd$2f10ab10$8d320130$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcwBvPMrYO+nXVxoQRuNBJh3Wh/PCQ== Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 13:48:56 -0000 Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is to catch any nits or issues before the document goes forward to IETF last call and IESG review. By getting these issues out at this stage we can hope for a higher quality review and a smoother passage through the process. I found number of small issues and questions. These are mainly concerns with clarity, and editorial issues. All of my comments are up for discussion, and you should not feel rail-roaded into making changes. But I do think my comments need to be addressed before this document is presented for IETF last call, and I would like you to have a look and see whether you can work to improve the text before I take it forward. I have moved the draft into "AD-review:Revised-ID-needed" state in the datatracker, and I look forward to seeing the new revision which I can put forward for IETF last call. Thanks, Adrian --- It would be best to expand the acronyms PHP and LSP in the document title. --- Acronyms need to be expanded on first use in the main body of the text. The Abstract should be seen as stand-alone, and you have to start expanding them again. I find: RSVP-TE MVPN VPLS LSR LSP --- Please decide between "out-of-band" and "out of band" and update the document accordingly. --- Abstract s/proposes/defines/ --- Section 2.1 When signaling a P2MP LSP, a source node may wish to solicit individual response to "non-PHP behavior flag" from the leaf nodes. Given the constraints on how the LSP_ATTRIBUTES may be carried in Path and Resv Messages according to RFC5420, in this situation a source node MUST use a separate Path message for each leaf. This is wrong, isn't it? P2MP signaling is defined in RFC 4875. That document clearly describes how LSP_ATTRIBUTES are used in the P2MP case. You have the RRO flags available to record egress LSR behavior. The same issue arrises in Section 2.2. --- Section 2.1 If the egress LSR - supports the LSP_ATTRIBUTES object but does not recognize the Attributes Flags TLV; or - supports the LSP_ATTRIBUTES object and recognize the Attributes Flags TLV, but does not recognize "non-PHP behavior flag"; then it SHOULD silently ignore this request. The behavior in these two cases is not something you can define here since such LSRs will not be conformant to this document. Fortunately, this behavior is defined in RFC 5420, so you can re-write as: then it will silently ignore this request according to the processing rules of [RFC5420]. The same applies in Section 2.2 --- Section 2.2 I had a bit an "I wouldn't have done it this way" moment. Can you explain why you opted for a mechanism that signals the fact that another mechanism will be used to bind LSPs, rather than enhancing RSVP-TE to actually signal the use? Actually, RSVP-TE already includes mechanisms that could very easily have carried the binding information. Obviously you need to support existing non-RSVP mechanisms, but that could have been rolled in. --- Section 2.4 It would be interesting to know whether OAM is expected to work or not while the egress is black-holing data pending binding. --- Section 3 Since you have introduced a dependence on an external communications method, you have also introduced a new security consideration. You have also introduced some new vectors that can be used to attack the LSP. For example, changing the label reported in the RRO can cause it to be torn down. Although this does not change the overall security model or techniques, it should be pointed out so that an operator can consider the additional pressure to apply adequate security mechanisms. You should include a reference to RFC 5920. --- Section 4 You are missing a subsection header 4.2. New RSVP Return Code --- Section 4.1 Please remove suggested values from this section and the whole document. You will notice that flag 6 has already been assigned. Including suggested values in a draft is only likely to result in confusion. --- Section 4.1 o These flags are to be used in the Attributes Flags TLV in both Path and Resv messages. Please be more explicit so that IANA can fill in the table at http://www.iana.org/assignments/rsvp-te-parameters The easiest is to supply all the table entries except for the TBD values. --- From jeff.tantsura@ericsson.com Mon Apr 25 00:27:21 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ACF2CE06FF for ; Mon, 25 Apr 2011 00:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[AWL=1.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F8UUiXf7WuJ for ; Mon, 25 Apr 2011 00:27:20 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id CAC46E06DC for ; Mon, 25 Apr 2011 00:27:20 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3P7RJEt021470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Apr 2011 02:27:20 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([147.117.20.26]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 25 Apr 2011 03:27:19 -0400 From: Jeff Tantsura To: Ross Callon Date: Mon, 25 Apr 2011 03:27:17 -0400 Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acv+Ay/TG4hjohrZQnWQ154hdA1FywFFvPbA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CABC94D95@EUSAACMS0701.eamcs.ericsson.se> 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 Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 07:27:21 -0000 Yes/support Regards, Jeff =20 On Mon, Apr 18, 2011 at 11:15 AM, Ross Callon wrote: > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > 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 jeff.tantsura@ericsson.com Mon Apr 25 00:30:07 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 010FAE06A2 for ; Mon, 25 Apr 2011 00:30:07 -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=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4S63LKKAsuE for ; Mon, 25 Apr 2011 00:30:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 65078E06DE for ; Mon, 25 Apr 2011 00:30:06 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3P7U0Af000364; Mon, 25 Apr 2011 02:30:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([147.117.20.26]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 25 Apr 2011 03:29:55 -0400 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" Date: Mon, 25 Apr 2011 03:29:54 -0400 Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AcwA5nEdI1jJ4wL/T96c/lahXALezACNBoCg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CABC94D96@EUSAACMS0701.eamcs.ericsson.se> References: <4DB1706B.3050602@pi.nu> In-Reply-To: <4DB1706B.3050602@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 Cc: Ross Callon Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 07:30:07 -0000 Yes/support Regards, Jeff =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Friday, April 22, 2011 05:11 To: mpls@ietf.org Cc: Ross Callon Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Working Group, this is to start a two week poll on making draft-asati-pignataro-mpls-ldp-iana-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 8th. /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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From xiao.min2@zte.com.cn Mon Apr 25 01:16:08 2011 Return-Path: X-Original-To: mpls@ietfc.amsl.com Delivered-To: mpls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 91D61E0712; Mon, 25 Apr 2011 01:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFwyAAelRVA4; Mon, 25 Apr 2011 01:16:08 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfc.amsl.com (Postfix) with ESMTP id 10612E06DC; Mon, 25 Apr 2011 01:16:05 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 125201784411434; Mon, 25 Apr 2011 16:14:51 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 35180.2311252665; Mon, 25 Apr 2011 15:56:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3P88L2O062841; Mon, 25 Apr 2011 16:08:21 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) In-Reply-To: <4DB1706B.3050602@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: xiao.min2@zte.com.cn Date: Mon, 25 Apr 2011 16:08:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-25 16:08:22, Serialize complete at 2011-04-25 16:08:22 Content-Type: multipart/alternative; boundary="=_alternative 002CAE104825787D_=" X-MAIL: mse01.zte.com.cn p3P88L2O062841 Cc: Ross Callon , "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 08:16:08 -0000 This is a multipart message in MIME format. --=_alternative 002CAE104825787D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQuDQoNCi0gWGlhbyBNaW4NCg0KDQoNCg0KTG9hIEFuZGVyc3NvbiA8bG9hQHBp Lm51PiANCreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS8wNC8yMiAyMDoxMQ0K DQrK1bz+yMsNCiJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4NCrOty80NClJvc3MgQ2Fs bG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0Pg0K1vfM4g0KW21wbHNdIHBvbGwgb24gZHJhZnQtYXNh dGktcGlnbmF0YXJvLW1wbHMtbGRwLWlhbmENCg0KDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQoN CnRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZw0KDQpkcmFmdC1hc2F0 aS1waWduYXRhcm8tbXBscy1sZHAtaWFuYS0wMQ0KDQphbiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQuDQoNCklmIHlvdSBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWluZyBhIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQNCnBsZWFzZSByZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICJ5ZXMvc3Vw cG9ydCINCg0KSWYgeW91IGRvIG5vdCBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWluZyBhIHdv cmtpbmcgZ3JvdXANCmRvY3VtZW50IHBsZWFzZSByZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICJu by9kbyBub3Qgc3VwcG9ydCINCmFuZCBhdCB0aGUgc2FtZSB0aW1lIGdpdmUgdGhlIHRlY2huaWNh bCByZWFzb25zIHdoeSB5b3UgYXJlDQpub3Qgc3VwcG9ydGluZyB0aGUgZG9jdW1lbnQuDQoNCklm IHlvdSBoYXZlIHRlY2huaWNhbCBjb21tZW50cyBvciBpbiBhbnkgb3RoZXIgd2F5IHdhbnQgdG8N CmRpc2N1c3MgdGhlIGRvY3VtZW50LCBwbGVhc2Ugc2VuZCB0aGVzZSBjb21tZW50cyB0byB0aGUg bXBscw0Kd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QsIGJ1dCB3aXRoIGFub3RoZXIgc3ViamVj dCB0aGFuIHdoYXQNCmlzIG9uIHRoaXMgbWFpbC4NCg0KVGhlIHBvbGwgZW5kcyBNYXkgOHRoLg0K DQovTG9hDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVt YWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJk cyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQpFcmljc3NvbiBJbmMgICAgICAgICAgICAg ICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQpt cGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg0KDQoNCg== --=_alternative 002CAE104825787D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy9TdXBwb3J0LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LSBYaWFvIE1pbjwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5M b2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9y ZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLzA0LzIyIDIw OjExPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPiZxdW90O21wbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5Sb3NzIENhbGxvbiAmbHQ7cmNhbGxvbkBqdW5pcGVyLm5ldCZndDs8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlttcGxzXSBwb2xsIG9uIGRyYWZ0LWFzYXRpLXBpZ25hdGFyby1tcGxz LWxkcC1pYW5hPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yPjx0dD5Xb3JraW5nIEdyb3VwLDxicj4NCjxicj4NCnRoaXMgaXMgdG8gc3RhcnQgYSB0 d28gd2VlayBwb2xsIG9uIG1ha2luZzxicj4NCjxicj4NCmRyYWZ0LWFzYXRpLXBpZ25hdGFyby1t cGxzLWxkcC1pYW5hLTAxPGJyPg0KPGJyPg0KYW4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50 Ljxicj4NCjxicj4NCklmIHlvdSBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWluZyBhIHdvcmtp bmcgZ3JvdXAgZG9jdW1lbnQ8YnI+DQpwbGVhc2UgcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAm cXVvdDt5ZXMvc3VwcG9ydCZxdW90Ozxicj4NCjxicj4NCklmIHlvdSBkbyBub3Qgc3VwcG9ydCB0 aGUgZG9jdW1lbnQgYmVjb21pbmcgYSB3b3JraW5nIGdyb3VwPGJyPg0KZG9jdW1lbnQgcGxlYXNl IHJlc3BvbmQgdG8gdGhpcyBwb2xsIHdpdGggJnF1b3Q7bm8vZG8gbm90IHN1cHBvcnQmcXVvdDs8 YnI+DQphbmQgYXQgdGhlIHNhbWUgdGltZSBnaXZlIHRoZSB0ZWNobmljYWwgcmVhc29ucyB3aHkg eW91IGFyZTxicj4NCm5vdCBzdXBwb3J0aW5nIHRoZSBkb2N1bWVudC48YnI+DQo8YnI+DQpJZiB5 b3UgaGF2ZSB0ZWNobmljYWwgY29tbWVudHMgb3IgaW4gYW55IG90aGVyIHdheSB3YW50IHRvPGJy Pg0KZGlzY3VzcyB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlIGNvbW1lbnRzIHRvIHRo ZSBtcGxzPGJyPg0Kd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QsIGJ1dCB3aXRoIGFub3RoZXIg c3ViamVjdCB0aGFuIHdoYXQ8YnI+DQppcyBvbiB0aGlzIG1haWwuPGJyPg0KPGJyPg0KVGhlIHBv bGwgZW5kcyBNYXkgOHRoLjxicj4NCjxicj4NCi9Mb2E8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+ DQpMb2EgQW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFu ZGVyc3NvbkBlcmljc3Nvbi5jb208YnI+DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFn ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+ DQpFcmljc3NvbiBJbmMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiAr NDYgMTAgNzE3IDUyIDEzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOys0NiA3NjcgNzIgOTIgMTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBs c0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs czxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K --=_alternative 002CAE104825787D_=-- From swallow@cisco.com Mon Apr 25 15:39:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564EBE069E for ; Mon, 25 Apr 2011 15:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.602 X-Spam-Level: X-Spam-Status: No, score=-106.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCQ6Csi-PYD3 for ; Mon, 25 Apr 2011 15:39:36 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 543B5E0670 for ; Mon, 25 Apr 2011 15:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=3997; q=dns/txt; s=iport; t=1303771176; x=1304980776; h=date:subject:from:to:message-id:mime-version; bh=SgYZdERU0vWbUSVZ0jwBdej568NZN/weYLzVi4P0FbQ=; b=dR5rp3k6YN96LVLoi3tves7+iwAnODpKbI1E5YXq4qDtZKWyGoyXMpOb LvcD2EhO/tJvswhAzPsw7gJdPyWNjowwftL7ZGodKirAfe+BUqhWwer3/ TPfPzdm/gD4x8Z8lBcSkVKHp0zoUnh3EMIKI50x+2kLwHFwy3CkzEzU2L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4HAH7ktU2tJV2d/2dsb2JhbACCYpU0jEted6gOnHiCf4J3BI41hA8 X-IronPort-AV: E=Sophos;i="4.64,266,1301875200"; d="scan'208,217";a="230923670" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2011 21:16:50 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p3PLGnY0018821 for ; Mon, 25 Apr 2011 21:16:49 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Apr 2011 16:16:49 -0500 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Apr 2011 21:16:49 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 25 Apr 2011 17:16:47 -0400 From: George Swallow To: Message-ID: Thread-Topic: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7g== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386596608_31253593" X-OriginalArrivalTime: 25 Apr 2011 21:16:49.0553 (UTC) FILETIME=[17265810:01CC038E] Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:39:37 -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_3386596608_31253593 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends. Mixed use is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure. Many organizations if not most already have AS Numbers. 2. Such an addition will add numerous object formats, and test cases. 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes of ICC and Global-ID identification is required, they can be added later. 4. For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC. That would be a radical change to how IP works. However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew --B_3386596608_31253593 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Mixing ICC and Global-IDs in MPLS-TP Identifiers? All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG = to use either the Global-ID for both ends or or the ICC for both ends.  = ;Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this.  

    1. Obtaining an AS Number (from w= hich the Global-ID is derived) is a fairly trivial procedure.  Many org= anizations if not most already have AS Numbers.=20
    2. Such an addition will add numerous= object formats, and test cases.=20
    3. The extent inter-provider MPLS-TP = is as yet unknown.  If mixed modes of ICC and Global-ID identification = is required, they can be added later.=20
    4. For signaled connections, there is= no plan to allow routing based on either the Global-ID or ICC.  That w= ould be a radical change to how IP works.  However for IP routing to wo= rk (in order to forward the signaling messages), the providers involved will= need to run BGP and have AS numbers.

    We are looking for input/consensus from the WG.

    George, Eric, & Matthew     --B_3386596608_31253593-- From Internet-Drafts@ietf.org Mon Apr 25 16:00:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B243BE0689; Mon, 25 Apr 2011 16:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G55YfWZom+te; Mon, 25 Apr 2011 16:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD15E068D; Mon, 25 Apr 2011 16:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110425230002.1805.96285.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2011 16:00:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-fastreroute-mib-17.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 23:00: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, et al. Filename : draft-ietf-mpls-fastreroute-mib-17.txt Pages : 50 Date : 2011-04-25 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-17.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-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-25155647.I-D@ietf.org> --NextPart-- From cts@etri.re.kr Mon Apr 25 17:14:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BA6E0679; Mon, 25 Apr 2011 17:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.41 X-Spam-Level: X-Spam-Status: No, score=-100.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XadyRJZFTLZZ; Mon, 25 Apr 2011 17:14:37 -0700 (PDT) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBA0E0663; Mon, 25 Apr 2011 17:14:30 -0700 (PDT) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Tue, 26 Apr 2011 09:14:29 +0900 Priority: normal thread-index: AcwDpuhamyf2ZMpFTkWleeqEb90q+Q== Thread-Topic: New Version Notification for draft-cheung-mpls-tp-mesh-protection-03 From: "Taesik Cheung" To: , Date: Tue, 26 Apr 2011 09:14:28 +0900 Comment: ??, ?, Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F6D_01CC03F2.5844BAD0" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 X-OriginalArrivalTime: 26 Apr 2011 00:14:29.0399 (UTC) FILETIME=[E8E9C270:01CC03A6] Subject: [mpls] FW: New Version Notification for draft-cheung-mpls-tp-mesh-protection-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Taesik Cheung List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 00:14:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0F6D_01CC03F2.5844BAD0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_0F6D_01CC03F2.5844BAD0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiIGlkPW1zZ2Jv ZHk+DQo8RElWPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1h bD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJ WkU6IDEwcHQiIGxhbmc9RU4tVVM+RGVhciBNUExTIFdHLDwvU1BBTj48U1BBTiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPjw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0g InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwv U1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286 cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05v cm1hbD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05U LVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+UGxlYXNlIG5vdGUgdGhhdCB3ZSBzdWJtaXR0ZWQgYSBu ZXcgdmVyc2lvbiZuYnNwO29mIHRoZSBNUExTLVRQIHNoYXJlZCBtZXNoIHByb3RlY3Rpb24uPC9T UEFOPjxTUEFOIGxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0IiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVT PkEgVVJMIGZvciB0aGlzJm5ic3A7SS1EIGlzOjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0IiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJH SU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPjxBIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZXVuZy1tcGxz LXRwLW1lc2gtcHJvdGVjdGlvbi0wMy50eHQiIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hldW5nLW1wbHMtdHAtbWVzaC1wcm90ZWN0aW9u LTAzLnR4dDwvQT48L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1V Uz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+ Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3Nh bnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+V2Ugd291bGQgYXBwcmVjaWF0 ZSB5b3VyIHJldmlldyBhbmQgY29tbWVudHMmbmJzcDtvbiBvdXIgZG9jdW1lbnQuPC9TUEFOPjxT UEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+ PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BB TiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpF OiAxMHB0IiBsYW5nPUVOLVVTPkJlc3QgcmVnYXJkcyw8L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQt U0laRTogMTBwdCIgbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZB TUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz5U YWVzaWs8L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz48bzpw PjwvbzpwPjwvU1BBTj48L1A+PEJSPg0KPERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsg V09SRC1CUkVBSzogYnJlYWstYWxsIj4NCjxESVY+DQo8RElWIHN0eWxlPSJGT05ULUZBTUlMWTog 6rW066a8OyBGT05ULVNJWkU6IDEwcHQiPg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj48L0RJVj48 L0RJVj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gIklFVEYgSS1E IFN1Ym1pc3Npb24gVG9vbCIgJmx0O2lkc3VibWlzc2lvbkBpZXRmLm9yZyZndDs8QlI+PEI+RnJv bSBEYXRlOjwvQj4gMjAxMS0wNC0yNSBQTSA1OjU1OjMzPEJSPjxCPlRvOjwvQj4gImN0c0BldHJp LnJlLmtyIiAmbHQ7Y3RzQGV0cmkucmUua3ImZ3Q7PEJSPjxCPkNjOjwvQj4gInJ5b29AZXRyaS5y ZS5rciIgJmx0O3J5b29AZXRyaS5yZS5rciZndDs8QlI+PEI+U3ViamVjdDo8L0I+IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hldW5nLW1wbHMtdHAtbWVzaC1wcm90ZWN0aW9u LTAzIDxCUj48QlI+DQo8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQg LS0+PEJSPjxCUj4NCjxQPjxGT05UIHNpemU9Mj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt Y2hldW5nLW1wbHMtdHAtbWVzaC1wcm90ZWN0aW9uLTAzLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFRhZS1zaWsgQ2hldW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS48QlI+PEJSPkZpbGVuYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkcmFmdC1jaGV1bmctbXBscy10cC1tZXNoLXByb3RlY3Rpb248QlI+UmV2aXNp b246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAzPEJSPlRpdGxl OiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TVBMUy1UUCBTaGFyZWQgTWVzaCBQcm90ZWN0aW9uPEJSPkNyZWF0aW9uX2RhdGU6Jm5ic3A7Jm5i c3A7IDIwMTEtMDQtMjU8QlI+V0cgSUQ6Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRlcGVuZGVudCBTdWJtaXNzaW9uPEJSPk51bWJlcl9v Zl9wYWdlczogMTg8QlI+PEJSPkFic3RyYWN0OjxCUj5UaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IG1lY2hhbmlzbSB0byBhZGRyZXNzIHRoZSByZXF1aXJlbWVudCBmb3I8QlI+cHJvdGVjdGlvbiBv ZiBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgaW4gYW4gTVBMUyBUcmFuc3BvcnQ8QlI+UHJv ZmlsZSAoTVBMUy1UUCkgbWVzaCB0b3BvbG9neS4gVGhlIHNoYXJlZCBtZXNoIHByb3RlY3Rpb24g bWVjaGFuaXNtPEJSPmVuYWJsZXMgbXVsdGlwbGUgcHJvdGVjdGlvbiBwYXRocyB3aXRoaW4gYSBz aGFyZWQgbWVzaCBwcm90ZWN0aW9uPEJSPmRvbWFpbiB0byBzaGFyZSBwcm90ZWN0aW9uIHJlc291 cmNlcyBmb3IgdGhlIHByb3RlY3Rpb24gb2Ygd29ya2luZzxCUj5wYXRocyBieSBjb29yZGluYXRp bmcgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgb3BlcmF0aW9ucyBhY2NvcmRpbmcgdG88QlI+dGhlIHBy aW9yaXR5IGFzc2lnbmVkIHRvIGVhY2ggZW5kLXRvLWVuZCBsaW5lYXIgcHJvdGVjdGlvbiBkb21h aW4uPEJSPjxCUj5UaGlzIGRvY3VtZW50IGlzIGEgcHJvZHVjdCBvZiBhIGpvaW50IEludGVybmV0 IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2U8QlI+KElFVEYpIC8gSW50ZXJuYXRpb25hbCBUZWxlY29t bXVuaWNhdGlvbiBVbmlvbiBUZWxlY29tbXVuaWNhdGlvbjxCUj5TdGFuZGFyZGl6YXRpb24gU2Vj dG9yIChJVFUtVCkgZWZmb3J0IHRvIGluY2x1ZGUgYW4gTVBMUyBUcmFuc3BvcnQ8QlI+UHJvZmls ZSB3aXRoaW4gdGhlIElFVEYgTVBMUyBhbmQgUFdFMyBhcmNoaXRlY3R1cmVzIHRvIHN1cHBvcnQg dGhlPEJSPmNhcGFiaWxpdGllcyBhbmQgZnVuY3Rpb25hbGl0aWVzIG9mIGEgcGFja2V0IHRyYW5z cG9ydCBuZXR3b3JrLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8QlI+PEJSPjxC Uj5UaGUgSUVURiBTZWNyZXRhcmlhdC48QlI+PEJSPjxCUj48L0ZPTlQ+PC9QPjwvRElWPjwvRElW PjwvRElWPg== ------=_NextPart_000_0F6D_01CC03F2.5844BAD0-- From Alexander.Vainshtein@ecitele.com Mon Apr 25 21:01:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D62E06CA for ; Mon, 25 Apr 2011 21:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KM6nwv-vrCp for ; Mon, 25 Apr 2011 21:01:05 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4C616E06B7 for ; Mon, 25 Apr 2011 21:01:04 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-89-4db643199c9c Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 7F.14.02691.91346BD4; Tue, 26 Apr 2011 06:59:21 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 26 Apr 2011 07:01:01 +0300 From: Alexander Vainshtein To: George Swallow Date: Tue, 26 Apr 2011 06:59:44 +0300 Thread-Topic: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gAOEqP7 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_A3C5DF08D38B6049839A6F553B331C76D722D0E7D9ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJsWRmVeSWpSXmKPExsUy+dWnL7qSztt8DY7MMbW4tXQlq8XtKU2M DkweU35vZPVYsuQnUwBTVAOjTWJeXn5JYkmqQkpqcbKtUkBRZllicqWSQmaKrZKhkkJBTmJy am5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1Lzk/JzEu3VfIM9te1sDC11DVUslNTNjS25grJ yCxWSNXNTczMUchNLS5OTE9VAIokbGHOWNS+nKngu07F10k/2RoYO9W6GDk5JARMJPZNWMsK YYtJXLi3ng3EFhLYySjRvtSli5ELyJ7CKHHr1C+wBJuArcSm1XfBbBEBNYl3S2YANXNwMAso S5y6KwMSZhFQleg81gBWIixgJ9HQuIkNpEREwF5i7c5gCNNIovmbO0gFr4C/xJv5DewQW/Uk ljTOYgKxOQX0JW7/PAV2GSPQZd9PrQGLMwuIS9x6Mp8J4mIBiSV7zjND2KISLx//g6oXlbjT vp4R4rB8iR/nwyFWCUqcnPmEBaJcUuLgihssExjFZiGZOguhYxaSDogSPYkbU6ewQdjaEssW vmaGsHUlZvw7xIIsvoCRfRWjaGZOQUlSbrqBkV5qcmZJak6qXnJ+7iZGSLJ5sYPx9hnNQ4wC HIxKPLwdC7f6CrEmlhVX5h5ilORgUhLlbXPa5ivEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhLf9 MFA5b0piZVVqUT5MyhUY8hOZpbiT84EJNK8k3tjAADdHSZz3XcISXyGBdGCizE5NLUgtgpkj w8GhJMF7FGS9YFFqempFWmZOCUKaiYMT5AweoDNqQGp4iwsSc4sz0yHypxgVpcR594IkBEAS GaV5cL2gDFP/////V4ziQE8L8x4AqeIBZie47ldAg5mABk87DvJfMTDDwKWkGhj12tkeXX66 Ue1jHTfP+ZppF2wet/pd0zWqStrDF7ouvtVk5x6NO71/k9rMMz0aJJJs/a8uTUi5qlKWwDH9 46Xklo1ryna1Hv12Znvr9Ivqgap9D621ZQv84/f8usvNYOYulM66z/Ubl8fOhul68+yd3EI0 nmx+JXnKM+bpHh4/5tjFAqxbniuxFGckGmoxFxUnAgDJzGfUCwQAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:01:05 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7D9ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable George, and all, I support the current restriction of not mixing Global and ICC-based identif= iers at the ends of an LSP. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of George Swal= low [swallow@cisco.com] Sent: Tuesday, April 26, 2011 12:16 AM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers= -04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each= end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= either the Global-ID for both ends or or the ICC for both ends. Mixed use= is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a fairl= y trivial procedure. Many organizations if not most already have AS Numbers= . 2. Such an addition will add numerous object formats, and test cases. 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes of= ICC and Global-ID identification is required, they can be added later. 4. For signaled connections, there is no plan to allow routing based on ei= ther the Global-ID or ICC. That would be a radical change to how IP works.= However for IP routing to work (in order to forward the signaling messages= ), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7D9ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
    George, and all,
    I support the current restriction of not= mixing Global and ICC-based identifiers at the ends of an LSP.<= /font>
     
    Regards,
         Sasha
     
    From: mpls-bounces= @ietf.org [mpls-bounces@ietf.org] On Behalf Of George Swallow [swallow@cisco= .com]
    Sent: Tuesday, April 26, 2011 12:16 AM
    To: mpls@ietf.org
    Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers= -04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each= end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG t= o use either the Global-ID for both ends or or the ICC for both ends.  = Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this.  
    1. Obtaining an AS Number (from which the Global-ID= is derived) is a fairly trivial procedure.  Many organizations if not= most already have AS Numbers.
    2. Such an addition will a= dd numerous object formats, and test cases.
    3. The extent inter-provid= er MPLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID iden= tification is required, they can be added later.
    4. For signaled connection= s, there is no plan to allow routing based on either the Global-ID or ICC. &= nbsp;That would be a radical change to how IP works.  However for IP routing to work (in order to forward the signaling messages), the provid= ers involved will need to run BGP and have AS numbers.<= font face=3D"Verdana, Helvetica, Arial">

    We are looking for input/consensus from the WG.

    George, Eric, & Matthew

    This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

    --_000_A3C5DF08D38B6049839A6F553B331C76D722D0E7D9ILPTMAIL02eci_-- From lizhong.jin@zte.com.cn Mon Apr 25 22:43:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AA0E06F5; Mon, 25 Apr 2011 22:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q1w7KQd8+J7; Mon, 25 Apr 2011 22:43:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 20339E067C; Mon, 25 Apr 2011 22:43:35 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 125202203882679; Tue, 26 Apr 2011 13:42:23 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4886.2203882679; Tue, 26 Apr 2011 13:43:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3Q5hMUa059145; Tue, 26 Apr 2011 13:43:22 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-25 20:13:22, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-25 20:13:22, Serialize complete at 2011-04-25 20:13:22, S/MIME Sign failed at 2011-04-25 20:13:22: The cryptographic key was not found, S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-26 13:43:27, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-26 13:43:27, Serialize complete at 2011-04-26 13:43:27, S/MIME Sign failed at 2011-04-26 13:43:27: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-26 13:43:23, Serialize complete at 2011-04-26 13:43:23 To: pwe3@ietf.org Sensitivity: X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Tue, 26 Apr 2011 13:43:23 +0800 Content-Type: multipart/alternative; boundary="=_alternative 001F71CD4825787E_=" X-MAIL: mse01.zte.com.cn p3Q5hMUa059145 Cc: mpls@ietf.org Subject: Re: [mpls] [PWE3] I-D ACTION:draft-ietf-pwe3-cbit-negotiation-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:43:37 -0000 This is a multipart message in MIME format. --=_alternative 001F71CD4825787E_= Content-Type: text/plain; charset="US-ASCII" Hi all, This draft is to collect all possible solutions to reach a most optimized one. In this 00 version of the draft, we got an alternative option at appendixB, and give a brief comparison between the two options. For better backward compatibility, we still keep the "label request message" option. If you have any preference or comments about the two options, please tell us. Also cc to MPLS WG, to ask for comments about the FEC128/129 update in current draft. There are many parameters in FEC128/129 which is not like prefix-FEC. In this draft, if a PE receives a label mapping with same FEC parameter and label, but only different Cbit value than previously received, then PE will update this FEC with new Cbit value. Thanks Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Apr 2011 10:45:02 -0700 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-cbit-negotiation-00.txt > Message-ID: <20110415174502.28931.24336.idtracker@ietfc.amsl.com> > Content-Type: text/plain; charset="us-ascii" > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Pseudowire Emulation Edge to Edge > Working Group of the IETF. > > Title : Pseudowire Control Word Negotiation Mechanism Update > > Author(s) : V. Manral, et al > Filename : draft-ietf-pwe3-cbit-negotiation-00.txt > Pages : 10 > Date : 2011-04-15 > > This document describes the problem of control word negotiation > mechanism specified in [RFC4447]. Based on the problem analysis, a > message exchanging mechanism is introduced to solve this control word > negotiation issue. This document is to update [RFC4447] control word > negotiation mechanism. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cbit-negotiation-00.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. > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001F71CD4825787E_= Content-Type: text/html; charset="US-ASCII"
    Hi all,
    This draft is to collect all possible solutions to reach a most optimized one. In this 00 version of the draft, we got an alternative option at appendixB, and give a brief comparison between the two options. For better backward compatibility, we still keep the "label request message" option. If you have any preference or comments about the two options, please tell us.

    Also cc to MPLS WG, to ask for comments about the FEC128/129 update in current draft. There are many parameters in FEC128/129 which is not like prefix-FEC. In this draft, if a PE receives a label mapping with same FEC parameter and label, but only different Cbit value than previously received, then PE will update this FEC with new Cbit value.

    Thanks
    Lizhong


    >
    > ----------------------------------------------------------------------
    >
    > Message: 1
    > Date: Fri, 15 Apr 2011 10:45:02 -0700
    > From: Internet-Drafts@ietf.org
    > To: i-d-announce@ietf.org
    > Cc: pwe3@ietf.org
    > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-cbit-negotiation-00.txt
    > Message-ID: <20110415174502.28931.24336.idtracker@ietfc.amsl.com>
    > Content-Type: text/plain; charset="us-ascii"
    >
    > A new Internet-Draft is available from the on-line Internet-Drafts
    > directories.
    > This draft is a work item of the Pseudowire Emulation Edge to Edge
    > Working Group of the IETF.
    >
    >     Title         : Pseudowire Control Word Negotiation Mechanism Update
    >
    >     Author(s)     : V. Manral, et al
    >     Filename      : draft-ietf-pwe3-cbit-negotiation-00.txt
    >     Pages         : 10
    >     Date          : 2011-04-15
    >    
    >    This document describes the problem of control word negotiation
    >    mechanism specified in [RFC4447].  Based on the problem analysis, a
    >    message exchanging mechanism is introduced to solve this control word
    >    negotiation issue.  This document is to update [RFC4447] control word
    >    negotiation mechanism.
    >
    >
    > A URL for this Internet-Draft is:
    > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cbit-negotiation-00.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.
    > 
    --------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
    --=_alternative 001F71CD4825787E_=-- From neil.2.harrison@bt.com Tue Apr 26 01:14:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F850E067C for ; Tue, 26 Apr 2011 01:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfhwJTi23glf for ; Tue, 26 Apr 2011 01:14:32 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id AEA69E067A for ; Tue, 26 Apr 2011 01:14:31 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 26 Apr 2011 09:14:29 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.218]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 26 Apr 2011 09:14:30 +0100 From: To: , Date: Tue, 26 Apr 2011 09:14:31 +0100 Thread-Topic: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gAS8t1A Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44021014C34@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E44021014C34EMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 08:14:37 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E44021014C34EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable George, IMO this is a disaster (on many levels).....see a few remarks in-line: From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: 25 April 2011 22:17 To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. NH=3D> The (access point) addressing of any layer network (whatever the mod= e) is crucial to get right at t=3D0. This has never been properly recognis= ed/appreciated for MPLS (due to its initial symbiotic relationship with a c= l-ps mode IP layer network...BTW IPv4 and IPv6 are very different IP layer = networks), let alone the quite artificial/unnecessary MS PW layer network t= hat has been created (moreover, the initial arch LDP merging problem that f= orced PW labels to assume a source address semantic which is quite the oppo= site of the forwarding (DA proxy) semantic a PW label needed in the MS case= ....see my mail to Matthew Bocci/PWE3 29 Nov 2008 that explains this probl= em in some detail). The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. NH=3D> Hmmm. If MPLS-TP is supposed to be a transport network then it MUST= deliver transparency to its clients. I am not sure many folks in ITU, let= alone IETF, properly understand this from what I have seen. However, MPLS= -TP cannot be transparent as long as it persists in having traditional LSP = sublayering (transport networks only require proper client/server layering = behaviour) and, much worse in many respects, *MS* PWs......no transport net= work worthy of the name generates another form of unnecessary layer network= above it (esp when that layer network was only a product of co-ps mode arc= h violations in a previously spin of MPLS that has to be deprecated in MPLS= -TP). The ITU liaison requests that we allow mixed use. NH=3D> It is only in *public TOS* layer networks that all parties MUST agre= e on a common, well-structured and enduring addressing structure (CF the pr= oblems caused by the small size of v4 addressing in the public Internet, an= d within this the initial Classful structure). This is because one is requ= ired to horizontally partition these layer networks between different opera= ting parties at E-NNIs and so getting the addressing right at the outset is= crucial (it is very hard to change addressing later if its wrong). This c= onsideration does NOT apply to non-TOS layer networks however.....which is = the vast majority of layer network modes/technologies, including all spins = of MPLS and its unnecessary PW layer network spawn. One can, of course, cr= eate such E-NNIs in non-TOS layer networks and thus generate lots of proble= ms/costs....indeed one can do all manner of unnecessary things in networkin= g. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a fair= ly trivial procedure. Many organizations if not most already have AS Numbe= rs. 2. Such an addition will add numerous object formats, and test cases. 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes o= f ICC and Global-ID identification is required, they can be added later. NH=3D> You only (and quite incorrectly) think of peering here. You should = actually only be concerned about true client/server layering too....and thi= s does hold a latent addressing problems wrt misconnectivity which I'll com= e back to shortly. Also note that mixed DP cases of layering and sublayeri= ng are 'not a great idea' and will generate further problems in the peering= case anyway....but as I have noted above, sublayering in a transport netwo= rk is unnecessary. 1. For signaled connections, there is no plan to allow routing based on e= ither the Global-ID or ICC. That would be a radical change to how IP works= . However for IP routing to work (in order to forward the signaling messag= es), the providers involved will need to run BGP and have AS numbers. NH=3D> I see we are still sort-of clinging to the 'common instance of routi= ng' myth here. I think its time to let go of this one now George. The GMP= LS folks had to let go of this a long time ago as its is just plain impossi= ble to have a common instance of routing across all layer networks TOS to B= OS. We are looking for input/consensus from the WG. NH=3D> On what? Agreeing to continue to endorse/promulgate arch and techni= cal errors? Anyway, let me close by noting a new misconnectivity problem that we will n= eed to think about in MPLS-TP. In traditional MPLS one only had intra-laye= r misconnectivity to worry about. However, even this was complicated becau= se: - we had LSP sublayering - we did not have consistent characteristic information (CI) wrt the m= eaning of a MPLS traffic unit header...esp the meaning of its (semantically= overloaded) label field. We should have removed both these problems in MPLS-TP as we were supposed t= o have been designing a transport network. But park that for now. As I noted earlier, THE key service a transport network has to provide to = its clients is client symbol transport transparency...and note carefully th= at this also includes the crucial MPLS-TPoverMPLS-TP case, where MPLS-TP is= now the client. Now the co-ps mode is not like the co-cs mode when considering client/serve= r relationships. In the co-cs case, and due to the physics of how labellin= g and resource partitioning works here, one cannot have XoverX (eg T1overT1= , VC4overVC4, etc). However, one can have XoverX in the co-ps mode. What this means in practice is that we can't have ambiguous cases of nested= client/server CI and inter-layer misconnectivity in the co-cs mode. Howev= er, with bad design we can have these problems in the co-ps mode. So, to cut to the chase, we can now have inter-layer and well as intra-laye= r misconnectivity in MPLS-TP....where the latter intra-layer misconnectivit= y case also retains instances of sublayer misconnectivity. Aside=3D> One c= an also add even more unnecessary TCM OAM sublayering to the mix if one wan= ts....remember, we are dealing with a non-TOS layer network here so all the= se problems are self-inflicted (whether by conscious bad design or ignoranc= e). Now providing one has consistent DP OAM and applies this to *all* connectio= ns within a co-ps mode layer network based on label-swapping (Aside=3D> thi= s is not a problem in a co-ps mode layer network that does not use label-sw= apping) one can mitigate the effects of a lack of consistent CI wrt intra-l= ayer misconnectivity (ie no matter where a DP connection is misdirected the= trail termination point must be able to parse/understand OAM traffic unit = fields). Now when we can also have client/server co-ps mode layering we ne= ed to extend this notion of consistent DP OAM to all the layer networks to = cater for the cases of inter-layer misconnectivity. Note - This is NOT the same problem as TOS layer network E-NNI peering wrt = its implications for access point addressing, ie all parties must agree on = a common/enduring forms of addressing. But we do need to ensure that addre= ssing in each layer network is unique and *well-known to all parties*..as w= e should always be using pukka access point addressing in the CV OAM flows = on *all* such nested layer networks (eg we need to know where any sources o= f misconnectivity we see in our layer network come from). Something else to think about.... regards, Neil Neil Harrison BT Design This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 George, Eric, & Matthew --_000_6D3D47CB84BDE349BC23BF1C94E316E44021014C34EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mixing ICC and Global-IDs in MPLS-TP Identifiers?

    George,

     

    IMO this is a disaster (on many levels).....see a few remarks in-line:

     

     

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow
    Sent: 25 April 2011 22:17
    To: mpls@ietf.org
    Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

     

    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers.

    NH=3D> The (access point) addressing of any layer network (whatever the mode) is crucial to get right at t=3D0.  This has never = been properly recognised/appreciated for MPLS (due to its initial symbiotic relationship with a cl-ps mode IP layer network...BTW IPv4 and IPv6 are ver= y different IP layer networks), let alone the quite artificial/unnecessary MS PW layer network that has been created (moreover, the initial arch LDP merging probl= em that forced PW labels to assume a source address semantic which is quite the opp= osite of the forwarding (DA proxy) semantic a PW label needed in the MS case ....= see my mail to Matthew Bocci/PWE3 29 Nov 2008 that explains this problem in som= e detail).


    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG t= o use either the Global-ID for both ends or or the ICC for both ends.  M= ixed use is not permitted.

    NH=3D> Hmmm.  If MPLS-TP is supposed to be a transpo= rt network then it MUST deliver transparency to its clients.  I am not su= re many folks in ITU, let alone IETF, properly understand this from what I hav= e seen.  However, MPLS-TP cannot be transparent as long as it persists i= n having traditional LSP sublayering (transport networks only require proper client/server layering behaviour) and, much worse in many respects, *MS* PW= s......no transport network worthy of the name generates another form of unnecessary = layer network above it (esp when that layer network was only a product of co-ps m= ode arch violations in a previously spin of MPLS that has to be deprecated in MPLS-T= P).  



    The ITU liaison requests that we allow mixed use.

    NH=3D> It is only in *public TOS* layer networks that all parties MUST agree on a common, well-structured and enduring addressing structure (CF the problems caused by the small size of v4 addressing in the public Internet, and within this the initial Classful structure).  Thi= s is because one is required to horizontally partition these layer networks betw= een different operating parties at E-NNIs and so getting the addressing right a= t the outset is crucial (it is very hard to change addressing later if its wr= ong).  This consideration does NOT apply to non-TOS layer networks however.....whi= ch is the vast majority of layer network modes/technologies, including all spi= ns of MPLS and its unnecessary PW layer network spawn.  One can, of cours= e, create such E-NNIs in non-TOS layer networks and thus generate lots of prob= lems/costs....indeed one can do all manner of unnecessary things in networking.



    The authors of the draft are very reluctant to do this.      <= /o:p>

    1. Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure.  Many organizations if not most already have AS Number= s.
    2. Such an addition will add numerous object formats, and test cases. <= o:p>
    3. The extent inter-provider MPLS-TP is as yet unknown.  If mixed modes = of ICC and Global-ID identification is required, they can be added later.=

    NH=3D> You on= ly (and quite incorrectly) think of peering here.  You should actually only be concerned about true client/server layering too....and this does hold a lat= ent addressing problems wrt misconnectivity which I’ll come back to shortly.  Also note that mixed DP cases of layering and sublayering ar= e ‘not a great idea’ and will generate further problems in the peering case anyway....but as I have noted above, sublayering in a transport network is = unnecessary.

     

    1. For signaled connections, there is no plan to allow routing based on eithe= r the Global-ID or ICC.  That would be a radical change to how IP works.  However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and h= ave AS numbers.

    NH=3D> I see = we are still sort-of clinging to the ‘common instance of routing’ myth here.  I think its time to let go of this one now George.  The GM= PLS folks had to let go of this a long time ago as its is just plain impossible= to have a common instance of routing across all layer networks TOS to BOS.&nbs= p;


    We are looking for input/consensus from the WG.

    NH=3D> On what?  Agreeing to continue to endorse/promulgate arch and technica= l errors?

     

    Anyway, let me close by noting a new misconnectivity problem that we will need to t= hink about in MPLS-TP.  In traditional MPLS one only had intra-layer misconnectivity to worry about.  However, even this was complicated because:

    -      we had LSP sublayering

    -      we did not have consistent characteristic information (CI) wrt the meaning of = a MPLS traffic unit header...esp the meaning of its (semantically overloaded) label field.

     

    We should have removed both these problems in MPLS-TP as we were supposed to h= ave been designing a transport network.  But park that for now.

     

    As I noted earlier, THE  key service a transport network has to provide t= o its clients is client symbol transport transparency...and note carefully th= at this also includes the crucial MPLS-TPoverMPLS-TP case, where MPLS-TP is now the client. 

     

    Now the co-ps mode is not like the co-cs mode when considering client/server relationships.  In the co-cs case, and due to the physics of how label= ling and resource partitioning works here, one cannot have XoverX (eg T1overT1, = VC4overVC4, etc).  However, one can have XoverX in the co-ps mode.

     

    What this means in practice is that we can’t have ambiguous cases of neste= d client/server CI and inter-layer misconnectivity in the co-cs mode.  However, with b= ad design we can have these problems in the co-ps mode. 

     

    So, to cut to the chase, we can now have inter-layer and well as intra-layer misconnectivity in MPLS-TP....where the latter intra-layer misconnectivity = case also retains instances of sublayer misconnectivity.  Aside=3D> One = can also add even more unnecessary TCM OAM sublayering to the mix if one wants....remember, we are dealing with a non-TOS layer network here so all these problems are self-inflicted (whether by conscious bad design or ignorance).

     

    Now providing one has consistent DP OAM and applies this to *all* connections within a co-ps mode layer network based on label-swapping (Aside=3D> thi= s is not a problem in a co-ps mode layer network that does not use label-swappin= g) one can mitigate the effects of a lack of consistent CI wrt intra-layer misconnectivity (ie no matter where a DP connection is misdirected the trai= l termination point must be able to parse/understand OAM traffic unit fields)= .  Now when we can also have client/server co-ps mode layering we need to exte= nd this notion of consistent DP OAM to all the layer networks to cater for the cases of inter-layer misconnectivity. 

     

    Note - This is NOT the same problem as TOS layer network E-NNI peering wrt its i= mplications for access point addressing, ie all parties must agree on a common/enduring forms of addressing.  But we do need to ensure that addressing in each layer network is unique and *well-known to all parties*..as we should alway= s be using pukka access point addressing in the CV OAM flows on *all* such neste= d layer networks (eg we need to know where any sources of misconnectivity we see in= our layer network come from).

     

    Something else to think about....

     

    regards, Neil

     

    Neil Harrison
    BT Design

    This email contains BT information, which may be privileged or confidential.
    It's meant only for the individual(s) or entity named above. If you're not = the intended
    recipient, note that disclosing, copying, distributing or using this information
    is prohibited. If you've received this email in error, please let me know immediately
    on the email address above. Thank you.
    We monitor our email system, and may record your emails.    <= /p>

    British Telecommunications p= lc
    Registered office: 81 Newgate Street London EC1A 7AJ
    Registered in England no: 1800000

     

     

     

     

     

     



    George, Eric, & Matthew

    --_000_6D3D47CB84BDE349BC23BF1C94E316E44021014C34EMV62UKRDdoma_-- From tnadeau@lucidvision.com Tue Apr 26 05:30:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60A1E0726 for ; Tue, 26 Apr 2011 05:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN9hQ3xUlKvv for ; Tue, 26 Apr 2011 05:30:19 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0EDE0715 for ; Tue, 26 Apr 2011 05:30:19 -0700 (PDT) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 52EF51B1AB2A; Tue, 26 Apr 2011 08:30:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-48--903711443 From: Thomas Nadeau In-Reply-To: Date: Tue, 26 Apr 2011 08:30:02 -0400 Message-Id: References: To: George Swallow X-Mailer: Apple Mail (2.1084) Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 12:30:22 -0000 --Apple-Mail-48--903711443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with the authors of the draft and recommend we reject = the liaison request for mixed use. --Tom > All - >=20 > Many of the comments received from the ITU on = draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC = identifiers. >=20 > The identifiers for Tunnel, LSP, PW, and MEG include fields to = identify each end of an LSP. Currently the draft allows a Tunnel, LSP, = PW, or MEG to use either the Global-ID for both ends or or the ICC for = both ends. Mixed use is not permitted. >=20 > The ITU liaison requests that we allow mixed use. >=20 > The authors of the draft are very reluctant to do this. =20 >=20 > Obtaining an AS Number (from which the Global-ID is derived) is a = fairly trivial procedure. Many organizations if not most already have = AS Numbers. > Such an addition will add numerous object formats, and test cases. > The extent inter-provider MPLS-TP is as yet unknown. If mixed modes = of ICC and Global-ID identification is required, they can be added = later. > For signaled connections, there is no plan to allow routing based on = either the Global-ID or ICC. That would be a radical change to how IP = works. However for IP routing to work (in order to forward the = signaling messages), the providers involved will need to run BGP and = have AS numbers.=20 >=20 > We are looking for input/consensus from the WG. >=20 > George, Eric, & Matthew > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-48--903711443 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

    I agree with the authors of the draft and recommend we reject the liaison request for mixed use.

    --Tom


    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends.  Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this.  

    1. Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure.  Many organizations if not most already have AS Numbers.
    2. Such an addition will add numerous object formats, and test cases.
    3. The extent inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID identification is required, they can be added later.
    4. For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC.  That would be a radical change to how IP works.  However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.

    We are looking for input/consensus from the WG.

    George, Eric, & Matthew
    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls

    --Apple-Mail-48--903711443-- From giles.heron@gmail.com Tue Apr 26 06:44:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60C0E072C for ; Tue, 26 Apr 2011 06:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TELK9AWOLK7N for ; Tue, 26 Apr 2011 06:44:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22087E0670 for ; Tue, 26 Apr 2011 06:44:49 -0700 (PDT) Received: by wyb29 with SMTP id 29so539592wyb.31 for ; Tue, 26 Apr 2011 06:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=j+JqxiW4bj5dFrxRgcX2c4DERlM92Gq7mxAdi6h1qNk=; b=k7k4/Qgm8orSSq4W44zYL85Ljsnbcvruqa6kLB2udZ+GSrDtHaSaDrM+uufqhrHZ9P tTKOB5UDd2UCoT1EvDHfTD0uFXWDyMESypfG2pQtQeR4kIeh8pbuCbErh0K0GOH1SWRy 7R8fdV3yeRCdsAQxc4fye2Vr9e7hPH0B+oHNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=XqDkDvR8c1YLVSwIQHH+iY2S7vmWkEmlljQEg4mYSn0ffUMh7hDYgmbZiZxwnY4M6i pbE+NGqXMVMBkQFWmjGlCk5PMGfj9bNCq3qWMqCBL04H8fR/EJZh4WhanLOqMx6A1HXb IDRy0lrSy3ARVhlrngf/AKs9kbSLct0ErQnq4= Received: by 10.227.140.159 with SMTP id i31mr796973wbu.166.1303825489191; Tue, 26 Apr 2011 06:44:49 -0700 (PDT) Received: from [144.254.149.140] (dhcp-144-254-149-140.cisco.com [144.254.149.140]) by mx.google.com with ESMTPS id y29sm3856144wbd.55.2011.04.26.06.44.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 06:44:47 -0700 (PDT) User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 26 Apr 2011 14:45:55 +0100 From: Giles Heron To: Loa Andersson , "mpls@ietf.org" Message-ID: Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AcwEGEPKwVds+10ovUC7gH2h2UbiGA== In-Reply-To: <4DB1706B.3050602@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ross Callon Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:44:51 -0000 support On 22/04/2011 13:11, "Loa Andersson" wrote: > Working Group, > > this is to start a two week poll on making > > draft-asati-pignataro-mpls-ldp-iana-01 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 8th. > > /Loa From giles.heron@gmail.com Tue Apr 26 06:46:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BE7E0738 for ; Tue, 26 Apr 2011 06:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKnnEvbIxFI3 for ; Tue, 26 Apr 2011 06:46:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 345FFE0670 for ; Tue, 26 Apr 2011 06:46:01 -0700 (PDT) Received: by wyb29 with SMTP id 29so540672wyb.31 for ; Tue, 26 Apr 2011 06:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=lHUiA05VgfeYnEPMZ6rd4QJTX1w9mkEb80qLdd5fbl8=; b=LD/Np4RjDoNuFPhyKNNMG3/KYjqtSDzzDC8CnsIZc3dfVvJ2LE0qVwP6xVLnCrCInL HuSgVrg/r8Z6jO+MoxOK7nbHaNbDkWJDE1VDfZMSfVbyP4FxVQp9fDrJLpfS7LsT0ein 8k9BLCLWBSW6Rh3b2QPym5VYxvDOYGgMJ/6/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=Uab/cDA9PrMN5+smWlwAcL+A7HetWkQWH7oFMuCnKrgJKooAM2IF4Qq88vpHXze9si ZrSDCg5omrkvNMAmnf6k20QXJUQC4AiJgg0pgpAypC9q8sX6jp7KLvpW9YxC7HewNK8B XZ0ZHwPG6eHmKCKpWwticXM/hphhQduIOToDU= Received: by 10.216.140.92 with SMTP id d70mr761376wej.105.1303825560147; Tue, 26 Apr 2011 06:46:00 -0700 (PDT) Received: from [144.254.149.140] (dhcp-144-254-149-140.cisco.com [144.254.149.140]) by mx.google.com with ESMTPS id t5sm3028438wes.9.2011.04.26.06.45.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 06:45:58 -0700 (PDT) User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 26 Apr 2011 14:47:04 +0100 From: Giles Heron To: Ross Callon , "mpls@ietf.org" Message-ID: Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQAY9g4O8= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:46:02 -0000 support On 18/04/2011 16:15, "Ross Callon" wrote: > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lavanya.srivatsa@aricent.com Tue Apr 26 06:50:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311FAE0793 for ; Tue, 26 Apr 2011 06:50:38 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh5C7n04tJ9U for ; Tue, 26 Apr 2011 06:50:37 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id 53579E07BE for ; Tue, 26 Apr 2011 06:50:36 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 75CCD36BC2; Tue, 26 Apr 2011 19:16:43 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 5B84936BBA; Tue, 26 Apr 2011 19:16:43 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Tue, 26 Apr 2011 19:20:33 +0530 From: Lavanya Srivatsa To: Lavanya Srivatsa , "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" , "mpls@ietf.org" Date: Tue, 26 Apr 2011 19:20:33 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt Thread-Index: AcvkeK8hutvfRZeXSZymrltxfoQJoAACOzwgAAZzYNADsf3Q8ACZOGDAA5MO6zg= 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_E13C8C03049AFA4E9CEE5A21D3E7F85D0739C28205GUREXMB02ASIA_" MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:50:38 -0000 --_000_E13C8C03049AFA4E9CEE5A21D3E7F85D0739C28205GUREXMB02ASIA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Yacoov, With regards to your below response about FS clear, my question is - what a= bout Manual Switch (MS) clear? Was this also a concious choice to make the = operator revert to Normal from DNR state by using MS also? As per the draft= , MS clear also seems to move to NR instead of DNR for non-revertive operat= ion. Or since MS is of lower priority, should it fall back to default DNR state = only for the non-revertive operation? If so, the draft needs a correction f= or this. Would appreciate your response on this. - Lavanya Scenario 2 Assume that there is a non-revertive protection switching set up between ro= uters R1 and R5 for working LSP1 and protection LSP2. [Sequence of events] Both R1 and R5 in Normal state --> SF on R1 --> SF clear on R1 --> FS on R1= --> FS clear on R1 [Result] Both R1 and R5 going to Normal state with NR(0,0) [Problem] Upon clearing the Forced Switch at R1, it is expected to go local Do-Not-Re= vert state again and begin transmitting DNR(0,1). Upon receiving this R5 is= expected to go to remote Do-Not-Revert state. yw> I do not agree that the domain should transition back to DNR state once= the operator did a Forced Switch he means to go back to Normal. In a prev= ious version of the draft we presented two possibilities of reverting to No= rmal from DNR state (either use an explicit Clear command or use FS) and th= e use of FS was chosen. So this is the very scenario that allows the opera= tor to revert back to Normal from DNR state. [LS] If this has been a conscious decision to switch back to working for a = non-revertive protection, then fine, I agree. [Suggested Solution] In Section 4.3.3.3, the 1st bullet item under local input needs to be modif= ied as - "A local Clear SHOULD be ignored if in remote Protecting administr= ative state. If in local Protecting administrative state then this input S= HALL cause the LER to go into Normal state and begin transmitting a NR(0,0)= message if in revertive mode or go into Do-Not-Revert state and begin tran= smitting DNR(0,1) if in non-revertive mode. ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_E13C8C03049AFA4E9CEE5A21D3E7F85D0739C28205GUREXMB02ASIA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hello Yacoov,
     
    With regards to your below response about F= S clear, my question is - what about Manual Switch (MS) clear? Was this als= o a concious choice to make the operator revert to Normal from DNR state by using MS also? As per the draft, MS cle= ar also seems to move to NR instead of DNR for non-revertive operation.
    Or since MS is of lower priority, shou= ld it fall back to default DNR state only for the non-revertive operation? = If so, the draft needs a correction for this.
     
    Would appreciate your response on this.
     
    - Lavanya
     
    Scenario 2

    Assume that there is a&n= bsp;non-revertive protection switching set up between routers R1 and R5 for= working LSP1 and protection LSP2.

     

    [Sequence of events]

    Both R1 and R5 in Normal state =E0= SF on R1 =E0= SF clear on R1 =E0= FS on R1 =E0= FS clear on R1

    [Result]

    Both R1 and R5 going to Normal state with NR(0,0)

    [Problem]

    Upon clearing the Forced Switch at R1, it is expected to go local Do-No= t-Revert state again and begin transmitting DNR(0,1). Upon receiving this R5 is expected to go to remote Do-Not-Revert= state.

     

    yw> I do not agree that the domain should transition back to D= NR state once the operator did a Forced Switch he means to go back to Normal.  In a previous version of the draft we= presented two possibilities of reverting to Normal from DNR state (either = use an explicit Clear command or use FS) and the use of FS was chosen. &nbs= p;So this is the very scenario that allows the operator to revert back to Normal from DNR state.

    [Suggested Solution]

    In Section 4.3.3.3, the 1st bullet item under local input needs to= be modified as - "A local Clear SHOULD be ignored if in remote Protecting administrative state.  If in local Protecting= administrative state then this input SHALL cause the LER to go into Normal= state and begin transmitting a NR(0,0) message if in revertive mode or go = into Do-Not-Revert state and begin transmitting DNR(0,1) if in non-revertive mode.

     


    "DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
     --_000_E13C8C03049AFA4E9CEE5A21D3E7F85D0739C28205GUREXMB02ASIA_-- From jdrake@juniper.net Tue Apr 26 12:35:09 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043DCE0763 for ; Tue, 26 Apr 2011 12:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JJ0RY4u6J28 for ; Tue, 26 Apr 2011 12:35:08 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 26814E0800 for ; Tue, 26 Apr 2011 12:35:08 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTbceap1tvV7bZ1eS5GfX9rKhYDVJ1hgh@postini.com; Tue, 26 Apr 2011 12:35:08 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 26 Apr 2011 12:34:41 -0700 From: John E Drake To: George Swallow , "mpls@ietf.org" Date: Tue, 26 Apr 2011 12:34:40 -0700 Thread-Topic: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gAuli7g Message-ID: <5E893DB832F57341992548CDBB333163A09766AA56@EMBX01-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: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A09766AA56EMBX01HQjnprn_" MIME-Version: 1.0 Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 19:35:09 -0000 --_000_5E893DB832F57341992548CDBB333163A09766AA56EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable George, I agree that mixed use identifiers do not make sense, for the reasons both = you and Neil cite. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: Monday, April 25, 2011 2:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a fair= ly trivial procedure. Many organizations if not most already have AS Numbe= rs. 2. Such an addition will add numerous object formats, and test cases. 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes o= f ICC and Global-ID identification is required, they can be added later. 4. For signaled connections, there is no plan to allow routing based on e= ither the Global-ID or ICC. That would be a radical change to how IP works= . However for IP routing to work (in order to forward the signaling messag= es), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew --_000_5E893DB832F57341992548CDBB333163A09766AA56EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mixing ICC and Global-IDs in MPLS-TP = Identifiers?

    George,

     

    I agree that mixed use identifiers do not make= sense, for the reasons both you and Neil  cite.

    =

     

    Thanks,

    &nbs= p;

    John

    <= p class=3DMsoNormal> 

    Sent from my iPhone

     

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beha= lf Of George Swallow
    Sent: Monday, April 25, 2011 2:17 PM
    = To: mpls@ietf.org
    Subject: [mpls] Mixing ICC and Global-ID= s in MPLS-TP Identifiers?

     

    All = -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-i= dentifiers-04 have to do with the Global and ICC identifiers.

    The id= entifiers for Tunnel, LSP, PW, and MEG include fields to identify each end = of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to us= e either the Global-ID for both ends or or the ICC for both ends.  Mix= ed use is not permitted.

    The ITU liaison requests that we allow mixe= d use.

    The authors of the draft are very reluctant to do this.  = ;

    1. Ob= taining an AS Number (from which the Global-ID is derived) is a fairly triv= ial procedure.  Many organizations if not most already have AS Numbers= .
    2. Such an addition will add= numerous object formats, and test cases.
    3. The extent inter-provider MPLS-TP is as yet unknown.  = If mixed modes of ICC and Global-ID identification is required, they can be= added later.
    4. For signaled = connections, there is no plan to allow routing based on either the Global-I= D or ICC.  That would be a radical change to how IP works.  Howev= er for IP routing to work (in order to forward the signaling messages), the= providers involved will need to run BGP and have AS numbers. <= /o:p>


    We are looking for input/consensus from th= e WG.

    George, Eric, & Matthew

    = = --_000_5E893DB832F57341992548CDBB333163A09766AA56EMBX01HQjnprn_-- From autumn.liu@ericsson.com Tue Apr 26 17:21:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B25E0690 for ; Tue, 26 Apr 2011 17:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRl+DKqIP2re for ; Tue, 26 Apr 2011 17:21:49 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id C3A64E068D for ; Tue, 26 Apr 2011 17:21:49 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3R0LkuQ007048; Tue, 26 Apr 2011 19:21:47 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.12]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 26 Apr 2011 20:21:40 -0400 From: Autumn Liu To: Giles Heron , Ross Callon , "mpls@ietf.org" Date: Tue, 26 Apr 2011 20:21:39 -0400 Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQAY9g4O8AFibvUA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD521AFABB1B@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 00:21:50 -0000 Support. -Autumn > All, >=20 > this is to start a two week working group poll on whether to make=20 > draft-kompella-mpls-entropy-label an mpls wg document. >=20 > Please send your comments to the mpls@ietf.org mailing list. >=20 > The poll ends on May 3rd. >=20 > thanks Ross (as WG co-chair) > _______________________________________________ > 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 autumn.liu@ericsson.com Tue Apr 26 17:22:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7955CE06B5 for ; Tue, 26 Apr 2011 17:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wguwMmcXSSUo for ; Tue, 26 Apr 2011 17:22:32 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id DC9B6E0680 for ; Tue, 26 Apr 2011 17:22:31 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3R0M6JA016849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Apr 2011 19:22:29 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.12]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 26 Apr 2011 20:22:24 -0400 From: Autumn Liu To: Giles Heron , Loa Andersson , "mpls@ietf.org" Date: Tue, 26 Apr 2011 20:22:23 -0400 Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AcwEGEPKwVds+10ovUC7gH2h2UbiGAAWOIVA Message-ID: <60C093A41B5E45409A19D42CF7786DFD521AFABB1C@EUSAACMS0703.eamcs.ericsson.se> References: <4DB1706B.3050602@pi.nu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 00:22:32 -0000 =20 Support -Autumn > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-asati-pignataro-mpls-ldp-iana-01 >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document please=20 > respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group document=20 > please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are not=20 > supporting the document. >=20 > If you have technical comments or in any other way want to discuss the=20 > document, please send these comments to the mpls working group mailing=20 > list, but with another subject than what is on this mail. >=20 > The poll ends May 8th. >=20 > /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From autumn.liu@ericsson.com Tue Apr 26 17:24:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B13E06B5 for ; Tue, 26 Apr 2011 17:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOXHpaGUY+nL for ; Tue, 26 Apr 2011 17:24:08 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3FE068D for ; Tue, 26 Apr 2011 17:24:07 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3R0O6T0016937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Apr 2011 19:24:06 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.12]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 26 Apr 2011 20:24:05 -0400 From: Autumn Liu To: Thomas Nadeau , George Swallow Date: Tue, 26 Apr 2011 20:24:04 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwEDdiC239W5mXVSx6aINRvFZSICQAY4IlQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD521AFABB1D@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD521AFABB1DEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 00:24:08 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD521AFABB1DEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 -Autumn ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Tho= mas Nadeau Sent: Tuesday, April 26, 2011 5:30 AM To: George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? I agree with the authors of the draft and recommend we reject the liaison r= equest for mixed use. --Tom All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a fair= ly trivial procedure. Many organizations if not most already have AS Numbe= rs. 2. Such an addition will add numerous object formats, and test cases. 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes o= f ICC and Global-ID identification is required, they can be added later. 4. For signaled connections, there is no plan to allow routing based on e= ither the Global-ID or ICC. That would be a radical change to how IP works= . However for IP routing to work (in order to forward the signaling messag= es), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_60C093A41B5E45409A19D42CF7786DFD521AFABB1DEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    +1
     
    -Autumn

    From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Thomas Nadeau
    Sent= :=20 Tuesday, April 26, 2011 5:30 AM
    To: George Swallow
    Cc:= =20 mpls@ietf.org
    Subject: Re: [mpls] Mixing ICC and Global-IDs in MP= LS-TP=20 Identifiers?


    I=20 agree with the authors of the draft and recommend we reject the liaison req= uest=20 for mixed use.

    --Tom


    All -

    Many of the comments received from= the=20 ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and I= CC=20 identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include= =20 fields to identify each end of an LSP.  Currently the draft allows a= =20 Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or t= he=20 ICC for both ends.  Mixed use is not permitted.

    The ITU liais= on=20 requests that we allow mixed use.

    The authors of the draft are ver= y=20 reluctant to do this.  
    1. Obtaining an AS Number (from which the Global= -ID is=20 derived) is a fairly trivial procedure.  Many organizations if not= most=20 already have AS Numbers.
    2. Such an addition will add numerous object for= mats,=20 and test cases.
    3. The extent inter-provider MPLS-TP is as yet u= nknown.=20  If mixed modes of ICC and Global-ID identification is required, t= hey=20 can be added later.
    4. For signaled connections, there is no plan to= allow=20 routing based on either the Global-ID or ICC.  That would be a rad= ical=20 change to how IP works.  However for IP routing to work (in order = to=20 forward the signaling messages), the providers involved will need to ru= n BGP=20 and have AS numbers.=20

    We=20 are looking for input/consensus from the WG.

    George, Eric, &=20 Matthew    =20
    _______________________________________________
    mpls mailing=20 list
    mpls@ietf.org
    https://www.ietf.org/m= ailman/listinfo/mpls

    --_000_60C093A41B5E45409A19D42CF7786DFD521AFABB1DEUSAACMS0703e_-- From xiao.min2@zte.com.cn Tue Apr 26 18:03:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7253CE074E; Tue, 26 Apr 2011 18:03:48 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04dEhzgcG09c; Tue, 26 Apr 2011 18:03:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 36512E0684; Tue, 26 Apr 2011 18:03:47 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 125201784411434; Wed, 27 Apr 2011 09:02:32 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 4886.1937000543; Wed, 27 Apr 2011 09:03:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3R13XBK001387; Wed, 27 Apr 2011 09:03:33 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) In-Reply-To: To: Ross Callon MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: xiao.min2@zte.com.cn Date: Wed, 27 Apr 2011 09:01:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-27 09:03:34, Serialize complete at 2011-04-27 09:03:34 Content-Type: multipart/alternative; boundary="=_alternative 00059BAA4825787F_=" X-MAIL: mse02.zte.com.cn p3R13XBK001387 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 01:03:48 -0000 This is a multipart message in MIME format. --=_alternative 00059BAA4825787F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQuDQoNCi0gWGlhbyBNaW4NCg0KDQoNCg0KUm9zcyBDYWxsb24gPHJjYWxsb25A anVuaXBlci5uZXQ+IA0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoyMDExLzA0LzE4 IDIzOjE1DQoNCsrVvP7Iyw0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0Ks63LzQ0K DQrW98ziDQpbbXBsc10gcG9sbCBvbiBkcmFmdC1rb21wZWxsYS1tcGxzLWVudHJvcHktbGFiZWwg YXMgTVBMUyBXRyBkb2N1bWVudA0KDQoNCg0KDQoNCg0KQWxsLA0KDQp0aGlzIGlzIHRvIHN0YXJ0 IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBwb2xsIG9uIHdoZXRoZXIgdG8gbWFrZQ0KZHJhZnQt a29tcGVsbGEtbXBscy1lbnRyb3B5LWxhYmVsIGFuIG1wbHMgd2cgZG9jdW1lbnQuDQoNClBsZWFz ZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHNAaWV0Zi5vcmcgbWFpbGluZyBsaXN0Lg0K DQpUaGUgcG9sbCBlbmRzIG9uIE1heSAzcmQuIA0KDQp0aGFua3MgUm9zcyAoYXMgV0cgY28tY2hh aXIpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBs cyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KDQoNCg0K --=_alternative 00059BAA4825787F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy9TdXBwb3J0LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LSBYaWFvIE1pbjwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5S b3NzIENhbGxvbiAmbHQ7cmNhbGxvbkBqdW5pcGVyLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBscy1ib3VuY2Vz QGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEv MDQvMTggMjM6MTU8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZn dDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlttcGxzXSBwb2xsIG9uIGRyYWZ0LWtvbXBlbGxhLW1wbHMtZW50cm9weS1sYWJlbA0KYXMg TVBMUyBXRyBkb2N1bWVudDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9Mj48dHQ+QWxsLDxicj4NCjxicj4NCnRoaXMgaXMgdG8gc3RhcnQgYSB0d28g d2VlayB3b3JraW5nIGdyb3VwIHBvbGwgb24gd2hldGhlciB0byBtYWtlPGJyPg0KZHJhZnQta29t cGVsbGEtbXBscy1lbnRyb3B5LWxhYmVsIGFuIG1wbHMgd2cgZG9jdW1lbnQuPGJyPg0KPGJyPg0K UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBsc0BpZXRmLm9yZyBtYWlsaW5nIGxp c3QuPGJyPg0KPGJyPg0KVGhlIHBvbGwgZW5kcyBvbiBNYXkgM3JkLiA8YnI+DQo8YnI+DQp0aGFu a3MgUm9zcyAoYXMgV0cgY28tY2hhaXIpPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0 Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+ DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 00059BAA4825787F_=-- From loa@pi.nu Tue Apr 26 19:06:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08E0E072B for ; Tue, 26 Apr 2011 19:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTEGh+MTmBYe for ; Tue, 26 Apr 2011 19:06:31 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0036EE078F for ; Tue, 26 Apr 2011 19:06:30 -0700 (PDT) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 57EBB2A8001; Wed, 27 Apr 2011 04:06:29 +0200 (CEST) Received: from 129.192.170.250 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Wed, 27 Apr 2011 04:06:29 +0200 Message-ID: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Date: Wed, 27 Apr 2011 04:06:29 +0200 From: loa@pi.nu To: mpls@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 02:06:31 -0000 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa From rajiva@cisco.com Tue Apr 26 19:36:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E522E067B for ; Tue, 26 Apr 2011 19:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78FcKsqy-j1r for ; Tue, 26 Apr 2011 19:36:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCF8E062A for ; Tue, 26 Apr 2011 19:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1239; q=dns/txt; s=iport; t=1303871801; x=1305081401; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mjsA7hQhhLqRx6G6YfvN59yzeEL0uJyT68AkFbIq7PE=; b=HZa0BiYf3XW9z/oQfid93+r/+kITXt5fsL1mDEYBZSl7ioTSEFO1jkKa ys9C7YnIncVkvGPGKKFTqSCLGVPduw7uxE+DWS7Vmv84DtHQD4jTdLbk7 SKkm9SDUyoBcUOGlZJ0FdCa9gFiGKYQSyMA9/VXYYRJ1xYxnMW5kPL+s+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioBADSAt02tJV2Z/2dsb2JhbACXfY1td6kJnHKFdgSFf4xhii4 X-IronPort-AV: E=Sophos;i="4.64,272,1301875200"; d="scan'208";a="436969718" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 02:36:41 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3R2aeLT000734; Wed, 27 Apr 2011 02:36:40 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 21:36:40 -0500 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: Tue, 26 Apr 2011 21:36:38 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C04C9B557@XMB-RCD-111.cisco.com> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf8f45eroZnoXQkOju9SeUku9eAABAbaA References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> From: "Rajiv Asati (rajiva)" To: , X-OriginalArrivalTime: 27 Apr 2011 02:36:40.0279 (UTC) FILETIME=[F0207E70:01CC0483] Cc: rcallon@juniper.net Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 02:36:42 -0000 Support. Cheers, Rajiv =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Tuesday, April 26, 2011 10:06 PM > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-leymann-mpls-seamless-mpls-03 >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document > please respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. >=20 > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. >=20 > The poll ends May 10th. >=20 > /Loa >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From wim.henderickx@alcatel-lucent.com Tue Apr 26 19:48:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC8EE0680 for ; Tue, 26 Apr 2011 19:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7zsr8-HWnCY for ; Tue, 26 Apr 2011 19:48:30 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 13D9AE062A for ; Tue, 26 Apr 2011 19:48:29 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3R2mSPA013719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Apr 2011 04:48:28 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 27 Apr 2011 04:48:28 +0200 From: "Henderickx, Wim (Wim)" To: "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 27 Apr 2011 04:48:25 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf753JWsxE6f4S4WgfzkdcKIV5wABdRQA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6718D90F47@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 02:48:31 -0000 yes/support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa= @pi.nu Sent: woensdag 27 april 2011 4:06 To: mpls@ietf.org Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Tue Apr 26 20:04:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCD0E0682 for ; Tue, 26 Apr 2011 20:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vOOwrYKnxbw for ; Tue, 26 Apr 2011 20:04:27 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 52C08E062A for ; Tue, 26 Apr 2011 20:04:27 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKA00HFZJ780W@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 27 Apr 2011 11:04:21 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKA006BDJ75OM@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 27 Apr 2011 11:04:20 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Apr 2011 11:02:57 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Wed, 27 Apr 2011 11:04:18 +0800 Date: Wed, 27 Apr 2011 03:03:39 +0000 From: Mach Chen In-reply-to: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> X-Originating-IP: [10.110.98.38] To: "loa@pi.nu" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-index: AQHMBIAbgCF/DaHx3UaEglAXX00ULZRxBnnw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 03:04:28 -0000 Yes/support. Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Wednesday, April 27, 2011 10:06 AM > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 > > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From malcolm.betts@zte.com.cn Tue Apr 26 21:05:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A5DE0686 for ; Tue, 26 Apr 2011 21:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.538 X-Spam-Level: X-Spam-Status: No, score=-101.538 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv440LKHbav4 for ; Tue, 26 Apr 2011 21:04:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A78B8E0685 for ; Tue, 26 Apr 2011 21:04:58 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12520806486374; Wed, 27 Apr 2011 12:03:32 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 74049.1060984407; Wed, 27 Apr 2011 11:53:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3R44mGI073106; Wed, 27 Apr 2011 12:04:48 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: To: George Swallow MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 27 Apr 2011 00:04:43 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-27 12:04:48, Serialize complete at 2011-04-27 12:04:48 Content-Type: multipart/alternative; boundary="=_alternative 001668BE8525787F_=" X-MAIL: mse01.zte.com.cn p3R44mGI073106 Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 04:05:00 -0000 This is a multipart message in MIME format. --=_alternative 001668BE8525787F_= Content-Type: text/plain; charset="US-ASCII" George, I do not agree the proposed resolution of this comment. As stated in the draft allows an operator can select the use of either Global (IP) or ICC based identifiers. Insisting that both ends of a LSP or PW must use the same scheme removes the freedom to select the between ICC and Global (IP) identifiers. MPLS-TP requires that the data plane and control plane are independent, including having independent identifiers. The draft describes the mapping between the GMPLS identifiers used by the control plane and the data plane identifiers. >From the perspective of the data plane an identifier is inserted at the source and received by the sink. Neither the source or sink need to understand the semantics of the identifier, all a sink needs to, for example, to verify connectivity is to check that the received identifier string matches the expected identifier string. Please see in-line below. Regards, Malcolm George Swallow Sent by: mpls-bounces@ietf.org 25/04/2011 05:16 PM To cc Subject [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends. Mixed use is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure. Many organizations if not most already have AS Numbers. [MB] Many organizations already have process in place to use ICC based identifiers for the data plane changing to IP based identifiers would be a major burden. 2. Such an addition will add numerous object formats, and test cases. [MB] Why - the data plane does not need to interpret the string, just check that it matches the expected string 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes of ICC and Global-ID identification is required, they can be added later. [MB] This would be a major roadblock to the use of MPLS-TP in an inter provider transport network 4. For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC. That would be a radical change to how IP works. However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers. [MB] The control plane identifiers must be independent of the data plane identifiers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 001668BE8525787F_= Content-Type: text/html; charset="US-ASCII"
    George,

    I do not agree the proposed resolution of this comment.  As stated in the draft allows an operator can select the use of either Global (IP) or ICC based identifiers.  Insisting that both ends of a LSP or PW must use the same scheme removes the freedom to select the between ICC and Global (IP) identifiers.

    MPLS-TP requires that the data plane and control plane are independent, including having independent identifiers.  The draft describes the mapping between the GMPLS identifiers used by the control plane and the data plane identifiers.

    From the perspective of the data plane an identifier is inserted at the source and received by the sink.  Neither the source or sink need to understand the semantics of the identifier, all a sink needs to, for example, to verify connectivity is to check that the received identifier string matches the expected identifier string.

    Please see in-line below.

    Regards,

    Malcolm




    George Swallow <swallow@cisco.com>
    Sent by: mpls-bounces@ietf.org

    25/04/2011 05:16 PM

    To
    		<mpls@ietf.org>
    cc
    Subject
    		[mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?





    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends.  Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this.  
    1.        Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure.  Many organizations if not most already have AS Numbers.
    [MB] Many organizations already have process in place to use ICC based identifiers for the data plane changing to IP based identifiers would be a major burden.
    2.        Such an addition will add numerous object formats, and test cases.
    [MB]  Why - the data plane does not need to interpret the string, just check that it matches the expected string
    3.        The extent inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID identification is required, they can be added later.
    [MB]  This would be a major roadblock to the use of MPLS-TP in an inter provider transport network
    4.        For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC.  That would be a radical change to how IP works.  However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.
    [MB] The control plane identifiers must be independent of the data plane identifiers.

    We are looking for input/consensus from the WG.

    George, Eric, & Matthew     _______________________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls
    --=_alternative 001668BE8525787F_=-- From jie.dong@huawei.com Tue Apr 26 21:10:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5DE0696 for ; Tue, 26 Apr 2011 21:10:39 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6CPAhAhJoki for ; Tue, 26 Apr 2011 21:10:38 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9B2E0686 for ; Tue, 26 Apr 2011 21:10:38 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKA005RTM7AAU@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 27 Apr 2011 12:09:10 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKA001MCM78LU@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 27 Apr 2011 12:09:10 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Apr 2011 12:09:09 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.8.154]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 27 Apr 2011 12:09:08 +0800 Date: Wed, 27 Apr 2011 04:09:07 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [10.110.98.34] To: Ross Callon , "mpls@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927AFDBBA@szxeml508-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQAa13pGA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 04:10:39 -0000 Support Jie > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Ross Callon > Sent: Monday, April 18, 2011 11:16 PM > To: mpls@ietf.org > Subject: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG > document > > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nurit.sprecher@nsn.com Tue Apr 26 22:44:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDCE06B8 for ; Tue, 26 Apr 2011 22:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.413 X-Spam-Level: X-Spam-Status: No, score=-4.413 tagged_above=-999 required=5 tests=[AWL=2.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFH6ofHp5ua2 for ; Tue, 26 Apr 2011 22:44:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 78200E06A2 for ; Tue, 26 Apr 2011 22:43:56 -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 p3R5hqgb023534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 07:43:52 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3R5hq3n015727; Wed, 27 Apr 2011 07:43:52 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 07:43:51 +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_01CC049E.16282301" Date: Wed, 27 Apr 2011 07:43:49 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403B78D19@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwEkFD+3bpWw8NWSZaLr0HER0O/HQADN3yw References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , "George Swallow" X-OriginalArrivalTime: 27 Apr 2011 05:43:51.0281 (UTC) FILETIME=[16536610:01CC049E] Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 05:44:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC049E.16282301 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think such mixing environment requires more study. We need to better understand the applicability and the implications on all components and planes... When such a mixing environment is completely analyzed and understood, if needed can be added in a later phase.=20 IMO, in the meantime the document should both ICC OR IP environments, with no mixing identifiers.=20 Best regards, Nurit =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Malcolm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 7:05 AM To: George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 George,=20 I do not agree the proposed resolution of this comment. As stated in the draft allows an operator can select the use of either Global (IP) or ICC based identifiers. Insisting that both ends of a LSP or PW must use the same scheme removes the freedom to select the between ICC and Global (IP) identifiers.=20 MPLS-TP requires that the data plane and control plane are independent, including having independent identifiers. The draft describes the mapping between the GMPLS identifiers used by the control plane and the data plane identifiers.=20 >From the perspective of the data plane an identifier is inserted at the source and received by the sink. Neither the source or sink need to understand the semantics of the identifier, all a sink needs to, for example, to verify connectivity is to check that the received identifier string matches the expected identifier string.=20 Please see in-line below.=20 Regards,=20 Malcolm=20 George Swallow =20 Sent by: mpls-bounces@ietf.org=20 25/04/2011 05:16 PM=20 To =20 cc =09 Subject [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 =09 All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends. Mixed use is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. =20 1. Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure. Many organizations if not most already have AS Numbers.=20 [MB] Many organizations already have process in place to use ICC based identifiers for the data plane changing to IP based identifiers would be a major burden.=20 2. Such an addition will add numerous object formats, and test cases.=20 [MB] Why - the data plane does not need to interpret the string, just check that it matches the expected string=20 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes of ICC and Global-ID identification is required, they can be added later.=20 [MB] This would be a major roadblock to the use of MPLS-TP in an inter provider transport network=20 4. For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC. That would be a radical change to how IP works. However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.=20 [MB] The control plane identifiers must be independent of the data plane identifiers.=20 We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01CC049E.16282301 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi,

    I think such mixing environment requires more study. We need to = better understand the applicability and the implications on all = components and planes…

    When such a mixing environment is completely analyzed and understood, = if needed can be added in a later phase.

    IMO, in the meantime the document should both ICC OR IP environments, = with no mixing identifiers.

    Best regards,

    Nurit

     

    From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Malcolm.BETTS@zte.com.cn
    Sent: Wednesday, April 27, = 2011 7:05 AM
    To: George Swallow
    Cc: = mpls@ietf.org
    Subject: Re: [mpls] Mixing ICC and Global-IDs in = MPLS-TP Identifiers?

     


    George,

    I do not = agree the proposed resolution of this comment.  As stated in the = draft allows an operator can select the use of either Global (IP) or ICC = based identifiers.  Insisting that both ends of a LSP or PW must = use the same scheme removes the freedom to select the between ICC and = Global (IP) identifiers.

    MPLS-TP = requires that the data plane and control plane are independent, = including having independent identifiers.  The draft describes the = mapping between the GMPLS identifiers used by the control plane and the = data plane identifiers.

    From the = perspective of the data plane an identifier is inserted at the source = and received by the sink.  Neither the source or sink need to = understand the semantics of the identifier, all a sink needs to, for = example, to verify connectivity is to check that the received identifier = string matches the expected identifier string.

    Please see = in-line below.

    Regards,

    Malcolm



    George = Swallow <swallow@cisco.com> =
    Sent by: = mpls-bounces@ietf.org

    25/04/2011 = 05:16 PM

    To=

    <mpls@ietf.= org>

    cc=

    Subject=

    [mpls] Mixing = ICC and Global-IDs in MPLS-TP = Identifiers?

     




    All = -

    Many of the comments received from the ITU on = draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC = identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include = fields to identify each end of an LSP.  Currently the draft allows = a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or = or the ICC for both ends.  Mixed use is not permitted.

    The = ITU liaison requests that we allow mixed use.

    The authors of the = draft are very reluctant to do this.  

    1.   =      Obtaining = an AS Number (from which the Global-ID is derived) is a fairly trivial = procedure.  Many organizations if not most already have AS = Numbers.
    [MB] Many = organizations already have process in place to use ICC based identifiers = for the data plane changing to IP based identifiers would be a major = burden.
    2.   =      Such an = addition will add numerous object formats, and test cases. =
    [MB] =  Why - the data plane does not need to interpret the string, just = check that it matches the expected string
    3.   =      The extent = inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC = and Global-ID identification is required, they can be added later. =
    [MB] =  This would be a major roadblock to the use of MPLS-TP in an inter = provider transport network
    4.   =      For = signaled connections, there is no plan to allow routing based on either = the Global-ID or ICC.  That would be a radical change to how IP = works.  However for IP routing to work (in order to forward the = signaling messages), the providers involved will need to run BGP and = have AS numbers.
    [MB] The = control plane identifiers must be independent of the data plane = identifiers.

    We are = looking for input/consensus from the WG.

    George, Eric, & = Matthew     ______________________________________________= _
    mpls mailing = list
    mpls@ietf.org
    https://www.ietf.org/mailman/l= istinfo/mpls

    ------_=_NextPart_001_01CC049E.16282301-- From lieven.levrau@alcatel-lucent.com Tue Apr 26 23:02:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676D0E06A2 for ; Tue, 26 Apr 2011 23:02:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF+8YGwpwsZ2 for ; Tue, 26 Apr 2011 23:02:04 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id F27FDE06AF for ; Tue, 26 Apr 2011 23:02:03 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3R61wue006948 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Apr 2011 08:01:59 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 27 Apr 2011 08:01:58 +0200 From: "LEVRAU, LIEVEN (LIEVEN)" To: "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 27 Apr 2011 08:01:56 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEoJ3RkkIZSbPcQduOCv6k4N9UKA== Message-ID: In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 06:02:08 -0000 Yes/support On 27/04/11 04:06, "loa@pi.nu" wrote: > >Working Group, > >this is to start a two week poll on making > >draft-leymann-mpls-seamless-mpls-03 > >an mpls working group document. > >If you support the document becoming a working group document >please respond to this poll with "yes/support" > >If you do not support the document becoming a working group >document please respond to this poll with "no/do not support" >and at the same time give the technical reasons why you are >not supporting the document. > >If you have technical comments or in any other way want to >discuss the document, please send these comments to the mpls >working group mailing list, but with another subject than what >is on this mail. > >The poll ends May 10th. > >/Loa > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Tue Apr 26 23:06:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BADE06B8 for ; Tue, 26 Apr 2011 23:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W040CIUVLc5p for ; Tue, 26 Apr 2011 23:06:09 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 170B5E06AD for ; Tue, 26 Apr 2011 23:06:07 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-fa-4db7b1eaf4a6 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 07.18.02691.AE1B7BD4; Wed, 27 Apr 2011 09:04:26 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 27 Apr 2011 09:06:05 +0300 From: Alexander Vainshtein To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "Malcolm.BETTS@zte.com.cn" Date: Wed, 27 Apr 2011 09:06:03 +0300 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwEkFD+3bpWw8NWSZaLr0HER0O/HQADN3ywAADM/kA= Message-ID: References: <077E41CFFD002C4CAB7DFA4386A5326403B78D19@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326403B78D19@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_A3C5DF08D38B6049839A6F553B331C76D722FE27B3ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURjt7szujubEuGZ7kx7LREKPtV0r2MqVKKyVkISeFJHj7nV3aHd2 mZkig8hKs5TKahFdCTU2rRRNEa3saS8yKREKSy3KHmYRZA8rQ5tx0oTo/jr3O+d+53D5PgLT lWqjCJYTEc8xbloTip/o7fti7K1pSDK9qYqwZOe81lqenj6rtnQ8b9BaOvz7wFLc5h+oUduC wR8q24/qR1pb5dXveDK+KQPEMRznFRkRGRxIsFvpZJ7dwdjTaQPrsNJm2uBzM3bkQZxopRmf D3EOOj7U8M+Jk2QsZ0Cc3etgOaeVTlyz2mixLFxkNNPx0TPM85eErnWxggEZPQzrNniQIDBO ZJAqKXWY6+K+y7ivMx/s9Be8xTPAz/0gB4QQkFoAH2c1/8GTYOuzak0OCCV0VCOAn4++B8ol H8Cb9/fiskpDWWFtRZdGxhOpPfB85nG1jDFqJczt9g9jnJoJg2/rhvURVAIszr2rUvQr4LdT 5WoFL4YnD7cM10lqNXyZV4ArZlcAvHf/DiYTIVQyHGi7PRwPSPH6mytVipkePn1VrFJiUzB4 +SGm4Ej4rntQregjYWd2NVD0Xtg38ABTzMLhvcJXuKKfDG+cacfzwKTAmLaBMU8CY54o9bmw pLFPo+A5sKz0PTaCW653q8bWS4D2HIhk3T4x1eM0xcYgOysiN4qxez21QJmpngugo2VWE6AI QIeRGxc1JOnUzA4h3dMEJhMqOpJMk0ZONyHV60h3MYJrK7/djYQmAAmMnkg2lEsc6WDSdyHe O0IlSN9/DIsab/dK08uJW+ebTP+/0HryY0owSUc5penchpAP8SN9phAEDcka2T6cR060M411 i39pFREixwiTYhTKGlLwMR6BdSp8MzASXbVF14AO57wcitKTV2QRJYtc27nRPvJm7RkaGuoF eukDIsgCWRUm7d1op17JRCWZFP+ql02kLRqlojLAXLst7YDJ3bp7Q6DsY0n09OUvB2zLNjvX D47je24Xxvw0vdlyJHN31sx1U+O/NrX1F2Wfb8/8MHSwTZzG9VvzVsWlfgvMMq7La499kHsr sfFST3vIJ3/9rcKUugo+9lBEbVfntHmLY79/MFuSEgZffG69VrXcXFHSberXl86of6Kbl0Xj gosxz8Z4gfkNoVJrHDQEAAA= Cc: "mpls@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 06:06:13 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D722FE27B3ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Malcolm, Nurit and all, One technical reason for not mixing identifiers of different types is that i= n certain situations these identifiers are treated as an ordered set, i.e.,= it is possible to say when one of these identifiers is "less" than the othe= r one. The typical use case is tie-breaking in various protocols (e.g., for decidin= g which request for a protection-related has to be granted). Even if the cur= rent set of MPLS-TP protocols does not use such tie-breakers, I would not pr= eclude this usage in future. It is relatively simple to impose some order on identifiers of the same type= . Imposing an order on a superset of identifiers at least requires some thou= ght. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spre= cher, Nurit (NSN - IL/Hod HaSharon) Sent: Wednesday, April 27, 2011 8:44 AM To: Malcolm.BETTS@zte.com.cn; George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi, I think such mixing environment requires more study. We need to better under= stand the applicability and the implications on all components and planes... When such a mixing environment is completely analyzed and understood, if nee= ded can be added in a later phase. IMO, in the meantime the document should both ICC OR IP environments, with n= o mixing identifiers. Best regards, Nurit From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Malcolm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 7:05 AM To: George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? George, I do not agree the proposed resolution of this comment. As stated in the dr= aft allows an operator can select the use of either Global (IP) or ICC based= identifiers. Insisting that both ends of a LSP or PW must use the same sch= eme removes the freedom to select the between ICC and Global (IP) identifier= s. MPLS-TP requires that the data plane and control plane are independent, incl= uding having independent identifiers. The draft describes the mapping betwe= en the GMPLS identifiers used by the control plane and the data plane identi= fiers. >From the perspective of the data plane an identifier is inserted at the sour= ce and received by the sink. Neither the source or sink need to understand= the semantics of the identifier, all a sink needs to, for example, to verif= y connectivity is to check that the received identifier string matches the e= xpected identifier string. Please see in-line below. Regards, Malcolm George Swallow Sent by: mpls-bounces@ietf.org 25/04/2011 05:16 PM To cc Subject [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers= -04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each= end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= either the Global-ID for both ends or or the ICC for both ends. Mixed use= is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a= fairly trivial procedure. Many organizations if not most already have AS N= umbers. [MB] Many organizations already have process in place to use ICC based ident= ifiers for the data plane changing to IP based identifiers would be a major= burden. 2. Such an addition will add numerous object formats, and test cases. [MB] Why - the data plane does not need to interpret the string, just check= that it matches the expected string 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mod= es of ICC and Global-ID identification is required, they can be added later. [MB] This would be a major roadblock to the use of MPLS-TP in an inter prov= ider transport network 4. For signaled connections, there is no plan to allow routing based= on either the Global-ID or ICC. That would be a radical change to how IP w= orks. However for IP routing to work (in order to forward the signaling mes= sages), the providers involved will need to run BGP and have AS numbers. [MB] The control plane identifiers must be independent of the data plane ide= ntifiers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76D722FE27B3ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

    Malcolm, Nur= it and all,

    One technical= reason for not mixing identifiers of different types is that in certain= situations these identifiers are treated as an ordered set, i.e., it is pos= sible to say when one of these identifiers is “less” than the ot= her one.

    The typical use ca= se is tie-breaking in various protocols (e.g., for deciding which request fo= r a protection-related has to be granted). Even if the current set of MPLS-T= P protocols does not use such tie-breakers, I would not preclude this usage= in future.

     

    It is relatively simple to impose som= e order on identifiers of the same type. Imposing an order on a superset of= identifiers at least requires some thought.

     

    Regards,

      &nbs= p;  Sasha

    =  

    From: mpls-bounce= s@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nuri= t (NSN - IL/Hod HaSharon)
    Sent: Wednesday, April 27, 2011 8:44 AM<= br>To: Malcolm.BETTS@zte.com.cn; George Swallow
    Cc: mpls@ie= tf.org
    Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Id= entifiers?

     =

    Hi,

    I think such mixing environment requires more study. We need to= better understand the applicability and the implications on all components= and planes…

    When such= a mixing environment is completely analyzed and understood, if needed can b= e added in a later phase.

    I= MO, in the meantime the document should both ICC OR IP environments, with no= mixing identifiers.

    Best= regards,

    Nurit

     

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Malcolm.BETTS@zte.com.cn
    Sent: Wednesday, Ap= ril 27, 2011 7:05 AM
    To: George Swallow
    Cc: mpls@ietf.or= g
    Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identif= iers?

     

    <= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>
    George,

    I do not agree the= proposed resolution of this comment.  As stated in the draft allows an= operator can select the use of either Global (IP) or ICC based identifiers.=  Insisting that both ends of a LSP or PW must use the same scheme remo= ves the freedom to select the between ICC and Global (IP) identifiers.

    = MPLS-TP requires that the data plane and control plane are independent, incl= uding having independent identifiers.  The draft describes the mapping= between the GMPLS identifiers used by the control plane and the data plane= identifiers.

    From the perspective of the data plane an identifier is i= nserted at the source and received by the sink.  Neither the source or= sink need to understand the semantics of the identifier, all a sink needs t= o, for example, to verify connectivity is to check that the received identif= ier string matches the expected identifier string.

    Please see in-line b= elow.

    Regards,

    Malcolm


    George Swallow <swallow@cisco.com>= =
    Sent by: mpls-bounces@ietf.org

    25/04/2011 05:16 PM

    		<= td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>

    Subject

     

    To

    <mpls@ietf.org>

    cc

    [mpls] Mixing IC= C and Global-IDs in MPLS-TP Identifiers?

    <= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>


    All -

    Many o= f the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 ha= ve to do with the Global and ICC identifiers.

    The identifiers for Tun= nel, LSP, PW, and MEG include fields to identify each end of an LSP.  C= urrently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global= -ID for both ends or or the ICC for both ends.  Mixed use is not permit= ted.

    The ITU liaison requests that we allow mixed use.

    The aut= hors of the draft are very reluctant to do this.  

    1.    = ;        Obtaining an AS Number (from which the Global-ID is derived) i= s a fairly trivial procedure.  Many organizations if not most already h= ave AS Numbers.
    [MB] Many organizations already have process in place to us= e ICC based identifiers for the data plane changing to IP based identifiers= would be a major burden.
    2.        Such an addition wi= ll add numerous object formats, and test cases.
    [MB]  Why - the data p= lane does not need to interpret the string, just check that it matches the e= xpected string
    3.        The extent inter-provider MPLS-= TP is as yet unknown.  If mixed modes of ICC and Global-ID identificati= on is required, they can be added later.
    [MB]  This would be a major r= oadblock to the use of MPLS-TP in an inter provider transport network=
    4. &n= bsp;      For signaled connections, there is no plan to allow= routing based on either the Global-ID or ICC.  That would be a radical= change to how IP works.  However for IP routing to work (in order to f= orward the signaling messages), the providers involved will need to run BGP= and have AS numbers.
    [MB] The control plane identifiers must be independen= t of the data plane identifiers.

    We are looking for input/consensus f= rom the WG.

    George, Eric, & Matthew     _______________________________________________
    mpls mailin= g list
    mpls@ietf.org
    https://www.ietf.org/mailman/li= stinfo/mpls

    This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

    --_000_A3C5DF08D38B6049839A6F553B331C76D722FE27B3ILPTMAIL02eci_-- From daniele.ceccarelli@ericsson.com Wed Apr 27 00:00:27 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2AFE06D7; Wed, 27 Apr 2011 00:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.728 X-Spam-Level: X-Spam-Status: No, score=-3.728 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eqF9cMtrQ2Z; Wed, 27 Apr 2011 00:00:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EA210E06C6; Wed, 27 Apr 2011 00:00:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-3d-4db7bf05e4c0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.7F.11171.50FB7BD4; Wed, 27 Apr 2011 09:00:21 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.150]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 27 Apr 2011 09:00:21 +0200 From: Daniele Ceccarelli To: Loa Andersson Date: Wed, 27 Apr 2011 09:00:20 +0200 Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AcwDIRABp0qxriM+TbuOzL3DZ9LohwBha4ag Message-ID: References: <4DB1706B.3050602@pi.nu> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: multipart/alternative; boundary="_000_B5630A95D803744A81C51AD4040A6DAA07C31CA80DESESSCMS0360e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Ross Callon , "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:00:27 -0000 --_000_B5630A95D803744A81C51AD4040A6DAA07C31CA80DESESSCMS0360e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQNCg0KQlINCkRhbmllbGUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIHhpYW8ubWluMkB6dGUuY29tLmNuDQpTZW50OiBsdW5lZKis IDI1IGFwcmlsZSAyMDExIDEwLjA4DQpUbzogTG9hIEFuZGVyc3Nvbg0KQ2M6IFJvc3MgQ2FsbG9u OyBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBs c10gcG9sbCBvbiBkcmFmdC1hc2F0aS1waWduYXRhcm8tbXBscy1sZHAtaWFuYQ0KDQoNClllcy9T dXBwb3J0Lg0KDQotIFhpYW8gTWluDQoNCg0KDQpMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+DQq3 orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAxMS8wNC8yMiAyMDoxMQ0KDQrK1bz+ yMsNCiJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4NCrOty80NClJvc3MgQ2FsbG9uIDxy Y2FsbG9uQGp1bmlwZXIubmV0Pg0K1vfM4g0KW21wbHNdIHBvbGwgb24gZHJhZnQtYXNhdGktcGln bmF0YXJvLW1wbHMtbGRwLWlhbmENCg0KDQoNCg0KDQpXb3JraW5nIEdyb3VwLA0KDQp0aGlzIGlz IHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcNCg0KZHJhZnQtYXNhdGktcGlnbmF0 YXJvLW1wbHMtbGRwLWlhbmEtMDENCg0KYW4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K DQpJZiB5b3Ugc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYSB3b3JraW5nIGdyb3VwIGRv Y3VtZW50DQpwbGVhc2UgcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAieWVzL3N1cHBvcnQiDQoN CklmIHlvdSBkbyBub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYSB3b3JraW5nIGdy b3VwDQpkb2N1bWVudCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAibm8vZG8gbm90 IHN1cHBvcnQiDQphbmQgYXQgdGhlIHNhbWUgdGltZSBnaXZlIHRoZSB0ZWNobmljYWwgcmVhc29u cyB3aHkgeW91IGFyZQ0Kbm90IHN1cHBvcnRpbmcgdGhlIGRvY3VtZW50Lg0KDQpJZiB5b3UgaGF2 ZSB0ZWNobmljYWwgY29tbWVudHMgb3IgaW4gYW55IG90aGVyIHdheSB3YW50IHRvDQpkaXNjdXNz IHRoZSBkb2N1bWVudCwgcGxlYXNlIHNlbmQgdGhlc2UgY29tbWVudHMgdG8gdGhlIG1wbHMNCndv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0LCBidXQgd2l0aCBhbm90aGVyIHN1YmplY3QgdGhhbiB3 aGF0DQppcyBvbiB0aGlzIG1haWwuDQoNClRoZSBwb2xsIGVuZHMgTWF5IDh0aC4NCg0KL0xvYQ0K LS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2Eu YW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2Vy ICAgICAgICAgICAgbG9hQHBpLm51DQpFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAg ICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyIDEzDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCg== --_000_B5630A95D803744A81C51AD4040A6DAA07C31CA80DESESSCMS0360e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Yes/Support
     
    BR
    Daniele

    From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 xiao.min2@zte.com.cn
    Sent: luned=A8=AC 25 aprile 2011=20 10.08
    To: Loa Andersson
    Cc: Ross Callon; mpls@ietf.org;= =20 mpls-bounces@ietf.org
    Subject: Re: [mpls] poll on=20 draft-asati-pignataro-mpls-ldp-iana


    Yes/Support.
    - Xiao Min



    Loa Andersson=20 <loa@pi.nu>
    =B7= =A2=BC=FE=C8=CB:=20  mpls-bounces@ietf.org=20

    2011/04/22 20:11

    =CA=D5=BC= =FE=C8=CB
    		"mpls@ietf.org"=20 <mpls@ietf.org>=20
    =B3=AD=CB= =CD
    		Ross Callon=20 <rcallon@juniper.net>=20
    =D6=F7=CC= =E2
    		[mpls] poll on=20 draft-asati-pignataro-mpls-ldp-iana
    =




    Working Group,

    this is to start a two week poll on=20 making

    draft-asati-pignataro-mpls-ldp-iana-01

    an mpls working= =20 group document.

    If you support the document becoming a working group= =20 document
    please respond to this poll with "yes/support"

    If you do= not=20 support the document becoming a working group
    document please respond to= this=20 poll with "no/do not support"
    and at the same time give the technical re= asons=20 why you are
    not supporting the document.

    If you have technical=20 comments or in any other way want to
    discuss the document, please send t= hese=20 comments to the mpls
    working group mailing list, but with another subjec= t=20 than what
    is on this mail.

    The poll ends May 8th.

    /Loa
    = --=20


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

    =
    --_000_B5630A95D803744A81C51AD4040A6DAA07C31CA80DESESSCMS0360e_-- From daniele.ceccarelli@ericsson.com Wed Apr 27 00:04:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C1CE06C6 for ; Wed, 27 Apr 2011 00:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.563 X-Spam-Level: X-Spam-Status: No, score=-5.563 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRc6XTn394-E for ; Wed, 27 Apr 2011 00:04:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EC958E06C7 for ; Wed, 27 Apr 2011 00:04:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-43-4db7bff9bb51 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 30.D0.11171.9FFB7BD4; Wed, 27 Apr 2011 09:04:26 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.150]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 27 Apr 2011 09:04:25 +0200 From: Daniele Ceccarelli To: "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 27 Apr 2011 09:04:24 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf8f45eroZnoXQkOju9SeUku9eAABAbaAAAlfWyA= Message-ID: References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> <067E6CE33034954AAC05C9EC85E2577C04C9B557@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C04C9B557@XMB-RCD-111.cisco.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:04:31 -0000 Yes/support BR Daniele =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Tuesday, April 26, 2011 10:06 PM > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-leymann-mpls-seamless-mpls-03 >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document please=20 > respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group document=20 > please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are not=20 > supporting the document. >=20 > If you have technical comments or in any other way want to discuss the=20 > document, please send these comments to the mpls working group mailing=20 > list, but with another subject than what is on this mail. >=20 > The poll ends May 10th. >=20 > /Loa >=20 >=20 > _______________________________________________ > 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 daniele.ceccarelli@ericsson.com Wed Apr 27 00:06:09 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C09E06DD for ; Wed, 27 Apr 2011 00:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.736 X-Spam-Level: X-Spam-Status: No, score=-5.736 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Djjpzg8aFFUO for ; Wed, 27 Apr 2011 00:06:05 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 39810E06E7 for ; Wed, 27 Apr 2011 00:06:04 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-e3-4db7c05b3633 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F1.67.28525.B50C7BD4; Wed, 27 Apr 2011 09:06:03 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.150]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 27 Apr 2011 09:06:03 +0200 From: Daniele Ceccarelli To: Ross Callon , "mpls@ietf.org" Date: Wed, 27 Apr 2011 09:06:01 +0200 Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQAa13pGAABi+ywA== Message-ID: References: <76CD132C3ADEF848BD84D028D243C927AFDBBA@szxeml508-mbs.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AFDBBA@szxeml508-mbs.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, 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] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:06:09 -0000 Yes/support BR Daniele > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Ross Callon > Sent: Monday, April 18, 2011 11:16 PM > To: mpls@ietf.org > Subject: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG=20 > document >=20 > All, >=20 > this is to start a two week working group poll on whether to make=20 > draft-kompella-mpls-entropy-label an mpls wg document. >=20 > Please send your comments to the mpls@ietf.org mailing list. >=20 > The poll ends on May 3rd. >=20 > thanks Ross (as WG co-chair) > _______________________________________________ > 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 loa@pi.nu Wed Apr 27 00:34:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF32DE067B for ; Wed, 27 Apr 2011 00:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xz7y5lMZB8x for ; Wed, 27 Apr 2011 00:34:40 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id E900DE06DD for ; Wed, 27 Apr 2011 00:34:39 -0700 (PDT) Received: from [172.17.113.226] (207.47.24.2.static.nextweb.net [207.47.24.2]) (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 A74CA2A8001; Wed, 27 Apr 2011 09:34:36 +0200 (CEST) Message-ID: <4DB7C709.1070404@pi.nu> Date: Wed, 27 Apr 2011 00:34:33 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexander Vainshtein References: <077E41CFFD002C4CAB7DFA4386A5326403B78D19@DEMUEXC014.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:34:44 -0000 Sasha, from 5036 2. LSR1 determines whether it will play the active or passive role in session establishment by comparing addresses A1 and A2 as unsigned integers. If A1 > A2, LSR1 plays the active role; otherwise, it is passive. tLDP maybe used to set up PWs in MPLS based transport networks! /Loa On 2011-04-26 23:06, Alexander Vainshtein wrote: > Malcolm, Nurit and all, > > One /technical/ reason for not mixing identifiers of different types is > that in certain situations these identifiers are treated as an ordered > set, i.e., it is possible to say when one of these identifiers is “less” > than the other one. > > The typical use case is tie-breaking in various protocols (e.g., for > deciding which request for a protection-related has to be granted). Even > if the current set of MPLS-TP protocols does not use such tie-breakers, > I would not preclude this usage in future. > > It is relatively simple to impose some order on identifiers of the same > type. Imposing an order on a superset of identifiers at least requires > some thought. > > Regards, > > Sasha > > *From:*mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Sprecher, Nurit (NSN - IL/Hod HaSharon) > *Sent:* Wednesday, April 27, 2011 8:44 AM > *To:* Malcolm.BETTS@zte.com.cn; George Swallow > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Hi, > > I think such mixing environment requires more study. We need to better > understand the applicability and the implications on all components and > planes… > > When such a mixing environment is completely analyzed and understood, if > needed can be added in a later phase. > > IMO, in the meantime the document should both ICC OR IP environments, > with no mixing identifiers. > > Best regards, > > Nurit > > *From:*mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *ext Malcolm.BETTS@zte.com.cn > *Sent:* Wednesday, April 27, 2011 7:05 AM > *To:* George Swallow > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > George, > > I do not agree the proposed resolution of this comment. As stated in the > draft allows an operator can select the use of either Global (IP) or ICC > based identifiers. Insisting that both ends of a LSP or PW must use the > same scheme removes the freedom to select the between ICC and Global > (IP) identifiers. > > MPLS-TP requires that the data plane and control plane are independent, > including having independent identifiers. The draft describes the > mapping between the GMPLS identifiers used by the control plane and the > data plane identifiers. > > From the perspective of the data plane an identifier is inserted at the > source and received by the sink. Neither the source or sink need to > understand the semantics of the identifier, all a sink needs to, for > example, to verify connectivity is to check that the received identifier > string matches the expected identifier string. > > Please see in-line below. > > Regards, > > Malcolm > > > *George Swallow * > Sent by: mpls-bounces@ietf.org > > 25/04/2011 05:16 PM > > > > To > > > > > > cc > > > > Subject > > > > [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > > > > > All - > > Many of the comments received from the ITU on > draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC > identifiers. > > The identifiers for Tunnel, LSP, PW, and MEG include fields to identify > each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG > to use either the Global-ID for both ends or or the ICC for both ends. > Mixed use is not permitted. > > The ITU liaison requests that we allow mixed use. > > The authors of the draft are very reluctant to do this. > > 1. Obtaining an AS Number (from which the Global-ID is derived) is a > fairly trivial procedure. Many organizations if not most already have AS > Numbers. > [MB] Many organizations already have process in place to use ICC based > identifiers for the data plane changing to IP based identifiers would be > a major burden. > 2. Such an addition will add numerous object formats, and test cases. > [MB] Why - the data plane does not need to interpret the string, just > check that it matches the expected string > 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes > of ICC and Global-ID identification is required, they can be added later. > [MB] This would be a major roadblock to the use of MPLS-TP in an inter > provider transport network > 4. For signaled connections, there is no plan to allow routing based on > either the Global-ID or ICC. That would be a radical change to how IP > works. However for IP routing to work (in order to forward the signaling > messages), the providers involved will need to run BGP and have AS numbers. > [MB] The control plane identifiers must be independent of the data plane > identifiers. > > We are looking for input/consensus from the WG. > > George, Eric, & Matthew _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. > > > > _______________________________________________ > 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 giles.heron@gmail.com Wed Apr 27 01:17:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310C5E06D1 for ; Wed, 27 Apr 2011 01:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hExyBYS3r8wi for ; Wed, 27 Apr 2011 01:17:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78F43E06C3 for ; Wed, 27 Apr 2011 01:17:36 -0700 (PDT) Received: by wyb29 with SMTP id 29so1229552wyb.31 for ; Wed, 27 Apr 2011 01:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=yRoN8KEbEJJxFiDtDAM3iG6FreROtTQlhZBxYYce7Jo=; b=Aku5Q4CAAP66Bd1SeaUvW0h4AUsUCZIRu/CxGhE2ey9difhTYmNYsXyGiD+b8QBMlU tyeu3Wzjc1pcJ9zdsVjGJEntjyeVN7R8+iET5rTK78ZyARm2y9zU1x3t69yPpUyf8rJ+ xbV44gxo74zX7CyVr/3raRPthNrWexExKEG4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=ObhFKCaAKg18tCTbcABxItvTZJmw8LPzn08+LoMTkGkmj6iwGwDsC/LZeKhic1AkZS astPfScVDu6zM9Nu5788id1MH7+8jj7fOIkeS/svb+U2v1cC96lgaCfE8GPzrBGWYOFH E70EIdNETIsvKwuJAdzgPcLehkWU21EEh92jk= Received: by 10.216.237.73 with SMTP id x51mr408185weq.16.1303892201978; Wed, 27 Apr 2011 01:16:41 -0700 (PDT) Received: from [192.168.1.7] (host81-159-253-163.range81-159.btcentralplus.com [81.159.253.163]) by mx.google.com with ESMTPS id o6sm294439wbo.20.2011.04.27.01.16.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 01:16:41 -0700 (PDT) User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 27 Apr 2011 09:17:43 +0100 From: Giles Heron To: Loa Andersson , Message-ID: Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEs5TbgrWwhHbX/UCifvhIKuORug== In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: rcallon@juniper.net Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 08:17:43 -0000 yes/support On 27/04/2011 03:06, "Loa Andersson" wrote: > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From matthew.bocci@alcatel-lucent.com Wed Apr 27 01:36:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750E2E0694 for ; Wed, 27 Apr 2011 01:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K0WhRhK5lF3 for ; Wed, 27 Apr 2011 01:36:14 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 39D07E06B9 for ; Wed, 27 Apr 2011 01:36:14 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3R8a4iL011438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Apr 2011 10:36:11 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 27 Apr 2011 10:36:08 +0200 From: "Bocci, Matthew (Matthew)" To: "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 27 Apr 2011 10:36:06 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEtifGMRxpmVBhRVmUO+Jn5e6aRA== Message-ID: In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 08:36:18 -0000 Yes/support. Cheers, Matthew On 27/04/2011 03:06, "loa@pi.nu" wrote: > >Working Group, > >this is to start a two week poll on making > >draft-leymann-mpls-seamless-mpls-03 > >an mpls working group document. > >If you support the document becoming a working group document >please respond to this poll with "yes/support" > >If you do not support the document becoming a working group >document please respond to this poll with "no/do not support" >and at the same time give the technical reasons why you are >not supporting the document. > >If you have technical comments or in any other way want to >discuss the document, please send these comments to the mpls >working group mailing list, but with another subject than what >is on this mail. > >The poll ends May 10th. > >/Loa > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nurit.sprecher@nsn.com Wed Apr 27 01:37:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DD3E06FE for ; Wed, 27 Apr 2011 01:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.777 X-Spam-Level: X-Spam-Status: No, score=-4.777 tagged_above=-999 required=5 tests=[AWL=1.822, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRfZp6OrYmdE for ; Wed, 27 Apr 2011 01:37:11 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 57A4EE06F3 for ; Wed, 27 Apr 2011 01:37:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p3R8b9Hr024392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 10:37:10 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3R8b8ki010719; Wed, 27 Apr 2011 10:37:09 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 10:37:01 +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, 27 Apr 2011 10:37:00 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403B78E9D@DEMUEXC014.nsn-intra.net> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf8UsOTcyuuW+TiyOaRwn3hvuuwANnyEg References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 27 Apr 2011 08:37:01.0720 (UTC) FILETIME=[47829180:01CC04B6] Cc: rcallon@juniper.net Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 08:37:13 -0000 Yes/support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext loa@pi.nu Sent: Wednesday, April 27, 2011 5:06 AM To: mpls@ietf.org Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From christian.jacquenet@orange-ftgroup.com Wed Apr 27 01:39:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE12E067A for ; Wed, 27 Apr 2011 01:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBgigNRMyhvx for ; Wed, 27 Apr 2011 01:39:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 12054E0706 for ; Wed, 27 Apr 2011 01:39:06 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 53AF73B414B; Wed, 27 Apr 2011 10:39:06 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 365E6238059; Wed, 27 Apr 2011 10:39:06 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 27 Apr 2011 10:39:06 +0200 From: To: "Bocci, Matthew (Matthew)" , "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 27 Apr 2011 10:39:05 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEtifGMRxpmVBhRVmUO+Jn5e6aRAAAFX7Q Message-ID: <3663_1303893546_4DB7D62A_3663_6024_3_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE77F6C8E@PUEXCB1C.nanterre.francetelecom.fr> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.27.63314 Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 08:39:11 -0000 Hi, I also support the adoption of this draft as a mpls WG document. Cheers, Christian.=20 > >Working Group, > >this is to start a two week poll on making > >draft-leymann-mpls-seamless-mpls-03 > >an mpls working group document. > >If you support the document becoming a working group document please=20 >respond to this poll with "yes/support" > >If you do not support the document becoming a working group document=20 >please respond to this poll with "no/do not support" >and at the same time give the technical reasons why you are not=20 >supporting the document. > >If you have technical comments or in any other way want to discuss the=20 >document, please send these comments to the mpls working group mailing=20 >list, but with another subject than what is on this mail. > >The poll ends May 10th. > >/Loa > > >_______________________________________________ >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 ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From nurit.sprecher@nsn.com Wed Apr 27 01:43:51 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE36E06E9; Wed, 27 Apr 2011 01:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.037 X-Spam-Level: X-Spam-Status: No, score=-5.037 tagged_above=-999 required=5 tests=[AWL=1.561, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEpbPBZAnT40; Wed, 27 Apr 2011 01:43:47 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B321AE0689; Wed, 27 Apr 2011 01:43:46 -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 p3R8hfJ4002014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 10:43:41 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3R8hclJ003525; Wed, 27 Apr 2011 10:43:40 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 10:43:33 +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_01CC04B7.3048EC58" Date: Wed, 27 Apr 2011 10:43:30 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403B78EAB@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WGdocument Thread-Index: AcwEdwQ2AHQqK6eZTSi9wojkZja4FwAQBYcQ References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "Ross Callon" X-OriginalArrivalTime: 27 Apr 2011 08:43:33.0465 (UTC) FILETIME=[31021C90:01CC04B7] Cc: mpls@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WGdocument X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 08:43:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC04B7.3048EC58 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Best regards, Nurit ----------------------------- All, this is to start a two week working group poll on whether to make draft-kompella-mpls-entropy-label an mpls wg document. Please send your comments to the mpls@ietf.org mailing list. The poll ends on May 3rd.=20 thanks Ross (as WG co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01CC04B7.3048EC58 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Yes/support

    Best regards,

    Nurit

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


    <= tt>All,

    this is to start a two week working group poll = on whether to make
    draft-kompella-mpls-entropy-label an mpls = wg document.

    Please send your comments to the = mpls@ietf.org mailing list.

    The poll ends on May 3rd. =

    thanks Ross (as WG = co-chair)
    _______________________________________________
    mpls mailing = list
    mpls@ietf.org
    https://www.ietf.org/mailman/l= istinfo/mpls

    ------_=_NextPart_001_01CC04B7.3048EC58-- From nurit.sprecher@nsn.com Wed Apr 27 01:45:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882BBE071E for ; Wed, 27 Apr 2011 01:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.777 X-Spam-Level: X-Spam-Status: No, score=-4.777 tagged_above=-999 required=5 tests=[AWL=1.822, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMwIEPh7mR27 for ; Wed, 27 Apr 2011 01:45:11 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEA3E071A for ; Wed, 27 Apr 2011 01:45:10 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p3R8j9Jp007066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 10:45:09 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3R8j4L1023794; Wed, 27 Apr 2011 10:45:09 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 10:45:08 +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, 27 Apr 2011 10:45:06 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403B78EB5@DEMUEXC014.nsn-intra.net> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf8UsOTcyuuW+TiyOaRwn3hvuuwANnyEg References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 27 Apr 2011 08:45:08.0445 (UTC) FILETIME=[699EE8D0:01CC04B7] Cc: rcallon@juniper.net, mpls@ietf.org Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 08:45:11 -0000 Yes/support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext loa@pi.nu Sent: Wednesday, April 27, 2011 5:06 AM To: mpls@ietf.org Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Wed Apr 27 04:24:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DAFE06CA for ; Wed, 27 Apr 2011 04:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuPsi5K2uPaT for ; Wed, 27 Apr 2011 04:24:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id CB771E06C2 for ; Wed, 27 Apr 2011 04:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1123; q=dns/txt; s=iport; t=1303903494; x=1305113094; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BcagscN0byg+SO78HS3QtXUSrW/i28gR5qgyQYUlAwI=; b=CnsOSEwiaCQy0/OPxL1Fxz4g4qcOFbxK6BGms4dEOSbCi2vXkElvqDAx bbADrb9RqPmUPkU1bYOWSI4aJ/Yci+HMksLngrd3B6d/0QVGv7ldC/BqX E6BKJihBvxLFTpfjJUWmgAJPyXpx/k/cTac04B5rX1agzqY73U6haiOW4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8BAG38t02tJXHB/2dsb2JhbACXfo1td6VLnHqFdgSGA4xoijA X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208";a="231545979" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2011 11:24:53 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p3RBOraM006017; Wed, 27 Apr 2011 11:24:53 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 06:24:53 -0500 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, 27 Apr 2011 06:24:50 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25057F55CF@XMB-RCD-201.cisco.com> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf8GfQIFBeZ7zTCGHblLsV+pbsQATdBLg References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> From: "Luyuan Fang (lufang)" To: , X-OriginalArrivalTime: 27 Apr 2011 11:24:53.0418 (UTC) FILETIME=[BAB5B8A0:01CC04CD] Cc: rcallon@juniper.net Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 11:24:59 -0000 Yes/support Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa@pi.nu Sent: Wednesday, April 27, 2011 3:06 AM To: mpls@ietf.org Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Thomas.Beckhaus@telekom.de Wed Apr 27 05:34:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA70E0729 for ; Wed, 27 Apr 2011 05:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvqEz4hR1S3v for ; Wed, 27 Apr 2011 05:34:31 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 97652E0727 for ; Wed, 27 Apr 2011 05:34:30 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 27 Apr 2011 14:34:26 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 27 Apr 2011 14:34:26 +0200 From: To: , Date: Wed, 27 Apr 2011 14:34:23 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf/k08oI4MDJLScqZtMGRTZRqiQAV1vkA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08406DA644@HE111648.emea1.cds.t-internal.com> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rcallon@juniper.net Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:34:35 -0000 yes/support Thomas > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of loa@pi.nu > Sent: Wednesday, April 27, 2011 4:06 AM > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 > > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From yaakov_s@rad.com Wed Apr 27 05:51:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C98FE074C for ; Wed, 27 Apr 2011 05:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1HvFUxo98Xk for ; Wed, 27 Apr 2011 05:51:50 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by ietfa.amsl.com (Postfix) with ESMTP id DF985E0731 for ; Wed, 27 Apr 2011 05:51:49 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 27 Apr 2011 15:51:48 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 27 Apr 2011 15:49:51 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Wed, 27 Apr 2011 15:49:51 +0300 From: Yaakov Stein To: "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AQHMBH+Q1LfPm0rYjUCTn8xuXgBECpRxpqMQ Date: Wed, 27 Apr 2011 12:49:51 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E41EBC@EXRAD5.ad.rad.co.il> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:51:58 -0000 Loa and all For reasons I specified in my previous email on this draft, I very strongly oppose making this draft a WG draft=20 until some plausible security mechanism is specified. As it stands, this draft is a serious danger not only to the access network= s to which it is extending MPLS,=20 but to the core network to which these access networks attach, and conceiva= bly to the public Internet. Adopting this draft with a security considerations section containing only = ridiculous statements and TBDs=20 is tantamount to saying that the IETF either doesn't understand or does not= care about basic network security. Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa= @pi.nu Sent: Wednesday, April 27, 2011 05:06 To: mpls@ietf.org Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From yaakov_s@rad.com Wed Apr 27 06:01:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344F5E0731 for ; Wed, 27 Apr 2011 06:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj7hBsMHj-Uw for ; Wed, 27 Apr 2011 06:01:35 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by ietfa.amsl.com (Postfix) with ESMTP id C045DE0732 for ; Wed, 27 Apr 2011 06:01:32 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 27 Apr 2011 16:01:31 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 27 Apr 2011 15:59:33 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Wed, 27 Apr 2011 15:59:33 +0300 From: Yaakov Stein To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AQHMAOYu+PN/G1PR2kOzoUBIBaPIVpRxsq1A Date: Wed, 27 Apr 2011 12:59:32 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E41EF7@EXRAD5.ad.rad.co.il> References: <4DB1706B.3050602@pi.nu> In-Reply-To: <4DB1706B.3050602@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:01:39 -0000 While I agree in principle that IANA needs well-defined policies, do we really need an RFC saying that unallocated bits are to be allocated v= ia "IETF Review". Perhaps an IESG clarification statement would suffice.=20 ... and if not, why only the ATM Label TLV, FR Label TLV, ... ? I am sure that there are plenty of underspecified IANA registries. Are we going to issue RFCs for every underspecified field in every registry= ? It would seem that an IAB document giving guidelines for all such cases would be a much more efficient route. Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Friday, April 22, 2011 15:11 To: mpls@ietf.org Cc: Ross Callon Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Working Group, this is to start a two week poll on making draft-asati-pignataro-mpls-ldp-iana-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 8th. /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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From swallow@cisco.com Wed Apr 27 06:13:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B6E06DD for ; Wed, 27 Apr 2011 06:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.601 X-Spam-Level: X-Spam-Status: No, score=-108.601 tagged_above=-999 required=5 tests=[AWL=1.998, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib-SmbYRku2h for ; Wed, 27 Apr 2011 06:13:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 74B04E069F for ; Wed, 27 Apr 2011 06:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=840; q=dns/txt; s=iport; t=1303910015; x=1305119615; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0lv9SN96UqDeONs03syRSLeb6kU+2JLMvvhEGoOc5Oo=; b=j/GVM6oGaHOJeD1SyUI4R11r1QU4LmLG+FuD6dsVpBgvbe9BTzc/n5vF RsbVbZwoNMSje6ItwK3AV6qbt2+9wtwbgFE6yepNQl9gVRuQPmCG6yZPq hLwSPSF0mn2bQU4Qst3dfv9ls6ET5QjMlPvbDD+rHsf4puqTqECItFJHr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABgVuE2tJV2b/2dsb2JhbACla3eIcJ0cnHeFdgSOUYQaii4 X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208";a="437329439" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 13:13:30 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3RDDUsI006298; Wed, 27 Apr 2011 13:13:30 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 08:13:29 -0500 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Apr 2011 13:13:29 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 27 Apr 2011 09:13:29 -0400 From: George Swallow To: Loa Andersson , Message-ID: Thread-Topic: poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwE3OZMDAxCMo7fOk+dwjo/2+osrA== In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2011 13:13:29.0612 (UTC) FILETIME=[E6AA04C0:01CC04DC] Cc: Ross Callon Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:13:39 -0000 Support. On 4/26/11 10:06 PM, "Loa Andersson" wrote: > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > From cpignata@cisco.com Wed Apr 27 06:56:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7302E0679 for ; Wed, 27 Apr 2011 06:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt8FYSkbHd9T for ; Wed, 27 Apr 2011 06:56:20 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4BE0704 for ; Wed, 27 Apr 2011 06:56:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3RDuJbi004787; Wed, 27 Apr 2011 09:56:19 -0400 (EDT) Received: from [64.102.218.93] (dhcp-64-102-218-93.cisco.com [64.102.218.93]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3RDuFRe026023; Wed, 27 Apr 2011 09:56:15 -0400 (EDT) Message-ID: <4DB8207F.2040203@cisco.com> Date: Wed, 27 Apr 2011 09:56:15 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Yaakov Stein References: <4DB1706B.3050602@pi.nu> <07F7D7DED63154409F13298786A2ADC903E41EF7@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903E41EF7@EXRAD5.ad.rad.co.il> X-Enigmail-Version: 1.1.1 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:56:25 -0000 Hi Yaakov, Please see inline. On 4/27/2011 8:59 AM, Yaakov Stein wrote: Apologies for dissecting this first sentence in a few fragments: > While I agree in principle that IANA needs well-defined policies, This is not a theoretical principle-driven exercise, but a practical one, as draft-asati-pignataro-mpls-ldp-gtsm [1] [2] needs to allocate a bit (for GTSM negotiation) for which there is no allocation policies. > do we really need an RFC This is what RFC 5226 specifies. Most allocation policies for LDP are included already in RFC 5036 [the why need an RFC applies here too], just not the one we now need. > saying that unallocated bits are to be allocated via "IETF Review". "IETF Review" is the new name for "IETF Consensus", which is the Well-Known IANA policy used in RFC 5036, and hence we think the most direct path forward. > > Perhaps an IESG clarification statement would suffice. I apologize I do not understand this. But IETF Review includes WG Review, IESG Review, etc. > ... and if not, why only the ATM Label TLV, FR Label TLV, ... ? > We only need, right now, bits in the Common Hello Parameters TLV. But since we are undertaking this work, we chose to comb through RFC 5036 and include all number spaces with undefined policies. > I am sure that there are plenty of underspecified IANA registries. > Are we going to issue RFCs for every underspecified field in every registry ? I hope not -- personally, I am inclusive of all number spaces when writing a protocol RFC. However, when something was not specified at the time, I think that a need-basis is the right approach. > It would seem that an IAB document giving guidelines for all such cases > would be a much more efficient route. > I also do not parse this -- but RFC 5226 is what gives guidelines currently, and beyond guidelines we need the actual doc to define how to allocate the bit we are after. Hope these responses clarify. Thanks, -- Carlos. [1] [2] > Y(J)S > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, April 22, 2011 15:11 > To: mpls@ietf.org > Cc: Ross Callon > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana > > Working Group, > > this is to start a two week poll on making > > draft-asati-pignataro-mpls-ldp-iana-01 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 8th. > > /Loa From mustapha.aissaoui@alcatel-lucent.com Wed Apr 27 07:00:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F803E06BC for ; Wed, 27 Apr 2011 07:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aT-D02ohQ6h for ; Wed, 27 Apr 2011 07:00:13 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8090BE0733 for ; Wed, 27 Apr 2011 07:00:13 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3RE0BnW027498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 09:00:12 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3RDve1e029456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Apr 2011 09:00:11 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 27 Apr 2011 08:59:42 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 27 Apr 2011 08:59:41 -0500 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf73lLrS2KgnYTNuvL30Bqx3w5wAY5RXA Message-ID: <5DF53972F7E9134782DCE51624466FE50AD0D26163@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.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-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:00:17 -0000 I support this. Mustapha.=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa= @pi.nu Sent: Tuesday, April 26, 2011 10:06 PM To: mpls@ietf.org Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respon= d to this poll with "yes/support" If you do not support the document becoming a working group document please= respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting = the document. If you have technical comments or in any other way want to discuss the docu= ment, please send these comments to the mpls working group mailing list, bu= t with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From yakov@juniper.net Wed Apr 27 07:32:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9177CE0798 for ; Wed, 27 Apr 2011 07:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWnx2dKBKzsn for ; Wed, 27 Apr 2011 07:32:26 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id B49B5E075B for ; Wed, 27 Apr 2011 07:32:25 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTbgo9IDJ1vdjEse62rCoIf+UClO15kUh@postini.com; Wed, 27 Apr 2011 07:32:25 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Apr 2011 07:25:39 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p3REPcv56436; Wed, 27 Apr 2011 07:25:38 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201104271425.p3REPcv56436@magenta.juniper.net> To: "loa@pi.nu" , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63512.1303914338.1@juniper.net> Date: Wed, 27 Apr 2011 07:25:38 -0700 From: Yakov Rekhter Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:32:26 -0000 support Yakov. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa@p i.nu > Sent: Tuesday, April 26, 2011 10:06 PM > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 > > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document please respond > to this poll with "yes/support" > > If you do not support the document becoming a working group document please > respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are not supporting th e document. > > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing list, > but with another subject than what is on this mail. > > The poll ends May 10th. > > /Loa > > > _______________________________________________ > 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 linda.dunbar@huawei.com Wed Apr 27 07:55:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93AFE0751 for ; Wed, 27 Apr 2011 07:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhpcMxVFiUE2 for ; Wed, 27 Apr 2011 07:55:25 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4780CE0721 for ; Wed, 27 Apr 2011 07:55:25 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKB00203G49J7@usaga02-in.huawei.com> for mpls@ietf.org; Wed, 27 Apr 2011 07:55:23 -0700 (PDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LKB00FW8G0A3K@usaga02-in.huawei.com> for mpls@ietf.org; Wed, 27 Apr 2011 07:52:58 -0700 (PDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Apr 2011 07:52:53 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.75]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 27 Apr 2011 07:52:58 -0700 Date: Wed, 27 Apr 2011 14:52:57 +0000 From: Linda Dunbar In-reply-to: X-Originating-IP: [10.192.11.188] To: "loa@pi.nu" , "mpls@ietf.org" Message-id: <4A95BA014132FF49AE685FAB4B9F17F605141118@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-index: AQHMBH/g7sSgQXWM9EqDv+yVTf+NxpRxe8KAgABQxHA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 14:55:25 -0000 Yes/support. Linda Dunbar > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Wednesday, April 27, 2011 10:06 AM > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 > > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > > _______________________________________________ > 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 jordan.britnell@bell.ca Wed Apr 27 08:15:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19001E0751 for ; Wed, 27 Apr 2011 08:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KZAyajjgG6A for ; Wed, 27 Apr 2011 08:15:31 -0700 (PDT) Received: from mail91.messagelabs.com (mail91.messagelabs.com [194.106.220.35]) by ietfa.amsl.com (Postfix) with ESMTP id D7D03E0743 for ; Wed, 27 Apr 2011 08:15:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jordan.britnell@bell.ca X-Msg-Ref: server-6.tower-91.messagelabs.com!1303917290!14793096!56 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [206.47.0.168] Received: (qmail 18670 invoked from network); 27 Apr 2011 15:15:29 -0000 Received: from tlsexchange.bellnexxia.net (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-6.tower-91.messagelabs.com with RC4-SHA encrypted SMTP; 27 Apr 2011 15:15:29 -0000 Received: from hub03-wyn.bell.corp.bce.ca (142.182.199.49) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.3.83.0; Wed, 27 Apr 2011 11:15:32 -0400 Received: from MBX06.bell.corp.bce.ca ([142.182.199.97]) by hub03-wyn.bell.corp.bce.ca ([142.182.199.49]) with mapi; Wed, 27 Apr 2011 11:15:27 -0400 From: "jordan.britnell@bell.ca" To: "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 27 Apr 2011 11:15:25 -0400 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AQHMBH/g7sSgQXWM9EqDv+yVTf+NxpRxe8KAgABQxHCAAAYz8A== Message-ID: References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> <4A95BA014132FF49AE685FAB4B9F17F605141118@dfweml503-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F605141118@dfweml503-mbx.china.huawei.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 Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:15:32 -0000 Support... Jordan Britnell Network Broadband Home 416-215-3729 Jordan.britnell@bell.ca -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lin= da Dunbar Sent: April-27-11 10:53 AM To: loa@pi.nu; mpls@ietf.org Cc: rcallon@juniper.net Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Yes/support. Linda Dunbar > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Wednesday, April 27, 2011 10:06 AM > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-leymann-mpls-seamless-mpls-03 >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document > please respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. >=20 > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. >=20 > The poll ends May 10th. >=20 > /Loa >=20 >=20 > _______________________________________________ > 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 thomas.morin@orange-ftgroup.com Wed Apr 27 08:21:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FFEE0721 for ; Wed, 27 Apr 2011 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwanRhuk3tgN for ; Wed, 27 Apr 2011 08:21:28 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5355FE06A8 for ; Wed, 27 Apr 2011 08:21:28 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BAF0D858012 for ; Wed, 27 Apr 2011 17:28:00 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B5C6785800D for ; Wed, 27 Apr 2011 17:28:00 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 17:20:37 +0200 Received: from [10.193.71.121] ([10.193.71.121]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 17:20:36 +0200 Message-ID: <4DB83444.4060801@orange-ftgroup.com> Date: Wed, 27 Apr 2011 17:20:36 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: mpls@ietf.org References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> X-TagToolbar-Keys: D20110427172036118 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Apr 2011 15:20:36.0679 (UTC) FILETIME=[A8C01570:01CC04EE] Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:21:29 -0000 Support. -Thomas loa@pi.nu a écrit : > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Wed Apr 27 09:11:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6CE0843 for ; Wed, 27 Apr 2011 09:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEPIPbZugjJf for ; Wed, 27 Apr 2011 09:11:16 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id EEF1AE0734 for ; Wed, 27 Apr 2011 09:11:15 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3RGBDXA003425; Wed, 27 Apr 2011 11:11:14 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 27 Apr 2011 12:11:08 -0400 From: Eric Gray To: George Swallow , "mpls@ietf.org" Date: Wed, 27 Apr 2011 12:11:05 -0400 Thread-Topic: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gBZvzlQ 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_C0AC8FAB6849AB4FADACCC70A949E2F10B070DAE9AEUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:11:16 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B070DAE9AEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As one of the co-authors on this draft, I support a restriction to using a = common form of identifier throughout an LSP or PW. In my opinion, it is far better to terminate LSPs or PWs at the point where= there might be an identifier form change and "stitch" them together if that is wh= at the operators want/agree to do. This limits the need-to-know for the mapping o= f one form of identifier to the other to the point at which this occurs, rather t= han at each node in the LSP or (potentially) MS-PW. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a fair= ly trivial procedure. Many organizations if not most already have AS Numbe= rs. 2. Such an addition will add numerous object formats, and test cases. 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes o= f ICC and Global-ID identification is required, they can be added later. 4. For signaled connections, there is no plan to allow routing based on e= ither the Global-ID or ICC. That would be a radical change to how IP works= . However for IP routing to work (in order to forward the signaling messag= es), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B070DAE9AEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mixing ICC and Global-IDs in MPLS-TP Identifiers?</TITLE= > <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6001.18602" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D151310616-27042011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>As one of the co-authors on this draft, I support = a=20 restriction to using a common</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D151310616-27042011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>form of identifier throughout an LSP or=20 PW.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D151310616-27042011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D151310616-27042011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>In my opinion, it is far better to terminate LSPs = or PWs at=20 the point where there</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D151310616-27042011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>might be an identifier form change and "stitch" th= em=20 together if that is what the</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D151310616-27042011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>operators want/agree to do.  This limits the= =20 need-to-know for the mapping of one</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D151310616-27042011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>form of identifier to the other to the point at wh= ich this=20 occurs, rather than at each</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D151310616-27042011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>node in the LSP or (potentially)=20 MS-PW.</FONT></SPAN></DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] <B>On Behalf Of </B>George=20 Swallow<BR><B>Sent:</B> Monday, April 25, 2011 5:17 PM<BR><B>To:</B>=20 mpls@ietf.org<BR><B>Subject:</B> [mpls] Mixing ICC and Global-IDs in MPLS-T= P=20 Identifiers?<BR></FONT><BR></DIV> <DIV></DIV><FONT size=3D1><FONT face=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN=20 style=3D"FONT-SIZE: 10pt">All -<BR><BR>Many of the comments received from t= he ITU=20 on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC=20 identifiers.<BR><BR>The identifiers for Tunnel, LSP, PW, and MEG include fi= elds=20 to identify each end of an LSP.  Currently the draft allows a Tunnel, = LSP,=20 PW, or MEG to use either the Global-ID for both ends or or the ICC for both= =20 ends.  Mixed use is not permitted.<BR><BR>The ITU liaison requests tha= t we=20 allow mixed use.<BR><BR>The authors of the draft are very reluctant to do t= his.=20  <BR><BR></SPAN></FONT></FONT> <OL> <LI><FONT size=3D1><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPA= N=20 style=3D"FONT-SIZE: 10pt">Obtaining an AS Number (from which the Global-I= D is=20 derived) is a fairly trivial procedure.  Many organizations if not m= ost=20 already have AS Numbers. </SPAN></FONT></FONT> <LI><FONT size=3D1><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPA= N=20 style=3D"FONT-SIZE: 10pt">Such an addition will add numerous object forma= ts, and=20 test cases. </SPAN></FONT></FONT> <LI><FONT size=3D1><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPA= N=20 style=3D"FONT-SIZE: 10pt">The extent inter-provider MPLS-TP is as yet unk= nown.=20  If mixed modes of ICC and Global-ID identification is required, the= y can=20 be added later. </SPAN></FONT></FONT> <LI><FONT size=3D1><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPA= N=20 style=3D"FONT-SIZE: 10pt">For signaled connections, there is no plan to a= llow=20 routing based on either the Global-ID or ICC.  That would be a radic= al=20 change to how IP works.  However for IP routing to work (in order to= =20 forward the signaling messages), the providers involved will need to run = BGP=20 and have AS numbers.</SPAN></FONT></FONT><FONT=20 face=3D"Verdana, Helvetica, Arial"><SPAN style=3D"FONT-SIZE: 14pt">=20 <BR></SPAN></FONT></LI></OL><FONT size=3D1><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN style=3D"FONT-SIZE: 10pt"= ><BR>We=20 are looking for input/consensus from the WG.<BR><BR>George, Eric, &=20 Matthew</SPAN></FONT></FONT> </BODY></HTML> --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B070DAE9AEUSAACMS0701e_-- From alessandro.capello@telecomitalia.it Wed Apr 27 09:14:31 2011 Return-Path: <alessandro.capello@telecomitalia.it> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE8E077B for <mpls@ietfa.amsl.com>; Wed, 27 Apr 2011 09:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.463 X-Spam-Level: * X-Spam-Status: No, score=1.463 tagged_above=-999 required=5 tests=[AWL=2.182, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FyhTq+LZ+wa for <mpls@ietfa.amsl.com>; Wed, 27 Apr 2011 09:14:29 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 04C5CE06A3 for <mpls@ietf.org>; Wed, 27 Apr 2011 09:14:25 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Apr 2011 18:14:23 +0200 Received: from GRFMBX702BA020.griffon.local ([10.188.101.11]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Wed, 27 Apr 2011 18:14:23 +0200 From: Capello Alessandro <alessandro.capello@telecomitalia.it> To: "loa@pi.nu" <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org> Date: Wed, 27 Apr 2011 18:14:19 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf89yVoPKQSiYTqyQdA7ZLF8ypgAdiNWg Message-ID: <36A93B31228D3B49B691AD31652BCAE9A53280F014@GRFMBX702BA020.griffon.local> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rcallon@juniper.net" <rcallon@juniper.net> Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 27 Apr 2011 16:14:31 -0000 Support. Regards, Alessandro -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa= @pi.nu Sent: mercoled=EC 27 aprile 2011 4.06 To: mpls@ietf.org Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ 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 eric.gray@ericsson.com Wed Apr 27 09:16:04 2011 Return-Path: <eric.gray@ericsson.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17046E084A for <mpls@ietfa.amsl.com>; Wed, 27 Apr 2011 09:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZJurd8amsJJ for <mpls@ietfa.amsl.com>; Wed, 27 Apr 2011 09:16:03 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 404CCE0803 for <mpls@ietf.org>; Wed, 27 Apr 2011 09:16:03 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3RGFwUH004488; Wed, 27 Apr 2011 11:15:59 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Apr 2011 12:15:52 -0400 From: Eric Gray <eric.gray@ericsson.com> To: "neil.2.harrison@bt.com" <neil.2.harrison@bt.com>, "swallow@cisco.com" <swallow@cisco.com>, "mpls@ietf.org" <mpls@ietf.org> Date: Wed, 27 Apr 2011 12:15:51 -0400 Thread-Topic: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gAS8t1AAEb7ynA= Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F10B070DAEA2@EUSAACMS0701.eamcs.ericsson.se> References: <C9DB5CFF.32D1F%swallow@cisco.com> <6D3D47CB84BDE349BC23BF1C94E316E44021014C34@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E44021014C34@EMV62-UKRD.domain1.systemhost.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_C0AC8FAB6849AB4FADACCC70A949E2F10B070DAEA2EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 27 Apr 2011 16:16:04 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B070DAEA2EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Neil, In short-form, are you saying that you support the restriction, or that= you think doing so is a bad idea? -- Eric ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of nei= l.2.harrison@bt.com Sent: Tuesday, April 26, 2011 4:15 AM To: swallow@cisco.com; mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? George, IMO this is a disaster (on many levels).....see a few remarks in-line: ---[SNIP]--- --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B070DAEA2EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:x =3D=20 "urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20 "urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20 "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20 "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20 "urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =3D= =20 "urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20 "urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20 "urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20 "urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20 "http://www.w3.org/TR/REC-html40" xmlns:q =3D=20 "http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc =3D=20 "http://microsoft.com/officenet/conferencing" XMLNS:D =3D "DAV:" XMLNS:Repl= =3D=20 "http://schemas.microsoft.com/repl/" xmlns:mt =3D=20 "http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2 =3D=20 "http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda =3D=20 "http://www.passport.com/NameSpace.xsd" xmlns:ois =3D=20 "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20 "http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20 "http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20 "http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20 "http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20 "http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20 "http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =3D= =20 "http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20 "http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20 "http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20 "http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs =3D=20 "http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf =3D=20 "http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p =3D=20 "http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf =3D=20 "http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss =3D=20 "http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi =3D=20 "http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi =3D=20 "http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mv= er =3D=20 "http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =3D=20 "http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20 "http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp = =3D=20 "http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t =3D=20 "http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =3D= =20 "http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl = =3D=20 "http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl =3D= =20 "http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksServ= ice"=20 XMLNS:Z =3D "urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD><TITLE>Mi= xing ICC and Global-IDs in MPLS-TP Identifiers?
    Neil,
     
        In short-form, are you saying= that=20 you support the restriction, or that you
    think doing so is a bad idea?
     
    --
    Eric
    From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 neil.2.harrison@bt.com
    Sent: Tuesday, April 26, 2011 4:15=20 AM
    To: swallow@cisco.com; mpls@ietf.org
    Subject: Re: [m= pls]=20 Mixing ICC and Global-IDs in MPLS-TP Identifiers?

    George,<= /o:p>

     

    IMO this is a= =20 disaster (on many levels).....see a few remarks in-line:<= /P>

     

    ---[SNIP]---

    --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B070DAEA2EUSAACMS0701e_-- From Manuel.Paul@telekom.de Wed Apr 27 10:07:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BB5E0754 for ; Wed, 27 Apr 2011 10:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1ycf1TGgoGg for ; Wed, 27 Apr 2011 10:07:15 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 51D33E0681 for ; Wed, 27 Apr 2011 10:07:15 -0700 (PDT) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 27 Apr 2011 19:06:58 +0200 Received: from HE101452.emea1.cds.t-internal.com ([169.254.2.70]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Wed, 27 Apr 2011 19:06:58 +0200 From: To: Date: Wed, 27 Apr 2011 19:06:58 +0200 Thread-Topic: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQAcOhQ2A= Message-ID: <9435EDACD941174099E143BCA2BCD615F720ACBE18@HE101452.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: rcallon@juniper.net Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 17:07:16 -0000 U3VwcG9ydC4NCg0KUmVnYXJkcywNCk1hbnVlbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFJvc3MgQ2FsbG9uDQo+IFNlbnQ6IE1vbmRheSwgQXBy aWwgMTgsIDIwMTEgNToxNiBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbbXBs c10gcG9sbCBvbiBkcmFmdC1rb21wZWxsYS1tcGxzLWVudHJvcHktbGFiZWwgYXMgTVBMUyBXRw0K PiBkb2N1bWVudA0KPg0KPiBBbGwsDQo+DQo+IHRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3 b3JraW5nIGdyb3VwIHBvbGwgb24gd2hldGhlciB0byBtYWtlDQo+IGRyYWZ0LWtvbXBlbGxhLW1w bHMtZW50cm9weS1sYWJlbCBhbiBtcGxzIHdnIGRvY3VtZW50Lg0KPg0KPiBQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzQGlldGYub3JnIG1haWxpbmcgbGlzdC4NCj4NCj4gVGhl IHBvbGwgZW5kcyBvbiBNYXkgM3JkLg0KPg0KPiB0aGFua3MgUm9zcyAoYXMgV0cgY28tY2hhaXIp DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1w bHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From jeff.tantsura@ericsson.com Wed Apr 27 10:40:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A91E07E6 for ; Wed, 27 Apr 2011 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[AWL=1.867, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix5CAJrdQrF0 for ; Wed, 27 Apr 2011 10:40:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3034AE07C7 for ; Wed, 27 Apr 2011 10:40:37 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3RHeV53020246; Wed, 27 Apr 2011 12:40:36 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 27 Apr 2011 13:40:25 -0400 From: Jeff Tantsura To: "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 27 Apr 2011 13:36:35 -0400 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf8DO6ugZR48+Q0S8eWSulklcNgAgeLMg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CABEC58DA@EUSAACMS0701.eamcs.ericsson.se> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.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 Cc: "rcallon@juniper.net" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 17:40:37 -0000 Yes/support Regards, Jeff =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa= @pi.nu Sent: Tuesday, April 26, 2011 19:06 To: mpls@ietf.org Cc: rcallon@juniper.net Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From malcolm.betts@zte.com.cn Wed Apr 27 15:44:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BF6E07B5; Wed, 27 Apr 2011 15:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.598 X-Spam-Level: X-Spam-Status: No, score=-101.598 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isOlAc3MECyK; Wed, 27 Apr 2011 15:44:31 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4C126E07AE; Wed, 27 Apr 2011 15:44:30 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 125201784411434; Thu, 28 Apr 2011 06:43:09 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 32266.2273265708; Thu, 28 Apr 2011 06:32:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3RMiMY5093066; Thu, 28 Apr 2011 06:44:22 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: To: Eric Gray MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 27 Apr 2011 18:44:10 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-28 06:44:22, Serialize complete at 2011-04-28 06:44:22 Content-Type: multipart/alternative; boundary="=_alternative 007CE7D48525787F_=" X-MAIL: mse01.zte.com.cn p3RMiMY5093066 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:44:32 -0000 This is a multipart message in MIME format. --=_alternative 007CE7D48525787F_= Content-Type: text/plain; charset="US-ASCII" Eric, If you "stitch" the LSP or PW and change identifiers you will not have end to end OAM which is a requirement for a MPLS-TP transport network. Regards, Malcolm Eric Gray Sent by: mpls-bounces@ietf.org 27/04/2011 12:11 PM To George Swallow , "mpls@ietf.org" cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? As one of the co-authors on this draft, I support a restriction to using a common form of identifier throughout an LSP or PW. In my opinion, it is far better to terminate LSPs or PWs at the point where there might be an identifier form change and "stitch" them together if that is what the operators want/agree to do. This limits the need-to-know for the mapping of one form of identifier to the other to the point at which this occurs, rather than at each node in the LSP or (potentially) MS-PW. From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends. Mixed use is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure. Many organizations if not most already have AS Numbers. 2. Such an addition will add numerous object formats, and test cases. 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes of ICC and Global-ID identification is required, they can be added later. 4. For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC. That would be a radical change to how IP works. However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 007CE7D48525787F_= Content-Type: text/html; charset="US-ASCII"
    Eric,

    If you "stitch" the LSP or PW and change identifiers you will not have end to end OAM which is a requirement for a MPLS-TP transport network.

    Regards,

    Malcolm



    Eric Gray <eric.gray@ericsson.com>
    Sent by: mpls-bounces@ietf.org

    27/04/2011 12:11 PM

    To
    		George Swallow <swallow@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
    cc
    Subject
    		Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?





    As one of the co-authors on this draft, I support a restriction to using a common
    form of identifier throughout an LSP or PW.
     
    In my opinion, it is far better to terminate LSPs or PWs at the point where there
    might be an identifier form change and "stitch" them together if that is what the
    operators want/agree to do.  This limits the need-to-know for the mapping of one
    form of identifier to the other to the point at which this occurs, rather than at each
    node in the LSP or (potentially) MS-PW.

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow
    Sent:     Monday, April 25, 2011 5:17 PM
    To:     mpls@ietf.org
    Subject:     [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends.  Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this.  
    1.        Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure.  Many organizations if not most already have AS Numbers.
    2.        Such an addition will add numerous object formats, and test cases.
    3.        The extent inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID identification is required, they can be added later.
    4.        For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC.  That would be a radical change to how IP works.  However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.

    We are looking for input/consensus from the WG.

    George, Eric, & Matthew     _______________________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls
    --=_alternative 007CE7D48525787F_=-- From malcolm.betts@zte.com.cn Wed Apr 27 15:49:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54892E0787 for ; Wed, 27 Apr 2011 15:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.638 X-Spam-Level: X-Spam-Status: No, score=-101.638 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkE2QvDgXqLl for ; Wed, 27 Apr 2011 15:49:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A855AE0780 for ; Wed, 27 Apr 2011 15:49:48 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12520806486374; Thu, 28 Apr 2011 06:48:31 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 32266.2396211085; Thu, 28 Apr 2011 06:37:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3RMnhCu080222; Thu, 28 Apr 2011 06:49:43 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326403B78D19@DEMUEXC014.nsn-intra.net> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 27 Apr 2011 18:49:33 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-28 06:49:43, Serialize complete at 2011-04-28 06:49:43 Content-Type: multipart/alternative; boundary="=_alternative 007D65D68525787F_=" X-MAIL: mse02.zte.com.cn p3RMnhCu080222 Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:49:52 -0000 This is a multipart message in MIME format. --=_alternative 007D65D68525787F_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Nurit, The initial last call of this draft was one year ago. How much longer do=20 we need to study this before all the requirements can be met. I see no major problems, please identify some specific issues. If mixing of identifier types is not allowed then it will be a significant = impediment to the deployment of MPLS-TP in a multi carrier transport=20 network application. Regards, Malcolm "Sprecher, Nurit (NSN - IL/Hod HaSharon)" =20 27/04/2011 01:43 AM To , "George Swallow" cc Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi, I think such mixing environment requires more study. We need to better=20 understand the applicability and the implications on all components and=20 planes? When such a mixing environment is completely analyzed and understood, if=20 needed can be added in a later phase.=20 IMO, in the meantime the document should both ICC OR IP environments, with = no mixing identifiers.=20 Best regards, Nurit =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 ext Malcolm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 7:05 AM To: George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 George,=20 I do not agree the proposed resolution of this comment. As stated in the=20 draft allows an operator can select the use of either Global (IP) or ICC=20 based identifiers. Insisting that both ends of a LSP or PW must use the=20 same scheme removes the freedom to select the between ICC and Global (IP)=20 identifiers.=20 MPLS-TP requires that the data plane and control plane are independent,=20 including having independent identifiers. The draft describes the mapping = between the GMPLS identifiers used by the control plane and the data plane = identifiers.=20 >From the perspective of the data plane an identifier is inserted at the=20 source and received by the sink. Neither the source or sink need to=20 understand the semantics of the identifier, all a sink needs to, for=20 example, to verify connectivity is to check that the received identifier=20 string matches the expected identifier string.=20 Please see in-line below.=20 Regards,=20 Malcolm=20 George Swallow =20 Sent by: mpls-bounces@ietf.org=20 25/04/2011 05:16 PM=20 To =20 cc Subject [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 All - Many of the comments received from the ITU on=20 draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC=20 identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify=20 each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG=20 to use either the Global-ID for both ends or or the ICC for both ends.=20 Mixed use is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. =20 1. Obtaining an AS Number (from which the Global-ID is derived) is=20 a fairly trivial procedure. Many organizations if not most already have=20 AS Numbers.=20 [MB] Many organizations already have process in place to use ICC based=20 identifiers for the data plane changing to IP based identifiers would be a = major burden.=20 2. Such an addition will add numerous object formats, and test=20 cases.=20 [MB] Why - the data plane does not need to interpret the string, just=20 check that it matches the expected string=20 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed=20 modes of ICC and Global-ID identification is required, they can be added=20 later.=20 [MB] This would be a major roadblock to the use of MPLS-TP in an inter=20 provider transport network=20 4. For signaled connections, there is no plan to allow routing=20 based on either the Global-ID or ICC. That would be a radical change to=20 how IP works. However for IP routing to work (in order to forward the=20 signaling messages), the providers involved will need to run BGP and have=20 AS numbers.=20 [MB] The control plane identifiers must be independent of the data plane=20 identifiers.=20 We are looking for input/consensus from the WG. George, Eric, & Matthew =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 --=_alternative 007D65D68525787F_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
    Nurit,

    The initial last call of this draft was one year ago.  How much longer do we need to study this before all the requirements can be met.

    I see no major problems, please iden= tify some specific issues.

    If mixing of identifier types is not allowed then it will be a significant impediment to the deployment of MPLS-= TP in a multi carrier transport network application.

    Regards,

    Malcolm



    "Sprecher, Nurit= (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>

    27/04/2011 01:43 AM

    To
    		<Malcolm.BETTS@zte.com.cn>, &q= uot;George Swallow" <swallow@cisco.com>
    cc
    		<mpls@ietf.org>
    Subject
    		RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?





    Hi,
    I think such mixing env= ironment requires more study. We need to better understand the applicability and the implications on all components and planes…
    When such a mixing envi= ronment is completely analyzed and understood, if needed can be added in a later phase.
    IMO, in the meantime the document should both ICC OR IP environments, with no mixing identifiers.
    Best regards,
    Nurit
     
    From: mpls-bounces@ietf.org [mail= to:mpls-bounces@ietf.org] On Behalf Of ext Malcolm.BETTS@zte.com.cn
    Sent:     Wednesday, April 27, 2011 7:05 AM
    To:     George Swallow
    Cc:     mpls@ietf.org
    Subject:     Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
     

    George,

    I do not agree the proposed resolution of this comment.  As stated in the draft allows an operator can select the use of either Global (IP) or ICC based identifiers.  Insisting that both ends of a LSP or PW must use the same scheme removes the freedom to select the between ICC and Global (IP) identifiers.

    MPLS-TP requires that the data plane and control plane are independent, including having independent identifiers.  The draft describes the mapping between the GMPLS identifiers used by the control plane and the data plane identifiers.

    >From the perspective of the data plane an identifier is inserted at the source and received by the sink.  Neither the source or sink need to understand the semantics of the identifier, all a sink needs to, for example, to verify connectivity is to check that the received identifier string matches the expected identifier string.

    Please see in-line below.
    Regards,

    Malcolm


    George Swallow <swallow= @cisco.com>
    Sent by: mpls-bounces@ietf.org    25/04/2011 05:16 PM
    To
    		<mpls@ietf.org><= font size=3D3 face=3D"Times New Roman">
    cc
    Subject
    		[mpls] Mixing ICC and Global-IDs in MPLS-= TP Identifiers?

     







    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends.  Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this.  

    1.            Obtain= ing an AS Number (from which the Global-ID is derived) is a fairly trivial procedure.  Many organizations if not most already have AS Numbers.
    [MB] Many organizations already have process in place to use ICC based identifiers for the data plane changing to IP based identifiers would be a major burden.
    2.            Such an addition will add numerous object formats, and test cases.
    [MB]  Why - the data plane does not need to interpret the string, just check that it matches the expected string
    3.            The ex= tent inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID identification is required, they can be added later.
    [MB]  This would be a major roadblock to the use of MPLS-TP in an inter provider transport network
    4.            For si= gnaled connections, there is no plan to allow routing based on either the Global-ID or ICC.  That would be a radical change to how IP works.  However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.
    [MB] The control plane identifiers must be independent of the data plane identifiers.

    We are looking for input/consensus from the WG.

    George, Eric, & Matthew     =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
    --=_alternative 007D65D68525787F_=-- From jdrake@juniper.net Wed Apr 27 15:58:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60131E07D8; Wed, 27 Apr 2011 15:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOS69p2DZTXN; Wed, 27 Apr 2011 15:58:16 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id A81E7E07CB; Wed, 27 Apr 2011 15:58:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTbifgrAMVqbvFFImhNV32lcUH2dwQFC4@postini.com; Wed, 27 Apr 2011 15:58:15 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 27 Apr 2011 15:53:23 -0700 From: John E Drake To: "Malcolm.BETTS@zte.com.cn" , Eric Gray Date: Wed, 27 Apr 2011 15:53:21 -0700 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwFLLJxeWNsB1qCTHCmlQSxiwfQcAAAM01Q Message-ID: <5E893DB832F57341992548CDBB333163A0977707D0@EMBX01-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: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A0977707D0EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:58:18 -0000 --_000_5E893DB832F57341992548CDBB333163A0977707D0EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, That's incorrect. There is a single end-to-end LSP composed of different p= ieces, each under the control of a different administrative entity. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 3:44 PM To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Eric, If you "stitch" the LSP or PW and change identifiers you will not have end = to end OAM which is a requirement for a MPLS-TP transport network. Regards, Malcolm Eric Gray Sent by: mpls-bounces@ietf.org 27/04/2011 12:11 PM To George Swallow , "mpls@ietf.org" cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? As one of the co-authors on this draft, I support a restriction to using a = common form of identifier throughout an LSP or PW. In my opinion, it is far better to terminate LSPs or PWs at the point where= there might be an identifier form change and "stitch" them together if that is wh= at the operators want/agree to do. This limits the need-to-know for the mapping o= f one form of identifier to the other to the point at which this occurs, rather t= han at each node in the LSP or (potentially) MS-PW. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a= fairly trivial procedure. Many organizations if not most already have AS = Numbers. 2. Such an addition will add numerous object formats, and test cases= . 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des of ICC and Global-ID identification is required, they can be added late= r. 4. For signaled connections, there is no plan to allow routing based= on either the Global-ID or ICC. That would be a radical change to how IP = works. However for IP routing to work (in order to forward the signaling m= essages), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_5E893DB832F57341992548CDBB333163A0977707D0EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Malcolm,<= o:p>

     

    That’s incorrect.  There is a sing= le end-to-end LSP composed of different pieces, each under the control of a= different administrative entity.  

     

    Thanks,

     

    John  

     

    = Sent from my iPhone

     

    <= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ma= lcolm.BETTS@zte.com.cn
    Sent: Wednesday, April 27, 2011 3:44 PMTo: Eric Gray
    Cc: mpls@ietf.org; mpls-bounces@ietf.orgSubject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifier= s?

     <= /p>


    Eric,

    If you "= stitch" the LSP or PW and change identifiers you will not have end to = end OAM which is a requirement for a MPLS-TP transport network.
    =
    Regar= ds,

    Malcolm


    Eric Gray <eric.gray@ericsson.com> <= br>Sent by= : mpls-bounces@ietf.org

    27/04/2011 12:11 PM

    		<= /tr>

    To

    George Swallow <swallow@cisco.com>, &= quot;mpls@ietf.org" <mpls@ietf.org>

    cc

    Subject

    Re: [mpls] Mix= ing ICC and Global-IDs in MPLS-TP Identifiers?

     




    As one of the co-authors on this dr= aft, I support a restriction to using a common
    form of identif= ier throughout an LSP or PW.
     
    In my opinion, it is f= ar better to terminate LSPs or PWs at the point where there
    mi= ght be an identifier form change and "stitch" them together if th= at is what the
    operators want/agree to do.  This limits t= he need-to-know for the mapping of one
    form of identifier to t= he other to the point at which this occurs, rather than at each
    = node in the LSP or (potentially) MS-PW.

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beha= lf Of George Swallow
    Sent:     Monday, April 25, 2011 5:17 PM<= br>To: mpls@ietf.org
    Subject:     [mpls] Mixing ICC and Global-ID= s in MPLS-TP Identifiers?

    All -

    Many of the comments received= from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Glob= al and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG= include fields to identify each end of an LSP.  Currently the draft a= llows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends o= r or the ICC for both ends.  Mixed use is not permitted.

    The IT= U liaison requests that we allow mixed use.

    The authors of the draft= are very reluctant to do this.  

    1.        <= /span>O= btaining an AS Number (from which the Global-ID is derived) is a fairly tri= vial procedure.  Many organizations if not most already have AS Number= s.
    2.        Such an addition will add numerous objec= t formats, and test cases.
    3.        The extent inter= -provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Global= -ID identification is required, they can be added later.
    4.    =    For signaled connections, there is no plan to allow routing b= ased on either the Global-ID or ICC.  That would be a radical change t= o how IP works.  However for IP routing to work (in order to forward t= he signaling messages), the providers involved will need to run BGP and hav= e AS numbers.

    We are looking for input/consensus from the WG.
    George, Eric, & Matthew     _= ______________________________________________
    mpls mailing listmpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls

    = --_000_5E893DB832F57341992548CDBB333163A0977707D0EMBX01HQjnprn_-- From jdrake@juniper.net Wed Apr 27 15:59:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D16E06F9 for ; Wed, 27 Apr 2011 15:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxnhcMHB1YJI for ; Wed, 27 Apr 2011 15:59:12 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id C3046E07E1 for ; Wed, 27 Apr 2011 15:59:05 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTbiftY70K92gfImR9zn3aCqq2DLSHFk6@postini.com; Wed, 27 Apr 2011 15:59:05 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 27 Apr 2011 15:56:44 -0700 From: John E Drake To: "Malcolm.BETTS@zte.com.cn" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Date: Wed, 27 Apr 2011 15:56:42 -0700 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwFLXFUgOGMghPnTPOvVG5JPt6C5wAAIv/g Message-ID: <5E893DB832F57341992548CDBB333163A0977707D8@EMBX01-HQ.jnpr.net> References: <077E41CFFD002C4CAB7DFA4386A5326403B78D19@DEMUEXC014.nsn-intra.net> 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_5E893DB832F57341992548CDBB333163A0977707D8EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:59:15 -0000 --_000_5E893DB832F57341992548CDBB333163A0977707D8EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, Please see the other email I just sent on this topic. LSP stitching and mu= lti-segment psedowire were designed to handle situations in which different= administrative domains each control different pieces of an end-to-end LSP = or pseudowire. Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 3:50 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Nurit, The initial last call of this draft was one year ago. How much longer do w= e need to study this before all the requirements can be met. I see no major problems, please identify some specific issues. If mixing of identifier types is not allowed then it will be a significant = impediment to the deployment of MPLS-TP in a multi carrier transport networ= k application. Regards, Malcolm "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 27/04/2011 01:43 AM To , "George Swallow" cc Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi, I think such mixing environment requires more study. We need to better unde= rstand the applicability and the implications on all components and planes.= .. When such a mixing environment is completely analyzed and understood, if ne= eded can be added in a later phase. IMO, in the meantime the document should both ICC OR IP environments, with = no mixing identifiers. Best regards, Nurit From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Malcolm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 7:05 AM To: George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? George, I do not agree the proposed resolution of this comment. As stated in the d= raft allows an operator can select the use of either Global (IP) or ICC bas= ed identifiers. Insisting that both ends of a LSP or PW must use the same = scheme removes the freedom to select the between ICC and Global (IP) identi= fiers. MPLS-TP requires that the data plane and control plane are independent, inc= luding having independent identifiers. The draft describes the mapping bet= ween the GMPLS identifiers used by the control plane and the data plane ide= ntifiers. >From the perspective of the data plane an identifier is inserted at the sou= rce and received by the sink. Neither the source or sink need to understan= d the semantics of the identifier, all a sink needs to, for example, to ver= ify connectivity is to check that the received identifier string matches th= e expected identifier string. Please see in-line below. Regards, Malcolm George Swallow Sent by: mpls-bounces@ietf.org 25/04/2011 05:16 PM To cc Subject [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a= fairly trivial procedure. Many organizations if not most already have AS = Numbers. [MB] Many organizations already have process in place to use ICC based iden= tifiers for the data plane changing to IP based identifiers would be a majo= r burden. 2. Such an addition will add numerous object formats, and test cases= . [MB] Why - the data plane does not need to interpret the string, just chec= k that it matches the expected string 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des of ICC and Global-ID identification is required, they can be added late= r. [MB] This would be a major roadblock to the use of MPLS-TP in an inter pro= vider transport network 4. For signaled connections, there is no plan to allow routing based= on either the Global-ID or ICC. That would be a radical change to how IP = works. However for IP routing to work (in order to forward the signaling m= essages), the providers involved will need to run BGP and have AS numbers. [MB] The control plane identifiers must be independent of the data plane id= entifiers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_5E893DB832F57341992548CDBB333163A0977707D8EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Malcolm,<= o:p>

     

    Please see the other email I just sent on thi= s topic.  LSP stitching and multi-segment psedowire were designed to h= andle situations in which different administrative domains each control dif= ferent pieces of an end-to-end LSP or pseudowire.

     

    Sent from my iPhone

    <= o:p> 

    From: mp= ls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malc= olm.BETTS@zte.com.cn
    Sent: Wednesday, April 27, 2011 3:50 PM
    <= b>To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
    Cc: mpls@ietf.o= rg
    Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Ident= ifiers?

     


    Nurit,
    The ini= tial last call of this draft was one year ago.  How much longer do we = need to study this before all the requirements can be met.

    <= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I see no m= ajor problems, please identify some specific issues.

    If mixing of ide= ntifier types is not allowed then it will be a significant impediment to th= e deployment of MPLS-TP in a multi carrier transport network application.

    Regards,

    Malcolm


    "Sprecher, Nurit (NSN - IL/Hod HaS= haron)" <nurit.sprecher@nsn.com>

    27/04/2011 01:4= 3 AM

    		<= /table>

     

    To

    <Malcolm.BETTS@zte.co= m.cn>, "George Swallow" <swallow@cisco.com> =

    cc<= /o:p>

    		<mpls@ietf.org>

    Subject

    RE: [mpls] Mixing = ICC and Global-IDs in MPLS-TP Identifiers?




    Hi,
    I think such = mixing environment requires more study. We need to better understand the ap= plicability and the implications on all components and planes…=
    When such a mixing environment is completely analyzed and under= stood, if needed can be added in a later phase.
    IMO, in t= he meantime the document should both ICC OR IP environments, with no mixing= identifiers.
    Best regards,
    Nurit
     
    From: mpls-bounces@ietf.org [mailto:mpls-bounc= es@ietf.org] On Behalf Of ext Malcolm.BETTS@zte.com.cn
    Sent: Wednesday, April 27, 2011 7:05 AM
    To:     George Swallow
    Cc:=     mpls@ietf.org
    Subject:     Re: [mpls] Mixing ICC and Global-IDs = in MPLS-TP Identifiers?
     

    George,

    I do not agree the p= roposed resolution of this comment.  As stated in the draft allows an = operator can select the use of either Global (IP) or ICC based identifiers.=  Insisting that both ends of a LSP or PW must use the same scheme rem= oves the freedom to select the between ICC and Global (IP) identifiers.
    <= br>MPLS-TP requires that the data plane and control plane are independent, = including having independent identifiers.  The draft describes the map= ping between the GMPLS identifiers used by the control plane and the data p= lane identifiers.

    From the perspective of the data plane an identifie= r is inserted at the source and received by the sink.  Neither the sou= rce or sink need to understand the semantics of the identifier, all a sink = needs to, for example, to verify connectivity is to check that the received= identifier string matches the expected identifier string.

    Please see= in-line below.

    Regards,

    Malcolm

    =

    George Swallow <swallow@= cisco.com>
    Sent by: mpls-bounces@ietf.org

    = 25/04/2011= 05:16 PM

    =  

    To

    <mpls@ietf.org>

    cc

    Subject

    [mpls] Mixing ICC and Global-IDs= in MPLS-TP Identifiers?


     

     




    All -

    Many of the comments received from the ITU on draft-iet= f-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers.
    The identifiers for Tunnel, LSP, PW, and MEG include fields to identif= y each end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, o= r MEG to use either the Global-ID for both ends or or the ICC for both ends= .  Mixed use is not permitted.

    The ITU liaison requests that we= allow mixed use.

    The authors of the draft are very reluctant to do = this.  

    1.            Obtaining an AS Number (fro= m which the Global-ID is derived) is a fairly trivial procedure.  Many= organizations if not most already have AS Numbers.
    [MB] Many organizatio= ns already have process in place to use ICC based identifiers for the data = plane changing to IP based identifiers would be a major burden.
    2. &nbs= p;          Such an addition will add numerous object formats, a= nd test cases.
    [MB]  Why - the data plane does not need to interpret= the string, just check that it matches the expected string
    3.   &nb= sp;        The extent inter-provider MPLS-TP is as yet unknown.  = ;If mixed modes of ICC and Global-ID identification is required, they can b= e added later.
    [MB]  This would be a major roadblock to the use of M= PLS-TP in an inter provider transport network
    4.       &nb= sp;    For signaled connections, there is no plan to allow routing based on eit= her the Global-ID or ICC.  That would be a radical change to how IP wo= rks.  However for IP routing to work (in order to forward the signalin= g messages), the providers involved will need to run BGP and have AS number= s.
    [MB] The control plane identifiers must be independent of the data pla= ne identifiers.

    We are looking for input/consensus from the WG.
    =
    George, Eric, & Matthew     _______________________________________________
    m= pls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/= mpls

    = --_000_5E893DB832F57341992548CDBB333163A0977707D8EMBX01HQjnprn_-- From gregimirsky@gmail.com Wed Apr 27 16:11:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10CE0713; Wed, 27 Apr 2011 16:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.035 X-Spam-Level: X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKs+Ezj2u-Vu; Wed, 27 Apr 2011 16:11:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87036E0678; Wed, 27 Apr 2011 16:11:27 -0700 (PDT) Received: by iwn39 with SMTP id 39so2276529iwn.31 for ; Wed, 27 Apr 2011 16:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G+ipLe5f2nZjfJLYh8z7syt4iXuoOGsPgfvss0LnzwA=; b=iqkHuxb/SJRJWlR3GqcLkLJ0GKmMu8p/W52uEADhI7ibwcO3uQqlaAKj0J062yFsbd 1Dl6/YdiAa6CI1P44EpC/Ya3dqDmAuTAQlOBCe0aqDQkC2bswzvEzEXvwkuEqWAgao4U YK9d2Gf66JhKt/Ux5v5MKx1nY498L5USWo4ew= 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=VRJVERzxpP6HWFRkZJW80jU3R42rbkP1CUDU8v+o6+XWKkXn0U40VA5FVPvYmIu125 o2pmZR+2dHWP0SMN/QFw0duWno8MR/PoGTSkTdFdDwaVu8onrsw83zDSdWSd8CTf87OA EsrwolCa9WL+jMUjki3dpSNEtJPRQf6gvXpwQ= MIME-Version: 1.0 Received: by 10.231.3.144 with SMTP id 16mr2126810ibn.86.1303945886984; Wed, 27 Apr 2011 16:11:26 -0700 (PDT) Received: by 10.231.36.9 with HTTP; Wed, 27 Apr 2011 16:11:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Apr 2011 16:11:26 -0700 Message-ID: From: Greg Mirsky To: Malcolm.BETTS@zte.com.cn Content-Type: multipart/alternative; boundary=0022152d5ded666d3304a1ee8f99 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:11:28 -0000 --0022152d5ded666d3304a1ee8f99 Content-Type: text/plain; charset=ISO-8859-1 Dear Malcolm, I agree that e2e OAM is one of requirements for MPLS-TP but I cannot find implicit, less explicit requirement to support e2e OAM over MPLS-TP LSP and PW with heterogeneous addressing (mixed IP and ICC). Regards, Greg On Wed, Apr 27, 2011 at 3:44 PM, wrote: > > Eric, > > If you "stitch" the LSP or PW and change identifiers you will not have end > to end OAM which is a requirement for a MPLS-TP transport network. > > Regards, > > Malcolm > > > > *Eric Gray * > Sent by: mpls-bounces@ietf.org > > 27/04/2011 12:11 PM > To > George Swallow , "mpls@ietf.org" > cc > Subject > Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > > > As one of the co-authors on this draft, I support a restriction to using a > common > form of identifier throughout an LSP or PW. > > In my opinion, it is far better to terminate LSPs or PWs at the point where > there > might be an identifier form change and "stitch" them together if that is > what the > operators want/agree to do. This limits the need-to-know for the mapping > of one > form of identifier to the other to the point at which this occurs, rather > than at each > node in the LSP or (potentially) MS-PW. > > ------------------------------ > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf Of > *George Swallow* > Sent:* Monday, April 25, 2011 5:17 PM* > To:* mpls@ietf.org* > Subject:* [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > All - > > Many of the comments received from the ITU on > draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC > identifiers. > > The identifiers for Tunnel, LSP, PW, and MEG include fields to identify > each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to > use either the Global-ID for both ends or or the ICC for both ends. Mixed > use is not permitted. > > The ITU liaison requests that we allow mixed use. > > The authors of the draft are very reluctant to do this. > > 1. Obtaining an AS Number (from which the Global-ID is derived) is > a fairly trivial procedure. Many organizations if not most already have AS > Numbers. > 2. Such an addition will add numerous object formats, and test > cases. > 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed > modes of ICC and Global-ID identification is required, they can be added > later. > 4. For signaled connections, there is no plan to allow routing > based on either the Global-ID or ICC. That would be a radical change to how > IP works. However for IP routing to work (in order to forward the signaling > messages), the providers involved will need to run BGP and have AS numbers. > > We are looking for input/consensus from the WG. > > George, Eric, & Matthew _______________________________________________ > > 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 > > --0022152d5ded666d3304a1ee8f99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Malcolm,
    I agree that e2e OAM is one of requirements for MPLS-TP bu= t I cannot find implicit, less explicit requirement to support e2e OAM over= MPLS-TP LSP and PW with heterogeneous addressing (mixed IP and ICC).

    Regards,
    Greg

    On Wed, Apr 27, 2011= at 3:44 PM, <Malcolm.BETTS@zte.com.cn> wrote:

    Eric,

    If you "stitch" the LSP = or PW and change identifiers you will not have end to end OAM which is a requi= rement for a MPLS-TP transport network.

    Regards,

    Malcolm



    Eric Gray <eric.gray@ericsson= .com>
    Sent by: mpls-bounces@ietf.org

    27/04/2011 12:11 PM

    To
    		George Swallow <swallow@cisco.com>, "mpls@ietf.org&= quot; <mpls@ietf.org<= /a>>
    cc
    Subject
    		Re: [mpls] Mixing ICC and Glo= bal-IDs in MPLS-TP Identifiers?





    As one of the co-authors= on this draft, I support a restriction to using a common
    form of identifier throu= ghout an LSP or PW.
    =A0
    In my opinion, it is far= better to terminate LSPs or PWs at the point where there
    might be an identifier f= orm change and "stitch" them together if that is what the
    operators want/agree to = do. =A0This limits the need-to-know for the mapping of one
    form of identifier to th= e other to the point at which this occurs, rather than at each
    node in the LSP or (pote= ntially) MS-PW.

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow
    Sent:     Monday, April 25, 2011 5:17 PM
    To:         mpls@ietf.org
    Subject:     [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP. =A0Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends. =A0Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this. =A0
    1. =A0 =A0 =A0 =A0Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure. =A0Many organizations if not most already have AS Numbers.
    2. =A0 =A0 =A0 =A0Such an addition will add numerous object formats, and test cases.
    3. =A0 =A0 =A0 =A0The extent inter-provider MPLS-TP is as yet unknown. =A0If mixed modes of ICC and Global-ID identification is required, they can be added later.
    4. =A0 =A0 =A0 =A0For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC. =A0That would be a radical change to how IP works. =A0However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.=

    We are looking for input/consensus from the WG.

    George, Eric, & Matthew     _______________________________________________

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

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


    --0022152d5ded666d3304a1ee8f99-- From jdrake@juniper.net Wed Apr 27 16:31:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734A7E07F8; Wed, 27 Apr 2011 16:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOobPTIbxncI; Wed, 27 Apr 2011 16:31:41 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3B78CE066F; Wed, 27 Apr 2011 16:31:41 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTbinWMbhi7CzCUr4N61bz8q5p/ZfDwMq@postini.com; Wed, 27 Apr 2011 16:31:41 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; Wed, 27 Apr 2011 16:25:18 -0700 From: John E Drake To: "Malcolm.BETTS@zte.com.cn" Date: Wed, 27 Apr 2011 16:25:16 -0700 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwFMJQdbd5orz5cRnC61/IdjrAtvAAAOG4A Message-ID: <5E893DB832F57341992548CDBB333163A09777082A@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0977707D0@EMBX01-HQ.jnpr.net> 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_5E893DB832F57341992548CDBB333163A09777082AEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:31:44 -0000 --_000_5E893DB832F57341992548CDBB333163A09777082AEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, I interpreted Eric's use of 'stitching' to be in the RFC 5150 sense. I t= hink I will let him clarify, but if used in the RFC 5150 sense, a 'stitched= ' LSP would have end-to-end OAM, and different pieces could use different i= dentifiers in the control and management planes. Also, as Greg notes, this appears to be a late breaking requirement. Thanks, John Sent from my iPhone From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Wednesday, April 27, 2011 4:11 PM To: John E Drake Cc: Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? John, The proposal from Eric is that the identifiers are "switched" at the stitch= ing point, this requires a complex interworking function and interrupts the= end to end OAM flow - i.e. data packet can transit without any manipulatio= n (other than the normal label swap) but OAM packets must be intercepted an= d manipulated in the middle of the connection so it is no longer an end to = end construct. User data and OAM no longer fully fate share. Regards, Malcolm John E Drake 27/04/2011 06:53 PM To "Malcolm.BETTS@zte.com.cn" , Eric Gray cc "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, That's incorrect. There is a single end-to-end LSP composed of different p= ieces, each under the control of a different administrative entity. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 3:44 PM To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Eric, If you "stitch" the LSP or PW and change identifiers you will not have end = to end OAM which is a requirement for a MPLS-TP transport network. Regards, Malcolm Eric Gray Sent by: mpls-bounces@ietf.org 27/04/2011 12:11 PM To George Swallow , "mpls@ietf.org" cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? As one of the co-authors on this draft, I support a restriction to using a = common form of identifier throughout an LSP or PW. In my opinion, it is far better to terminate LSPs or PWs at the point where= there might be an identifier form change and "stitch" them together if that is wh= at the operators want/agree to do. This limits the need-to-know for the mapping o= f one form of identifier to the other to the point at which this occurs, rather t= han at each node in the LSP or (potentially) MS-PW. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a= fairly trivial procedure. Many organizations if not most already have AS = Numbers. 2. Such an addition will add numerous object formats, and test cases= . 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des of ICC and Global-ID identification is required, they can be added late= r. 4. For signaled connections, there is no plan to allow routing based= on either the Global-ID or ICC. That would be a radical change to how IP = works. However for IP routing to work (in order to forward the signaling m= essages), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_5E893DB832F57341992548CDBB333163A09777082AEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Malcolm,<= o:p>

     

    I interpreted Eric’s use of  ̵= 6;stitching’  to be in the RFC 5150 sense.  I think I will = let him clarify, but if used in the RFC 5150 sense, a ‘stitched’= ; LSP would have end-to-end OAM, and different pieces could use different i= dentifiers in the control and management planes.

     

    Also, as Greg notes, this appears to be a late breaking requirement.

     

    =

    Thanks,

     

    John=

     

    Sent from my iPhone

     

    From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.c= n]
    Sent: Wednesday, April 27, 2011 4:11 PM
    To: John E = Drake
    Cc: Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org
    S= ubject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

     


    John,

    The proposal from = Eric is that the identifiers are "switched" at the stitching poin= t, this requires a complex interworking function and interrupts the end to = end OAM flow - i.e. data packet can transit without any manipulation (other= than the normal label swap) but OAM packets must be intercepted and manipu= lated in the middle of the connection so it is no longer an end to end cons= truct.  User data and OAM no longer fully fate share.

    <= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Regards,

    Malcolm


    John E Drake <jdrake@juniper.net>

    27/04/2011 06:53 PM

    "M= alcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Eric Gray &= lt;eric.gray@ericsson.com>

    To

    cc

    "mpls@ietf.org"= ; <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-bounces= @ietf.org>

    Subject

    RE: [mpls] Mixing ICC and Global-I= Ds in MPLS-TP Identifiers?

     




    Malcolm,
     
    That’s incorrect.  There is a single end-to-end LSP composed o= f different pieces, each under the control of a different administrative en= tity.  
     
    Thanks,
    =  
    John  
     =
    Sent from my iPhone
     
    From:= mpl= s-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malco= lm.BETTS@zte.com.cn
    Sent:     Wednesday, April 27, 2011 3:44 PMTo: Eric Gray
    Cc:     mpls@ietf.org; mpls-bounces@ietf.orgSubject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?<= /span>
     

    Eric,

    If you "stitch" the LSP or PW and ch= ange identifiers you will not have end to end OAM which is a requirement fo= r a MPLS-TP transport network.

    Regards,

    Malcolm

    Eric Gray <eric.g= ray@ericsson.com>
    Sent by: mpls-bounces@ietf.org     =

    27/= 04/2011 12:11 PM

    =  

    To

    George Swallow <swallow@cisco.com>, "mpls@ietf.org" = <mpls@ietf.org>

    cc

    Subject

    Re: [mpls] Mixing ICC and Global-IDs in= MPLS-TP Identifiers?


     

     


    <= br>

    As one of the co-authors on this draft, I support a restrictio= n to using a common
    form of identifier throughout an LSP or PW= .
     
    In my opinion, it is far better to terminate LSPs = or PWs at the point where there
    might be an identifier form ch= ange and "stitch" them together if that is what the
    = operators want/agree to do.  This limits the need-to-know for the mapp= ing of one
    form of identifier to the other to the point at whi= ch this occurs, rather than at each
    node in the LSP or (potent= ially) MS-PW.

     


    From: mpls-bounces@ietf.org [mailto:mpls= -bounces@ietf.org] On Behalf Of George Swallow
    Sent:     Monda= y, April 25, 2011 5:17 PM
    To:     mpls@ietf.org
    Subject:     [m= pls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

    All -

    = Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers.

    The identifiers= for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP= .  Currently the draft allows a Tunnel, LSP, PW, or MEG to use either = the Global-ID for both ends or or the ICC for both ends.  Mixed use is= not permitted.

    The ITU liaison requests that we allow mixed use.
    The authors of the draft are very reluctant to do this.      <= br>
    1.=            Obtaining an AS Number (from which the Global-I= D is derived) is a fairly trivial procedure.  Many organizations if no= t most already have AS Numbers.
    2.            Such an add= ition will add numerous object formats, and test cases.
    3.    =        The extent inter-provider MPLS-TP is as yet unknown.  If= mixed modes of ICC and Global-ID identification is required, they can be a= dded later.
    4.            For signaled connections, there= is no plan to allow routing based on either the Global-ID or ICC.  Th= at would be a radical change to how IP works.  However for IP routing = to work (in order to forward the signaling messages), the providers involve= d will need to run BGP and have AS numbers.

    We are looking for inpu= t/consensus from the WG.

    George, Eric, & Matthew     ________________________= _______________________
    mpls mailing list
    mpls@ietf.org
    https://ww= w.ietf.org/mailman/listinfo/mpls

    <= /html>= --_000_5E893DB832F57341992548CDBB333163A09777082AEMBX01HQjnprn_-- From lizhong.jin@zte.com.cn Wed Apr 27 18:02:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51538E087A for ; Wed, 27 Apr 2011 18:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvAMpuwwD5Vd for ; Wed, 27 Apr 2011 18:02:31 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3183BE066F for ; Wed, 27 Apr 2011 18:02:31 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12520806486374; Thu, 28 Apr 2011 09:01:08 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 4886.1180738496; Thu, 28 Apr 2011 09:02:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3S12HWd028532; Thu, 28 Apr 2011 09:02:17 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Thu, 28 Apr 2011 09:02:17 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-28 09:02:18, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-04-28 09:02:18, Serialize complete at 2011-04-28 09:02:18, S/MIME Sign failed at 2011-04-28 09:02:18: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-28 09:02:17, Serialize complete at 2011-04-28 09:02:17 Content-Type: multipart/alternative; boundary="=_alternative 0005B43D48257880_=" X-MAIL: mse02.zte.com.cn p3S12HWd028532 Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 01:02:32 -0000 This is a multipart message in MIME format. --=_alternative 0005B43D48257880_= Content-Type: text/plain; charset="US-ASCII" Yes, support. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Apr 2011 04:06:29 +0200 > From: loa@pi.nu > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 > Message-ID: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> > Content-Type: text/plain;charset=iso-8859-1 > > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0005B43D48257880_= Content-Type: text/html; charset="US-ASCII"
    Yes, support.

    Regards
    Lizhong


    > ----------------------------------------------------------------------
    >
    > Message: 1
    > Date: Wed, 27 Apr 2011 04:06:29 +0200
    > From: loa@pi.nu
    > To: mpls@ietf.org
    > Cc: rcallon@juniper.net
    > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03
    > Message-ID: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu>
    > Content-Type: text/plain;charset=iso-8859-1
    >
    >
    > Working Group,
    >
    > this is to start a two week poll on making
    >
    > draft-leymann-mpls-seamless-mpls-03
    >
    > an mpls working group document.
    >
    > If you support the document becoming a working group document
    > please respond to this poll with "yes/support"
    >
    > If you do not support the document becoming a working group
    > document please respond to this poll with "no/do not support"
    > and at the same time give the technical reasons why you are
    > not supporting the document.
    >
    > If you have technical comments or in any other way want to
    > discuss the document, please send these comments to the mpls
    > working group mailing list, but with another subject than what
    > is on this mail.
    >
    > The poll ends May 10th.
    >
    > /Loa
    >
    >
    >
    > 
    --------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
    --=_alternative 0005B43D48257880_=-- From curtis@occnc.com Wed Apr 27 20:23:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E42E0793 for ; Wed, 27 Apr 2011 20:23:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLEkBrYl9PE7 for ; Wed, 27 Apr 2011 20:23:07 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 64675E0680 for ; Wed, 27 Apr 2011 20:23:07 -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 p3S3N4Ef078060; Wed, 27 Apr 2011 23:23:04 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104280323.p3S3N4Ef078060@harbor.orleans.occnc.com> To: George Swallow From: Curtis Villamizar In-reply-to: Your message of "Mon, 25 Apr 2011 17:16:47 EDT." Date: Wed, 27 Apr 2011 23:23:04 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 03:23:08 -0000 In message George Swallow writes: > > All - > > Many of the comments received from the ITU on > draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC > identifiers. > > The identifiers for Tunnel, LSP, PW, and MEG include fields to > identify each end of an LSP. Currently the draft allows a Tunnel, > LSP, PW, or MEG to use either the Global-ID for both ends or or the > ICC for both ends. Mixed use is not permitted. > > The ITU liaison requests that we allow mixed use. > > The authors of the draft are very reluctant to do this. > > 1. Obtaining an AS Number (from which the Global-ID is derived) is a > fairly trivial procedure. Many organizations if not most already have > AS Numbers. 2. Such an addition will add numerous object formats, and > test cases. 3. The extent inter-provider MPLS-TP is as yet unknown. > If mixed modes of ICC and Global-ID identification is required, they > can be added later. 4. For signaled connections, there is no plan to > allow routing based on either the Global-ID or ICC. That would be a > radical change to how IP works. However for IP routing to work (in > order to forward the signaling messages), the providers involved will > need to run BGP and have AS numbers. > > We are looking for input/consensus from the WG. > > George, Eric, & Matthew George, I agree with the authors on this. Keep the restriction. Do not allow mixed ICC and IP identifiers. If ever there were a transition necessary an LSR can support both address types during the transition but not have any one PW or LSP with different MEG ID on either side. Curtis From malcolm.betts@zte.com.cn Wed Apr 27 20:25:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542CBE0793; Wed, 27 Apr 2011 20:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.367 X-Spam-Level: X-Spam-Status: No, score=-101.367 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuHlcnQ8CzcN; Wed, 27 Apr 2011 20:25:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E47BDE081C; Wed, 27 Apr 2011 20:25:15 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 125201784411434; Thu, 28 Apr 2011 11:23:46 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 4886.3228747972; Thu, 28 Apr 2011 11:25:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3S3OumX070042; Thu, 28 Apr 2011 11:24:56 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <5E893DB832F57341992548CDBB333163A09777082A@EMBX01-HQ.jnpr.net> To: John E Drake MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 27 Apr 2011 23:24:46 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-28 11:24:57, Serialize complete at 2011-04-28 11:24:57 Content-Type: multipart/alternative; boundary="=_alternative 0012C27585257880_=" X-MAIL: mse02.zte.com.cn p3S3OumX070042 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 03:25:20 -0000 This is a multipart message in MIME format. --=_alternative 0012C27585257880_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable John, John, if you do not allow mix identifier types how can you have an end to=20 end CV message. If you are using stitching to allow a single identifier=20 type then the identifiers in a CV message must be translated at the=20 stitching point. A very bad idea! This is not a "late breaking requirement". The requirements for support=20 of both ICC and IP identifiers schemes is well documented. As is the=20 expectation of using MPLS-TP in multi-operator transport networks. Hence=20 the need to support both on a LSP/PW. This comment has been made during=20 previous last calls on this draft. Regards, Malcolm John E Drake =20 27/04/2011 07:25 PM To "Malcolm.BETTS@zte.com.cn" cc Eric Gray , "mpls@ietf.org" ,=20 "mpls-bounces@ietf.org" Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, =20 I interpreted Eric?s use of ?stitching? to be in the RFC 5150 sense. I=20 think I will let him clarify, but if used in the RFC 5150 sense, a=20 ?stitched? LSP would have end-to-end OAM, and different pieces could use=20 different identifiers in the control and management planes. =20 Also, as Greg notes, this appears to be a late breaking requirement. =20 Thanks, =20 John =20 Sent from my iPhone =20 From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]=20 Sent: Wednesday, April 27, 2011 4:11 PM To: John E Drake Cc: Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 John,=20 The proposal from Eric is that the identifiers are "switched" at the=20 stitching point, this requires a complex interworking function and=20 interrupts the end to end OAM flow - i.e. data packet can transit without=20 any manipulation (other than the normal label swap) but OAM packets must=20 be intercepted and manipulated in the middle of the connection so it is no = longer an end to end construct. User data and OAM no longer fully fate=20 share.=20 Regards,=20 Malcolm=20 John E Drake =20 27/04/2011 06:53 PM=20 To "Malcolm.BETTS@zte.com.cn" , Eric Gray=20 =20 cc "mpls@ietf.org" , "mpls-bounces@ietf.org"=20 =20 Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 Malcolm,=20 =20 That?s incorrect. There is a single end-to-end LSP composed of different=20 pieces, each under the control of a different administrative entity.=20 =20 Thanks,=20 =20 John =20 =20 Sent from my iPhone=20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Malcolm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 3:44 PM To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?=20 =20 Eric,=20 If you "stitch" the LSP or PW and change identifiers you will not have end = to end OAM which is a requirement for a MPLS-TP transport network.=20 Regards,=20 Malcolm=20 Eric Gray =20 Sent by: mpls-bounces@ietf.org=20 27/04/2011 12:11 PM=20 =20 To George Swallow , "mpls@ietf.org" =20 cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 =20 As one of the co-authors on this draft, I support a restriction to using a = common=20 form of identifier throughout an LSP or PW.=20 =20 In my opinion, it is far better to terminate LSPs or PWs at the point=20 where there=20 might be an identifier form change and "stitch" them together if that is=20 what the=20 operators want/agree to do. This limits the need-to-know for the mapping=20 of one=20 form of identifier to the other to the point at which this occurs, rather=20 than at each=20 node in the LSP or (potentially) MS-PW.=20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 George Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on=20 draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC=20 identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify=20 each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG=20 to use either the Global-ID for both ends or or the ICC for both ends.=20 Mixed use is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. =20 1. Obtaining an AS Number (from which the Global-ID is derived) is=20 a fairly trivial procedure. Many organizations if not most already have=20 AS Numbers.=20 2. Such an addition will add numerous object formats, and test=20 cases.=20 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed=20 modes of ICC and Global-ID identification is required, they can be added=20 later.=20 4. For signaled connections, there is no plan to allow routing=20 based on either the Global-ID or ICC. That would be a radical change to=20 how IP works. However for IP routing to work (in order to forward the=20 signaling messages), the providers involved will need to run BGP and have=20 AS numbers.=20 We are looking for input/consensus from the WG. George, Eric, & Matthew =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 --=_alternative 0012C27585257880_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
    John,

    John, if you do not allow mix identi= fier types how can you have an end to end CV message.  If you are using stitching to allow a single identifier type then the identifiers in a CV message must be translated at the stitching point.  A very bad idea!

    This is not a "late breaking re= quirement".  The requirements for support of both ICC and IP identifiers schemes is well documented.  As is the expectation of using MPLS-TP in multi-o= perator transport networks.  Hence the need to support both on a LSP/PW.  = ;This comment has been made during previous last calls on this draft.

    Regards,

    Malcolm



    John E Drake <jdra= ke@juniper.net>

    27/04/2011 07:25 PM

    To
    		"Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>
    cc
    		Eric Gray <eric.gray@ericsson.com= >, "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.or= g" <mpls-bounces@ietf.org>
    Subject
    		RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?





    Malcolm,
     
    I interpreted Eric̵= 7;s use of  ‘stitching’  to be in the RFC 5150 sense.  I= think I will let him clarify, but if used in the RFC 5150 sense, a ‘stitche= d’ LSP would have end-to-end OAM, and different pieces could use different identifiers in the control and management planes.
     
    Also, as Greg notes, th= is appears to be a late breaking requirement.
     
    Thanks,
     
    John
     
    Sent from my iPhone
     
    From: Malcolm.BETTS@zte.com.cn [m= ailto:Malcolm.BETTS@zte.com.cn]
    Sent:     Wednesday, April 27, 2011 4:11 PM
    To:     John E Drake
    Cc:     Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org
    Subject:     RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
     

    John,

    The proposal from Eric is that the identifiers are "switched" at the stitching point, this requires a complex interworking function and interrupts the end to end OAM flow - i.e. data packet can transit without any manipulation (other than the normal label swap) but OAM packets must be intercepted and manipulated in the middle of the connection so it is no longer an end to end construct.  User data and OAM no longer fully fate share.

    Regards,

    Malcolm

    John E Drake <jdrake@ju= niper.net>

    27/04/2011 06:53 PM


    To
    		"Malcolm.BETTS@zte.com.c= n" <Malcolm.BETTS@zte.com.cn>, Eric Gray <eric.gray@ericsson.com><= /font>
    cc
    		"mpls@ietf.org" <mpls@ietf.o= rg>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>
    Subject
    		RE: [mpls] Mixing ICC and Global-IDs in M= PLS-TP Identifiers?

     







    Malcolm,
     
    That’s incorrect.  There is a single end-to-end LSP composed of = different pieces, each under the control of a different administrative entity.  
     
    Thanks,
     
    John  
     
    Sent from my iPhone     <= font size=3D2 color=3D#1f497d face=3D"Calibri">
     
    From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn
    Sent:     Wednesday, April 27, 2011 3:44 PM
    To:     Eric Gray
    Cc:     mpls@ietf.org; mpls-bounces@ietf.org
    Subject:     Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
     

    Eric,

    If you "stitch" the LSP or PW and change identifiers you will not have end to end OAM which is a requirement for a MPLS-TP transport network.

    Regards,

    Malcolm

    Eric Gray <eric.gray@er= icsson.com>
    Sent by: mpls-bounces@ietf.org    27/04/2011 12:11 PM     		 


    To
    		George Swallow <swallow@ci= sco.com>, "mpls@ietf.org" <mpls@ietf.org>
    cc
    Subject
    		Re: [mpls] Mixing ICC and Global-IDs in M= PLS-TP Identifiers?


     

     







    As one of the co-authors on this draft, I support a restriction to using a common
    form of identifier throughout an LSP or PW.

    In my opinion, it is far better to terminate LSPs or PWs at the point where there
    might be an identifier form change and "stitch" them together if that is what the     <= font size=3D2 color=3Dblue face=3D"Arial">
    operators want/agree to do.  This limits the need-to-know for the mapping of one
    form of identifier to the other to the point at which this occurs, rather than at each
    node in the LSP or (potentially) MS-PW.


     


    From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow
    Sent:     Monday, April 25, 2011 5:17 PM
    To:     mpls@ietf.org
    Subject:     [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends.  Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this.  

    1.            Obtain= ing an AS Number (from which the Global-ID is derived) is a fairly trivial procedure.  Many organizations if not most already have AS Numbers.
    2.            Such an addition will add numerous object formats, and test cases.
    3.            The ex= tent inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID identification is required, they can be added later.
    4.            For si= gnaled connections, there is no plan to allow routing based on either the Global-ID or ICC.  That would be a radical change to how IP works.  However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.

    We are looking for input/consensus from the WG.

    George, Eric, & Matthew     =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
    --=_alternative 0012C27585257880_=-- From fjjc@tid.es Thu Apr 28 00:47:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1249E06AF for ; Thu, 28 Apr 2011 00:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v0k1lf3G7HW for ; Thu, 28 Apr 2011 00:47:55 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 90512E06A6 for ; Thu, 28 Apr 2011 00:47:54 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC00AE4QZSXX@tid.hi.inet> for mpls@ietf.org; Thu, 28 Apr 2011 09:47:52 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id A8.67.28958.EB929BD4; Thu, 28 Apr 2011 10:47:58 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LKC00AE1QZRXX@tid.hi.inet> for mpls@ietf.org; Thu, 28 Apr 2011 09:47:52 +0200 (MEST) Received: from [10.95.50.11] (10.95.67.43) by htcasmad2.hi.inet (10.95.67.75) with Microsoft SMTP Server id 8.3.83.0; Thu, 28 Apr 2011 09:47:51 +0200 Date: Thu, 28 Apr 2011 09:47:50 +0200 From: Javier Jimenez In-reply-to: To: undisclosed-recipients: ; Cc: "mpls@ietf.org" Message-id: <4DB91BA6.4000508@tid.es> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hgijd44/6xgAw8UQfOiQpA)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 X-AuditID: 0a5f4e69-b7bd4ae00000711e-f8-4db929be2e54 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsXCFe9nqLtPc6evweeVsha3lq5kdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu6OrcwFmywq+q4tZWxgXGzYxcjBISQgJXHqYymIKSFgIrFz fkYXIyeQKSZx4d56ti5GLqCK7YwSTbcfM4IkRARkJObOfswKkfjBKNExcS8zhDOdUWLWj1cs IFUsAqoS82dMYwax2QSUJB413mQF2SAsYC9x9h4HSJhTIFTi/oE9bCA2s4CyxPvnE8EW8AK1 7lx/nwXCFpT4MfkeC0RNiMSNtS9ZQMaICuRItHzXBgkLAYXPP+9im8AoOAtJxywkHRC2rcSr uxNYIWxtiWULXzND2LoSF/5PYUEWX8DItopRrDipKDM9oyQ3MTMn3cBILyNTLzMvtWQTIyTA M3cwLt+pcohRgINRiYc3wnK7rxBrYllxZe4hRkkOJiVR3smSO32F+JLyUyozEosz4otKc1KL DzFKcDArifA+4AbK8aYkVlalFuXDpGQ4OJQkeNmkgVKCRanpqRVpmTnAOIZJM3FwgrTzALVv kwJpLy5IzC3OTIfIn2LU5vi+5ux+Ro71B4CkEEtefl6qlDjEOAGQ0ozSPLhprxjFgc4W5v0G MogHmJTg5rwCWsEEtKJk/g6QFSWJCCmpBkZdc4dsxX9/u7lyco/nL1nsa34iK/vxoVd6/VHs FvkS6sxml9e65/suS7m7P9pt5S6BjeyTPj7Yf2XpNa1Yz4XVLCbP+vgjl/h/9DQ+nLY66HXO W1G1a7/DpJu+uNtsVe/tO8DK8Lh5YkjZBtbmyhOsU/2eZB7aH/rVUdn0JJ/QtWe50gtSOJVY ijMSDbWYi4oTAQk3I6AHAwAA References: Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 07:47:57 -0000 --Boundary_(ID_hgijd44/6xgAw8UQfOiQpA) Content-type: text/plain; charset=iso-8859-1; format=flowed Content-transfer-encoding: quoted-printable Yes, support. El 28/04/2011 3:02, lizhong.jin@zte.com.cn e= scribi=F3: Yes, support. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Apr 2011 04:06:29 +0200 > From: loa@pi.nu > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 > Message-ID: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> > Content-Type: text/plain;charset=3Diso-8859-1 > > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_hgijd44/6xgAw8UQfOiQpA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Yes, support.

    El 28/04/2011 3:02, lizhong.jin@zte.com.cn escribi=F3:

    Yes, support.

    Regards
    Lizhong


    > ----------------------------------------------------------------------=
    >
    > Message: 1
    > Date: Wed, 27 Apr 2011 04:06:29 +0200
    > From: = loa@pi.nu
    > To: mpls@ietf.org
    > Cc: rcallon@juniper.net
    > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03
    > Message-ID: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu>
    > Content-Type: text/plain;charset=3Diso-8859-1
    >
    >
    > Working Group,
    >
    > this is to start a two week poll on making
    >
    > draft-leymann-mpls-seamless-mpls-03
    >
    > an mpls working group document.
    >
    > If you support the document becoming a working group document
    > please respond to this poll with "yes/support"
    >
    > If you do not support the document becoming a working group
    > document please respond to this poll with "no/do not support"= ;
    > and at the same time give the technical reasons why you are
    > not supporting the document.
    >
    > If you have technical comments or in any other way want to
    > discuss the document, please send these comments to the mpls
    > working group mailing list, but with another subject than what
    > is on this mail.
    >
    > The poll ends May 10th.
    >
    > /Loa
    >
    >
    >
    > 
    --------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

    Este mensaje se dirige exclu= sivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo = y recepci=F3n de correo electr=F3nico en el enlace situado m=E1s abajo.
    This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at.
    http://www.tid.es/ES/PAGINAS/disclaimer.aspx
     --Boundary_(ID_hgijd44/6xgAw8UQfOiQpA)-- From yaakov_s@rad.com Thu Apr 28 00:54:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6288FE06CD for ; Thu, 28 Apr 2011 00:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLeE+6l7K4+5 for ; Thu, 28 Apr 2011 00:54:56 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9F2E06A6 for ; Thu, 28 Apr 2011 00:54:53 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 28 Apr 2011 10:54:52 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 28 Apr 2011 10:52:52 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Thu, 28 Apr 2011 10:54:51 +0300 From: Yaakov Stein To: Carlos Pignataro Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AQHMAOYu+PN/G1PR2kOzoUBIBaPIVpRxsq1A///e+4CAAV7lgA== Date: Thu, 28 Apr 2011 07:52:51 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E423EE@EXRAD5.ad.rad.co.il> References: <4DB1706B.3050602@pi.nu> <07F7D7DED63154409F13298786A2ADC903E41EF7@EXRAD5.ad.rad.co.il> <4DB8207F.2040203@cisco.com> In-Reply-To: <4DB8207F.2040203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 07:54:57 -0000 based on Carlos' answers, I change my position to "support". Y(J)S -----Original Message----- From: Carlos Pignataro [mailto:cpignata@cisco.com]=20 Sent: Wednesday, April 27, 2011 16:56 To: Yaakov Stein Cc: Loa Andersson; mpls@ietf.org; Ross Callon Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Hi Yaakov, Please see inline. On 4/27/2011 8:59 AM, Yaakov Stein wrote: Apologies for dissecting this first sentence in a few fragments: > While I agree in principle that IANA needs well-defined policies, This is not a theoretical principle-driven exercise, but a practical one, as draft-asati-pignataro-mpls-ldp-gtsm [1] [2] needs to allocate a bit (for GTSM negotiation) for which there is no allocation policies. > do we really need an RFC=20 This is what RFC 5226 specifies. Most allocation policies for LDP are included already in RFC 5036 [the why need an RFC applies here too], just not the one we now need. > saying that unallocated bits are to be allocated via "IETF Review". "IETF Review" is the new name for "IETF Consensus", which is the Well-Known IANA policy used in RFC 5036, and hence we think the most direct path forward. >=20 > Perhaps an IESG clarification statement would suffice.=20 I apologize I do not understand this. But IETF Review includes WG Review, IESG Review, etc. > ... and if not, why only the ATM Label TLV, FR Label TLV, ... ? >=20 We only need, right now, bits in the Common Hello Parameters TLV. But since we are undertaking this work, we chose to comb through RFC 5036 and include all number spaces with undefined policies. > I am sure that there are plenty of underspecified IANA registries. > Are we going to issue RFCs for every underspecified field in every regist= ry ? I hope not -- personally, I am inclusive of all number spaces when writing a protocol RFC. However, when something was not specified at the time, I think that a need-basis is the right approach. > It would seem that an IAB document giving guidelines for all such cases > would be a much more efficient route. >=20 I also do not parse this -- but RFC 5226 is what gives guidelines currently, and beyond guidelines we need the actual doc to define how to allocate the bit we are after. Hope these responses clarify. Thanks, -- Carlos. [1] [2] > Y(J)S >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa Andersson > Sent: Friday, April 22, 2011 15:11 > To: mpls@ietf.org > Cc: Ross Callon > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-asati-pignataro-mpls-ldp-iana-01 >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document > please respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. >=20 > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. >=20 > The poll ends May 8th. >=20 > /Loa From Alexander.Vainshtein@ecitele.com Thu Apr 28 02:14:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA92FE06FB for ; Thu, 28 Apr 2011 02:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGgA8vb6pcHL for ; Thu, 28 Apr 2011 02:14:19 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id D9B50E06B8 for ; Thu, 28 Apr 2011 02:14:18 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-2b-4db92f848a70 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 40.1E.02691.48F29BD4; Thu, 28 Apr 2011 12:12:37 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 28 Apr 2011 12:14:16 +0300 From: Alexander Vainshtein To: "Malcolm.BETTS@zte.com.cn" Date: Thu, 28 Apr 2011 12:14:11 +0300 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwFLfk/gfSfKCr1Tj6aiEKiy5K+uQAViJHQ 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_A3C5DF08D38B6049839A6F553B331C76D722FE2C3EILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURTNm+kyQEeHAvKomNQBwYWlLMYSKJEoRk0aMPqhfihD+2hH22nT GQn4I8QQYo0b7vWDRVQEEoJbIG6AHyKBuEXCImoUN1QwRNk+xBlGkMQ4H5Pz7jnv3JOXewlc e1ytI1hOQB6OcdAqf8XJodEfsSXxzWbDwwHKWOp9rzb2XbqqXIttrK6exDbW35tQZGM7i0Aa w3EugRGQ3op4i4nO9rD5jKWQ1rNWE51A690OxoKciBNMNON2I85Kp/vr//nSRBnL6RFncVlZ zmaiN23NijUaV6fEJtDpUREJSan+2+wsr0exToZ16J2I5xkb0ouVnBu4fazko9p9txMU9Ndd UBeBu9eBF/gRkEqGwyONahkvgk9eNai8wJ/QUrcBLB7zAvlwBsCylteYpFJRJnitbkAl4WAq BR4rvYl7AUHgVATsGAiXoIJaBlu9OyRFEJUJyw8/xGT1BjhWdUUpSYKpRNj4YY1UJqks+LV7 /E/bcwB+9D3HJcKP2gqP9PTNZANitvGO+hkfnAqFfYPlmJyZgtV3HuMyDoGf3/1SyvoQ+LK0 Ach6F/zU3qiUmwXCR+cHFbI+DLbW9CiOg0W+eba+eVd8867I9RhYcXtUJeNV8HLlF3wWd7a8 w+bXK4C6FoSwDreQ67QZEuOQhRWQA8VZXM5rQB6eT02gv3NFG6AIQGtIYk+TWatk8vlCZxsI IzA6hPwa12zWLsh1WQvtDG/f7dnnQHwbgAROB5NvAkSOtDKF+5HHNUtlio9/AtcFWFzimHLC 7iSD4f8HOpQczqk2aymbOJp7EXIjz6xPOEHQkEwWR1sb6EE2VJDHOoS/NEb4STE0YowhKSLJ uxknz9pkvgMkEeVnu+4DoqFC/GsVnItDulAyXrKjJKl9HzfnJi3Sgenp6SEQKj5DELlcUmnE NZvzGxJbYWIrobxJaiUu0hylEyf5REvkSPRl0w9zxtHoF4v51Mqp1jGr5q2wOu/i1Ov8iWdE 15uy9uaIQ1VRE9t1t4oXRkU/ONWx8OByTSR4OrJrZ0pJjfJ5+HpjxunM9i3c5rNLl9R2Tpq+ 1x2ozPoZoV1nGAw6HZZj723pqZkwBI/ei075hncH+gJ6n8QU9dtSsShawduZhJW4h2d+Ay6d 3m0jBAAA Cc: "mpls@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 09:14:23 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D722FE2C3EILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Malcolm, Lots of thanks for a prompt response. I did not ever say this is impossible - just that nobody took care to define= the order so far. An even simpler way would be to say that Global identifiers are always "grea= ter" than ICC-based ones (or vice versa:) - depending on where you come from= ). The point is, have we fully covered all the cases that should be considered= if we allow for mixed identifiers? And would it be really worth the time an= effort spent... Regards, Sasha From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Thursday, April 28, 2011 1:54 AM To: Alexander Vainshtein Cc: mpls@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Sasha, One way of resolving this is to treat the n bytes of the identifier as a bin= ary number. This would ensure consistent behaviour. Regards, Malcolm Alexander Vainshtein 27/04/2011 02:06 AM To "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "Malcolm= .BETTS@zte.com.cn" cc "mpls@ietf.org" , George Swallow Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, Nurit and all, One technical reason for not mixing identifiers of different types is that i= n certain situations these identifiers are treated as an ordered set, i.e.,= it is possible to say when one of these identifiers is "less" than the othe= r one. The typical use case is tie-breaking in various protocols (e.g., for decidin= g which request for a protection-related has to be granted). Even if the cur= rent set of MPLS-TP protocols does not use such tie-breakers, I would not pr= eclude this usage in future. It is relatively simple to impose some order on identifiers of the same type= . Imposing an order on a superset of identifiers at least requires some thou= ght. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spre= cher, Nurit (NSN - IL/Hod HaSharon) Sent: Wednesday, April 27, 2011 8:44 AM To: Malcolm.BETTS@zte.com.cn; George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi, I think such mixing environment requires more study. We need to better under= stand the applicability and the implications on all components and planes... When such a mixing environment is completely analyzed and understood, if nee= ded can be added in a later phase. IMO, in the meantime the document should both ICC OR IP environments, with n= o mixing identifiers. Best regards, Nurit From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Malcolm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 7:05 AM To: George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? George, I do not agree the proposed resolution of this comment. As stated in the dr= aft allows an operator can select the use of either Global (IP) or ICC based= identifiers. Insisting that both ends of a LSP or PW must use the same sch= eme removes the freedom to select the between ICC and Global (IP) identifier= s. MPLS-TP requires that the data plane and control plane are independent, incl= uding having independent identifiers. The draft describes the mapping betwe= en the GMPLS identifiers used by the control plane and the data plane identi= fiers. >From the perspective of the data plane an identifier is inserted at the sour= ce and received by the sink. Neither the source or sink need to understand= the semantics of the identifier, all a sink needs to, for example, to verif= y connectivity is to check that the received identifier string matches the e= xpected identifier string. Please see in-line below. Regards, Malcolm George Swallow Sent by: mpls-bounces@ietf.org 25/04/2011 05:16 PM To cc Subject [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers= -04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each= end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= either the Global-ID for both ends or or the ICC for both ends. Mixed use= is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a= fairly trivial procedure. Many organizations if not most already have AS N= umbers. [MB] Many organizations already have process in place to use ICC based ident= ifiers for the data plane changing to IP based identifiers would be a major= burden. 2. Such an addition will add numerous object formats, and test cases. [MB] Why - the data plane does not need to interpret the string, just check= that it matches the expected string 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mod= es of ICC and Global-ID identification is required, they can be added later. [MB] This would be a major roadblock to the use of MPLS-TP in an inter prov= ider transport network 4. For signaled connections, there is no plan to allow routing based= on either the Global-ID or ICC. That would be a radical change to how IP w= orks. However for IP routing to work (in order to forward the signaling mes= sages), the providers involved will need to run BGP and have AS numbers. [MB] The control plane identifiers must be independent of the data plane ide= ntifiers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76D722FE2C3EILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

    Malcolm,

    Lots of thanks for a prompt res= ponse.

     

    I did not ever say this is impossible R= 11; just that nobody took care to define the order so far.=

     

    An even simpler way would be to say that Global identifiers are al= ways “greater” than ICC-based ones (or vice versaJ= - depending on where you come from).

    The point is, have we fully covered all the cases that should be= considered if we allow for mixed identifiers? And would it be really worth= the time an effort spent…

    <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'> 

    Regards,

         Sasha=

     

    From: Malcolm.BETTS@zte.com.cn [mailto:Malco= lm.BETTS@zte.com.cn]
    Sent: Thursday, April 28, 2011 1:54 AM
    To:     Alexander Vainshtein
    Cc: mpls@ietf.org
    Subject:= RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

     


    Sasha,

    One way of resolving this is to t= reat the n bytes of the identifier as a binary number.  This would ensu= re consistent behaviour.

    Regards,

    Malcolm


    =




    Malco= lm, Nurit and all,
    One technical reason for not mixi= ng identifiers of different types is that in certain situations these identi= fiers are treated as an ordered set, i.e., it is possible to say when one of= these identifiers is “less” than the other one.
    The typical use case is tie-breaking in various protocols (e.g., for decid= ing which request for a protection-related has to be granted). Even if the c= urrent set of MPLS-TP protocols does not use such tie-breakers, I would not= preclude this usage in future.
     
    It= is relatively simple to impose some order on identifiers of the same type.= Imposing an order on a superset of identifiers at least requires some thoug= ht.
     
    Regards,
     = ;    Sasha
     
    From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN= - IL/Hod HaSharon)
    Sent:     Wednesday, April 27, 2011 8:44 AM
    = To:     Malcolm.BETTS@zte.com.cn; George Swallow
    Cc:     mpls@ietf.org=
    Subject:     Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifi= ers?
     
    Hi,
    I think such mixing en= vironment requires more study. We need to better understand the applicabilit= y and the implications on all components and planes…
    When such a mixing environment is completely analyzed and understood, if ne= eded can be added in a later phase.
    IMO, in the meantime th= e document should both ICC OR IP environments, with no mixing identifiers. <= /span>
    Best regards,
    Nurit
     = ;
    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Be= half Of ext Malcolm.BETTS@zte.com.cn
    Sent:     Wednesday, April 27= , 2011 7:05 AM
    To:     George Swallow
    Cc:     mpls@ietf.orgSubject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?<= /span>
     

    George,

    I do not agree the proposed resolution of this= comment.  As stated in the draft allows an operator can select the use= of either Global (IP) or ICC based identifiers.  Insisting that both e= nds of a LSP or PW must use the same scheme removes the freedom to select th= e between ICC and Global (IP) identifiers.

    MPLS-TP requires that the da= ta plane and control plane are independent, including having independent ide= ntifiers.  The draft describes the mapping between the GMPLS identifier= s used by the control plane and the data plane identifiers.

    From the pe= rspective of the data plane an identifier is inserted at the source and rece= ived by the sink.  Neither the source or sink need to understand the se= mantics of the identifier, all a sink needs to, for example, to verify conne= ctivity is to check that the received identifier string matches the expected= identifier string.

    Please see in-line below.

    Regards,
    =
    Malcol= m

    Alexander Vainshtein= <Alexander.Vainshtein@ecitele.com>

    27/04/2011 02:06 AM<= /span>

    		<= tr>

    To

    "Sprecher, Nurit (NSN - IL/Hod= HaSharon)" <nurit.sprecher@nsn.com>, "Malcolm.BETTS@zte.com= .cn" <Malcolm.BETTS@zte.com.cn>

    cc

    "mpls@ietf.= org" <mpls@ietf.org>, George Swallow <swallow@cisco.com>

    Subject<= /span>

    RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifie= rs?

     <= /o:p>

    George= Swallow <swallow@cisco.com>
    Sent by: mpls-bounces@ietf.org    =

    25/04/2011 05:16 PM

     

    To

    		=

    <mpls@ietf.org>

    cc

    Subject

    [mpls] Mixing ICC and Global-IDs in M= PLS-TP Identifiers?


     

     




    <= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'>
    All -=

    Many of the comments received from the ITU on draft-ietf-mpls-tp-ide= ntifiers-04 have to do with the Global and ICC identifiers.

    The ident= ifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of a= n LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to use eit= her the Global-ID for both ends or or the ICC for both ends.  Mixed use= is not permitted.

    The ITU liaison requests that we allow mixed use.<= br>
    The authors of the draft are very reluctant to do this.  =

    1.=            Obtaining an AS Number (from which the Global-ID= is derived) is a fairly trivial procedure.  Many organizations if not= most already have AS Numbers.
    [MB] Many organizations already have process= in place to use ICC based identifiers for the data plane changing to IP bas= ed identifiers would be a major burden.
    2.        Suc= h an addition will add numerous object formats, and test cases.
    [MB]  = Why - the data plane does not need to interpret the string, just check that= it matches the expected string
    3.            The extent in= ter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Glob= al-ID identification is required, they can be added later.
    [MB]  This= would be a major roadblock to the use of MPLS-TP in an inter provider trans= port network
    4.            For signaled connections, there i= s no plan to allow routing based on either the Global-ID or ICC.  That= would be a radical change to how IP works.  However for IP routing to= work (in order to forward the signaling messages), the providers involved w= ill need to run BGP and have AS numbers.
    [MB] The control plane identifiers= must be independent of the data plane identifiers.

    We are looking fo= r input/consensus from the WG.

    George, Eric, & Matthew     ____________________= ___________________________
    mpls mailing list
    mpls@ietf.org
    https:/= /www.ietf.org/mailman/listinfo/mpls

    This e-mail mes= sage is intended for the recipient only and contains information which is CO= NFIDENTIAL and which may be proprietary to ECI Telecom. If you have received= this transmission in error, please inform us by e-mail, phone or fax, and t= hen delete the original and all copies thereof.

    <= p> This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

    --_000_A3C5DF08D38B6049839A6F553B331C76D722FE2C3EILPTMAIL02eci_-- From Alexander.Vainshtein@ecitele.com Thu Apr 28 02:25:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D53E06C1 for ; Thu, 28 Apr 2011 02:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARxSliD5baz2 for ; Thu, 28 Apr 2011 02:25:22 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 36DADE0697 for ; Thu, 28 Apr 2011 02:25:21 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-c1-4db9321ce091 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id D2.6E.02691.C1239BD4; Thu, 28 Apr 2011 12:23:41 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 28 Apr 2011 12:25:20 +0300 From: Alexander Vainshtein To: Loa Andersson Date: Thu, 28 Apr 2011 12:25:18 +0300 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwErZSqZCdy3wzZRKeVY10qlAiAAwA1yYHQ Message-ID: References: <077E41CFFD002C4CAB7DFA4386A5326403B78D19@DEMUEXC014.nsn-intra.net> <4DB7C709.1070404@pi.nu> In-Reply-To: <4DB7C709.1070404@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-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTaWjTYBjmS9I2q4tk0drPqRAjCtNttJtiPSqCqPXH2HT+UmTG9rONtmlt 4tgEsTp0Op0HHsOiu6w6z+EQtzFxh4g4j81b5jzAKbqJ6PBo8ZhJg3NifoQnea4v4X1JnAkZ kklBlFFQ5L2c3kjs7+3/nDYuozHLUrObsv06egS3FZe8Nti6jp/S2Z6+qDfMJRyRSAxzxGof Ghzhsm16x9krUSKHWBYCs3lR9Mu8jFgXkpx2Lico5PPOQo4VXHbOyrEBL+9EPiTKdo4PBJDo 4uYY2f+u2YpMEFkkOv0uQXTbuUW52Wk227QZaVZuzqQJ1sxZxqUeQWJRmo8XvKwPSRLvRqzy ZuVF3LP55QNd4ODMgmjRG10I1KWWgAQS0lPh3a99Og2Pgp3Pa/UlwEgydCOAPffLMJVg6AMA ft+SqGI9bYd1Z57pVTySHgcfXYphqgGnqwEs3d4RTyLoiTB2L2RQ8Qh6PqzYeR3TDAvg1+qT Og1nwMtNH+Mais6G0av9QGsux+DNW9fiDQlKUM3WH0DFQDnet/az8SCcNsOungpMOzYNI5c7 cA2b4LtXv3Sa3gS7i2uBpk+FlU39eg1PgSeq+nCtOAneONxDaN7RsLXmCbEXmMNDKsJD7OEh 9vAQeyUgTgOT4A3Iq3xuS0Y6cgoy8qJ0p99XB7TJedsAnt5KaQM0CbhEilzTkMXo+Hyp0NcG RpMYZ6KgpTGLGb7K7yr08JInL7jei6Q2AEmcG0kJVoWjXHzhBhT0/6Fsym/ehycPc/qVGRXl vEyL5Z8Hzkx9WBnJYmi3MnZrEQqg4B/rWJLkIKVXRplJCiI3KlgteOW/NEYmqM2JSnNTvFkK 8D5JcGt8O8gkK8puNwOytlK5M4ToF1GymfqpSmlV6lkvDqapi7NpYGCgF5iVLx9BRVVVorJW g3m9ShWmVMkVDWqVsiSDVHIIYHceXCw9tiu1PmV3VXlX989KY6qjbg8qn7ADHkravrwl70tD 93hr+40P0dw7RRFmR7/lW/rN949yU/TTW79khx4ffX1+3b6CaL3pXFV55u2+bWxs0uKFLbsO CkXVzQmfOjf2Onz5xd6W0kOtc09cHxPd9CI0asnmC28izs6O7/OaV5zjCMnDWyfjQYn/DcYe /9sTBAAA Cc: "mpls@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 09:25:24 -0000 Loa, Lots of thanks for a prompt response. I am not sure your example fully applies, because tLDP (which, I fully agree= , is part of the MPLS-TP CP) always runs over IP and hence can always use co= mparison of IP addresses. A more interesting example could be the PW redundancy protocol which today c= ompares IP addresses of PE boxes as a tie breaker. In MPLS-TP (with PW status carried in static status messages) this would not= be always applicable, and one possibility would be to use MPLS-TP identifie= rs... Regards, Sasha > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, April 27, 2011 10:35 AM > To: Alexander Vainshtein > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); Malcolm.BETTS@zte.com.cn; > mpls@ietf.org > Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Sasha, > > from 5036 > > 2. LSR1 determines whether it will play the active or passive > role > in session establishment by comparing addresses A1 and A2 as > unsigned integers. If A1 > A2, LSR1 plays the active role; > otherwise, it is passive. > > tLDP maybe used to set up PWs in MPLS based transport networks! > > /Loa > > On 2011-04-26 23:06, Alexander Vainshtein wrote: > > Malcolm, Nurit and all, > > > > One /technical/ reason for not mixing identifiers of different types > is > > that in certain situations these identifiers are treated as an > ordered > > set, i.e., it is possible to say when one of these identifiers is > "less" > > than the other one. > > > > The typical use case is tie-breaking in various protocols (e.g., for > > deciding which request for a protection-related has to be granted). > Even > > if the current set of MPLS-TP protocols does not use such tie- > breakers, > > I would not preclude this usage in future. > > > > It is relatively simple to impose some order on identifiers of the > same > > type. Imposing an order on a superset of identifiers at least > requires > > some thought. > > > > Regards, > > > > Sasha > > > > *From:*mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On > Behalf > > Of *Sprecher, Nurit (NSN - IL/Hod HaSharon) > > *Sent:* Wednesday, April 27, 2011 8:44 AM > > *To:* Malcolm.BETTS@zte.com.cn; George Swallow > > *Cc:* mpls@ietf.org > > *Subject:* Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > > > > Hi, > > > > I think such mixing environment requires more study. We need to > better > > understand the applicability and the implications on all components > and > > planes... > > > > When such a mixing environment is completely analyzed and understood, > if > > needed can be added in a later phase. > > > > IMO, in the meantime the document should both ICC OR IP environments, > > with no mixing identifiers. > > > > Best regards, > > > > Nurit > > > > *From:*mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On > Behalf > > Of *ext Malcolm.BETTS@zte.com.cn > > *Sent:* Wednesday, April 27, 2011 7:05 AM > > *To:* George Swallow > > *Cc:* mpls@ietf.org > > *Subject:* Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > > > > > > George, > > > > I do not agree the proposed resolution of this comment. As stated in > the > > draft allows an operator can select the use of either Global (IP) or > ICC > > based identifiers. Insisting that both ends of a LSP or PW must use > the > > same scheme removes the freedom to select the between ICC and Global > > (IP) identifiers. > > > > MPLS-TP requires that the data plane and control plane are > independent, > > including having independent identifiers. The draft describes the > > mapping between the GMPLS identifiers used by the control plane and > the > > data plane identifiers. > > > > From the perspective of the data plane an identifier is inserted at > the > > source and received by the sink. Neither the source or sink need to > > understand the semantics of the identifier, all a sink needs to, for > > example, to verify connectivity is to check that the received > identifier > > string matches the expected identifier string. > > > > Please see in-line below. > > > > Regards, > > > > Malcolm > > > > > > *George Swallow * > > Sent by: mpls-bounces@ietf.org > > > > 25/04/2011 05:16 PM > > > > > > > > To > > > > > > > > > > > > cc > > > > > > > > Subject > > > > > > > > [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > > > > > > > > > > > > All - > > > > Many of the comments received from the ITU on > > draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC > > identifiers. > > > > The identifiers for Tunnel, LSP, PW, and MEG include fields to > identify > > each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or > MEG > > to use either the Global-ID for both ends or or the ICC for both > ends. > > Mixed use is not permitted. > > > > The ITU liaison requests that we allow mixed use. > > > > The authors of the draft are very reluctant to do this. > > > > 1. Obtaining an AS Number (from which the Global-ID is derived) is a > > fairly trivial procedure. Many organizations if not most already have > AS > > Numbers. > > [MB] Many organizations already have process in place to use ICC > based > > identifiers for the data plane changing to IP based identifiers would > be > > a major burden. > > 2. Such an addition will add numerous object formats, and test cases. > > [MB] Why - the data plane does not need to interpret the string, just > > check that it matches the expected string > > 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed > modes > > of ICC and Global-ID identification is required, they can be added > later. > > [MB] This would be a major roadblock to the use of MPLS-TP in an > inter > > provider transport network > > 4. For signaled connections, there is no plan to allow routing based > on > > either the Global-ID or ICC. That would be a radical change to how IP > > works. However for IP routing to work (in order to forward the > signaling > > messages), the providers involved will need to run BGP and have AS > numbers. > > [MB] The control plane identifiers must be independent of the data > plane > > identifiers. > > > > We are looking for input/consensus from the WG. > > > > George, Eric, & Matthew > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please > inform > > us by e-mail, phone or fax, and then delete the original and all > copies > > thereof. > > > > > > > > _______________________________________________ > > 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 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From huubatwork@gmail.com Thu Apr 28 03:44:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8BEE06B1 for ; Thu, 28 Apr 2011 03:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuKpZ63kj6I9 for ; Thu, 28 Apr 2011 03:44:32 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 200E5E0659 for ; Thu, 28 Apr 2011 03:44:32 -0700 (PDT) Received: by pvh1 with SMTP id 1so2144123pvh.31 for ; Thu, 28 Apr 2011 03:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:disposition-notification-to:date :from:reply-to:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mIYVfX5VMoxDvhqxogYmPJFOhE0fB2y02I/sThrH8aU=; b=kp9AUk201bH1eTgigc65/VycgrKX0QIeClU3owVcyzChCvCtL66mskqt8bSKw1HUmF COjJ3Xumb9rZuNeifUEfDcA+H38b+9/N3vPZ6o1r+Gyt9MOq5jCtEAK4HYD/Dtj/zEwB HjmwJIsRvYbMoYeEuAJLAo46No9TxPn/F+/TE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; b=wghD4ok59u64o5kNTfpXs37g0hm3wQtsEpEM0spLnrPKEUshSx8pA5MUG68EYSnVF2 SgsF0FtQpyp+Mk5md8OcdHhg2T16eOYZi5O1G7VauOM3/hWFIAlnBYdGxjJoQIhDafRI j2Df0T18ZdWjSi1EYh4U5K/MpSuYaCLweuk5Q= Received: by 10.68.32.232 with SMTP id m8mr3250145pbi.99.1303987471803; Thu, 28 Apr 2011 03:44:31 -0700 (PDT) Received: from McAsterix.local (138.034.dsl.mel.iprimus.net.au [210.50.235.138]) by mx.google.com with ESMTPS id c14sm1143635pbu.84.2011.04.28.03.44.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 03:44:26 -0700 (PDT) Message-ID: <4DB944FC.906@gmail.com> Date: Thu, 28 Apr 2011 12:44:12 +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@ietf.org References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 10:44:34 -0000 Hi Malcolm,

    You wrote:
    John, if you do not allow mix identifier types how can you have an end to end CV message.  If you are using stitching to allow a single identifier type then the identifiers in a CV message must be translated at the stitching point.  A very bad idea!
    Indeed!
    This is not a "late breaking requirement".  The requirements for support of both ICC and IP identifiers schemes is well documented.  As is the expectation of using MPLS-TP in multi-operator transport networks.  Hence the need to support both on a LSP/PW.  This comment has been made during previous last calls on this draft.
    Correct. I fully agree with your assessment.

    Best regards, Huub.



    Sent from my mobile device.
    John E Drake <jdrake@juniper.net>

    27/04/2011 07:25 PM

    To
    		 "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>
    cc
    		 Eric Gray <eric.gray@ericsson.com>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>
    Subject
    		 RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?







    Malcolm,
     
    I interpreted Eric’s use of  ‘stitching’  to be in the RFC 5150 sense.  I think I will let him clarify, but if used in the RFC 5150 sense, a ‘stitched’ LSP would have end-to-end OAM, and different pieces could use different identifiers in the control and management planes.
     
    Also, as Greg notes, this appears to be a late breaking requirement.
     
    Thanks,
     
    John
     
    Sent from my iPhone
     
    From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
    Sent:     Wednesday, April 27, 2011 4:11 PM
    To:     John E Drake
    Cc:     Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org
    Subject:     RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
     

    John,

    The proposal from Eric is that the identifiers are "switched" at the stitching point, this requires a complex interworking function and interrupts the end to end OAM flow - i.e. data packet can transit without any manipulation (other than the normal label swap) but OAM packets must be intercepted and manipulated in the middle of the connection so it is no longer an end to end construct.  User data and OAM no longer fully fate share.

    Regards,

    Malcolm

    John E Drake <jdrake@juniper.net>

    27/04/2011 06:53 PM


    To
    		 "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Eric Gray <eric.gray@ericsson.com>
    cc
    		 "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>
    Subject
    		 RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

     









    Malcolm,
     
    That’s incorrect.  There is a single end-to-end LSP composed of different pieces, each under the control of a different administrative entity.  
     
    Thanks,
     
    John  
     
    Sent from my iPhone
     
    From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn
    Sent:     Wednesday, April 27, 2011 3:44 PM
    To:     Eric Gray
    Cc:     mpls@ietf.org; mpls-bounces@ietf.org
    Subject:     Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
     

    Eric,

    If you "stitch" the LSP or PW and change identifiers you will not have end to end OAM which is a requirement for a MPLS-TP transport network.

    Regards,

    Malcolm

    Eric Gray <eric.gray@ericsson.com>
    Sent by: mpls-bounces@ietf.org

    27/04/2011 12:11 PM

    		 


    To
    		 George Swallow <swallow@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
    cc
    Subject
    		 Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?


     

     









    As one of the co-authors on this draft, I support a restriction to using a common
    form of identifier throughout an LSP or PW.

    In my opinion, it is far better to terminate LSPs or PWs at the point where there
    might be an identifier form change and "stitch" them together if that is what the
    operators want/agree to do.  This limits the need-to-know for the mapping of one
    form of identifier to the other to the point at which this occurs, rather than at each
    node in the LSP or (potentially) MS-PW.


     


    From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow
    Sent:     Monday, April 25, 2011 5:17 PM
    To:     mpls@ietf.org
    Subject:     [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

    All -

    Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends.  Mixed use is not permitted.

    The ITU liaison requests that we allow mixed use.

    The authors of the draft are very reluctant to do this.  

    1.            Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure.  Many organizations if not most already have AS Numbers.
    2.            Such an addition will add numerous object formats, and test cases.
    3.            The extent inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID identification is required, they can be added later.
    4.            For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC.  That would be a radical change to how IP works.  However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.

    We are looking for input/consensus from the WG.

    From nurit.sprecher@nsn.com Thu Apr 28 04:01:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B4DE0663 for ; Thu, 28 Apr 2011 04:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.384 X-Spam-Level: X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xV1DoJ3VE9G6 for ; Thu, 28 Apr 2011 04:01:31 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 11197E0659 for ; Thu, 28 Apr 2011 04:01:30 -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 p3SB1SKV009982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Apr 2011 13:01:28 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3SB1Pjs011605; Thu, 28 Apr 2011 13:01:28 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 13:01:25 +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_01CC0593.9E5300C2" Date: Thu, 28 Apr 2011 13:01:23 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403B797E2@DEMUEXC014.nsn-intra.net> In-Reply-To: <4DB944FC.906@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwFkVAPqIlVVMBbRWSYhTt7TtKviQAADl/w References: <4DB944FC.906@gmail.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 28 Apr 2011 11:01:25.0895 (UTC) FILETIME=[9E2C8170:01CC0593] Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 11:01:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0593.9E5300C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I cannot find such a requirement in the MPLS-TP requirement documents. =20 It may be a very valid requirement, but it requires more study to understand the applicability, implications on the different components and protocols, and it can be added in a later phase. As indicated before, I support the completion of the document supporting both IP and ICC addresses but not a mixture. This should be added when we have complete understanding of the applicability, implications, etc.=20 Best regards, Nurit =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Huub van Helvoort Sent: Thursday, April 28, 2011 1:44 PM To: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 Hi Malcolm, You wrote: John, if you do not allow mix identifier types how can you have an end to end CV message. If you are using stitching to allow a single identifier type then the identifiers in a CV message must be translated at the stitching point. A very bad idea!=20 Indeed! This is not a "late breaking requirement". The requirements for support of both ICC and IP identifiers schemes is well documented. As is the expectation of using MPLS-TP in multi-operator transport networks. Hence the need to support both on a LSP/PW. This comment has been made during previous last calls on this draft.=20 Correct. I fully agree with your assessment. Best regards, Huub. Sent from my mobile device.=20 John E Drake =20 27/04/2011 07:25 PM=20 To "Malcolm.BETTS@zte.com.cn" =20 cc Eric Gray , "mpls@ietf.org" , "mpls-bounces@ietf.org" =20 Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 =09 Malcolm,=20 =20 I interpreted Eric's use of 'stitching' to be in the RFC 5150 sense. I think I will let him clarify, but if used in the RFC 5150 sense, a 'stitched' LSP would have end-to-end OAM, and different pieces could use different identifiers in the control and management planes.=20 =20 Also, as Greg notes, this appears to be a late breaking requirement.=20 =20 Thanks,=20 =20 John=20 =20 Sent from my iPhone=20 =20 From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]=20 Sent: Wednesday, April 27, 2011 4:11 PM To: John E Drake Cc: Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?=20 =20 John,=20 The proposal from Eric is that the identifiers are "switched" at the stitching point, this requires a complex interworking function and interrupts the end to end OAM flow - i.e. data packet can transit without any manipulation (other than the normal label swap) but OAM packets must be intercepted and manipulated in the middle of the connection so it is no longer an end to end construct. User data and OAM no longer fully fate share.=20 Regards,=20 Malcolm=20 John E Drake =20 27/04/2011 06:53 PM=20 =20 To "Malcolm.BETTS@zte.com.cn" , Eric Gray =20 cc "mpls@ietf.org" , "mpls-bounces@ietf.org" =20 Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 =20 =09 Malcolm,=20 =20 That's incorrect. There is a single end-to-end LSP composed of different pieces, each under the control of a different administrative entity. =20 =20 Thanks,=20 =20 John =20 =20 Sent from my iPhone=20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 3:44 PM To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?=20 =20 Eric,=20 If you "stitch" the LSP or PW and change identifiers you will not have end to end OAM which is a requirement for a MPLS-TP transport network.=20 Regards,=20 Malcolm=20 Eric Gray =20 Sent by: mpls-bounces@ietf.org=20 27/04/2011 12:11 PM=20 =20 =20 To George Swallow , "mpls@ietf.org" =20 cc =09 Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 =20 =20 =09 As one of the co-authors on this draft, I support a restriction to using a common=20 form of identifier throughout an LSP or PW.=20 In my opinion, it is far better to terminate LSPs or PWs at the point where there=20 might be an identifier form change and "stitch" them together if that is what the=20 operators want/agree to do. This limits the need-to-know for the mapping of one=20 form of identifier to the other to the point at which this occurs, rather than at each=20 node in the LSP or (potentially) MS-PW.=20 =20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify each end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or the ICC for both ends. Mixed use is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. =20 1. Obtaining an AS Number (from which the Global-ID is derived) is a fairly trivial procedure. Many organizations if not most already have AS Numbers.=20 2. Such an addition will add numerous object formats, and test cases.=20 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed modes of ICC and Global-ID identification is required, they can be added later.=20 4. For signaled connections, there is no plan to allow routing based on either the Global-ID or ICC. That would be a radical change to how IP works. However for IP routing to work (in order to forward the signaling messages), the providers involved will need to run BGP and have AS numbers.=20 We are looking for input/consensus from the WG. =20 ------_=_NextPart_001_01CC0593.9E5300C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi,

    I cannot find such a requirement in the MPLS-TP requirement = documents.  

    It may be a very valid requirement, but it requires more study to = understand the applicability, implications on the different components = and protocols, and it can be added in a later = phase.

    As indicated before, I support the completion of the document = supporting both IP and ICC addresses but not a mixture. This should be = added when we have complete understanding of the applicability, = implications, etc.

    Best regards,

    Nurit

     

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of ext Huub van Helvoort
    Sent: Thursday, April 28, 2011 = 1:44 PM
    To: mpls@ietf.org
    Subject: Re: [mpls] Mixing = ICC and Global-IDs in MPLS-TP = Identifiers?

     

    Hi = Malcolm,

    You wrote:

    John, if you = do not allow mix identifier types how can you have an end to end CV = message.  If you are using stitching to allow a single identifier = type then the identifiers in a CV message must be translated at the = stitching point.  A very bad idea!

    Indeed!

    This is not = a "late breaking requirement".  The requirements for = support of both ICC and IP identifiers schemes is well documented. =  As is the expectation of using MPLS-TP in multi-operator transport = networks.  Hence the need to support both on a LSP/PW.  This = comment has been made during previous last calls on this draft. =

    Correct. I fully agree with your = assessment.

    Best regards, Huub.



    Sent from my = mobile device.

    John E Drake = <jdrake@juniper.net><= /b> =

    27/04/2011 = 07:25 PM

    To=

    "Malcolm.BETTS@zte.com.cn&q= uot; <Malcolm.BETTS@zte.com.cn>=

    cc=

    Eric Gray <eric.gray@ericsson.com>= , "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>

    Subject=

    RE: [mpls] = Mixing ICC and Global-IDs in MPLS-TP = Identifiers?

     




    Malcolm,
     
    I interpreted Eric’s use of  ‘stitching’ =  to be in the RFC 5150 sense.  I think I will let him clarify, = but if used in the RFC 5150 sense, a ‘stitched’ LSP would = have end-to-end OAM, and different pieces could use different = identifiers in the control and management planes.
     
    Also, as Greg notes, this appears to be a late breaking = requirement.
     
    Thanks,
     
    John
     
    Sent from my iPhone
     
    From:= = Malcolm.BETTS@zte.com.cn = [mailto:Malcolm.BETTS@zte.com.cn<= /a>]
    Sent:     Wednesday, April 27, 2011 4:11 PM
    To:     = John E Drake
    Cc:     Eric Gray;     mpls@ietf.org; mpls-bounces@ietf.org
    Sub= ject:     RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP = Identifiers?
     

    John,

    The = proposal from Eric is that the identifiers are "switched" at = the stitching point, this requires a complex interworking function and = interrupts the end to end OAM flow - i.e. data packet can transit = without any manipulation (other than the normal label swap) but OAM = packets must be intercepted and manipulated in the middle of the = connection so it is no longer an end to end construct.  User data = and OAM no longer fully fate share.

    Regards,<= /span>

    Malcolm

    John E Drake = <jdrake@juniper.net><= /b> =

    27/04/2011 = 06:53 PM

     

    To=

    "Malcolm.BETTS@zte.com.cn&q= uot; <Malcolm.BETTS@zte.com.cn>= , Eric Gray <eric.gray@ericsson.com>=

    cc=

    "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>

    Subject=

    RE: [mpls] = Mixing ICC and Global-IDs in MPLS-TP = Identifiers?


      =

     





    Malcolm,
     
    That’s incorrect.  There is a single end-to-end LSP = composed of different pieces, each under the control of a different = administrative entity.  
     
    Thanks,
     
    John  
     
    Sent from my iPhone
     
    From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] = On Behalf Of Malcolm.BETTS@zte.com.cn<= br>Sent: Wednesday, April 27, 2011 3:44 PM
    To:     Eric = Gray
    Cc:     mpls@ietf.org; = mpls-bounces@ietf.org
    Sub= ject:     Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP = Identifiers?
     

    Eric,=

    If = you "stitch" the LSP or PW and change identifiers you will not = have end to end OAM which is a requirement for a MPLS-TP transport = network.

    Regar= ds,

    Malco= lm

    Eric Gray <eric.gray@ericsson.com>=
    Sent by: = mpls-bounces@ietf.org     =

    27/04/2011 = 12:11 PM

     

     

    To=

    George = Swallow <swallow@cisco.com>, "mpls@ietf.org" <mpls@ietf.org> =

    cc=

    Subject=

    Re: [mpls] = Mixing ICC and Global-IDs in MPLS-TP = Identifiers?



      =

     

     




    As one of the co-authors on this draft, I support a restriction to = using a common     form of identifier throughout an LSP or PW.
    In my opinion, it is far better to terminate LSPs or PWs at the point = where there might be an identifier form change and "stitch" them = together if that is what the operators want/agree to do.  This limits the need-to-know for the = mapping of one form of identifier to the other to the point at which this occurs, = rather than at each node in the LSP or (potentially) MS-PW.


      =



    From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] = On Behalf Of George Swallow
    Sent:     Monday, April 25, = 2011 5:17 PM
    To:     mpls@ietf.org
    Subject:     = [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

    All= -

    Many of the comments received from the ITU on = draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC = identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include = fields to identify each end of an LSP.  Currently the draft allows = a Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or = or the ICC for both ends.  Mixed use is not permitted.

    The = ITU liaison requests that we allow mixed use.

    The authors of the = draft are very reluctant to do this.  

    1. =            Obtaining = an AS Number (from which the Global-ID is derived) is a fairly trivial = procedure.  Many organizations if not most already have AS Numbers. =
    2. =            Such an = addition will add numerous object formats, and test cases.
    3. =            The extent = inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC = and Global-ID identification is required, they can be added later. =
    4. =            For = signaled connections, there is no plan to allow routing based on either = the Global-ID or ICC.  That would be a radical change to how IP = works.  However for IP routing to work (in order to forward the = signaling messages), the providers involved will need to run BGP and = have AS numbers. =

    We = are looking for input/consensus from the WG.

     

    ------_=_NextPart_001_01CC0593.9E5300C2-- From jdrake@juniper.net Thu Apr 28 09:22:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE19E0685; Thu, 28 Apr 2011 09:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXBwGeIQjFwz; Thu, 28 Apr 2011 09:22:39 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0D897E06A1; Thu, 28 Apr 2011 09:22:38 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTbmUStURUjlXvlaEZBb4pAlimdaU6Crk@postini.com; Thu, 28 Apr 2011 09:22:39 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 28 Apr 2011 09:22:14 -0700 From: John E Drake To: "Malcolm.BETTS@zte.com.cn" Date: Thu, 28 Apr 2011 09:22:13 -0700 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwFU/q//krs3+/FTY2yHCzygySeewAa1GJA Message-ID: <5E893DB832F57341992548CDBB333163A097770CB0@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A09777082A@EMBX01-HQ.jnpr.net> 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_5E893DB832F57341992548CDBB333163A097770CB0EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 16:22:43 -0000 X-List-Received-Date: Thu, 28 Apr 2011 16:22:43 -0000 --_000_5E893DB832F57341992548CDBB333163A097770CB0EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline. Sent from my iPhone From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Wednesday, April 27, 2011 8:25 PM To: John E Drake Cc: Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? John, John, if you do not allow mix identifier types how can you have an end to e= nd CV message. JD: The endpoints have to agree on a common format for the data plane. Th= at's the whole point of the discussion. If you are using stitching to allow a single identifier type then the iden= tifiers in a CV message must be translated at the stitching point. A very = bad idea! JD: I never proposed this. You have a tendency to attribute a silly idea = to someone and then ridicule it. Btw, you might consider reviewing RFC 515= 0. This is not a "late breaking requirement". The requirements for support of= both ICC and IP identifiers schemes is well documented. As is the expecta= tion of using MPLS-TP in multi-operator transport networks. Hence the need= to support both on a LSP/PW. This comment has been made during previous l= ast calls on this draft. JD: If it is not in the MPLS-TP requirements RFCs, it is by definition a l= ate breaking requirement. Regards, Malcolm John E Drake 27/04/2011 07:25 PM To "Malcolm.BETTS@zte.com.cn" cc Eric Gray , "mpls@ietf.org" , "mpls-= bounces@ietf.org" Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, I interpreted Eric's use of 'stitching' to be in the RFC 5150 sense. I t= hink I will let him clarify, but if used in the RFC 5150 sense, a 'stitched= ' LSP would have end-to-end OAM, and different pieces could use different i= dentifiers in the control and management planes. Also, as Greg notes, this appears to be a late breaking requirement. Thanks, John Sent from my iPhone From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Wednesday, April 27, 2011 4:11 PM To: John E Drake Cc: Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? John, The proposal from Eric is that the identifiers are "switched" at the stitch= ing point, this requires a complex interworking function and interrupts the= end to end OAM flow - i.e. data packet can transit without any manipulatio= n (other than the normal label swap) but OAM packets must be intercepted an= d manipulated in the middle of the connection so it is no longer an end to = end construct. User data and OAM no longer fully fate share. Regards, Malcolm John E Drake 27/04/2011 06:53 PM To "Malcolm.BETTS@zte.com.cn" , Eric Gray cc "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, That's incorrect. There is a single end-to-end LSP composed of different p= ieces, each under the control of a different administrative entity. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 3:44 PM To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Eric, If you "stitch" the LSP or PW and change identifiers you will not have end = to end OAM which is a requirement for a MPLS-TP transport network. Regards, Malcolm Eric Gray Sent by: mpls-bounces@ietf.org 27/04/2011 12:11 PM To George Swallow , "mpls@ietf.org" cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? As one of the co-authors on this draft, I support a restriction to using a = common form of identifier throughout an LSP or PW. In my opinion, it is far better to terminate LSPs or PWs at the point where= there might be an identifier form change and "stitch" them together if that is wh= at the operators want/agree to do. This limits the need-to-know for the mapping o= f one form of identifier to the other to the point at which this occurs, rather t= han at each node in the LSP or (potentially) MS-PW. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a= fairly trivial procedure. Many organizations if not most already have AS = Numbers. 2. Such an addition will add numerous object formats, and test cases= . 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des of ICC and Global-ID identification is required, they can be added late= r. 4. For signaled connections, there is no plan to allow routing based= on either the Global-ID or ICC. That would be a radical change to how IP = works. However for IP routing to work (in order to forward the signaling m= essages), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_5E893DB832F57341992548CDBB333163A097770CB0EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Comments = inline.

     <= /span>

    Sent from my iPhone=

     

    From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BET= TS@zte.com.cn]
    Sent: Wednesday, April 27, 2011 8:25 PM
    To:= John E Drake
    Cc: Eric Gray; mpls@ietf.org; mpls-bounces@ietf= .org
    Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Ide= ntifiers?

     =


    John,
    <= br>John, = if you do not allow mix identifier types how can you have an end to end CV = message.

    JD:  The endpoints = have to agree on a common format for the data plane.  That’s the= whole point of the discussion.

     If you are using stitching to allow a single id= entifier type then the identifiers in a CV message must be translated at th= e stitching point.  A very bad idea!

    JD:  I never proposed this.  You have a tendency to att= ribute a silly idea to someone and then ridicule it.  Btw, you might c= onsider reviewing RFC 5150.

    This is not a "late breaking requirem= ent".  The requirements for support of both ICC and IP identifier= s schemes is well documented.  As is the expectation of using MPLS-TP = in multi-operator transport networks.  Hence the need to support both = on a LSP/PW.  This comment has been made during previous last calls on= this draft.

    JD:  If it is n= ot in the MPLS-TP requirements RFCs, it is by definition a late breaking re= quirement.

    Regards,

    Malcolm


    John E Drake <jdrake@junip= er.net>

    27/04/2011 07:25 PM

    <= td width=3D"64%" valign=3Dtop style=3D'width:64.0%;padding:.75pt .75pt .75p= t .75pt'>

    RE: [mpl= s] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

    <= /td>

    To

    "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zt= e.com.cn>

    cc

    Eric Gray <eric.gray@ericsson.com>= ;, "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf= .org" <mpls-bounces@ietf.org>

    Subject

     




    Malcolm,
     
    I interpreted Eric’s use of  ‘s= titching’  to be in the RFC 5150 sense.  I think I will let= him clarify, but if used in the RFC 5150 sense, a ‘stitched’ L= SP would have end-to-end OAM, and different pieces could use different iden= tifiers in the control and management planes.
     
    Also, as Greg notes, this appears to be a late breaking requi= rement.
     
    Thanks,
     
    John
     
    = Sent from my iPhone
     
    From: Malcolm.BETTS@z= te.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
    Sent:     Wednesday, Apr= il 27, 2011 4:11 PM
    To:     John E Drake
    Cc:     Eric Gray; mpl= s@ietf.org; mpls-bounces@ietf.org
    Subject:     RE: [mpls] Mixing ICC = and Global-IDs in MPLS-TP Identifiers?
     

    John,

    The pro= posal from Eric is that the identifiers are "switched" at the sti= tching point, this requires a complex interworking function and interrupts = the end to end OAM flow - i.e. data packet can transit without any manipula= tion (other than the normal label swap) but OAM packets must be intercepted= and manipulated in the middle of the connection so it is no longer an end = to end construct.  User data and OAM no longer fully fate share.
    Regards,

    Malcolm

    =

    John E Drake <jdrake@juniper.net>

    = 27/04/2011 06:53 PM

     

    "m= pls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org"= <mpls-bounces@ietf.org>

    <= /table>


     

     <= /p>

    To

    "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn&g= t;, Eric Gray <eric.gray@ericsson.com>

    cc

    Subject

    RE: [mpls] Mixing = ICC and Global-IDs in MPLS-TP Identifiers?





    Malcolm,
    &n= bsp;
    That’s incorrect.  There is a single end-to-end L= SP composed of different pieces, each under the control of a different admi= nistrative entity.  
     
    Thanks,
     
    John  
     
    Sent from my iPhone
     
    From:     mpls-b= ounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.= BETTS@zte.com.cn
    Sent:     Wednesday, April 27, 2011 3:44 PM
    To= :     Eric Gray
    Cc:     mpls@ietf.org; mpls-bounces@ietf.org
    Su= bject:     Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
     

    Eric,

    If you "stitch" the LSP or PW and change= identifiers you will not have end to end OAM which is a requirement for a = MPLS-TP transport network.

    Regards,

    Malcolm     <= /p>

    Eric Gray <eric.gray@= ericsson.com>
    Sent by: mpls-bounces@ietf.org

    =

    27/04/2= 011 12:11 PM

    &nbs= p;

     



     

     

    &nbs= p;

    <= p class=3DMsoNormal align=3Dright style=3D'text-align:right'>To

    =

    George Swallow <swallow@cisco.com>, "m= pls@ietf.org" <mpls@ietf.org>

    cc

    Subject

    Re: [mpls] Mixing IC= C and Global-IDs in MPLS-TP Identifiers?

    <= /table>





    As one of the co-authors on t= his draft, I support a restriction to using a common
    form of i= dentifier throughout an LSP or PW.

    In my opinion, it is fa= r better to terminate LSPs or PWs at the point where there
    mig= ht be an identifier form change and "stitch" them together if tha= t is what the
    operators want/agree to do.  This limits th= e need-to-know for the mapping of one
    form of identifier to th= e other to the point at which this occurs, rather than at each     node in the LSP or (potentially) MS-PW.


      <= /p>



    From:    = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of G= eorge Swallow
    Sent:     Monday, April 25, 2011 5:17 PM
    To:     = mpls@ietf.org
    Subject:     [mpls] Mixing ICC and Global-IDs in MPLS-T= P Identifiers?

    All -

    Many of the comments received from the I= TU on draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC = identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fi= elds to identify each end of an LSP.  Currently the draft allows a Tun= nel, LSP, PW, or MEG to use either the Global-ID for both ends or or the IC= C for both ends.  Mixed use is not permitted.

    The ITU liaison r= equests that we allow mixed use.

    The authors of the draft are very r= eluctant to do this.  

    1.            Obtaining an= AS Number (from which the Global-ID is derived) is a fairly trivial proced= ure.  Many organizations if not most already have AS Numbers. <= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>
    2. &nb= sp;      Such an addition will add numerous object formats, = and test cases.
    3.            The extent inter-provider M= PLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID identif= ication is required, they can be added later.
    4.       &nb= sp;    For signaled connections, there is no plan to allow routing based on eit= her the Global-ID or ICC.  That would be a radical change to how IP wo= rks.  However for IP routing to work (in order to forward the signalin= g messages), the providers involved will need to run BGP and have AS number= s.

    We are looking for input/consensus from the WG.

    George, E= ric, & Matthew     _______________________________________________
    mpls mailing l= ist
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls     <= o:p>

    = --_000_5E893DB832F57341992548CDBB333163A097770CB0EMBX01HQjnprn_-- From eric.gray@ericsson.com Thu Apr 28 13:58:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D2EE071E for ; Thu, 28 Apr 2011 13:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 834npr7Y86Hl for ; Thu, 28 Apr 2011 13:58:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 37020E070A for ; Thu, 28 Apr 2011 13:58:02 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3SKvxOs000536; Thu, 28 Apr 2011 15:58:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 28 Apr 2011 16:57:53 -0400 From: Eric Gray To: "Malcolm.BETTS@zte.com.cn" , George Swallow Date: Thu, 28 Apr 2011 16:57:51 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwEkFBXYbQnS5CrT4ylyW0UNm7Y0wBUJvjw 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_C0AC8FAB6849AB4FADACCC70A949E2F10B0732D07FEUSAACMS0701e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:58:03 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0732D07FEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, There is nothing about not mixing the two identifier formats that prevents an operator from continuing to use ICC identifiers within their own network. The implication that it is okay to require any operator that does not use ICC identifiers to be able to recognize them, but it is not okay for an operator that use them to be able to recognize the Global Identifier format, is decidedly one sided. But, to be able to recognize the Global identifier format, the ICC user has to first be able to support this format. Contrary to your assertion, the format and comparison semantics of the two are not the same. The Global Identifier format consists of a pair of 32-bit integers, in network bit/byte order. The ICC is a litteral string. Most of us know that the same comparison operation cannot be used with these two formats. For example, a very significant fraction of all Global Identifiers would match in a string compare with the empty string (""). Hence the specific identifier semantics is significant. As for the inter-provider case, do you now assert that there will in fact be a requirement for OAM interworking, given that at least some subset of the carriers that use ICC format identifiers are the same carriers who argued that the applications were more than sufficently different to justify specification of distinct OAM? If there is going to be a requirement for OAM inteworking, then let's allow that this interworking function will probably need to support identifier format conversion. Certainly we should not - at this point - rule this likelihood out. Also, see in-line responses below. -- Eric ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 12:05 AM To: George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? George, I do not agree the proposed resolution of this comment. As stated in the d= raft allows an operator can select the use of either Global (IP) or ICC bas= ed identifiers. Insisting that both ends of a LSP or PW must use the same = scheme removes the freedom to select the between ICC and Global (IP) identi= fiers. Are suggesting that the same operator might make different choices in diffe= rent parts of the same network? This seems very unlikely, except possibly in the case where one operator wh= o uses one format identifier is acquired by another operator who uses the oth= er. In any case, if the decision to use a particular identifier is made consist= ently within any adminstrative domain, then the onus is on the boundary points to make stuff work, not on every device in the network. MPLS-TP requires that the data plane and control plane are independent, inc= luding having independent identifiers. The draft describes the mapping bet= ween the GMPLS identifiers used by the control plane and the data plane ide= ntifiers. I believe you are correct in terms of what the requirements are. There is = nothing I am aware of that prevents any operator from using a form of identifier th= at is not necessarily consistent with their choice of signaling or configuration. It is exceedingly unlikely that operators that use existing (G)MPLS signali= ng will be in the camp that would prefer not to use identifiers that are consistent= with IP addressing and routing - but it is possible. If that is the case, then the= y are free to do so as far as I can tell. It is (probably?) much more likely that operators that use configuration wi= ll still elect to use identifiers that are consistent with IP addressing and routing= . They can certainly do that. If you know of a specific place in the text that preculdes this, please poi= nt it out. >From the perspective of the data plane an identifier is inserted at the sou= rce and received by the sink. Neither the source or sink need to understan= d the semantics of the identifier, all a sink needs to, for example, to ver= ify connectivity is to check that the received identifier string matches th= e expected identifier string. Here is - in part at least - the crux of the misunderstanding. The Global = Identifier format does not include the notion of an identifier string. Hence the comp= arison you describe is less than adequate. Please see in-line below. Regards, Malcolm George Swallow Sent by: mpls-bounces@ietf.org 25/04/2011 05:16 PM To cc Subject [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a= fairly trivial procedure. Many organizations if not most already have AS = Numbers. [MB] Many organizations already have process in place to use ICC based iden= tifiers for the data plane changing to IP based identifiers would be a majo= r burden. 2. Such an addition will add numerous object formats, and test cases= . [MB] Why - the data plane does not need to interpret the string, just chec= k that it matches the expected string 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des of ICC and Global-ID identification is required, they can be added late= r. [MB] This would be a major roadblock to the use of MPLS-TP in an inter pro= vider transport network 4. For signaled connections, there is no plan to allow routing based= on either the Global-ID or ICC. That would be a radical change to how IP = works. However for IP routing to work (in order to forward the signaling m= essages), the providers involved will need to run BGP and have AS numbers. [MB] The control plane identifiers must be independent of the data plane id= entifiers. We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0732D07FEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Malcolm,
     
      &n= bsp; There is nothing about not mixing the= two=20 identifier formats that
    prevents an operator from continuing to use ICC id= entifiers=20 within
    their own network.  The implication that it=20 is okay to require any
    operator that does not use ICC identifiers to be a= ble to=20 recognize
    them, but it is=20 not okay for an operator that use them to = be=20 able to
    recognize the Global Identifier format, is decided= ly one=20 sided.
     
      &n= bsp; But, to be able to recognize the Glob= al=20 identifier format, the ICC
    user has to first be able to support this format.&= nbsp;=20 Contrary to your
    assertion, the format and comparison semantics of = the two=20 are not
    the same.
     
      &n= bsp; The Global Identifier format consists= of a pair=20 of 32-bit integers,
    in network bit/byte order.  The ICC is a litt= eral=20 string.  Most of us
    know that the same comparison operation cannot be = used with=20
    these two formats.  For example, a very= =20 significant fraction of all
    Global Identifiers would match in a string compare= with the=20 empty
    string ("").
     
        Hence the specific identifier s= emantics=20 is significant.
     
      &n= bsp; As for the inter-provider case, do yo= u=20 now assert that there will
    in fact be a requirement for OAM interworking, giv= en that=20 at least
    some subset of the carriers that use ICC format id= entifiers=20 are the
    same carriers who argued that the application= s were=20 more than
    sufficently different to justify specification of= =20 distinct OAM?
     
      &n= bsp; If there is going to be a requirement= for OAM=20 inteworking, then
    let's allow that this interworking function will p= robably=20 need to
    support identifier format conv= ersion. =20 Certainly we should not - at
    this point - rule this likelihood=20 out.
     
      &n= bsp; Also, see in-line responses=20 below.
     
    --
    Eric

    From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Malcolm.BETTS@zte.com.cn
    Sent: Wednesday, April 27, 2011 12:0= 5=20 AM
    To: George Swallow
    Cc: mpls@ietf.org
    Subject:<= /B>=20 Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP=20 Identifiers?


    George,

    I do not agree the proposed resolution of this c= omment.=20  As stated in the draft allows an operator can select the use of eithe= r=20 Global (IP) or ICC based identifiers.  Insisting that both ends of a L= SP or=20 PW must use the same scheme removes the freedom to select the between ICC a= nd=20 Global (IP) identifiers. 
    <= FONT=20 face=3DArial color=3D#0000ff size=3D2>
    Are=20 suggesting that the same operator might make different choices in=20 different 
    parts=20 of the same network?
     
    This=20 seems very unlikely, except possibly in the case where one operator=20 who
    uses=20 one format identifier is acquired by another operator who uses the=20 other.
     
    In any=20 case, if the decision to use a particular identifier is made=20 consistently
    within=20 any adminstrative domain, then the onus is on the boundary points=20 to
    make=20 stuff work, not on every device in the=20 network. 

    MPLS-T= P=20 requires that the data plane and control plane are independent, including h= aving=20 independent identifiers.  The draft describes the mapping between the = GMPLS=20 identifiers used by the control plane and the data plane=20 identifiers. 
    I=20 believe you are correct in terms of what the requirements are.  There = is=20 nothing 
    I am=20 aware of that prevents any operator from using a form of identifier that is= =20 not
    necessarily consistent with their choice of signaling or=20 configuration.
     
    It is=20 exceedingly unlikely that operators that use existing (G)MPLS signaling=20 will
    be in=20 the camp that would prefer not to use=20 identifiers that are consistent with IP
    addressing and routing - but it is possible.  If that is the = case,=20 then they are free
    to do=20 so as far as I can tell.
     
    It is=20 (probably?) much more likely that operators that use configuration will=20 still
    elect=20 to use identifiers that are consistent with IP addressing and routing. = ;=20 They
    can=20 certainly do that.

    If=20 you know of a specific place in the text that preculdes this, please p= oint=20 it out. 

    From th= e=20 perspective of the data plane an identifier is inserted at the source and=20 received by the sink.  Neither the source or sink need to understand t= he=20 semantics of the identifier, all a sink needs to, for example, to verify=20 connectivity is to check that the received identifier string matches the=20 expected identifier string. 
    Here=20 is - in part at least - the crux of the misunderstanding.  The Global= =20 Identifier
    format=20 does not include the notion of an identifier string.  Hence the=20 comparison
    you=20 describe is less than adequate. 

    Please see in-line below.

    Regards,

    Malcolm=20




    George Swallow=20 <swallow@cisco.com>
    Sent=20 by: mpls-bounces@ietf.org=20

    25/04/2011 05:16 PM

    To
    		<mpls@ietf.org>= =20
    cc
    Subject
    		[mpls] Mixing ICC and Global= -IDs in=20 MPLS-TP Identifiers?





    All -

    Many of the comments received from the ITU on=20 draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC=20 identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include fi= elds=20 to identify each end of an LSP.  Currently the draft allows a Tunnel, = LSP,=20 PW, or MEG to use either the Global-ID for both ends or or the ICC for both= =20 ends.  Mixed use is not permitted.

    The ITU liaison requests tha= t we=20 allow mixed use.

    The authors of the draft are very reluctant to do t= his.=20  

    1.     &nbs= p;=20  Obtaining an AS Number (from whi= ch the=20 Global-ID is derived) is a fairly trivial procedure.  Many organizatio= ns if=20 not most already have AS Numbers.
    [MB]=20 Many organizations already have process in place to use ICC based identifie= rs=20 for the data plane changing to IP based identifiers would be a major burden= .=20
    2.      =20  Such an addition will add numero= us object=20 formats, and test cases.
    [MB] &= nbsp;Why=20 - the data plane does not need to interpret the string, just check that it= =20 matches the expected string
    3. =  =20      The extent inter-p= rovider=20 MPLS-TP is as yet unknown.  If mixed modes of ICC and Global-ID=20 identification is required, they can be added later.
    [MB]  This would be a major roadblock to th= e use of=20 MPLS-TP in an inter provider transport network
    4.        For=20 signaled connections, there is no plan to allow routing based on either the= =20 Global-ID or ICC.  That would be a radical change to how IP works.=20  However for IP routing to work (in order to forward the signaling=20 messages), the providers involved will need to run BGP and have AS=20 numbers.
    [MB] The control plane= =20 identifiers must be independent of the data plane identifiers.
    <= FONT=20 face=3DCalibri size=3D2>
    We are looking for input/consensus from the=20 WG.

    George, Eric, & Matthew _______________________________________________
    mpls mailin= g=20 list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls

    --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0732D07FEUSAACMS0701e_-- From eric.gray@ericsson.com Thu Apr 28 14:17:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61683E072C for ; Thu, 28 Apr 2011 14:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpEESGV3UvbC for ; Thu, 28 Apr 2011 14:17:31 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4DE0728 for ; Thu, 28 Apr 2011 14:17:31 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3SLHSA8010087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Apr 2011 16:17:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 28 Apr 2011 17:17:27 -0400 From: Eric Gray To: "huubatwork@gmail.com" , "mpls@ietf.org" Date: Thu, 28 Apr 2011 17:17:26 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwFkU51Z2C1bcRdTLi6CEYCWO8nNQAVd7ug Message-ID: References: <4DB944FC.906@gmail.com> In-Reply-To: <4DB944FC.906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0732D0ABEUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 21:17:36 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0732D0ABEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Huub, Please see below... -- Eric ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Huu= b van Helvoort Sent: Thursday, April 28, 2011 6:44 AM To: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi Malcolm, You wrote: John, if you do not allow mix identifier types how can you have an end to e= nd CV message. If you are using stitching to allow a single identifier typ= e then the identifiers in a CV message must be translated at the stitching = point. A very bad idea! Indeed! Actually I think a fair number of us disagree. It seems obvious (to me at least) that some sort of OAM interworking function is going to be necessary, given that there is almost certainly a non-null intersection of operators that use ICC format identifiers, who also plan to use OAM as specified in G8113.1 and who are now arguing they want end-to-end OAM with operators who will use Global identifiers and may very well use OAM as specified in IETF RFCs. Given that such an interworking requirement is likely, it is a far better use of time and energy to start thinking about how such an interworking function would work and would most likely support translation of ICC and Global Identifiers. It is certainly a better use of time and energy than it is to try to suppor= t a presumed mixing of the two formats in a single administrative domain. This is not a "late breaking requirement". The requirements for support of= both ICC and IP identifiers schemes is well documented. As is the expecta= tion of using MPLS-TP in multi-operator transport networks. Hence the need= to support both on a LSP/PW. This comment has been made during previous l= ast calls on this draft. Correct. I fully agree with your assessment. Unfortunately this is an incorrect (or naive) assessment. Many houses have both a furnace and one or more sets of furniture. It is certainly arguable that the need for both is a rigid requirement in some of the less temperate zones. Should this be formalized as a crystal clear housing requirement, I'm pretty sure that no one would subsequently interpret it to mean that both the furniture and the furnace need to be able to occupy the same space in the same house. Since the apparent "requirement" that the same messages should be able to include either or both of the required identifiers, and this is not obvious from the assertion of a requirement to merely allow support for both, this is indeed a late-breaking requirement. Best regards, Huub. Sent from my mobile device. John E Drake 27/04/2011 07:25 PM To "Malcolm.BETTS@zte.com.cn" cc Eric Gray , = "mpls@ietf.org" = , "mpls-bounces@ietf.org" Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, I interpreted Eric's use of 'stitching' to be in the RFC 5150 sense. I t= hink I will let him clarify, but if used in the RFC 5150 sense, a 'stitched= ' LSP would have end-to-end OAM, and different pieces could use different i= dentifiers in the control and management planes. Also, as Greg notes, this appears to be a late breaking requirement. Thanks, John Sent from my iPhone From: Malcolm.BETTS@zte.com.cn [mailto:Mal= colm.BETTS@zte.com.cn] Sent: Wednesday, April 27, 2011 4:11 PM To: John E Drake Cc: Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? John, The proposal from Eric is that the identifiers are "switched" at the stitch= ing point, this requires a complex interworking function and interrupts the= end to end OAM flow - i.e. data packet can transit without any manipulatio= n (other than the normal label swap) but OAM packets must be intercepted an= d manipulated in the middle of the connection so it is no longer an end to = end construct. User data and OAM no longer fully fate share. Regards, Malcolm John E Drake 27/04/2011 06:53 PM To "Malcolm.BETTS@zte.com.cn" , Eric Gray cc "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, That's incorrect. There is a single end-to-end LSP composed of different p= ieces, each under the control of a different administrative entity. Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn Sent: Wednesday, April 27, 2011 3:44 PM To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Eric, If you "stitch" the LSP or PW and change identifiers you will not have end = to end OAM which is a requirement for a MPLS-TP transport network. Regards, Malcolm Eric Gray Sent by: mpls-bounces@ietf.org 27/04/2011 12:11 PM To George Swallow , "mpls= @ietf.org" cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? As one of the co-authors on this draft, I support a restriction to using a = common form of identifier throughout an LSP or PW. In my opinion, it is far better to terminate LSPs or PWs at the point where= there might be an identifier form change and "stitch" them together if that is wh= at the operators want/agree to do. This limits the need-to-know for the mapping o= f one form of identifier to the other to the point at which this occurs, rather t= han at each node in the LSP or (potentially) MS-PW. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of George Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All - Many of the comments received from the ITU on draft-ietf-mpls-tp-identifier= s-04 have to do with the Global and ICC identifiers. The identifiers for Tunnel, LSP, PW, and MEG include fields to identify eac= h end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to u= se either the Global-ID for both ends or or the ICC for both ends. Mixed u= se is not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. 1. Obtaining an AS Number (from which the Global-ID is derived) is a= fairly trivial procedure. Many organizations if not most already have AS = Numbers. 2. Such an addition will add numerous object formats, and test cases= . 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des of ICC and Global-ID identification is required, they can be added late= r. 4. For signaled connections, there is no plan to allow routing based= on either the Global-ID or ICC. That would be a radical change to how IP = works. However for IP routing to work (in order to forward the signaling m= essages), the providers involved will need to run BGP and have AS numbers. We are looking for input/consensus from the WG. --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0732D0ABEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Huub,
     
      &n= bsp; Please see below...
     
    --
    Eric

    From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Huub van=20 Helvoort
    Sent: Thursday, April 28, 2011 6:44 AM
    To:=20 mpls@ietf.org
    Subject: Re: [mpls] Mixing ICC and Global-IDs in MP= LS-TP=20 Identifiers?

    Hi Malcolm,

    You wrote:
    John, if you do not allow mi= x=20 identifier types how can you have an end to end CV message.  If you = are=20 using stitching to allow a single identifier type then the identifiers in= a CV=20 message must be translated at the stitching point.  A very bad=20 idea!
    Indeed!

    Actually I think a fair number of us=20 disagree.
     
    It=20 seems obvious (to me at least) that some sort of OAM=20 interworking
    function is going to be necessary, given that there is almost=20 certainly
    a=20 non-null intersection of operators that use ICC format identifiers,=20 who
    also=20 plan to use OAM as specified in G8113.1 and who are now arguing=20
    they want end-to-end OAM with operators who= will=20 use Global identifiers
    = and may very well use OAM as= =20 specified in IETF RFCs.
     
    Given that such an interworking requirement is l= ikely,=20 it is a far better
    use of time and energy to start thinking about h= ow such=20 an interworking
    function would work and would most likely suppor= t=20 translation of ICC and
    Global Identifiers.<= /DIV>
     
    It is certainly a better use of time and energy = than it=20 is to try to support
    a presumed mixing of the two formats in a single= =20 administrative domain. 

    This is not a "late breaking= =20 requirement".  The requirements for support of both ICC and IP=20 identifiers schemes is well documented.  As is the expectation of us= ing=20 MPLS-TP in multi-operator transport networks.  Hence the need to sup= port=20 both on a LSP/PW.  This comment has been made during previous last c= alls=20 on this draft.
    Correct. I fully agree with your assessment.

    Unfo= rtunately=20 this is an incorrect (or naive) assessment. 

    Many houses have both a furnace and one or more sets of=20 furniture.
     
    It is=20 certainly arguable that the need for both is a rigid requirement=20 in
    some=20 of the less temperate zones.
     
    Should=20 this be formalized as a crystal clear housing requirement,=20 I'm
    pretty=20 sure that no one would subsequently interpret it to mean=20 that
    both=20 the furniture and the furnace need to be able to occupy the=20 same
    space=20 in the same house. 
     
    Since=20 the apparent "requirement" that the same messages should be
    able=20 to include either or both of the required identifiers, and this is=20 not
    obvious from the assertion of a requirement to merely allow suppor= t=20 for
    both,=20 this is indeed a late-breaking=20 requirement.
     
    Best regards, Huub.



    Sent fr= om my=20 mobile device.



    Malcolm,
     
    I interpreted Eric’s use of  ‘stitching’ =  to be in the RFC=20 5150 sense.  I think I will let him clarify, but if used in the RFC = 5150=20 sense, a ‘stitched’ LSP would have end-to-end OAM, and differ= ent pieces could=20 use different identifiers in the control and management planes.=20
     
    Also, as Greg notes, this appears= to be a=20 late breaking requirement.
     
    Thanks,
     
    = John=20
     
    Sent from my iPhone
     
    From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn<= /A>]=20
    Sent:     Wednesday, April 27, 2011 4:11 PM
    To:     John E=20 Drake
    Cc:     Eric Gray; mpls@ietf.org; mpls-bounces@ietf.org
    Sub= ject:    =20 RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
    <= FONT=20 face=3D"Times New Roman" size=3D3> 

    John,

    The proposal from Eric is that the identifiers = are=20 "switched" at the stitching point, this requires a complex interworking=20 function and interrupts the end to end OAM flow - i.e. data packet can tr= ansit=20 without any manipulation (other than the normal label swap) but OAM packe= ts=20 must be intercepted and manipulated in the middle of the connection so it= is=20 no longer an end to end construct.  User data and OAM no longer full= y=20 fate share.

    Regards,=20

    Malcolm

    John E Drake <jdrake@juniper.net>=20

    27/04/2011 07:25 PM

    =
    To=
    		"Malcolm.BETTS@zte.c= om.cn"=20 <Malcolm.BETTS@zt= e.com.cn>=20
    cc=
    		Eric Gray <eric.gray@ericsson= .com>,=20 "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org"= <mpls-bounces@ietf.o= rg>=20
    Subject
    		 RE: [mpls] Mixing ICC and= =20 Global-IDs in MPLS-TP Identifiers?







    Malcolm,
     
    T= hat’s=20 incorrect.  There is a single end-to-end LSP composed of different=20 pieces, each under the control of a different administrative entity. &nbs= p;=20
     
    Thanks,    =20
     
    John       <= /FONT>
     
    S= ent from my=20 iPhone
     
    From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] <= B>On=20 Behalf Of Malcolm.BETTS@zte.com.cn<= BR>Sent:=20 Wednesday, April 27, 2011 3:44 PM
    To:     Eric Gray
    Cc:     <= A=20 class=3Dmoz-txt-link-abbreviated href=3D"mailto:mpls@ietf.org">mpls@ietf.= org;=20 mpls-bounces@ietf.org
    Sub= ject:    =20 Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
     

    Eric,

    If you "stitch" the LSP or PW and change id= entifiers=20 you will not have end to end OAM which is a requirement for a MPLS-TP=20 transport network.     =

    Regards,=20

    Malcolm

    John E Drake <jdrake@juniper.net>=20

    27/04/2011 06:53 PM


    To
    		 "Malcolm.BETTS@zte.c= om.cn"=20 <Malcolm.BETTS@zt= e.com.cn>,=20 Eric Gray <eric.gray@ericsson= .com>
    cc
    		 "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org"= <mpls-bounces@ietf.o= rg>
    Subject=
    		RE: [mpls] Mixing ICC and Globa= l-IDs=20 in MPLS-TP Identifiers?

    <= FONT=20 face=3D"Times New Roman" size=3D3> =20









    As one of the co-authors on this draft, I s= upport a=20 restriction to using a common    =20
    form of identifier th= roughout an=20 LSP or PW.

    In my opinion, it is far better to= terminate=20 LSPs or PWs at the point where there
    might be an= identifier=20 form change and "stitch" them together if that is what the
    operators want/agree to do.  This limits the need-to-kn= ow for=20 the mapping of one     =
    form of identifier to the other to= the point=20 at which this occurs, rather than at each
    node in the= LSP or=20 (potentially) MS-PW.


     


    From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] <= B>On=20 Behalf Of George Swallow
    Sent:     Monday, April 25, 2011 5:17= =20 PM
    To:     mpls@ietf.org
    Subject:     [mpls]= Mixing=20 ICC and Global-IDs in MPLS-TP Identifiers?

    All -

    Many of the comments received from the ITU = on=20 draft-ietf-mpls-tp-identifiers-04 have to do with the Global and ICC=20 identifiers.

    The identifiers for Tunnel, LSP, PW, and MEG include= =20 fields to identify each end of an LSP.  Currently the draft allows a= =20 Tunnel, LSP, PW, or MEG to use either the Global-ID for both ends or or t= he=20 ICC for both ends.  Mixed use is not permitted.

    The ITU liais= on=20 requests that we allow mixed use.

    The authors of the draft are ver= y=20 reluctant to do this.  

    1.=  =20          Obtaining an AS = Number=20 (from which the Global-ID is derived) is a fairly trivial procedure.=20  Many organizations if not most already have AS Numbers.
    2.            Such an addition will add numerous object formats, and test case= s.=20
    3.        The extent inter-provider MPLS-TP is as yet unkno= wn.=20  If mixed modes of ICC and Global-ID identification is required, the= y can=20 be added later.
    4.     &= nbsp;=20      For signaled connections, ther= e is no=20 plan to allow routing based on either the Global-ID or ICC.  That wo= uld=20 be a radical change to how IP works.  However for IP routing to work= (in=20 order to forward the signaling messages), the providers involved will nee= d to=20 run BGP and have AS numbers. =

    We are looking for input/consensus from t= he=20 WG.
    --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B0732D0ABEUSAACMS0701e_-- From sriganeshkini@gmail.com Thu Apr 28 15:30:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7190BE070A for ; Thu, 28 Apr 2011 15:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axdtb8gVWldW for ; Thu, 28 Apr 2011 15:29:59 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5B53E06A6 for ; Thu, 28 Apr 2011 15:29:59 -0700 (PDT) Received: by qyk29 with SMTP id 29so2729981qyk.10 for ; Thu, 28 Apr 2011 15:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=OzMwYvnR+KWGSNCZ/aD2QrApEntPfhqMqjNGHieBTx8=; b=L+9NabxYDCh54OrwWVXlNeeqx5nI463xVYB6ZvMjSnzxhmPEM0jOoNAuUbSGRHrrVy q9tc4A97WuxuURFoFcvAUFtWNTBvJBoRQAAn4xSYR5Gd98LNVBjQsQQolc6lQjzvfkG9 +zW9Z6vYWpKjS8oUlyYS+su1gXtNgr7/mnrSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; b=OcH/RDX+NXrp8SuXOGQxHfB3skpPTcZOEKAXV7QnfVM9tfROppXRdSFaDRTfXU+I82 1Mr5TJx6iOieUTUhWXOPHmWT1tK8ZL50s0lsEmHFpEoUSzTB4W4w1DTUxqpQz6Qs2ZI8 YCdJ6JKWJJin25buc0iWtdL9vHeeD3yzrxfy0= Received: by 10.229.190.133 with SMTP id di5mr2620378qcb.286.1304029799182; Thu, 28 Apr 2011 15:29:59 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.75.13 with HTTP; Thu, 28 Apr 2011 15:29:29 -0700 (PDT) From: Sriganesh Kini Date: Thu, 28 Apr 2011 15:29:29 -0700 X-Google-Sender-Auth: trHh_CjPM6KxV9D9UhXWzF2OJPw Message-ID: To: Ross Callon Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" Subject: [mpls] Comments - Re: poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 22:30:00 -0000 Hi Kireeti and other authors, Need a couple clarification 1. This draft seems to apply to the TE LSP (or transport LSP) for the adaptation in figure 3.4.5 of RFC 5921 since that section apparently applies to MPLS in addition to MPLS-TP. Can you confirm that. 2. In that case, when the client layer is MPLS enabled where is the EL in the label stack relative to the labels from the client? Thanks On Mon, Apr 18, 2011 at 8:15 AM, Ross Callon wrote: > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- - Sri From jdrake@juniper.net Thu Apr 28 15:40:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D29E0712 for ; Thu, 28 Apr 2011 15:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1PoQ8ieIOiq for ; Thu, 28 Apr 2011 15:40:31 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3A45FE070B for ; Thu, 28 Apr 2011 15:40:31 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTbns3AhwJ6x/0cEmAXuXOEzZNU0tiwyl@postini.com; Thu, 28 Apr 2011 15:40:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 28 Apr 2011 15:38:11 -0700 From: John E Drake To: Sriganesh Kini , Ross Callon Date: Thu, 28 Apr 2011 15:38:10 -0700 Thread-Topic: [mpls] Comments - Re: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: AcwF89SmyjLAUgdgS4umm1OsQ3+1BAAAIQlw Message-ID: <5E893DB832F57341992548CDBB333163A0978A0555@EMBX01-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 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments - Re: poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 22:40:32 -0000 Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Sriganesh Kini > Sent: Thursday, April 28, 2011 3:29 PM > To: Ross Callon > Cc: mpls@ietf.org > Subject: [mpls] Comments - Re: poll on draft-kompella-mpls-entropy- > label as MPLS WG document >=20 > Hi Kireeti and other authors, >=20 > Need a couple clarification > 1. This draft seems to apply to the TE LSP (or transport LSP) for the > adaptation in figure 3.4.5 of RFC 5921 since that section apparently > applies to MPLS in addition to MPLS-TP. Can you confirm that. JD: You mean figure 7|8 in section 3.4.5? But yes, entropy labels apply t= o Packet Transport Service. > 2. In that case, when the client layer is MPLS enabled where is the EL > in the label stack relative to the labels from the client? JD: It's always bottom of stack, so if it is present, it was placed there = by the client. >=20 > Thanks >=20 > On Mon, Apr 18, 2011 at 8:15 AM, Ross Callon > wrote: > > All, > > > > this is to start a two week working group poll on whether to make > > draft-kompella-mpls-entropy-label an mpls wg document. > > > > Please send your comments to the mpls@ietf.org mailing list. > > > > The poll ends on May 3rd. > > > > thanks Ross (as WG co-chair) > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 >=20 > -- > - Sri > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Fri Apr 29 07:13:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09133E06BF for ; Fri, 29 Apr 2011 07:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj1wI-ZjVA1z for ; Fri, 29 Apr 2011 07:13:27 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC0A5E0659 for ; Fri, 29 Apr 2011 07:13:27 -0700 (PDT) Received: by qwc23 with SMTP id 23so2323755qwc.31 for ; Fri, 29 Apr 2011 07:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QDxx8S5/JvyR2/tBJeM2f0KgqIpgHevhfz2tuoN/FC0=; b=IKwGVNkwL6jnZVoKNPQFYB2pwk/8Pk7a/ais0LCyM2UZQb5edVHUH+6B+3+vSLzFJH Tj70fPEU45HscTF4HREhXKnzfzZZ0CUoQ/j6bUPZEVo09QRb7m1xal6kfPnAwt6TOwdr ti/XZb4+huveSWHeyYxBnOYeB4zfuIUHMBPfA= 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 :cc:content-type; b=XDzlXQ9R8a8fZtZKDuY3ZU1nVDR/N5ygpKND6aJwhVpMl0eeXmTlA5dxu7ho857JDU UIkG0k3IWGJGeSF2wToMUeK9j9VF/oNiC2mSNKpzqN+gC8y8wI7hN5pIdr6U2kz6PEsy 7nut0ED6IcCf1c6F8rOOLOvIztDnnUplz+FQ0= Received: by 10.229.24.19 with SMTP id t19mr3900428qcb.167.1304086407092; Fri, 29 Apr 2011 07:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.227.1 with HTTP; Fri, 29 Apr 2011 07:13:06 -0700 (PDT) In-Reply-To: <07F7D7DED63154409F13298786A2ADC903E41EBC@EXRAD5.ad.rad.co.il> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> <07F7D7DED63154409F13298786A2ADC903E41EBC@EXRAD5.ad.rad.co.il> From: "Andrew G. Malis" Date: Fri, 29 Apr 2011 10:13:06 -0400 Message-ID: To: Yaakov Stein Content-Type: text/plain; charset=ISO-8859-1 Cc: "rcallon@juniper.net" , "mpls@ietf.org" Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:13:32 -0000 While I agree with Yaakov's security concerns (and would like to see, at the very least, the "SHOULD NOT" in section 8 replaced by "MUST NOT"), I see no reason why improving the security mechanisms cannot be done as a working group activity, and thus support making this a working group draft. Cheers, Andy On Wed, Apr 27, 2011 at 8:49 AM, Yaakov Stein wrote: > Loa and all > > For reasons I specified in my previous email on this draft, > I very strongly oppose making this draft a WG draft > until some plausible security mechanism is specified. > > As it stands, this draft is a serious danger not only to the access networks to which it is extending MPLS, > but to the core network to which these access networks attach, and conceivably to the public Internet. > > Adopting this draft with a security considerations section containing only ridiculous statements and TBDs > is tantamount to saying that the IETF either doesn't understand or does not care about basic network security. > > Y(J)S > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa@pi.nu > Sent: Wednesday, April 27, 2011 05:06 > To: mpls@ietf.org > Cc: rcallon@juniper.net > Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 > > > Working Group, > > this is to start a two week poll on making > > draft-leymann-mpls-seamless-mpls-03 > > an mpls working group document. > > If you support the document becoming a working group document > please respond to this poll with "yes/support" > > If you do not support the document becoming a working group > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are > not supporting the document. > > If you have technical comments or in any other way want to > discuss the document, please send these comments to the mpls > working group mailing list, but with another subject than what > is on this mail. > > The poll ends May 10th. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From gregory.mirsky@ericsson.com Fri Apr 29 16:39:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765ECE06DC for ; Fri, 29 Apr 2011 16:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buD1QTWAs3Qw for ; Fri, 29 Apr 2011 16:39:01 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7A0E06AF for ; Fri, 29 Apr 2011 16:38:58 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3TNcuO3016808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 29 Apr 2011 18:38:57 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.126]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 29 Apr 2011 19:38:56 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Date: Fri, 29 Apr 2011 19:38:55 -0400 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwGxl1rD/TtgmT2QmeT/8RrHg5rrQAAB6hg 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_FE60A4E52763E84B935532D7D9294FF1218E44C1DEEUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 23:39:02 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1DEEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support Regards, Greg ________________________________ From: > Date: Tue, Apr 26, 2011 at 7:06 PM Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 To: mpls@ietf.org Cc: rcallon@juniper.net Working Group, this is to start a two week poll on making draft-leymann-mpls-seamless-mpls-03 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 10th. /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1DEEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    yes/support
     
    Regards,
    Greg

    From: <loa@pi.nu>
    Date: Tue, Apr 26, 20= 11 at=20 7:06 PM
    Subject: [mpls] poll on draft-leymann-mpls-seamless-mpls-03
    T= o: mpls@ietf.org
    Cc: rcallon@juniper.net



    = Working=20 Group,

    this is to start a two week poll on=20 making

    draft-leymann-mpls-seamless-mpls-03

    an mpls working gr= oup=20 document.

    If you support the document becoming a working group=20 document
    please respond to this poll with "yes/support"

    If you do= not=20 support the document becoming a working group
    document please respond to= this=20 poll with "no/do not support"
    and at the same time give the technical re= asons=20 why you are
    not supporting the document.

    If you have technical=20 comments or in any other way want to
    discuss the document, please send t= hese=20 comments to the mpls
    working group mailing list, but with another subjec= t=20 than what
    is on this mail.

    The poll ends May=20 10th.

    /Loa


    ______________________________________________= _
    mpls=20 mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls
    --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1DEEUSAACMS0715e_-- From gregory.mirsky@ericsson.com Fri Apr 29 16:42:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8DCE06AD for ; Fri, 29 Apr 2011 16:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdjBtpqlZOO5 for ; Fri, 29 Apr 2011 16:42:55 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8876CE0698 for ; Fri, 29 Apr 2011 16:42:55 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3TNgs4U016906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 29 Apr 2011 18:42:54 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.126]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 29 Apr 2011 19:42:53 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Date: Fri, 29 Apr 2011 19:42:52 -0400 Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: AcwGxvjQrM4gjgBkQ0myeEjqtSgF8gAABCQQ 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_FE60A4E52763E84B935532D7D9294FF1218E44C1DFEUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 23:42:56 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1DFEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support Regards, Greg ________________________________ > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf > Of Ross Callon > Sent: Monday, April 18, 2011 11:16 PM > To: mpls@ietf.org > Subject: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG > document > > All, > > this is to start a two week working group poll on whether to make > draft-kompella-mpls-entropy-label an mpls wg document. > > Please send your comments to the mpls@ietf.org mail= ing list. > > The poll ends on May 3rd. > > thanks Ross (as WG co-chair) > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1DFEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    yes/support
     
        Regards,
          &= nbsp;=20 Greg

    > -----Original=20 Message-----
    > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf<= BR>>=20 Of Ross Callon
    > Sent: Monday, April 18, 2011 11:16 PM
    > To: mpls@ietf.org
    > Subject: [mpls] pol= l on=20 draft-kompella-mpls-entropy-label as MPLS WG
    > document
    >
    &g= t;=20 All,
    >
    > this is to start a two week working group poll on whet= her=20 to make
    > draft-kompella-mpls-entropy-label an mpls wg=20 document.
    >
    > Please send your comments to the mpls@ietf.org mailing list.
    >
    &g= t; The=20 poll ends on May 3rd.
    >
    > thanks Ross (as WG co-chair)
    >= =20 _______________________________________________
    > mpls mailing=20 list
    > mpls@ietf.org
    > https://www.ietf.org/mailman/listinfo/mpls
    _________= ______________________________________
    --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1DFEUSAACMS0715e_-- From gregory.mirsky@ericsson.com Fri Apr 29 16:46:54 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DC8E07B8 for ; Fri, 29 Apr 2011 16:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5zWfNBrPQsr for ; Fri, 29 Apr 2011 16:46:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id DC9ADE0698 for ; Fri, 29 Apr 2011 16:46:53 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3TNkqeS020066 for ; Fri, 29 Apr 2011 18:46:53 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.126]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 29 Apr 2011 19:46:46 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Date: Fri, 29 Apr 2011 19:46:45 -0400 Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana Thread-Index: AcwGx2T2OklxW7RSTUishsj7AfJPZAAACj/A 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_FE60A4E52763E84B935532D7D9294FF1218E44C1E3EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-asati-pignataro-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 23:46:54 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1E3EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support Regards, Greg ________________________________ > Working Group, > > this is to start a two week poll on making > > draft-asati-pignataro-mpls-ldp-iana-01 > > an mpls working group document. > > If you support the document becoming a working group document please > respond to this poll with "yes/support" > > If you do not support the document becoming a working group document > please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are not > supporting the document. > > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing > list, but with another subject than what is on this mail. > > The poll ends May 8th. > > /Loa --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1E3EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    yes/support
     
        Regards,
           =20 Greg
    =
    > Working Group,
    >
    > this is to start a two week poll on=20 making
    >
    > draft-asati-pignataro-mpls-ldp-iana-01
    >
    &g= t; an=20 mpls working group document.
    >
    > If you support the document=20 becoming a working group document please
    > respond to this poll with= =20 "yes/support"
    >
    > If you do not support the document becoming a= =20 working group document
    > please respond to this poll with "no/do not= =20 support"
    > and at the same time give the technical reasons why you ar= e=20 not
    > supporting the document.
    >
    > If you have technical= =20 comments or in any other way want to discuss the
    > document, please s= end=20 these comments to the mpls working group mailing
    > list, but with ano= ther=20 subject than what is on this mail.
    >
    > The poll ends May=20 8th.
    >
    > /Loa


    --_000_FE60A4E52763E84B935532D7D9294FF1218E44C1E3EUSAACMS0715e_-- From loa@pi.nu Sat Apr 30 10:56:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2056FE06B2 for ; Sat, 30 Apr 2011 10:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gf4SXcK6T2jL for ; Sat, 30 Apr 2011 10:56:02 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDA0E06A7 for ; Sat, 30 Apr 2011 10:56:02 -0700 (PDT) Received: from [172.17.113.226] (207.47.24.2.static.nextweb.net [207.47.24.2]) (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 7A6862A8001; Sat, 30 Apr 2011 19:55:59 +0200 (CEST) Message-ID: <4DBC4D2C.9090901@pi.nu> Date: Sat, 30 Apr 2011 10:55:56 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 17:56:03 -0000 Working Group, this is to start a two week poll on making draft-asati-pignataro-mpls-ldp-gtsm-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. The poll ends May 14th. /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 Adrian.Farrel@huawei.com Sat Apr 30 15:24:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD1FE06D0 for ; Sat, 30 Apr 2011 15:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.665 X-Spam-Level: X-Spam-Status: No, score=-105.665 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7rIdgpatUbS for ; Sat, 30 Apr 2011 15:24:53 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id DE655E062A for ; Sat, 30 Apr 2011 15:24:52 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKH006M3KXGD4@usaga03-in.huawei.com> for mpls@ietf.org; Sat, 30 Apr 2011 17:24:52 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKH00IOOKXEAX@usaga03-in.huawei.com> for mpls@ietf.org; Sat, 30 Apr 2011 17:24:52 -0500 (CDT) Date: Sat, 30 Apr 2011 23:24:50 +0100 From: Adrian Farrel To: draft-ietf-mpls-mp-ldp-reqs@tools.ietf.org Message-id: <038501cc0785$6ca37c00$45ea7400$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcwHhWUrtDZOT/mGSDqbDuFO7FcPmw== Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-mp-ldp-reqs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 22:24:54 -0000 Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is to catch any nits or issues before the document goes forward to IETF last call and IESG review. By getting these issues out at this stage we can hope for a higher quality review and a smoother passage through the process. Thank you for a good analysis of the requirements for P2MP LDP. Most of my issues are either relatively minor editorial changes or take the form of questions. A few points, however, may take a little bit of new textto resolve. All of my comments (especially the questions) are up for discussion, and you should not feel rail-roaded into making changes. But I do think my comments need to be addressed before the draft moves forward, and I would like to see a revised I-D to tidy up the editorial points. I have moved the draft into "AD-review:Revised-ID-needed" state in the datatracker, and I look forward to seeing the new revision which I can put forward for IETF last call. Thanks, Adrian --- Having 7 authors listed on the front page is somewhat unusual and is also likely to mean that the document is slow to progress through the later stages of publication. Would it be possible to consider moving everyone except for the editor off the front page? You will still all be listed as authors at the end of the document. --- You need to add a couple of acronyms to Section 1.1 LSP LSR MP2P --- Section 2 and have already deployed LDP for P2P traffic s/and/and who/ --- Section 3.1 seems to replicate a deal of text from Section 2. --- Section 5.1 Only one copy of a packet MUST be sent on a given link of a P2MP LSP. I think you mean... Exactly one copy of a packet MUST be sent on a given link of a P2MP LSP. ...or better... More than one copy of a packet MUST NOT be sent on a given link of a P2MP LSP. But really, the ambiguity is caused by the passive voice. So... An LSR MUST NOT send more than one copy of a packet on any given link of a P2MP LSP. --- Section 5.2 As such, a new LDP FEC that is suitable for P2MP forwarding MUST be specified. You are prejudging the solution by stating that existing FECs are not suitable. How about: If existing FECs cannot be used for this purpose, a new LDP FEC that is suitable for P2MP forwarding MUST be specified. --- Section 5.3 I have no issues with the assumption of bidirectional links, but maybe you should state the assumption? OLD It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path to the Ingress LSR so as to setup an MPLS shortest path tree. NEW It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path to the Ingress LSR so as to setup an MPLS shortest path tree assuming all links are bidirectional. END But, are you sure you want shortest path trees? It is certainly the easiest solution to build using the mechanism recommended, but I wonder whether the requirement here is being driven by the solution you have in mind, rather than being the real requirement. Anyway, you said earlier in the document that an objective was to optimise resource usage in network, and shortest path trees don't guarantee that. So maybe you need to go back to that base requirement and soften it to say "make better use of network resources." --- Section 5.4 I think you need to add that the mechanisms by which an ingress can discover the identities of the egresses attached to the P2MP LSP are also out of scope. --- Section 5.4 The P2MP LDP mechanism MUST allow the dynamic addition and removal of leaves to and from a P2MP LSP, without any restriction (provided there is network connectivity). I agree that the mechanism must allow this. One of the issues we faced with P2MP RSVP-TE was a belief that there might be limits to the branching capabilities in some nodes. This is potentially both a physical limit for the node, and a practical limit for the LSP (if round-robin replication is needed). So the mechanism needs to allow a node to say "I can't be a branch for any more spurs of this tree." The solution to this situation might be in direct conflict to your requirement in 5.1 about duplicate packets on a "link". Again, see the way we got around this in P2MP RSVP-TE. --- Section 5.7 This may rely on extensions to the LDP Loop detection mechanism defined in [RFC5036]. A loop detection mechanism may require recording the set of LSRs traversed on the P2MP Tree. The P2MP loop avoidance mechanism MUST NOT impact the scalability of the P2MP LDP solution. I think both "may" should be "MAY" --- Section 5.8 Given that P2MP LDP routing should rely on the RIB, the achievement of the following requirements also implies the underlying routing protocols (IGP, etc.). Something wrong with this sentence around "also implies". --- Section 5.8.1 A mechanism MUST be defined to prevent constant P2MP LSP teardown and rebuild which may be caused by the instability of a specific link/ node in the network. This will rely on IGP dampening but may be completed by specific dampening at the LDP level. Again, this is driving the solution a bit hard. If you really want to say "will rely" then you should convert it to "MUST rely". s/may/MAY/ in the last subclause. --- Section 5.9 I am not sure why you limit this case to a LAN. Would you consider replacing "LAN" with "multi-access network"? Needs a little rewording around "LAN interface" but that looks easy enough. --- Section 5.16. A solution MUST avoid single points of failures provided there is enough network connectivity. What does this mean? It shows up again in section 6.1. --- Section 5.18 In order to allow for a smooth migration, the P2MP LDP mechanism SHOULD offer as much backward compatibility as possible. In particular, the solution SHOULD allow the setup of a P2MP LSP along non-Branch Transit LSRs that do not support P2MP LDP extensions. Hooray for this, but note that if a legacy LSR is at a topological branch, it will result in duplicate packets being sent by an upstream LSR on some links that the P2MP LSP traverses. This would be in direct conflict with your requirement in 5.1 about duplicate packets on a "link". Maybe you need to redefine a "link of a P2MP LSP"? --- Section 6. For traffic delivery between a group of N Leaf LSRs which are acting indifferently as Ingress or Egress LSRs, it may be useful to setup a shared tree connecting all these LSRs, instead of having N P2MP LSPs. "acting indifferently" has some unfortunate overtones! How about... For traffic delivery between a group of N LSRs that may be ingress and egress LSRs on different P2MP flows, it may be useful to setup a shared tree connecting all these LSRs, instead of having N P2MP LSPs. Or did you mean For traffic delivery between a group of N LSRs that all act as ingress and egress LSRs on different P2MP flows, it may be useful to setup a shared tree connecting all these LSRs, instead of having N P2MP LSPs. This shows up in 6.1 as well. --- Section 6.1 Requirements for P2MP LSPs, set forth in section 6, apply equally to MP2MP LSPs. Particular attention should be given on the below requirements: s/6/5/ --- Section 6.1 o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that may trigger exponential growth of traffic. Note that this requirement is more challenging with MP2MP LSPs as a LSR can receive traffic for a given LSP on multiple interfaces. s/can receive/can legitimately receive/ --- Section 6.1 Are you sure that the following two requirements are not in conflict: o It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a specific LSR called root LSR; o The solution SHOULD avoid that all traffic between any pair of leaves is traversing a root LSR, and SHOULD as much as possible minimize the distance between two leaves (similarly to PIM-Bidir trees); --- 7.1. Performances s/Performances/Performance/ --- Section 7.1 I thought that optimality of the use of network resources was a criterion --- Section 8 More important than commenting on the security implications of *this* document is to set security requirements for the P2MP solution. This should include the normal control plane considerations, but should also examine the risks of a leaf adding itself to a tree to which it does not belong. I think there may be some specific additional requirements on the solution in this regard. --- Section 10 We don't normally name people's companies in the Acknowledgements section. One reason (as in this case) is that some of them change jobs. --- Section 11 According to the use in Section 5.1, RFC 4461 is a normative reference.
    Eric Gray <eric.gray@ericsson.com&g= t;=20
    Sent by: mpls-bounces@ietf.org

    27/04/2011 12:11 PM

    		 =20


    To
    		 George Swallow <swallow@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
    cc
    Subject=
    		Re: [mpls] Mixing ICC and Globa= l-IDs=20 in MPLS-TP Identifiers?

    <= FONT=20 face=3D"Times New Roman" size=3D3>